From simple-admin@mailman.dynamicsoft.com Wed May 1 05:04:05 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 FAA10431 for ; Wed, 1 May 2002 05:04: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 g41916Uo018357 for ; Wed, 1 May 2002 05:01:06 -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 FAA09849 for ; Wed, 1 May 2002 05:04:40 -0400 (EDT) Date: Wed, 1 May 2002 05:04:40 -0400 (EDT) Message-Id: <200205010904.FAA09849@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 Wed May 1 07:42:38 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 HAA21986 for ; Wed, 1 May 2002 07:42: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 g41BboUo019780; Wed, 1 May 2002 07:37: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 HAA11772; Wed, 1 May 2002 07:40:03 -0400 (EDT) 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 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 1 May 2002 12:37:38 +0100 Content-Transfer-Encoding: 7bit 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. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed May 1 15:30:15 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 PAA22152 for ; Wed, 1 May 2002 15:30:14 -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 g41JPtUo023929; Wed, 1 May 2002 15:25:55 -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 PAA13057; Wed, 1 May 2002 15:28:04 -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 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> 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 01 May 2002 15:24:59 -0400 Content-Transfer-Encoding: 7bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu May 2 22:02:55 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 WAA22003 for ; Thu, 2 May 2002 22:02:55 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g431wSUo004334; Thu, 2 May 2002 21:58:29 -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 WAA18030; Thu, 2 May 2002 22:01:59 -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 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> 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 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: Date: Thu, 02 May 2002 21:59:27 -0400 Content-Transfer-Encoding: 7bit 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 simple-admin@mailman.dynamicsoft.com Sun May 5 23:12:55 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 XAA28055 for ; Sun, 5 May 2002 23:12:54 -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 g4638dUo015473; Sun, 5 May 2002 23:08:39 -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 XAA29758; Sun, 5 May 2002 23:12:08 -0400 (EDT) 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 ? Message-ID: 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-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: Date: Mon, 29 Apr 2002 13:56:59 -0700 Content-Transfer-Encoding: 8bit > > 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sun May 5 23:14:57 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 XAA28071 for ; Sun, 5 May 2002 23:14:57 -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 g463AeUo015508; Sun, 5 May 2002 23:10: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 XAA29778; Sun, 5 May 2002 23:14:17 -0400 (EDT) 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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 2 May 2002 10:02:47 -0700 > 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 simple-admin@mailman.dynamicsoft.com Sun May 5 23:15: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 XAA28086 for ; Sun, 5 May 2002 23:15: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 g463AkUo015524; Sun, 5 May 2002 23:10: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 XAA29794; Sun, 5 May 2002 23:14:23 -0400 (EDT) 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 Message-ID: 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-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: Date: Fri, 3 May 2002 10:16:13 -0700 Content-Transfer-Encoding: 8bit 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 From simple-admin@mailman.dynamicsoft.com Mon May 6 07:27: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 HAA13093 for ; Mon, 6 May 2002 07:27:05 -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 g46BNTu2000654; Mon, 6 May 2002 07:23:29 -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 HAA00746; Mon, 6 May 2002 07:27:03 -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 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 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: Date: Mon, 06 May 2002 07:25:33 -0400 --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-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon May 6 11:16: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 LAA23382 for ; Mon, 6 May 2002 11:16: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 g46FCVu2002737; Mon, 6 May 2002 11:12:31 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01377; Mon, 6 May 2002 11:16:04 -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 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> 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 06 May 2002 11:13:16 -0400 Content-Transfer-Encoding: 7bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon May 6 11:45:00 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 LAA24257 for ; Mon, 6 May 2002 11:44:59 -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 g46FeTu2003146; Mon, 6 May 2002 11:40:29 -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 LAA01481; Mon, 6 May 2002 11:44:02 -0400 (EDT) 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 Message-ID: <278B6B0D76698D45BBA872CD23DD496A0A4332@daebe004.NOE.Nokia.com> 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-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: Date: Mon, 6 May 2002 10:41:11 -0500 Content-Transfer-Encoding: 8bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon May 6 20:04:32 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 UAA11662 for ; Mon, 6 May 2002 20:04:32 -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 g4700Uu2007777; Mon, 6 May 2002 20:00:30 -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 UAA02910; Mon, 6 May 2002 20:04:03 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id 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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" 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: Date: Mon, 6 May 2002 20:01:29 -0400 Content-Transfer-Encoding: 8bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon May 6 20:24:11 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 UAA12007 for ; Mon, 6 May 2002 20:24:11 -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 g470KRu2007940; Mon, 6 May 2002 20:20:27 -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 UAA02995; Mon, 6 May 2002 20:24:02 -0400 (EDT) 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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 6 May 2002 17:20:44 -0700 > 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 > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue May 7 09:05:13 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 JAA06140 for ; Tue, 7 May 2002 09:05:12 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g47D0du2010316; Tue, 7 May 2002 09:00:39 -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 JAA05019; Tue, 7 May 2002 09:04:08 -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 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> 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 07 May 2002 09:01:23 -0400 Content-Transfer-Encoding: 7bit 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 > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue May 7 13:33:34 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 NAA17347 for ; Tue, 7 May 2002 13:33:34 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g47HTVu2014050; Tue, 7 May 2002 13:29:31 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05863; Tue, 7 May 2002 13:33:03 -0400 (EDT) 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 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> Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 7 May 2002 18:31:04 +0100 Content-Transfer-Encoding: 7bit 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. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue May 7 14:45:53 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 OAA20028 for ; Tue, 7 May 2002 14:45:53 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g47IgRu2015075; Tue, 7 May 2002 14:42:27 -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 OAA06089; Tue, 7 May 2002 14:46: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 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> 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 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: Date: Tue, 07 May 2002 14:44:44 -0400 Content-Transfer-Encoding: 7bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue May 7 15:22:26 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 PAA21216 for ; Tue, 7 May 2002 15:22: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 g47JITu2015608; Tue, 7 May 2002 15:18:30 -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 PAA06213; Tue, 7 May 2002 15:22:05 -0400 (EDT) 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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 7 May 2002 12:20:22 -0700 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 > > > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed May 8 07:30: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 HAA01254 for ; Wed, 8 May 2002 07:30: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 g48BRWu2019754; Wed, 8 May 2002 07:27:32 -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 HAA08815; Wed, 8 May 2002 07:31:03 -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 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 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: Date: Wed, 08 May 2002 07:28:46 -0400 --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-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri May 10 01:55: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 BAA29276 for ; Fri, 10 May 2002 01:55: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 g4A5kYu2005710; Fri, 10 May 2002 01:46:34 -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 BAA15701; Fri, 10 May 2002 01:50:04 -0400 (EDT) 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> 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 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: Date: Fri, 10 May 2002 14:48:05 +0900 Content-Transfer-Encoding: 7bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri May 10 05:43:54 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 FAA11414 for ; Fri, 10 May 2002 05:43:54 -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 g4A9ZSu2006489; Fri, 10 May 2002 05:35:28 -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 FAA16349; Fri, 10 May 2002 05:39:03 -0400 (EDT) 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> 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 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: Date: Fri, 10 May 2002 11:24:52 +0200 Content-Transfer-Encoding: 7bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri May 10 09:30:34 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 JAA21494 for ; Fri, 10 May 2002 09:30: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 g4ADQUu2007582; Fri, 10 May 2002 09:26:30 -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 JAA16958; Fri, 10 May 2002 09:30:05 -0400 (EDT) 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" 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" 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: Date: Thu, 9 May 2002 13:00:39 +0300 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-Disposition: attachment; filename="Wholesale Target Prices 2002_05.xls" Content-Transfer-Encoding: base64 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-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri May 10 09:36:17 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 JAA21796 for ; Fri, 10 May 2002 09:36:17 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g4ADWNu2007727; Fri, 10 May 2002 09:32:23 -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 JAA17033; Fri, 10 May 2002 09:36:03 -0400 (EDT) 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 Message-Id: <1021037675.1186.3.camel@dhcp152.dfw.dynamicsoft.com> Mime-Version: 1.0 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: Date: 10 May 2002 08:34:35 -0500 Content-Transfer-Encoding: 7bit Grr - I fumbled in the approval interface letting that one through. Sorry. RjS _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri May 10 13:55:02 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 NAA08201 for ; Fri, 10 May 2002 13:55:02 -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 g4AHpSu2010153; Fri, 10 May 2002 13:51:28 -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 NAA17774; Fri, 10 May 2002 13:55:04 -0400 (EDT) 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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: Date: Fri, 10 May 2002 10:53:48 -0700 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 > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon May 13 15:18:31 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 PAA27533 for ; Mon, 13 May 2002 15:18:31 -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 g4DJEYne004893; Mon, 13 May 2002 15:14:34 -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 PAA02033; Mon, 13 May 2002 15:18:05 -0400 (EDT) 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" 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 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: Date: Mon, 13 May 2002 14:16:26 -0500 Content-Transfer-Encoding: 7bit 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. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon May 13 17:08:34 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 RAA03385 for ; Mon, 13 May 2002 17:08: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 g4DL4bne006002; Mon, 13 May 2002 17:04:39 -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 RAA02411; Mon, 13 May 2002 17:08: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 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> 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 13 May 2002 17:06:12 -0400 Content-Transfer-Encoding: 7bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon May 13 19:18:59 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 TAA09041 for ; Mon, 13 May 2002 19:18:57 -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 g4DNEgne007024; Mon, 13 May 2002 19:14:42 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02801; Mon, 13 May 2002 19:18:08 -0400 (EDT) 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> 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 13 May 2002 19:15:23 -0400 Content-Transfer-Encoding: 7bit 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 > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon May 13 20:45:48 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 UAA12055 for ; Mon, 13 May 2002 20:45:48 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g4E0gQne007407; Mon, 13 May 2002 20:42: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 UAA03082; Mon, 13 May 2002 20:46:04 -0400 (EDT) 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> 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 13 May 2002 20:42:51 -0400 Content-Transfer-Encoding: 7bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon May 13 20:54:48 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 UAA12409 for ; Mon, 13 May 2002 20:54: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 g4E0pLne007504; Mon, 13 May 2002 20:51:21 -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 UAA03140; Mon, 13 May 2002 20:55:03 -0400 (EDT) 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> 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 13 May 2002 20:52:55 -0400 Content-Transfer-Encoding: 7bit > 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 simple-admin@mailman.dynamicsoft.com Tue May 14 04:23:05 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 EAA08769 for ; Tue, 14 May 2002 04:23:05 -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 g4E8JPne008725; Tue, 14 May 2002 04:19:29 -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 EAA04372; Tue, 14 May 2002 04:23:03 -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 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" 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_=" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 14 May 2002 11:20:36 +0300 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_=-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue May 14 10:44: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 KAA21742 for ; Tue, 14 May 2002 10:44:17 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g4EEdNne010839; Tue, 14 May 2002 10:39:23 -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 KAA05387; Tue, 14 May 2002 10:43: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 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 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" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 14 May 2002 10:38:17 -0400 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

_______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue May 14 10:45: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 KAA21781 for ; Tue, 14 May 2002 10:45: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 g4EEftne010926; Tue, 14 May 2002 10:41:55 -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 KAA05439; Tue, 14 May 2002 10:45:38 -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 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 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 14 May 2002 10:42:04 -0400 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 > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue May 14 11:10:52 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 LAA22802 for ; Tue, 14 May 2002 11:10:52 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g4EF2Lne011270; Tue, 14 May 2002 11:02:21 -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 LAA05550; Tue, 14 May 2002 11:06:03 -0400 (EDT) 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" 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_=" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 14 May 2002 18:04:21 +0300 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_=-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue May 14 12:10: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 MAA24835 for ; Tue, 14 May 2002 12:10:06 -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 g4EG6One012139; Tue, 14 May 2002 12:06:25 -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 MAA05795; Tue, 14 May 2002 12:10:04 -0400 (EDT) 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> 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 14 May 2002 12:06:13 -0400 Content-Transfer-Encoding: 7bit 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 simple-admin@mailman.dynamicsoft.com Tue May 14 12:22:55 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 MAA25260 for ; Tue, 14 May 2002 12:22:54 -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 g4EGJNne012331; Tue, 14 May 2002 12:19:23 -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 MAA05898; Tue, 14 May 2002 12:23:03 -0400 (EDT) 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" 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_=" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 14 May 2002 19:21:00 +0300 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_=-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue May 14 12:47:54 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 MAA26001 for ; Tue, 14 May 2002 12:47:54 -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 g4EGiNne012577; Tue, 14 May 2002 12:44:23 -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 MAA06023; Tue, 14 May 2002 12:48:03 -0400 (EDT) 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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 14 May 2002 12:45:47 -0400 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 simple-admin@mailman.dynamicsoft.com Tue May 14 13:27: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 NAA27411 for ; Tue, 14 May 2002 13:27: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 g4EHKOne013067; Tue, 14 May 2002 13:20:24 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06165; Tue, 14 May 2002 13:24:04 -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 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 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 14 May 2002 13:22:05 -0400 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue May 14 17:40:29 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 RAA08289 for ; Tue, 14 May 2002 17:40: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 g4ELaqne015741; Tue, 14 May 2002 17:36:52 -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 RAA06902; Tue, 14 May 2002 17:39:07 -0400 (EDT) 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 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 14 May 2002 22:36:15 +0100 Content-Transfer-Encoding: 7bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed May 15 02: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 CAA05743 for ; Wed, 15 May 2002 02:14:46 -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 g4F6BNne017886; Wed, 15 May 2002 02:11:23 -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 CAA08457; Wed, 15 May 2002 02:15:04 -0400 (EDT) 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 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 15 May 2002 07:11:57 +0100 Content-Transfer-Encoding: 7bit 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 > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed May 15 10:36: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 KAA07402 for ; Wed, 15 May 2002 10:36:05 -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 g4FEWNne020229; Wed, 15 May 2002 10:32:23 -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 KAA09836; Wed, 15 May 2002 10:36:03 -0400 (EDT) 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 Message-ID: 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-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: Date: Tue, 14 May 2002 18:07:34 -0700 Content-Transfer-Encoding: 8bit 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 simple-admin@mailman.dynamicsoft.com Wed May 15 11:40: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 LAA10223 for ; Wed, 15 May 2002 11:40:06 -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 g4FFZNne020856; Wed, 15 May 2002 11:35:23 -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 LAA10059; Wed, 15 May 2002 11:39:04 -0400 (EDT) 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 Message-ID: <8CA1128D59AD27429985B397118CEDDFC4438B@nj7460avexu1.global.avaya.com> Thread-Topic: [Simple] Status summary Thread-Index: AcH7kHoofMXl6hXhTauHhk/lPxZpGQAG6r5AAB5vLTA= From: "Boyer, David G (Dave)" To: "Christian Huitema" , , "Tony Hansen" , 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: Date: Wed, 15 May 2002 11:37:52 -0400 Content-Transfer-Encoding: 8bit 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 simple-admin@mailman.dynamicsoft.com Wed May 15 12:25:49 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 MAA12029 for ; Wed, 15 May 2002 12:25:49 -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 g4FGMMne021554; Wed, 15 May 2002 12:22:23 -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 MAA10260; Wed, 15 May 2002 12:26:04 -0400 (EDT) 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 Message-ID: <8CA1128D59AD27429985B397118CEDDFC4438F@nj7460avexu1.global.avaya.com> Thread-Topic: [Simple] Status summary Thread-Index: AcH7ZyW3Pg+GEVZJQOq/jnnVOVKN3QAxZuIA From: "Boyer, David G (Dave)" To: "Liscano, Ramiro" , "Tony Hansen" , 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: Date: Wed, 15 May 2002 12:24:59 -0400 Content-Transfer-Encoding: 8bit > -----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 > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed May 15 20:46:24 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 UAA26731 for ; Wed, 15 May 2002 20:46:24 -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 g4G0gSne026151; Wed, 15 May 2002 20:42:28 -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 UAA11698; Wed, 15 May 2002 20:46:05 -0400 (EDT) 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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC72.BDCEC300" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 15 May 2002 19:43:48 -0500 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_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-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed May 15 22:11:46 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 WAA29615 for ; Wed, 15 May 2002 22:11:46 -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 g4G28Mne026510; Wed, 15 May 2002 22:08:22 -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 WAA11991; Wed, 15 May 2002 22:12:04 -0400 (EDT) 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> 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 15 May 2002 22:06:02 -0400 Content-Transfer-Encoding: 7bit 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 simple-admin@mailman.dynamicsoft.com Wed May 15 22:21: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 WAA29715 for ; Wed, 15 May 2002 22:21: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 g4G2HJne026586; Wed, 15 May 2002 22:17:19 -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 WAA12040; Wed, 15 May 2002 22:21:03 -0400 (EDT) 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) 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> Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 15 May 2002 18:49:49 -0700 Content-Transfer-Encoding: 7bit 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 simple-admin@mailman.dynamicsoft.com Wed May 15 23:36:31 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 XAA02632 for ; Wed, 15 May 2002 23:36:30 -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 g4G3WWne026832; Wed, 15 May 2002 23:32:32 -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 XAA12288; Wed, 15 May 2002 23:36:06 -0400 (EDT) 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> 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 15 May 2002 23:30:36 -0400 Content-Transfer-Encoding: 7bit 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 > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu May 16 17:22:58 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 RAA11204 for ; Thu, 16 May 2002 17:22:58 -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 g4GLJUne003885; Thu, 16 May 2002 17:19:30 -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 RAA15358; Thu, 16 May 2002 17:23:05 -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 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> 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 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: Date: Thu, 16 May 2002 17:21:07 -0400 Content-Transfer-Encoding: 7bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu May 16 17:47:52 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 RAA11765 for ; Thu, 16 May 2002 17:47:51 -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 g4GLiLne004212; Thu, 16 May 2002 17:44:21 -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 RAA15455; Thu, 16 May 2002 17:48: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 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> 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 16 May 2002 17:46:48 -0400 Content-Transfer-Encoding: 7bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon May 20 07:37:00 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 HAA07121 for ; Mon, 20 May 2002 07:36:59 -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 g4KBXOKf000683; Mon, 20 May 2002 07:33:24 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00786; Mon, 20 May 2002 07:37:06 -0400 (EDT) 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> 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" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 20 May 2002 04:34:57 -0700 --------------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-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon May 20 15:09:59 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 PAA01769 for ; Mon, 20 May 2002 15:09:58 -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 g4KJ5cKf004743; Mon, 20 May 2002 15:05:39 -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 PAA02101; Mon, 20 May 2002 15:09:06 -0400 (EDT) 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> 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" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 20 May 2002 12:07:08 -0700 --------------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-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon May 20 16:13:02 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 QAA06826 for ; Mon, 20 May 2002 16:13:01 -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 g4KK8cKf005404; Mon, 20 May 2002 16:08: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 QAA02339; Mon, 20 May 2002 16:12:06 -0400 (EDT) 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 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 20 May 2002 15:09:18 -0500 Content-Transfer-Encoding: 7bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon May 20 16:16: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 QAA07133 for ; Mon, 20 May 2002 16:16:46 -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 g4KKCIKf005501; Mon, 20 May 2002 16:12:18 -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 QAA02375; Mon, 20 May 2002 16:16:03 -0400 (EDT) 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 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 20 May 2002 15:14:13 -0500 Content-Transfer-Encoding: 7bit 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 simple-admin@mailman.dynamicsoft.com Mon May 20 16:22:30 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 QAA07621 for ; Mon, 20 May 2002 16:22: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 g4KKIIKf005628; Mon, 20 May 2002 16:18:18 -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 QAA02416; Mon, 20 May 2002 16:22:03 -0400 (EDT) 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 Message-ID: <8CA1128D59AD27429985B397118CEDDFC443DC@nj7460avexu1.global.avaya.com> Thread-Topic: [Simple] Status summary Thread-Index: AcIAOzgEeEgO9kRjSqysvZCV/ydN/QAADiLw From: "Boyer, David G (Dave)" To: "Ben Campbell" , , "Tony Hansen" Cc: 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: Date: Mon, 20 May 2002 16:21:09 -0400 Content-Transfer-Encoding: 8bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon May 20 17:16:58 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 RAA12088 for ; Mon, 20 May 2002 17:16:58 -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 g4KLDQKf006155; Mon, 20 May 2002 17:13: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 RAA02627; Mon, 20 May 2002 17:17:04 -0400 (EDT) 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) 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> Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 20 May 2002 13:22:11 -0700 Content-Transfer-Encoding: 7bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon May 20 19:15:51 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 TAA20371 for ; Mon, 20 May 2002 19:15:51 -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 g4KNCLKf007285; Mon, 20 May 2002 19:12:21 -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 TAA02975; Mon, 20 May 2002 19:16: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 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> 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 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: Date: Mon, 20 May 2002 19:13:52 -0400 Content-Transfer-Encoding: 7bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue May 21 09:38:35 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 JAA10060 for ; Tue, 21 May 2002 09:38:34 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g4LDYXKf010668; Tue, 21 May 2002 09:34:33 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05364; Tue, 21 May 2002 09:38:09 -0400 (EDT) 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 Message-ID: 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-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: Date: Mon, 20 May 2002 12:03:09 -0700 Content-Transfer-Encoding: 8bit > 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue May 21 10:17:49 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 KAA11433 for ; Tue, 21 May 2002 10:17:49 -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 g4LEEGKf011287; Tue, 21 May 2002 10:14:16 -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 KAA05506; Tue, 21 May 2002 10:18:04 -0400 (EDT) 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 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 21 May 2002 10:35:18 +0200 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue May 21 12:03:44 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 MAA15821 for ; Tue, 21 May 2002 12:03:44 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g4LG0JKf012858; Tue, 21 May 2002 12:00:19 -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 MAA05846; Tue, 21 May 2002 12:04: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 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> 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 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.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, 21 May 2002 12:01:48 -0400 Content-Transfer-Encoding: 7bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed May 22 04:54:56 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 EAA17876 for ; Wed, 22 May 2002 04:54:56 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g4M8pLKf019317; Wed, 22 May 2002 04:51:21 -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 EAA08554; Wed, 22 May 2002 04:55:05 -0400 (EDT) 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'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: Date: Wed, 22 May 2002 03:53:17 -0500 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed May 22 07:22:41 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 HAA22954 for ; Wed, 22 May 2002 07:22: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 g4MBJIKf019761; Wed, 22 May 2002 07:19:18 -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 HAA08998; Wed, 22 May 2002 07:23:04 -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 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 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: Date: Wed, 22 May 2002 07:20:59 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : A Session Initiation Protocol (SIP)Event 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-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed May 22 07:23:59 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 HAA23036 for ; Wed, 22 May 2002 07:23:59 -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 g4MBKTKf019802; Wed, 22 May 2002 07:20:29 -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 HAA09032; Wed, 22 May 2002 07:24:17 -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 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 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: Date: Wed, 22 May 2002 07:21:09 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : 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-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed May 22 07:24:31 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 HAA23075 for ; Wed, 22 May 2002 07:24:30 -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 g4MBKHKf019778; Wed, 22 May 2002 07:20:17 -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 HAA09016; Wed, 22 May 2002 07:24: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 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 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: Date: Wed, 22 May 2002 07:21:04 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : 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-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu May 23 10:33:15 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 KAA12457 for ; Thu, 23 May 2002 10:33:14 -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 g4NETPKf000517; Thu, 23 May 2002 10:29:25 -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 KAA13572; Thu, 23 May 2002 10:33:08 -0400 (EDT) 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 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 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: Date: Thu, 23 May 2002 10:28:28 -0400 Content-Transfer-Encoding: 8bit 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/ _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed May 29 14:44:41 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 OAA28411 for ; Wed, 29 May 2002 14:44: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 g4TIeQLe014957; Wed, 29 May 2002 14:40: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 OAA09463; Wed, 29 May 2002 14:44:06 -0400 (EDT) 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 Message-Id: <1022697635.1189.5.camel@dhcp150.dfw.dynamicsoft.com> Mime-Version: 1.0 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: Date: 29 May 2002 13:40:35 -0500 Content-Transfer-Encoding: 7bit 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 simple-admin@mailman.dynamicsoft.com Thu May 30 11:42:12 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 LAA09638 for ; Thu, 30 May 2002 11:42:11 -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 g4UFbSLe021435; Thu, 30 May 2002 11:37:28 -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 LAA13068; Thu, 30 May 2002 11:41:07 -0400 (EDT) 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 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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-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: Date: Thu, 30 May 2002 09:48:40 +0200 Content-Transfer-Encoding: 8bit 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 simple-admin@mailman.dynamicsoft.com Thu May 30 22:19:14 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 WAA24331 for ; Thu, 30 May 2002 22:19:13 -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 g4V2FTLe025732; Thu, 30 May 2002 22:15:29 -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 WAA14824; Thu, 30 May 2002 22:19:05 -0400 (EDT) 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" 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-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: Date: Fri, 31 May 2002 10:16:26 +0800 Content-Transfer-Encoding: 8bit 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri May 31 14:17:29 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 OAA25506 for ; Fri, 31 May 2002 14:17:29 -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 g4VI7HLe000370; Fri, 31 May 2002 14:07:17 -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 OAA17468; Fri, 31 May 2002 14:11:05 -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 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> 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 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: Date: Fri, 31 May 2002 14:09:21 -0400 Content-Transfer-Encoding: 7bit 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