From simple-admin@mailman.dynamicsoft.com Thu Aug 1 05:03:08 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10945 for ; Thu, 1 Aug 2002 05:03:08 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7193Qgb015962 for ; Thu, 1 Aug 2002 05:03:26 -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 FAA14143 for ; Thu, 1 Aug 2002 05:03:45 -0400 (EDT) Date: Thu, 1 Aug 2002 05:03:45 -0400 (EDT) Message-Id: <200208010903.FAA14143@mailman.dynamicsoft.com> Subject: mailman.dynamicsoft.com mailing list memberships reminder From: mailman-owner@mailman.dynamicsoft.com To: simple-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk This is a reminder, sent out once a month, about your mailman.dynamicsoft.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, simple-request@mailman.dynamicsoft.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@mailman.dynamicsoft.com. Thanks! Passwords for simple-archive@lists.ietf.org: List Password // URL ---- -------- simple@mailman.dynamicsoft.com ifheto http://mailman.dynamicsoft.com/mailman/options/simple/simple-archive%40lists.ietf.org From simple-admin@mailman.dynamicsoft.com Fri Aug 2 10:18:07 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21070 for ; Fri, 2 Aug 2002 10:18:07 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g72EHngb021970; Fri, 2 Aug 2002 10:17:49 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20738; Fri, 2 Aug 2002 10:18:03 -0400 (EDT) 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) Message-Id: <1028297786.2593.1.camel@dhcp151.dfw.dynamicsoft.com> Mime-Version: 1.0 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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: 02 Aug 2002 09:16:26 -0500 Content-Transfer-Encoding: 7bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Aug 5 08:54:28 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10703 for ; Mon, 5 Aug 2002 08:54:28 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g75CrroJ000810; Mon, 5 Aug 2002 08:53:53 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00977; Mon, 5 Aug 2002 08:54:04 -0400 (EDT) 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> To: sip-implementors@cs.columbia.edu, simple@mailman.dynamicsoft.com X-Mailer: VM 7.04 under Emacs 21.2.1 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: Date: Mon, 5 Aug 2002 08:45:52 -0400 Content-Transfer-Encoding: 7bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Aug 5 09:13:39 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11657 for ; Mon, 5 Aug 2002 09:13:39 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g75DDeoJ000926; Mon, 5 Aug 2002 09:13:40 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01058; Mon, 5 Aug 2002 09:14:02 -0400 (EDT) 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 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 5 Aug 2002 18:40:25 +0530 Content-Transfer-Encoding: 7bit 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 > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Aug 13 08:23:03 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09406 for ; Tue, 13 Aug 2002 08:23:03 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7DCMp2e004294; Tue, 13 Aug 2002 08:22:51 -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 IAA04731; Tue, 13 Aug 2002 08:23:04 -0400 (EDT) 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" Message-ID: 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-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: Date: Tue, 13 Aug 2002 15:22:55 +0300 Content-Transfer-Encoding: 8bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Aug 13 11:42:33 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16971 for ; Tue, 13 Aug 2002 11:42:33 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7DFdj2e005099; Tue, 13 Aug 2002 11:39:45 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05312; Tue, 13 Aug 2002 11:40:03 -0400 (EDT) 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 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 13 Aug 2002 08:39:35 -0700 Content-Transfer-Encoding: 7bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Aug 14 03:14:47 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29017 for ; Wed, 14 Aug 2002 03:14:47 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7E7Ej2e008414; Wed, 14 Aug 2002 03:14:45 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08155; Wed, 14 Aug 2002 03:15:04 -0400 (EDT) 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> 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 14 Aug 2002 03:14:07 -0400 Content-Transfer-Encoding: 7bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Aug 14 09:18:09 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08217 for ; Wed, 14 Aug 2002 09:18:08 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7EDHk2e009306; Wed, 14 Aug 2002 09:17:46 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09295; Wed, 14 Aug 2002 09:18:06 -0400 (EDT) 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 Message-ID: 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-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: Date: Wed, 14 Aug 2002 16:17:08 +0300 Content-Transfer-Encoding: 8bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Aug 16 17:39:04 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01811 for ; Fri, 16 Aug 2002 17:39:04 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7GLUl2e019297; Fri, 16 Aug 2002 17:30:47 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18521; Fri, 16 Aug 2002 17:31:03 -0400 (EDT) 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 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 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: Date: Fri, 16 Aug 2002 14:29:50 -0700 Content-Transfer-Encoding: 7bit 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 From simple-admin@mailman.dynamicsoft.com Fri Aug 16 18:18:27 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02484 for ; Fri, 16 Aug 2002 18:18:27 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7GMAZ2e019483; Fri, 16 Aug 2002 18:10:36 -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 SAA18672; Fri, 16 Aug 2002 18:11:02 -0400 (EDT) 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 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 16 Aug 2002 15:10:01 -0700 (PDT) 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 simple-admin@mailman.dynamicsoft.com Mon Aug 19 11:46:18 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06523 for ; Mon, 19 Aug 2002 11:46:18 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7JFjj2N001261; Mon, 19 Aug 2002 11:45:46 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01446; Mon, 19 Aug 2002 11:46:05 -0400 (EDT) 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: 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: 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: Date: Thu, 15 Aug 2002 16:27:59 -0700 Content-Transfer-Encoding: 7bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Aug 20 14:11:39 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20954 for ; Tue, 20 Aug 2002 14:11:38 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7KIAl2N006306; Tue, 20 Aug 2002 14:10:47 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06003; Tue, 20 Aug 2002 14:11:08 -0400 (EDT) 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> 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 20 Aug 2002 14:10:33 -0400 Content-Transfer-Encoding: 7bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Aug 22 03:21:37 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17288 for ; Thu, 22 Aug 2002 03:21:37 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7M7Li2N012474; Thu, 22 Aug 2002 03:21: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 DAA12337; Thu, 22 Aug 2002 03:22:03 -0400 (EDT) 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 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 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: Date: Thu, 22 Aug 2002 08:16:50 +0100 This is a MIME-encapsulated message --==_07165003100229@pd.gordano.com==_ Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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-Disposition: attachment; filename="Griff James.vcf" Content-Transfer-Encoding: quoted-printable 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==_-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Aug 22 10:37:43 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27418 for ; Thu, 22 Aug 2002 10:37:43 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7MEbc2N013481; Thu, 22 Aug 2002 10:37:38 -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 KAA13582; Thu, 22 Aug 2002 10:38:03 -0400 (EDT) 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 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 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: Date: Wed, 21 Aug 2002 15:46:35 +0100 This is a MIME-encapsulated message --==_14463528100191@pd.gordano.com==_ Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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-Disposition: attachment; filename="Griff James.vcf" Content-Transfer-Encoding: quoted-printable 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==_-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Aug 23 07:53:39 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04221 for ; Fri, 23 Aug 2002 07:53:39 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7NBrk2N016806; Fri, 23 Aug 2002 07:53:46 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17004; Fri, 23 Aug 2002 07:54:05 -0400 (EDT) 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 Message-ID: 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-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: Date: Fri, 23 Aug 2002 14:53:42 +0300 Content-Transfer-Encoding: 8bit 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 > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sun Aug 25 19:12:42 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16619 for ; Sun, 25 Aug 2002 19:12:41 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7PNCo2N022054; Sun, 25 Aug 2002 19:12:50 -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 TAA26827; Sun, 25 Aug 2002 19:13:14 -0400 (EDT) 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: 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 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: Date: Mon, 26 Aug 2002 01:12:06 +0200 I will be out of the office starting August 23, 2002 and will not return until September 9, 2002. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Aug 26 13:50:06 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16031 for ; Mon, 26 Aug 2002 13:50:04 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7QHnfQm001934; Mon, 26 Aug 2002 13:49:41 -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 NAA01856; Mon, 26 Aug 2002 13:50:06 -0400 (EDT) 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 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> Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 26 Aug 2002 12:48:48 -0500 Content-Transfer-Encoding: 7bit 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 > > > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Aug 28 01:41:27 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24559 for ; Wed, 28 Aug 2002 01:41:26 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7S5ffQm008297; Wed, 28 Aug 2002 01:41:41 -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 BAA08012; Wed, 28 Aug 2002 01:42:04 -0400 (EDT) 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> 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 27 Aug 2002 22:27:33 -0400 Content-Transfer-Encoding: 7bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Aug 28 07:19:23 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23763 for ; Wed, 28 Aug 2002 07:19:22 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7SBJZQm008938; Wed, 28 Aug 2002 07:19:36 -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 HAA08940; Wed, 28 Aug 2002 07:20:04 -0400 (EDT) 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> 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 28 Aug 2002 14:20:13 +0300 (EET DST) Content-Transfer-Encoding: 8bit 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 From simple-admin@mailman.dynamicsoft.com Thu Aug 29 11:05:36 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25630 for ; Thu, 29 Aug 2002 11:05:36 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7TF5dQm014337; Thu, 29 Aug 2002 11:05:40 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13617; Thu, 29 Aug 2002 11:06:05 -0400 (EDT) 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: ; 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: Date: Tue, 27 Aug 2002 14:44:44 -0400 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. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Aug 30 04:37:20 2002 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07606 for ; Fri, 30 Aug 2002 04:37:20 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g7U8baQm017632; Fri, 30 Aug 2002 04:37:36 -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 EAA16566; Fri, 30 Aug 2002 04:38:03 -0400 (EDT) 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" Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9010FE3F7@esebe013.ntc.nokia.com> Thread-Topic: PUBLISH and expires Thread-Index: AcJQAHzXqaldqT4CQa6TSG/KpPYu8A== To: X-OriginalArrivalTime: 30 Aug 2002 08:37:35.0433 (UTC) FILETIME=[7D6D4390:01C25000] 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: Date: Fri, 30 Aug 2002 11:37:35 +0300 Content-Transfer-Encoding: 8bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple