From simple-admin@mailman.dynamicsoft.com Wed Jan 1 05:04:39 2003 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02120 for ; Wed, 1 Jan 2003 05:04:39 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h01A5rcF005902 for ; Wed, 1 Jan 2003 05:05:55 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA10438 for ; Wed, 1 Jan 2003 05:07:16 -0500 (EST) Date: Wed, 1 Jan 2003 05:07:16 -0500 (EST) Message-Id: <200301011007.FAA10438@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 Jan 1 09:57:39 2003 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06221 for ; Wed, 1 Jan 2003 09:57:39 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h01EwlcF007568; Wed, 1 Jan 2003 09:58:47 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13356; Wed, 1 Jan 2003 10:00:04 -0500 (EST) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13343 for ; Wed, 1 Jan 2003 09:59:10 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id h01ExAVF058600 for ; Wed, 1 Jan 2003 15:59:10 +0100 Received: from d10ml001.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h01ExAck024494 for ; Wed, 1 Jan 2003 15:59:10 +0100 To: simple@mailman.dynamicsoft.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: "Avshalom Houri" X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 01/01/2003 16:59:10, Serialize complete at 01/01/2003 16:59:10 Content-Type: text/plain; charset="US-ASCII" Subject: [Simple] SIMPLE system architecture - outline Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.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 Jan 2003 16:59:02 +0200 Few weeks ago we have asked for issues to be included in an outline of a SIMPLE system architecture. We still did not get any comments from the list :-(. Following is an initial version of the outline. Please comment. Thanks a lot to Jonathan Rosenberg for his help. Thanks Tony Hansen Avshalom Houri Server Centric Architecture View --------------------------------- 1. Services provided by the Architecture 2. Components and Layouts (Each type of layout will relate also to firewalls and edge systems) 2.1 Enterprise (Single Domains of Trust) 2.2 Federated Networks 2.3 Public Systems Interconnecting User Centric Scenarios and Message Flows ----------------------------------------- 3 Locating the Server 4 Logging-In 4.1 Authentication 4.2 Identification of Client Capabilities 5 Presence Lists 5.1 Management 6. Subscriptions 6.1 Subscribing to Presence List 6.2 Subscribing to Watchers List 6.3 Authorization 6.3.1 Reactive 6.3.2 Asynchronous 7. Presence Statuses 7.1 Status Values 7.2 Invisible (Lurking) Mode 7.3 Enhanced Status Codes 7.4 Permissions 7.5 Setting 7.6 Propagation 8. Instant Messaging 8.1 Page Mode IMs 8.2 IM Sessions 8.3 Permissions 8.4 Action Cues(Is-Typing) 8.5 Message History 8.6 Offline Messages 8.6.1 Queued Offline Messages (Messages that are delivered to the user when s/he logs in) 8.6.2 Other Offline (Delivery via email SMS etc.) 8.7 Emoticons (smily etc.) 8.8 Message Backgrounds (E.g. Yahoo's IMVironments) 9 IM Conferences 9.1 Instant Conferences 9.2 Scheduled Conferences 9.3 Switching between IM Page Mode, IM Sessions and IM Conferences 9.4 Permissions 10 Additional Services 10.1 File sharing 10.2 Voice 10.3 Video 10.4 General Application Invocation 10.5 Profiles (Searching for other users, Sending profiles to other users etc.) Server Centric Scenarios and Message Flows ------------------------------------------ Note: The full list should fall out of the user-centric features, when applying them inter-domain. 11 Locating other servers 12 Authentication between servers 13 Trust Between Servers from Different Domains 14 Replication of Data 15 Use of Directories 16 Logging Capabilities (e.g. Message History) 17 Offline Messages _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jan 2 17:37:10 2003 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16106 for ; Thu, 2 Jan 2003 17:37:10 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h02MbmcF010524; Thu, 2 Jan 2003 17:37:49 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18835; Thu, 2 Jan 2003 17:39:04 -0500 (EST) Received: from magus.nostrum.com (magus.nostrum.com [208.21.192.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18824 for ; Thu, 2 Jan 2003 17:38:17 -0500 (EST) Received: from dynamicsoft.com (root@magus.nostrum.com [10.10.10.2]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id h02McDdk082722; Thu, 2 Jan 2003 16:38:14 -0600 (CST) Message-ID: <3E14BF45.8050103@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: krisztian.kiss@nokia.com CC: jdrosen@dynamicsoft.com, aki.niemi@nokia.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] PUBLISH requirements References: In-Reply-To: X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: Thu, 02 Jan 2003 16:37:57 -0600 Content-Transfer-Encoding: 7bit krisztian.kiss@nokia.com wrote: > Hi All, > > In order to help to progress the PUBLISH requirements work, here is a collection of requirements as a discussion opener. Comments are more than welcome. > > REQ1: It must be possible for the PUA to add elements to the presence information as well as remove or modify existing elements of the presence information. > > REQ2: The publish mechanism must allow a PUA to change only part of the presentity's presence information. For example, a PUA must be able to only publish one single element of the presentity's PIDF document, while the document contains several elements. > > REQ3: There must be one default content type for the publish mechanism. I am not sure if this means there should be a default that is assumed if the type is not specified, or that their should be a common type that all implementations are required to understand. > > REQ4: It must be possible for the presentity to publish multimedia contents along with their communication means. I am not sure what communication type means here. Are we talking about content published indirectly? If so, then the descriminator should be "large content" or "indirect content" rather than multimedia content. > > REQ5: The publication mechanism must allow publishing from multiple PUAs of a single presentity. > > REQ6: The PUA must be able to publish to a specific piece of presence, shared among many PUAs (the number of sources must neither be limited nor pre-defined). This means that the published tuples need to be identified across all of the PUAs of a presentity. I am not sure I understand this one. What do you mean by the phrase "specific piece of presence"? I tend to assume that this means a specific tuple, but the latter part of the requirement seems to contradict that. > > REQ7: Presence information must be always available. This means that in case the PUAs do not refresh presence information, some information must remain available for watchers, as - for example - the remaining information is hard-state data by nature or soft-state data but it has default value when data expired. This has a lot of interesting permutations. Is it enough that a watcher remembers the last presence document it saw before the expiration? If a presence document has expired, is the compositor obligated to keep it around forever, in case someone asks for it that may not have received the latest known document? > > REQ8: The PUA must be able to receive feedback about the result of a publishing transaction, the feedback must contain enough information for the principal controlling the presentity to know that the published presence information was successfully composed into the presence document by the Presence Server. Does this imply a requirement that the PUA receive the final composed document as part of the feedback? Or is it enough just to return a response code, and say the PUA must subscribe to the presence doc if it cares? > > Regards, > Krisztian > > >>-----Original Message----- >>From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Sent: Friday, December 13, 2002 7:36 AM >>To: Niemi Aki (NET/Espoo) >>Cc: simple@mailman.dynamicsoft.com >>Subject: Re: [Simple] PUBLISH requirements >> >> >> >> >>aki.niemi@nokia.com wrote: >> >> > The discussion in the SIMPLE session in Atlanta lead us towards >> > another round of PUBLISH requirements. I think it would be good to >> > look at some requirements that might be arising from the fact that >> > the dynamics of publishing are distinctly different from >>the dynamics >> > of notification. >> >>Yes, I agree. Makes you glad we didn't go for NOTIFY as the >>publication >>mechanism... >> >> In order for the composer to make a >> > coherent, single presence document out of the information >>coming from >> > many sources, the composer should be able to identify the published >> > information uniquely across all of the PUAs of a presentity. >> >>The information is needed by others too. A presentity might want to >>setup a policy that says "only Joe and Bob can see my cell >>phone". That >>requires some unique way for the composer to identify which >>tuple is the >>cell phone. >> >> > >> > For example, if we say that a tuple is the base data unit of >> > published presence information, then a specific tuple has to have a >> > common ID across all PUAs of a presentity. In other words, the >> > tuple-id needs to have semantics associated with it. This way the >> > composer can merge two "im-inbox" publications into one single >> > presence document tuple. This seems like an additional requirement >> > for PIDF when it is used in publishing presence state. >> >>I think this is a slightly different issue than above. One >>requirement >>is just identification of the tuples whose scope is broader >>than the id >>attribute. What you are suggesting here, I think, is almost to define >>different classes of tuples. THis way, if I have two PCs, >>each of which >>has an "im-inbox", the composer could know to combine (or >>treat in the >>appropriate manner) those two tuples. That seems more of a >>slippery slope. >> >> > >> > In addition to this, I think there may also be other requirements >> > there related to expiration of state, and the fact that not all >> > presence information is wrapped into a element. E.g., the >> > presentity level element is not dependent of any >>tuples. How >> > does one only publish a ? Or remove it? >> >>Well, PIDF is going to change to allow a document with just a note. I >>raised this issue in IMPP and folks were ok with the change. >> >>Now, to remove a note, you'd presumably publish an empty document. >> >>That is, the assumption is that, as far as each publication >>instance is >>concerned, each publication represents the complete presence >>state from >>that instance. >> >>-Jonathan R. >> >>-- >>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >>Chief Scientist First Floor >>dynamicsoft East Hanover, NJ 07936 >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> >>_______________________________________________ >>simple mailing list >>simple@mailman.dynamicsoft.com >>http://mailman.dynamicsoft.com/mailman/listinfo/simple >> > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jan 2 17:59:35 2003 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16468 for ; Thu, 2 Jan 2003 17:59:35 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h02N0ecF010642; Thu, 2 Jan 2003 18:00:40 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA18922; Thu, 2 Jan 2003 18:02:02 -0500 (EST) Received: from magus.nostrum.com (magus.nostrum.com [208.21.192.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA18911 for ; Thu, 2 Jan 2003 18:01:33 -0500 (EST) Received: from dynamicsoft.com (root@magus.nostrum.com [10.10.10.2]) by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id h02N1Kdk083328; Thu, 2 Jan 2003 17:01:21 -0600 (CST) Message-ID: <3E14C4B0.10503@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avshalom Houri CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] SIMPLE system architecture - outline References: In-Reply-To: X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: Thu, 02 Jan 2003 17:01:04 -0600 Content-Transfer-Encoding: 7bit The outline below looks (with a few nits) looks good from a provider oriented perspective; that is, one where much of the service is provided by, and controlled by, some service provider. I would also like to see a description of a more client (or end to end) focused architecture, where provider-hosted servers play very little role beyond helping clients discover each other. Some more comments inline: Avshalom Houri wrote: [...] > 2. Components and Layouts > (Each type of layout will relate also to firewalls > and edge systems) > 2.1 Enterprise (Single Domains of Trust) > 2.2 Federated Networks > 2.3 Public Systems Interconnecting The 2.x terminology above seems to favor controlled interconnection between provider domains, much like you see on telecom networks. We also need to discuss open, uncontrolled communication between domains like you often see over the internet with technologies such as email. > > > User Centric Scenarios and Message Flows > ----------------------------------------- > > 3 Locating the Server > > 4 Logging-In > 4.1 Authentication > 4.2 Identification of Client Capabilities I am not sure what is meant by "logging in" in a SIMPLE based presence/IM service. Are we simply talking about authentication of an initial SIP (or other protocol) interaction? [...] > 6. Subscriptions > 6.1 Subscribing to Presence List > 6.2 Subscribing to Watchers List > 6.3 Authorization > 6.3.1 Reactive > 6.3.2 Asynchronous Need an entry for subscribing to a presentity. > > 7. Presence Statuses > 7.1 Status Values > 7.2 Invisible (Lurking) Mode > 7.3 Enhanced Status Codes > 7.4 Permissions > 7.5 Setting > 7.6 Propagation May need an entry for composition of presence status from multiple sources. > > 8. Instant Messaging > 8.1 Page Mode IMs > 8.2 IM Sessions > 8.3 Permissions Need a discussion of IM privacy and integrity protection. > 8.4 Action Cues(Is-Typing) > 8.5 Message History > 8.6 Offline Messages > 8.6.1 Queued Offline Messages > (Messages that are delivered to the user when s/he logs in) > 8.6.2 Other Offline > (Delivery via email SMS etc.) > 8.7 Emoticons (smily etc.) > 8.8 Message Backgrounds (E.g. Yahoo's IMVironments) Much of 8.7 and 8.8 involve IM sender attempts to control the user experience of the receiver. We might need some discussion on what controls the receiver can place on this as well. For example, if we give you a mechanism to send me animated emoticons, we should give me a mechanism to make sure I never receive one of the vile things;-) This might be part of permissions and capabilities as mentioned in previous places. [...] _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Jan 2 23:58:46 2003 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22654 for ; Thu, 2 Jan 2003 23:58:46 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h034xicF011263; Thu, 2 Jan 2003 23:59:44 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA19984; Fri, 3 Jan 2003 00:01:03 -0500 (EST) 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 AAA19973 for ; Fri, 3 Jan 2003 00:00:49 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.143]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0350nYH024693; Fri, 3 Jan 2003 00:00:49 -0500 (EST) Message-ID: <3E1518FD.5060807@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Avshalom Houri , simple@mailman.dynamicsoft.com Subject: Re: [Simple] SIMPLE system architecture - outline References: <3E14C4B0.10503@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: Fri, 03 Jan 2003 00:00:45 -0500 Content-Transfer-Encoding: 7bit inline. Ben Campbell wrote: > The outline below looks (with a few nits) looks good from a provider > oriented perspective; that is, one where much of the service is provided > by, and controlled by, some service provider. > > I would also like to see a description of a more client (or end to end) > focused architecture, where provider-hosted servers play very little > role beyond helping clients discover each other. > > Some more comments inline: > > Avshalom Houri wrote: > [...] > >> 2. Components and Layouts >> (Each type of layout will relate also to firewalls >> and edge systems) >> 2.1 Enterprise (Single Domains of Trust) >> 2.2 Federated Networks >> 2.3 Public Systems Interconnecting > > > The 2.x terminology above seems to favor controlled interconnection > between provider domains, much like you see on telecom networks. We also > need to discuss open, uncontrolled communication between domains like > you often see over the internet with technologies such as email. I agree completely. However, it was my assumption that this was under the scope of "federated networks" since, in fact, its the same problem sans the security. Perhaps worth splitting off though. > >> >> >> User Centric Scenarios and Message Flows >> ----------------------------------------- >> >> 3 Locating the Server >> >> 4 Logging-In >> 4.1 Authentication >> 4.2 Identification of Client Capabilities > > > I am not sure what is meant by "logging in" in a SIMPLE based > presence/IM service. Are we simply talking about authentication of an > initial SIP (or other protocol) interaction? I thought this meant REGISTER, which is our closest analogy to logging in. >> >> 7. Presence Statuses >> 7.1 Status Values >> 7.2 Invisible (Lurking) Mode >> 7.3 Enhanced Status Codes >> 7.4 Permissions >> 7.5 Setting >> 7.6 Propagation > > > May need an entry for composition of presence status from multiple sources. A good point. In fact, multiple clients impact in multiple places. For example, in delivery of an IM (forking). Might be worth considering it throughout the doc. >> 8.4 Action Cues(Is-Typing) >> 8.5 Message History >> 8.6 Offline Messages >> 8.6.1 Queued Offline Messages >> (Messages that are delivered to the user when s/he logs in) >> 8.6.2 Other Offline >> (Delivery via email SMS etc.) >> 8.7 Emoticons (smily etc.) >> 8.8 Message Backgrounds (E.g. Yahoo's IMVironments) > > > Much of 8.7 and 8.8 involve IM sender attempts to control the user > experience of the receiver. We might need some discussion on what > controls the receiver can place on this as well. For example, if we give > you a mechanism to send me animated emoticons, we should give me a > mechanism to make sure I never receive one of the vile things;-) IMHO, emoticons as they are done today are horrible and would be an unending source of interoperability problems. I much better way to do it is to send an IM with a markup, perhaps HTML, that contains inline images to the desired emoticons. This way, there is no ambiguity in the intent of the sender. It also gets you what you want - a receiver can always choose not to download the inline images. As an example of the problem, Dean Willis and I were IM'ming on yahoo. He IM'd me his sip URI: sip:dwillis@dynamicsoft.com now, it turns out that :d is a big grinned smiley face emoticon on yahoo. Thus, Dean's sip URL came through with a happy face in the middle. Kind of appropriate but not what he meant. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Jan 3 01:02:33 2003 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23565 for ; Fri, 3 Jan 2003 01:02:32 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h0363gcF011435; Fri, 3 Jan 2003 01:03:42 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA20213; Fri, 3 Jan 2003 01:05:04 -0500 (EST) 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 BAA20200 for ; Fri, 3 Jan 2003 01:04:24 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.143]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0364PYH024716; Fri, 3 Jan 2003 01:04:25 -0500 (EST) Message-ID: <3E1527E6.7090709@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: krisztian.kiss@nokia.com, aki.niemi@nokia.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] PUBLISH requirements References: <3E14BF45.8050103@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: Fri, 03 Jan 2003 01:04:22 -0500 Content-Transfer-Encoding: 7bit inline. Ben Campbell wrote: > krisztian.kiss@nokia.com wrote: > >> Hi All, >> >> In order to help to progress the PUBLISH requirements work, here is a >> collection of requirements as a discussion opener. Comments are more >> than welcome. >> >> REQ1: It must be possible for the PUA to add elements to the presence >> information as well as remove or modify existing elements of the >> presence information. I think you need to be careful here. I don't think the requirement is that it be able to explicitly say "add this tuple". I think that each PUA should publish its own view of the state of the presentity, and that the compositor combine all such views together. I am not convinced that there is a need, out of the gate, to be able to do differential publication on a PUAs own view. That is, PUA1 publishes tuples A and B, and PUA2 publishes tuples C and D. The composite presence document has all four. I believe that PUA1, when it updates its view of tuple B, would send A and B again. There need not be a way to publish just the differential to B. I don't think such a thing is bad, I just think its not critical at this time. >> REQ2: The publish mechanism must allow a PUA to change only part of >> the presentity's presence information. For example, a PUA must be able >> to only publish one single element of the presentity's PIDF >> document, while the document contains several elements. Again, based on the above, I agree that a PUA need only publish its view of the presentity state, which is by definition only a partial view. >> >> REQ3: There must be one default content type for the publish mechanism. > > > I am not sure if this means there should be a default that is assumed if > the type is not specified, or that their should be a common type that > all implementations are required to understand. I assumed this meant that there was a baseline standard, i.e., everyone has to support PIDF. > >> >> REQ4: It must be possible for the presentity to publish multimedia >> contents along with their communication means. > > > I am not sure what communication type means here. Are we talking about > content published indirectly? If so, then the descriminator should be > "large content" or "indirect content" rather than multimedia content. I agree we should allow for URI references to things like pictures and vcards. But, that seems more an issue for the PIDF extension work than PUBLISH. > >> >> REQ5: The publication mechanism must allow publishing from multiple >> PUAs of a single presentity. No doubt. >> REQ6: The PUA must be able to publish to a specific piece of presence, >> shared among many PUAs (the number of sources must neither be limited >> nor pre-defined). This means that the published tuples need to be >> identified across all of the PUAs of a presentity. > > > I am not sure I understand this one. What do you mean by the phrase > "specific piece of presence"? I tend to assume that this means a > specific tuple, but the latter part of the requirement seems to > contradict that. I think I understand. The idea is that I may have one tuple, representing my work desktop presence. If I leave it on, I should be able to go home, and publish from my laptop, an update to that state. This requires some kind of broadly scoped tuple naming and discovery mechanisms. A PUA would need to be able to find the tuple name for the work PC, and then PUBLISH an update to it. Now, there are two views for what it means for two PUA to publish to the same tuple. One interpretation is that the status's between the two are to be combined. So, for example, if my work PC was publishing OPEN for that tuple, and my laptop at home published alive for that tuple, the compositor would act as if it had received a single tuple with both statuses (of course during composition it may discard one or the other, but the publication intent is clear.) Another interpretation is that one of them "wins". So that, in the example above, my laptop would now "win" and the compositor would act as if it had received a single tuple with JUST the simple:newstatus status. I personally prefer this interpretation, but I suppose one could argue for either one. Assuming we do go for this "replace" semantic, this also means that subsequent publishes by the desktop PC need to be rejected (assuming it automatically refreshes). Something like IF-MODIFIED-SINCE (from acap) as part of the publication process would work for that. Credit goes to Robert Sparks for suggesting that to me privately. So, I would actually expand this into several requirements: * There must be a way to uniquely identify tuples across all PUA for a particular presentity * There must be a way for a PUA to discover the tuple names for those tuples currently active from other PUA for that presentity. I will note that Krisztian has presented this requirement in the past, and in the past, I have questioned it. I am now convinced that these tuple names live **ONLY** on the publication side, so that it is not sufficient to subscribe to the presence of the presentity in order to learn them. Thus, I now accept this requirement. * There must be a way to allow two PUA to publish data for the same tuple (i.e, the same name) * There must be a way to publish with a "forced write" so that the published tuple overrides any existing tuple with the same name * There must be a way to reject a published tuple from a PUA because it has been replaced by one published from another PUA > >> >> REQ7: Presence information must be always available. This means that >> in case the PUAs do not refresh presence information, some information >> must remain available for watchers, as - for example - the remaining >> information is hard-state data by nature or soft-state data but it has >> default value when data expired. > > > This has a lot of interesting permutations. Is it enough that a watcher > remembers the last presence document it saw before the expiration? If a > presence document has expired, is the compositor obligated to keep it > around forever, in case someone asks for it that may not have received > the latest known document? I think its compositor policy about what to do here. I believe published presence documents are fundamentally soft-state. If they expire, the "input" to the compositor disappears. How the compositor reacts to this is policy dependent. It might choose to drop those tuples from the overall presentity document. Or, it might drop them until all published inputs have expired, and then resort to some provisioned "default" presence status. I don't think we can or should specify this. > > >> >> REQ8: The PUA must be able to receive feedback about the result of a >> publishing transaction, the feedback must contain enough information >> for the principal controlling the presentity to know that the >> published presence information was successfully composed into the >> presence document by the Presence Server. > > > Does this imply a requirement that the PUA receive the final composed > document as part of the feedback? Or is it enough just to return a > response code, and say the PUA must subscribe to the presence doc if it > cares? Well, by itself this requirement just says it has to know whether it worked or not. It may be, because of the requirement I suggest above about learning the other published tuple names, that the PUBLISH response return the current "input" tuple set. But, thats an implementation approach not a requirement. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sat Jan 4 13:48:55 2003 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14473 for ; Sat, 4 Jan 2003 13:48:55 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h04InncF014994; Sat, 4 Jan 2003 13:49:49 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26615; Sat, 4 Jan 2003 13:51:04 -0500 (EST) Received: from bdsl.greycouncil.com (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26603 for ; Sat, 4 Jan 2003 13:50:31 -0500 (EST) Received: from txdwillis (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.5/8.12.5) with ESMTP id h04IoN8X008440; Sat, 4 Jan 2003 12:50:23 -0600 From: "Dean Willis" To: "'Jonathan Rosenberg'" , "'Ben Campbell'" Cc: , , Subject: RE: [Simple] PUBLISH requirements Message-ID: <004401c2b422$16b71460$0c02a8c0@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E1527E6.7090709@dynamicsoft.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id NAA26603 Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Sat, 4 Jan 2003 12:50:00 -0600 Content-Transfer-Encoding: 8bit Jdrosen said: > I am not convinced that there is a need, out of the gate, to > be able to > do differential publication on a PUAs own view. That is, PUA1 > publishes > tuples A and B, and PUA2 publishes tuples C and D. The composite > presence document has all four. I believe that PUA1, when it > updates its > view of tuple B, would send A and B again. There need not be a way to > publish just the differential to B. > > I don't think such a thing is bad, I just think its not > critical at this > time. > Well, there are some 3G people thinking that they want to use very large direct (not indirect) presence documents. There might be, say, 500 tuples, or individual tuples that are several hundred bytes in size, all sourced from a single PUA. There might be a tuple changing every minute or so. Given an expensive, low-bandwidth connection, it doesn't seem like a good idea to have to keep republishing all the tuples that didn't change. I tend to envision the tuple-space as something like a database. From the PUA's perspective, each tuple is a record in that database. The composition function is also somewhat like a "view" operation on a database. The records selected from a "view" (an output function) may be somewhat different from those submitted into the database. The compositor function can be though of as something like a stored procedure that does a join-and-merge operation to generate a view. -- Dean _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Sun Jan 5 21:19:55 2003 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13692 for ; Sun, 5 Jan 2003 21:19:55 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h062KkcF016901; Sun, 5 Jan 2003 21:20:46 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA02057; Sun, 5 Jan 2003 21:22:04 -0500 (EST) 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 VAA02046 for ; Sun, 5 Jan 2003 21:21:41 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.11]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h062LeYH025524; Sun, 5 Jan 2003 21:21:40 -0500 (EST) Message-ID: <3E18E832.1050708@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: "'Ben Campbell'" , krisztian.kiss@nokia.com, aki.niemi@nokia.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] PUBLISH requirements References: <004401c2b422$16b71460$0c02a8c0@txdwillis> 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: Sun, 05 Jan 2003 21:21:38 -0500 Content-Transfer-Encoding: 7bit inline. Dean Willis wrote: > Jdrosen said: > >>I am not convinced that there is a need, out of the gate, to >>be able to >>do differential publication on a PUAs own view. That is, PUA1 >>publishes >>tuples A and B, and PUA2 publishes tuples C and D. The composite >>presence document has all four. I believe that PUA1, when it >>updates its >>view of tuple B, would send A and B again. There need not be a way to >>publish just the differential to B. >> >>I don't think such a thing is bad, I just think its not >>critical at this >>time. >> > > > Well, there are some 3G people thinking that they want to use very large > direct (not indirect) presence documents. There might be, say, 500 tuples, > or individual tuples that are several hundred bytes in size, all sourced > from a single PUA. There might be a tuple changing every minute or so. > Given an expensive, low-bandwidth connection, it doesn't seem like a good > idea to have to keep republishing all the tuples that didn't change. Given these assumptions, I would be inclined to agree. However, I cannot imagine what application would use 500 tuples. I have no problem developing standards to solve real problems, but not ones to solve potential issues that there are no real use cases for. > > I tend to envision the tuple-space as something like a database. From the > PUA's perspective, each tuple is a record in that database. The composition > function is also somewhat like a "view" operation on a database. The records > selected from a "view" (an output function) may be somewhat different from > those submitted into the database. The compositor function can be though of > as something like a stored procedure that does a join-and-merge operation to > generate a view. I think the notion of a view is close, but different. DB views give you access to a subset of the database. With presence, the "view" seen by any particular subscriber may be totally different, containing different values for the same rows, even. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Jan 6 12:03:39 2003 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07421 for ; Mon, 6 Jan 2003 12:03:38 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h06H4kjK001384; Mon, 6 Jan 2003 12:04:46 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01610; Mon, 6 Jan 2003 12:06:04 -0500 (EST) Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (dyn-tx-arch-crash.dfw.dynamicsoft.com [63.110.3.64]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01554 for ; Mon, 6 Jan 2003 12:03:56 -0500 (EST) Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h06H3wK23276 for ; Mon, 6 Jan 2003 11:03:58 -0600 From: Robert Sparks To: simple@mailman.dynamicsoft.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Message-Id: <1041872629.913.67.camel@RjS.localdomain> Mime-Version: 1.0 Subject: [Simple] IMPORTANT: Mailing list move Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: 06 Jan 2003 11:03:49 -0600 Content-Transfer-Encoding: 7bit Folks - We are moving the SIMPLE mailing list to the servers provided by ietf.org. As of now, the older list (simple@mailman.dynamicsoft.com) is closed to new posts. The archives of this old list are, and will continue to be, available at ftp://ftp.ietf.org/ietf-mail-archive/simple/ Information to subscribing to the new list is available at https://www1.ietf.org/mailman/listinfo/simple. You can also get instructions by sending a "help" request to simple-request@ietf.org. You must to subscribe to the new list using one of the methods documented above. Current subscribers to the old list are not automatically subscribed to the new. I apologize for this small inconvenience, but it will help greatly to remove a certain class of dead addresses from the list. Hopefully, this will be a quick and smooth transition. Please promptly report any problems you encounter to me. Thanks, RjS _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 7 10:18:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17546 for ; Tue, 7 Jan 2003 10:18:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07FT7r27786 for simple-archive@odin.ietf.org; Tue, 7 Jan 2003 10:29:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07FT7J27783 for ; Tue, 7 Jan 2003 10:29:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17493 for ; Tue, 7 Jan 2003 10:17:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07FT5J27775; Tue, 7 Jan 2003 10:29:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07FE5J26986 for ; Tue, 7 Jan 2003 10:14:05 -0500 Received: from mail1.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16168 for ; Tue, 7 Jan 2003 10:02:48 -0500 (EST) Resent-From: simple-admin@mailman.dynamicsoft.com Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h07F4ZjK004883 for ; Tue, 7 Jan 2003 10:04:35 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05664 for ; Tue, 7 Jan 2003 10:06:01 -0500 (EST) Resent-Date: Tue, 7 Jan 2003 10:06:01 -0500 (EST) Resent-Message-Id: <200301071506.KAA05664@mailman.dynamicsoft.com> 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 IAA05333 for ; Tue, 7 Jan 2003 08:31:58 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11981; Tue, 7 Jan 2003 08:28:43 -0500 (EST) Message-Id: <200301071328.IAA11981@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mmusic@ietf.org, simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Resent-To: simple@ietf.org X-Ack: no X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk Subject: [Simple] I-D ACTION:draft-rosenberg-mmusic-comedia-fix-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 07 Jan 2003 08:28:43 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Proposed Changes to Connection Oriented Media Handling in the Session Description Protocol (SDP) Author(s) : J. Rosenberg Filename : draft-rosenberg-mmusic-comedia-fix-00.txt Pages : 19 Date : 2003-1-6 This document describes changes that are proposed to draft-ietf-mmusic-sdp-comedia-04, which describes the handling of connection oriented media in the Session Description Protocol (SDP). These changes are motivated by problems encountered in using comedia to support instant messaging sessions in the SIMPLE working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-mmusic-comedia-fix-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-mmusic-comedia-fix-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-mmusic-comedia-fix-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: <2003-1-6145253.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-mmusic-comedia-fix-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-mmusic-comedia-fix-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-6145253.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 7 14:20:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25385 for ; Tue, 7 Jan 2003 14:20:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h07JVEG11928 for simple-archive@odin.ietf.org; Tue, 7 Jan 2003 14:31:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07JVDJ11925 for ; Tue, 7 Jan 2003 14:31:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25374 for ; Tue, 7 Jan 2003 14:19:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07JVBJ11916; Tue, 7 Jan 2003 14:31:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07JUuJ11843 for ; Tue, 7 Jan 2003 14:30:56 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25363 for ; Tue, 7 Jan 2003 14:19:32 -0500 (EST) From: krisztian.kiss@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h07JOjt13853 for ; Tue, 7 Jan 2003 21:24:45 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 7 Jan 2003 21:22:47 +0200 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 7 Jan 2003 21:22:47 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 7 Jan 2003 21:22:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] PUBLISH requirements Message-ID: Thread-Topic: [Simple] PUBLISH requirements Thread-Index: AcKy7fl7+jUQAjVEQ7KbqWjDD+UmzQAP89SQ To: , , Cc: , , X-OriginalArrivalTime: 07 Jan 2003 19:22:46.0866 (UTC) FILETIME=[28F0AB20:01C2B682] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h07JUuJ11844 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 7 Jan 2003 21:22:45 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Jonathan, Ben, Dean, Thanks for the replies. Please see inline: > >> REQ1: It must be possible for the PUA to add elements to > the presence > >> information as well as remove or modify existing elements of the > >> presence information. > > >>I am not convinced that there is a need, out of the gate, to > >>be able to > >>do differential publication on a PUAs own view. That is, PUA1 > >>publishes > >>tuples A and B, and PUA2 publishes tuples C and D. The composite > >>presence document has all four. I believe that PUA1, when it > >>updates its > >>view of tuple B, would send A and B again. There need not > be a way to > >>publish just the differential to B. > >> > >>I don't think such a thing is bad, I just think its not > >>critical at this > >>time. > >> > > Well, there are some 3G people thinking that they want to > use very large > > direct (not indirect) presence documents. There might be, > say, 500 tuples, > > or individual tuples that are several hundred bytes in > size, all sourced > > from a single PUA. There might be a tuple changing every > minute or so. > > Given an expensive, low-bandwidth connection, it doesn't > seem like a good > > idea to have to keep republishing all the tuples that didn't change. > > Given these assumptions, I would be inclined to agree. > However, I cannot > imagine what application would use 500 tuples. I have no problem > developing standards to solve real problems, but not ones to solve > potential issues that there are no real use cases for. The use case for 'partial publication' would be the 'large direct content in presence document', namely the problem of 'individual tuple that is several hundred bytes'. This might be a potential use case in 3G, if the security & charging problems of content indirection could not be resolved. It is true that REQ1 implicitly sets a requirement for partial publication. Instead of each PUA would publish its own view of state of the presentity, there would be a need for add/modify/remove operations (the minimum data element one publish operation could change would be the element or other elements under element). > >> REQ2: The publish mechanism must allow a PUA to change > only part of > >> the presentity's presence information. For example, a PUA > must be able > >> to only publish one single element of the > presentity's PIDF > >> document, while the document contains several elements. > > Again, based on the above, I agree that a PUA need only > publish its view > of the presentity state, which is by definition only a partial view. Yes, this is the intention of REQ2. > >> REQ3: There must be one default content type for the > publish mechanism. > > > > > > I am not sure if this means there should be a default that > is assumed if > > the type is not specified, or that their should be a common > type that > > all implementations are required to understand. > > I assumed this meant that there was a baseline standard, > i.e., everyone > has to support PIDF. Right. All implementations are required to support the default content type. > >> REQ4: It must be possible for the presentity to publish multimedia > >> contents along with their communication means. > > > > > > I am not sure what communication type means here. Are we > talking about > > content published indirectly? If so, then the descriminator > should be > > "large content" or "indirect content" rather than > multimedia content. > > I agree we should allow for URI references to things like > pictures and > vcards. But, that seems more an issue for the PIDF extension > work than > PUBLISH. This is again the issue whether direct content is possible or not. If possible, then PUBLISH is probably affected by new content-types (e.g. MIME Multipart/Related). > >> REQ5: The publication mechanism must allow publishing from > multiple > >> PUAs of a single presentity. > > No doubt. > > >> REQ6: The PUA must be able to publish to a specific piece > of presence, > >> shared among many PUAs (the number of sources must neither > be limited > >> nor pre-defined). This means that the published tuples need to be > >> identified across all of the PUAs of a presentity. > > > > > > I am not sure I understand this one. What do you mean by the phrase > > "specific piece of presence"? I tend to assume that this means a > > specific tuple, but the latter part of the requirement seems to > > contradict that. > > I think I understand. The idea is that I may have one tuple, > representing my work desktop presence. If I leave it on, I should be > able to go home, and publish from my laptop, an update to that state. > This requires some kind of broadly scoped tuple naming and discovery > mechanisms. A PUA would need to be able to find the tuple > name for the > work PC, and then PUBLISH an update to it. > > Now, there are two views for what it means for two PUA to > publish to the > same tuple. One interpretation is that the status's between > the two are > to be combined. So, for example, if my work PC was publishing > OPEN for that tuple, and my laptop at home published > alive for that tuple, the > compositor would act as if it had received a single tuple with both > statuses (of course during composition it may discard one or > the other, > but the publication intent is clear.) > > Another interpretation is that one of them "wins". So that, in the > example above, my laptop would now "win" and the compositor > would act as > if it had received a single tuple with JUST the > simple:newstatus status. > I personally prefer this interpretation, but I suppose one > could argue > for either one. I would also prefer this latter interpretation. > Assuming we do go for this "replace" semantic, this also means that > subsequent publishes by the desktop PC need to be rejected > (assuming it > automatically refreshes). Something like IF-MODIFIED-SINCE > (from acap) > as part of the publication process would work for that. > Credit goes to > Robert Sparks for suggesting that to me privately. > > So, I would actually expand this into several requirements: > > * There must be a way to uniquely identify tuples across all > PUA for a > particular presentity > > * There must be a way for a PUA to discover the tuple names for those > tuples currently active from other PUA for that presentity. I > will note > that Krisztian has presented this requirement in the past, and in the > past, I have questioned it. I am now convinced that these tuple names > live **ONLY** on the publication side, so that it is not > sufficient to > subscribe to the presence of the presentity in order to learn them. > Thus, I now accept this requirement. > > * There must be a way to allow two PUA to publish data for the same > tuple (i.e, the same name) > > * There must be a way to publish with a "forced write" so that the > published tuple overrides any existing tuple with the same name > > * There must be a way to reject a published tuple from a PUA > because it > has been replaced by one published from another PUA These requirements sound good to me. At the same time, this might bring a lot of new issues related to publication authorization. I mean e.g. the following: - when there is a tuple collision, the conflicting PUAs could be informed about the situation - the conflict could be resolved somehow by deciding which PUA wins and which PUA is ignored - the result could be communicated to the PUAs - as a summary, the presentity could control its PUAs and authorize them to publish. Probably this would cause more problems than solve, so I am not convinced if this is really needed. As I understand, you are proposing to solve the conflict with simple rules. Taking the example of the desktop PC (which keeps refreshing state even if there is no activity on the PC), the IF-MODIFIED-SINCE rule would mean that the publication from the desktop PC could be just ignored if it contains the same state since e.g. one hour AND there is another PUA which intends to overwrite the same tuple. Correct? Is this satisfying? > >> REQ7: Presence information must be always available. This > means that > >> in case the PUAs do not refresh presence information, some > information > >> must remain available for watchers, as - for example - the > remaining > >> information is hard-state data by nature or soft-state > data but it has > >> default value when data expired. > > > > > > This has a lot of interesting permutations. Is it enough > that a watcher > > remembers the last presence document it saw before the > expiration? If a > > presence document has expired, is the compositor obligated > to keep it > > around forever, in case someone asks for it that may not > have received > > the latest known document? > > I think its compositor policy about what to do here. I > believe published > presence documents are fundamentally soft-state. If they expire, the > "input" to the compositor disappears. How the compositor > reacts to this > is policy dependent. It might choose to drop those tuples from the > overall presentity document. Or, it might drop them until all > published > inputs have expired, and then resort to some provisioned "default" > presence status. I don't think we can or should specify this. Dean wrote: > I think what you mean here is that the invocation of the publishing > mechanism should not, by default, erase any previously published > information. For example, if many different tuples exist for a > presentity, that publishing a single new tuple should not > normally cause > the other previously published tuples to be discarded. Right? I think there is a requirement for the compositor that it is obligated to always provide some sort of presence document to watchers instead of notifying that 'presence document is not available as it is expired'. Furthermore, I think what Dean wrote is also needed. In case of expiry, the compositor policy shouldn't say, by default, to forget about the information, it should rather set a default value, if there is any, or remember e.g. only the tuple name. > >> REQ8: The PUA must be able to receive feedback about the > result of a > >> publishing transaction, the feedback must contain enough > information > >> for the principal controlling the presentity to know that the > >> published presence information was successfully composed into the > >> presence document by the Presence Server. > > > > > > Does this imply a requirement that the PUA receive the > final composed > > document as part of the feedback? Or is it enough just to return a > > response code, and say the PUA must subscribe to the > presence doc if it > > cares? > > Well, by itself this requirement just says it has to know whether it > worked or not. Yes, this requirement only refers to the case how the PUA discovers whether the published document was e.g. a well-formed PIDF. That's another issue how the PUA learns the actual tuple names on the publication side. Regards, Krisztian > It may be, because of the requirement I suggest above about > learning the > other published tuple names, that the PUBLISH response return the > current "input" tuple set. But, thats an implementation > approach not a > requirement. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 9 13:30:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20183 for ; Thu, 9 Jan 2003 13:30:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09IgGw13448 for simple-archive@odin.ietf.org; Thu, 9 Jan 2003 13:42:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IgGJ13445 for ; Thu, 9 Jan 2003 13:42:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20157 for ; Thu, 9 Jan 2003 13:29:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IgBJ13436; Thu, 9 Jan 2003 13:42:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09HNSJ07786 for ; Thu, 9 Jan 2003 12:23:28 -0500 Received: from ams-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18041 for ; Thu, 9 Jan 2003 12:11:11 -0500 (EST) Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09HCtoJ021851 for ; Thu, 9 Jan 2003 18:12:58 +0100 (MET) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 9 Jan 2003 18:14:25 +0100 Received: from cisco.com ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 9 Jan 2003 18:14:25 +0100 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: simple@ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.551) X-OriginalArrivalTime: 09 Jan 2003 17:14:25.0569 (UTC) FILETIME=[8F6F8110:01C2B802] Content-Transfer-Encoding: 7bit Subject: [Simple] Fwd: Evaluation: draft-ietf-simple-winfo-package - Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Jan 2003 18:14:23 +0100 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit More IESG issues. paf Begin forwarded message: > From: "Wijnen, Bert (Bert)" > Date: tor jan 9, 2003 17:52:46 Europe/Stockholm > To: "Iesg-Secretary (E-mail)" > Cc: "Iesg (E-mail)" > Subject: Evaluation: draft-ietf-simple-winfo-package - > > Subject: Evaluation: draft-ietf-simple-winfo-package - A Session > Initiation Protocol (SIP)Event Template-Package for Watcher > Information to Proposed Standard > -------- > > Yes No-Objection Discuss * Abstain > > > Bert Wijnen [ ] [ ] [ X ] [ ] > > > Document draft-ietf-simple-winfo-package-04.txt has improper examples: > > SUBSCRIBE sip:joe@bar.com SIP/2.0 > Via: SIP/2.0/UDP pc34.bar.com;branch=z9hG4bKnashds7 > From: sip:joe@bar.com;tag=123aa9 > To: sip:joe@bar.com > Call-ID: 9987@pc34.bar.com > CSeq: 9887 SUBSCRIBE > Contact: sip:joe@pc34.bar.com > Event: presence.winfo > Max-Forwards: 70 > > I do not see IPR sections, as required per our NITS document > and the RFC2026 rules. This I believe is true for all 3 documents > > Thanks, > Bert > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 9 13:30:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20185 for ; Thu, 9 Jan 2003 13:30:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09IgG213463 for simple-archive@odin.ietf.org; Thu, 9 Jan 2003 13:42:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IgGJ13460 for ; Thu, 9 Jan 2003 13:42:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20156 for ; Thu, 9 Jan 2003 13:29:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09IgAJ13416; Thu, 9 Jan 2003 13:42:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09HESJ07373 for ; Thu, 9 Jan 2003 12:14:28 -0500 Received: from ams-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17808 for ; Thu, 9 Jan 2003 12:02:11 -0500 (EST) Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09H3vgL020333 for ; Thu, 9 Jan 2003 18:03:58 +0100 (MET) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 9 Jan 2003 18:05:25 +0100 Received: from cisco.com ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 9 Jan 2003 18:05:25 +0100 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: simple@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <8AA01134-23F4-11D7-871D-0003934B2128@cisco.com> X-Mailer: Apple Mail (2.551) X-OriginalArrivalTime: 09 Jan 2003 17:05:25.0680 (UTC) FILETIME=[4DA2FB00:01C2B801] Content-Transfer-Encoding: 7bit Subject: [Simple] Fwd: Evaluation: draft-ietf-simple-winfo-package - A Session Initiation Protocol (SIP)Event Template-Package for Watcher Information to Proposed Standard Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 9 Jan 2003 18:05:23 +0100 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Here are some questions from Harald...as a start (first) questions from IESG. Can you please quickly look at these and get back with an answer. If you are confused by him saying "not a Discuss" etc, look at the draft tracker we have. It means "if there is an issue so the document need to be updated, I will place a discuss which I will clear when the document is updated". So, first step now is just to ask if he is correct -- whether this should document should be updated or not. If you are unsure, and need to think, just say so, and we will handle this the normal way with "comments". paf Begin forwarded message: > From: Harald Tveit Alvestrand > Date: tor jan 9, 2003 15:28:44 Europe/Stockholm > To: Internet Engineering Steering Group > Subject: Re: Evaluation: draft-ietf-simple-winfo-package - A Session > Initiation Protocol (SIP)Event Template-Package for Watcher > Information to Proposed Standard > > Worry, not a DISCUSS. > May be satisfied with an explanation from Patrik, otherwise I'll plant > a DISCUSS on it and ask for clarification. > > The simple-presence document says: > >> 5 Usage of Presence URIs >> >> A presentity is identified in the most general way through a >> presence >> URI [3], which is of the form pres:user@domain. These URIs are >> protocol independent. They are resolved to protocol specific URIs, >> such as a SIP or SIPS URI, through domain-specific mapping >> policies. >> >> If a subscriber is only aware of the protocol-independent pres URI >> for a presentity, it follows the procedures defined in [5]. These >> procedures will result in the placement of the pres URI in the >> Request-URI of the SIP request, followed by the usage of the DNS >> procedures defined in [5] to determine the host to send the SIP >> request to. Of course, a local outbound proxy may alternatively be >> used, as specified in RFC 3261 [1]. If the subscriber is aware of >> both the protocol-independent pres URI and the SIP or SIPS URI for >> the same presentity, it SHOULD use the SIP or SIPS URI. >> >> SUBSCRIBE messages also contain logical identifiers that define the >> originator and recipient of the subscription (the To and From >> header >> fields). These SHOULD contain SIP or SIPS URIs whenever possible, >> but >> MAY contain a pres URI if a SIP or SIPS URI is not known or >> available. > > [5] is D. Crocker et al. , "Address resolution for instant messaging > and presence," Internet Draft, Internet Engineering Task Force, Oct. > 2002. Work in progress. > > I assume this is draft-ietf-impp-srv-01.txt (same title!). > That draft seems to envision DNS entries of the form > "_pres._sip.example.com" to look up which host to contact when one > wants to use SIP to contact a presentity named > "pres:xyzzy@example.com". > There's no mapping from one type of URI to another - in either > direction. > > This has two problems: > > 1) If a client uses SIP, he presumably has SIP URIs for himself. So he > will use that SIP URI in the From field of a SUBSCRIBE, even though he > also has his own PRES URI. > If the SUBSCRIBE has to be gatewayed to a non-SIP domain, per CPIM, > how is the gateway to find the corresponding PRES URI? > > 2) If a client starts with the PRES URI, and later learns the SIP URI > of someone, and those two identities part way for some reason (perhaps > the client stops using SIP, or the SIP URI was to a proxy service, or > something) - how does the client learn that it's time to go back to > the PRES URI? > > Both problems would be avoided if this document said to use PRES URI > when both are available. > > draft-ietf-impp-serv says: > >> CPIM and CPP both specify operations that have 'source' and >> 'destination' attributes. While only the semantics, not the >> syntax, >> of these attributes are defined by CPIM and CPP, many instant >> messaging and presence protocols today support the use of URIs to >> reflect the source and destination of their operations. Such >> protocols might be able to use the 'im' and 'pres' URI schemes >> directly to express the identities of the principals associated >> with >> a protocol exchange. When these operations pass through a CPIM or >> CPP gateway, these URIs could be relayed without modification, >> which >> has a number of desirable properties for the purposes of >> interoperability. > > Seems to me like a good argument for preferring "pres:" here. > I've added this comment to the tracker too. > > Harald > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 9 18:06:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29890 for ; Thu, 9 Jan 2003 18:06:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09NIJW01637 for simple-archive@odin.ietf.org; Thu, 9 Jan 2003 18:18:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09NIJJ01634 for ; Thu, 9 Jan 2003 18:18:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29826 for ; Thu, 9 Jan 2003 18:05:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09NI3J01619; Thu, 9 Jan 2003 18:18:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09NHxJ01605 for ; Thu, 9 Jan 2003 18:17:59 -0500 Received: from auemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29659 for ; Thu, 9 Jan 2003 18:04:50 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h09N84e03069 for ; Thu, 9 Jan 2003 18:08:04 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA02257; Thu, 9 Jan 2003 17:08:02 -0600 (CST) Message-ID: <3E1E008C.7080802@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Extending for presence Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 09 Jan 2003 17:06:52 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello: discusses extending the element beyond sub-element . defines coarse grained information -- 'open' or 'close' only. Is there any work underway to extend element and define more fine-grained presence/availability information, such as 'away', 'be back in 5 minutes', 'out to lunch', 'busy', etc.? I looked at but while it notes that "[h]istorically, presence has been limited to "on-line" and "off-line" indicators;", I do not see anywhere in that I-D where it extends to something beyond "on-line" and "off-line". Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 9 18:27:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00309 for ; Thu, 9 Jan 2003 18:27:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h09Nd6n02939 for simple-archive@odin.ietf.org; Thu, 9 Jan 2003 18:39:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09Nd5J02936 for ; Thu, 9 Jan 2003 18:39:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00304 for ; Thu, 9 Jan 2003 18:26:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09Nd3J02922; Thu, 9 Jan 2003 18:39:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h09NcdJ02903 for ; Thu, 9 Jan 2003 18:38:39 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00297 for ; Thu, 9 Jan 2003 18:26:14 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h09NUC3i020766; Thu, 9 Jan 2003 18:30:12 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX65070; Thu, 9 Jan 2003 18:34:31 -0500 (EST) Message-ID: <3E1E05D9.90408@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <3E1E008C.7080802@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 09 Jan 2003 18:29:29 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay, Yes, there is work underway. Two current relevant active drafts are: draft-kyzivat-simple-prescaps-reqts-00.txt draft-lonnfors-simple-prescaps-ext-00.txt However, they probably don't cover what you are looking for. At IETF55, the authors of the above were asked to evolve them to address the more general IM status issues such as you mention. We have been discussing that privately, and are working on revisions. It would be very useful to have a few people to use as references, who have detailed knowledge about the various popular IM systems at large. I can tell you right off that one thing I *don't* intend to do is define xml status values like . Instead, I am trying to identify more primitive status elements that can be combined to represent the various states that different IM systems use. ( is of course one of those primitive elements.) If you can act as an expert about one or more existing systems, or if you have specific suggestions, I would be interested in hearing from you. (As far as I'm concerned you don't need to know the code to be an expert. An experienced and observant user is probably sufficient.) Paul Vijay K. Gurbani wrote: > Hello: > > discusses extending the > element beyond sub-element . defines coarse grained > information -- 'open' or 'close' only. > > Is there any work underway to extend element and define more > fine-grained presence/availability information, such as 'away', 'be back > in 5 minutes', 'out to lunch', 'busy', etc.? > > I looked at but while it notes that > "[h]istorically, presence has been limited to "on-line" and "off-line" > indicators;", I do not see anywhere in that I-D where it extends > to something beyond "on-line" and "off-line". > > Thanks, > > - vijay _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 10 11:38:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03056 for ; Fri, 10 Jan 2003 11:38:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AGpFW12623 for simple-archive@odin.ietf.org; Fri, 10 Jan 2003 11:51:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AGpEJ12620 for ; Fri, 10 Jan 2003 11:51:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03047 for ; Fri, 10 Jan 2003 11:38:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AGp9J12608; Fri, 10 Jan 2003 11:51:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AGovJ12577 for ; Fri, 10 Jan 2003 11:50:57 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03000 for ; Fri, 10 Jan 2003 11:38:10 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.7]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0AGfUYH028602; Fri, 10 Jan 2003 11:41:30 -0500 (EST) Message-ID: <3E1EF7B5.6030304@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: simple@ietf.org Subject: Re: [Simple] Fwd: Evaluation: draft-ietf-simple-winfo-package - References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 11:41:25 -0500 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Responses inline. Patrik Fältström wrote: > Begin forwarded message: > >> From: "Wijnen, Bert (Bert)" >> Date: tor jan 9, 2003 17:52:46 Europe/Stockholm >> To: "Iesg-Secretary (E-mail)" >> Cc: "Iesg (E-mail)" >> Subject: Evaluation: draft-ietf-simple-winfo-package - >> >> Subject: Evaluation: draft-ietf-simple-winfo-package - A Session >> Initiation Protocol (SIP)Event Template-Package for Watcher >> Information to Proposed Standard >> -------- >> >> Yes No-Objection Discuss * Abstain >> >> >> Bert Wijnen [ ] [ ] [ X ] [ ] >> >> >> Document draft-ietf-simple-winfo-package-04.txt has improper examples: >> >> SUBSCRIBE sip:joe@bar.com SIP/2.0 >> Via: SIP/2.0/UDP pc34.bar.com;branch=z9hG4bKnashds7 >> From: sip:joe@bar.com;tag=123aa9 >> To: sip:joe@bar.com >> Call-ID: 9987@pc34.bar.com >> CSeq: 9887 SUBSCRIBE >> Contact: sip:joe@pc34.bar.com >> Event: presence.winfo >> Max-Forwards: 70 Yes, you are correct. My apologies here. This is correct in draft-ietf-simple-presence, which uses only example.com. I will fix here and in the the winfo-format document as well. >> >> I do not see IPR sections, as required per our NITS document >> and the RFC2026 rules. This I believe is true for all 3 documents Correct. Fixed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 10 12:39:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05811 for ; Fri, 10 Jan 2003 12:39:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AHqAI17005 for simple-archive@odin.ietf.org; Fri, 10 Jan 2003 12:52:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AHqAJ17002 for ; Fri, 10 Jan 2003 12:52:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05791 for ; Fri, 10 Jan 2003 12:39:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AHq6J16985; Fri, 10 Jan 2003 12:52:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AHpXJ16967 for ; Fri, 10 Jan 2003 12:51:33 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05777 for ; Fri, 10 Jan 2003 12:38:46 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.7]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0AHfvYH028657; Fri, 10 Jan 2003 12:41:58 -0500 (EST) Message-ID: <3E1F05E1.9060105@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: "Vijay K. Gurbani" , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <3E1E008C.7080802@lucent.com> <3E1E05D9.90408@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 12:41:53 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > I can tell you right off that one thing I *don't* intend to do is define > xml status values like . Some more about this. We've had extensive discussions for quite a while on this. The general conclusion, I think, is that things like "out to lunch" are best done by a note which is consumed by a person. You only need new status types if they are consumed by an automata. Its not clear to anyone that an automata would ever need to know that you are out to lunch, as opposed to simply not available, where CLOSED would suffice. One potential usage for these statuses is the display of an icon on the watcher's system. I am intimately familiar with Yahoo, which today has three icons. These indicate available, not-available, and idle. That does beg the question if we need to have an idle status. I suppose another way to handle icons is to send a URI as part of the presence which poitns to the icon. However, I can imagine that you'd want to render the icons differently on different devices; a PC might be ok with a 20x20 jpeg, but that is not going to fly on a wireless phone, which needs something smaller. In that case, sending a status with a defined meaning, which each local watcher can map to a device-appropriate icon, would make more sense. So, would someone ever want to build a system with an "out-to-lunch" icon? Possibly. Certainly not outside the realm of possibility. Where to draw the line is always the question... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 10 13:16:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08362 for ; Fri, 10 Jan 2003 13:16:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AIT5D19306 for simple-archive@odin.ietf.org; Fri, 10 Jan 2003 13:29:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AIT5J19303 for ; Fri, 10 Jan 2003 13:29:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08353 for ; Fri, 10 Jan 2003 13:16:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AIT1J19278; Fri, 10 Jan 2003 13:29:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AISGJ19220 for ; Fri, 10 Jan 2003 13:28:16 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08331 for ; Fri, 10 Jan 2003 13:15:28 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA16797; Fri, 10 Jan 2003 13:18:43 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA13909; Fri, 10 Jan 2003 13:18:45 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Jan 2003 13:18:44 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" , Paul Kyzivat Cc: "Vijay K. Gurbani" , simple@ietf.org Subject: RE: [Simple] Extending for presence MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 13:18:44 -0500 Jonathan Suppose your voicemail greeting depended on your presence status? Out-to-lunch might then be quite useful. I actually don't think this particular example is great, but I do think that there is a use for "On Vacation" vs. "Out of Office". Here, I would forward (at least some) calls to a cellphone for the latter, but not the former. Fine grained presence state is very useful. Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, January 10, 2003 12:42 PM > To: Paul Kyzivat > Cc: Vijay K. Gurbani; simple@ietf.org > Subject: Re: [Simple] Extending for presence > > > > > Paul Kyzivat wrote: > > > I can tell you right off that one thing I *don't* intend to > do is define > > xml status values like . > > Some more about this. We've had extensive discussions for > quite a while > on this. The general conclusion, I think, is that things like "out to > lunch" are best done by a note which is consumed by a person. > You only > need new status types if they are consumed by an automata. > Its not clear > to anyone that an automata would ever need to know that you > are out to > lunch, as opposed to simply not available, where CLOSED would suffice. > > One potential usage for these statuses is the display of an > icon on the > watcher's system. I am intimately familiar with Yahoo, which > today has > three icons. These indicate available, not-available, and idle. That > does beg the question if we need to have an idle status. > > I suppose another way to handle icons is to send a URI as part of the > presence which poitns to the icon. However, I can imagine that you'd > want to render the icons differently on different devices; a > PC might be > ok with a 20x20 jpeg, but that is not going to fly on a > wireless phone, > which needs something smaller. In that case, sending a status with a > defined meaning, which each local watcher can map to a > device-appropriate icon, would make more sense. > > So, would someone ever want to build a system with an "out-to-lunch" > icon? Possibly. Certainly not outside the realm of > possibility. Where to > draw the line is always the question... > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 10 13:24:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08899 for ; Fri, 10 Jan 2003 13:24:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AIb6U20010 for simple-archive@odin.ietf.org; Fri, 10 Jan 2003 13:37:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AIb6J20003 for ; Fri, 10 Jan 2003 13:37:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08854 for ; Fri, 10 Jan 2003 13:24:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AIb1J19852; Fri, 10 Jan 2003 13:37:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AIauJ19807 for ; Fri, 10 Jan 2003 13:36:56 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08809 for ; Fri, 10 Jan 2003 13:24:07 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.7]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0AIRMYH028672; Fri, 10 Jan 2003 13:27:24 -0500 (EST) Message-ID: <3E1F1087.8050607@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: Paul Kyzivat , "Vijay K. Gurbani" , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 13:27:19 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > Jonathan > > Suppose your voicemail greeting depended on your presence status? > Out-to-lunch might then be quite useful. Well, I could argue for TTS applied to the note, but clearly a set of known statuses would work better (you could have recorded audio for each of them rather than attempting TTS on arbitrary text). This is actually a pretty good example use case. > > I actually don't think this particular example is great, but I do > think that there is a use for "On Vacation" vs. "Out of Office". > Here, I would forward (at least some) calls to a cellphone for > the latter, but not the former. Fine grained presence state is > very useful. I think this is a case where you don't really want "on vacation" or "out-of-office" per se, but some kind of more general purpose status with semantics that imply preferences for one type of communications device over another. That leads to an interesting issue. Right now, statuses are always associated with a tuple. Here, I think we are talking about a status element that is truly applicable to the presentity, and not any one of their devices. You can't have presentity-level statuses in PIDF. We could designate a tuple as a "presentity tuple", I suppose, but you'd need some way to convay this fact (perhaps a pres contact address). -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 10 13:40:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10618 for ; Fri, 10 Jan 2003 13:40:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AIqrH21218 for simple-archive@odin.ietf.org; Fri, 10 Jan 2003 13:52:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AIqqJ21214 for ; Fri, 10 Jan 2003 13:52:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10596 for ; Fri, 10 Jan 2003 13:40:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AIqoJ21206; Fri, 10 Jan 2003 13:52:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AIpJJ21154 for ; Fri, 10 Jan 2003 13:51:19 -0500 Received: from ihemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10482 for ; Fri, 10 Jan 2003 13:38:31 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0AIfks20341; Fri, 10 Jan 2003 13:41:46 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA19526; Fri, 10 Jan 2003 12:41:45 -0600 (CST) Message-ID: <3E1F13A1.8010504@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Rosen, Brian" , Paul Kyzivat , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 12:40:33 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: [...] > I think this is a case where you don't really want "on vacation" or > "out-of-office" per se, but some kind of more general purpose status > with semantics that imply preferences for one type of communications > device over another. Often times, the need is not necessarily to establish a communication channel, but just sense presence information. For instance, it suffices to know that my wife is out to lunch; I do not necessarily want to talk to her. So, what you say next is exactly what I have in mind: > That leads to an interesting issue. Right now, statuses are always > associated with a tuple. Here, I think we are talking about a status > element that is truly applicable to the presentity, and not any one of > their devices. You can't have presentity-level statuses in PIDF. We > could designate a tuple as a "presentity tuple", I suppose, but you'd > need some way to convay this fact (perhaps a pres contact address). Or maybe have a tuple whose contact element URI is the same as the entity parameter of the element. Such a tuple pertains to the presentity itself, rather than any of the devices used by that presentity. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 10 13:52:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10964 for ; Fri, 10 Jan 2003 13:52:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AJ5Bh21675 for simple-archive@odin.ietf.org; Fri, 10 Jan 2003 14:05:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AJ5BJ21672 for ; Fri, 10 Jan 2003 14:05:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10955 for ; Fri, 10 Jan 2003 13:52:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AJ56J21664; Fri, 10 Jan 2003 14:05:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AJ4PJ21635 for ; Fri, 10 Jan 2003 14:04:25 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10912 for ; Fri, 10 Jan 2003 13:51:36 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA18468; Fri, 10 Jan 2003 13:54:51 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA19703; Fri, 10 Jan 2003 13:54:53 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Jan 2003 13:54:52 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D09@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" Cc: Paul Kyzivat , "Vijay K. Gurbani" , simple@ietf.org Subject: RE: [Simple] Extending for presence MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 13:54:51 -0500 > > I actually don't think this particular example is great, but I do > > think that there is a use for "On Vacation" vs. "Out of Office". > > Here, I would forward (at least some) calls to a cellphone for > > the latter, but not the former. Fine grained presence state is > > very useful. > > I think this is a case where you don't really want "on vacation" or > "out-of-office" per se, but some kind of more general purpose status > with semantics that imply preferences for one type of communications > device over another. I don't think so. The presentity sets his state by what he is actually doing. The systems around him react to that appropriately. I don't want to have a caller know what is happening (although he might care, the note would work to tell him what to expect when he places a call), but I want my system to decide if it should ring my desk, my cell or my home phone depending on who is calling and what my presence state is. It's up to me (the presentity) to decide if I will in fact forward a call from you to my cellphone if I am "out of office", and in fact, if it's my wife calling, I will forward the call to my mobile even if I'm "On Vacation". So, presence state of "On Vacation" is what my local incoming proxy needs. I make it a watcher, and > > That leads to an interesting issue. Right now, statuses are always > associated with a tuple. Here, I think we are talking about a status > element that is truly applicable to the presentity, and not > any one of > their devices. You can't have presentity-level statuses in PIDF. We > could designate a tuple as a "presentity tuple", I suppose, but you'd > need some way to convay this fact (perhaps a pres contact address). Yeah, but I think this gets complicated fast, and I'm okay with having to set presence for both IM and voice/video independently; I can automate that at the presentity UI. Brian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 10 15:41:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15457 for ; Fri, 10 Jan 2003 15:41:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AKs9128383 for simple-archive@odin.ietf.org; Fri, 10 Jan 2003 15:54:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AKs8J28380 for ; Fri, 10 Jan 2003 15:54:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15452 for ; Fri, 10 Jan 2003 15:41:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AKs4J28371; Fri, 10 Jan 2003 15:54:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AKreJ28340 for ; Fri, 10 Jan 2003 15:53:40 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15444 for ; Fri, 10 Jan 2003 15:40:49 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0AKiguI004337; Fri, 10 Jan 2003 15:44:42 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX71363; Fri, 10 Jan 2003 15:49:01 -0500 (EST) Message-ID: <3E1F308F.5060602@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Rosen, Brian" , "Vijay K. Gurbani" , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 15:43:59 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > Rosen, Brian wrote: > >> Jonathan >> >> Suppose your voicemail greeting depended on your presence status? >> Out-to-lunch might then be quite useful. > > Well, I could argue for TTS applied to the note, but clearly a set of > known statuses would work better (you could have recorded audio for each > of them rather than attempting TTS on arbitrary text). This is actually > a pretty good example use case. If your really want to do this, then TTS seems like a good solution to me. Trying to define distinct status values for every interesting state that you might want to advertise seems like a slippery slope to a mess. Given the definition of PIDF, there is nothing to stop anybody from doing this, but I certainly don't want to take the SIMPLE group there. >> I actually don't think this particular example is great, but I do >> think that there is a use for "On Vacation" vs. "Out of Office". >> Here, I would forward (at least some) calls to a cellphone for >> the latter, but not the former. Fine grained presence state is >> very useful. > > I think this is a case where you don't really want "on vacation" or > "out-of-office" per se, but some kind of more general purpose status > with semantics that imply preferences for one type of communications > device over another. My preferred path is similar. Namely to indicate which media I am willing to communicate with, and which I am not. For instance, if you are on the phone you may be unavailable to accept voice calls, but available to accept IM. If these are different tuples it is easy. If they are part of the same tuple, because your sip device does both, then you need more nuanced status. The callerprefs stuff already handles this, at least to a degree. If On Vacation means your office phone won't answer (or will only take messages), but you can be reached on your mobile phone, and those are represented by different tuples, that is easy to report. If you choose to represent your office and mobile phones by the same tuple, then I'm not sure how you should represent your status. Maybe you should simply change your callerprefs "class" attribute to "personal". > That leads to an interesting issue. Right now, statuses are always > associated with a tuple. Here, I think we are talking about a status > element that is truly applicable to the presentity, and not any one of > their devices. You can't have presentity-level statuses in PIDF. We > could designate a tuple as a "presentity tuple", I suppose, but you'd > need some way to convay this fact (perhaps a pres contact address). You only represent your presence with multiple tuples if you want to, or if they have incompatible means of communication. As long as we are talking about SIMPLE, all the devices can be registered with a single Address of Record and represented as a single tuple. Nevertheless, I can see some value in having global status values that serve as defaults for all tuples. But doing that cleanly would require a change to PIDF. And it would probably complicate PUBLISH. Is it really such a burden to replicate a piece of status in multiple tuples, if that is what you mean? Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 10 15:54:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15959 for ; Fri, 10 Jan 2003 15:54:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AL79Y29134 for simple-archive@odin.ietf.org; Fri, 10 Jan 2003 16:07:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AL79J29131 for ; Fri, 10 Jan 2003 16:07:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15945 for ; Fri, 10 Jan 2003 15:54:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AL76J29039; Fri, 10 Jan 2003 16:07:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AL6cJ28900 for ; Fri, 10 Jan 2003 16:06:38 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15938 for ; Fri, 10 Jan 2003 15:53:46 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0AKveEj006226; Fri, 10 Jan 2003 15:57:40 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX71495; Fri, 10 Jan 2003 16:01:59 -0500 (EST) Message-ID: <3E1F3399.7080403@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Jonathan Rosenberg'" , "Vijay K. Gurbani" , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D09@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 15:56:57 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: >>I think this is a case where you don't really want "on vacation" or >>"out-of-office" per se, but some kind of more general purpose status >>with semantics that imply preferences for one type of communications >>device over another. > > I don't think so. The presentity sets his state by what he is actually > doing. The systems around him react to that appropriately. This is one approach. But not the only one. When I publish that I am "on vacation", I leave it up to the presence client to decide if it is ok to call or not. I might prefer not to share that kind of info with the public, but instead simply say whether I am answering the phone or not. > I don't want to have a caller know what is happening (although he > might care, the note would work to tell him what to expect when he > places a call), but I want my system to decide if it should ring > my desk, my cell or my home phone depending on who is calling and > what my presence state is. The behavior you describe here doesn't require presence at all. This is what callerprefs plus CPL are for. Presence permits the caller to take over some of this. It is exactly why we are trying to get all the callerprefs info into presence. It is interesting to consider a proxy that makes routing decisions based on presence rather than a location service and callerprefs. I firmly believe that this is what would happen if we were starting over with sip - we would use this instead of registration. But given where we are today, I don't think that presence will replace registration any time soon. > It's up to me (the presentity) to decide if I will in fact forward > a call from you to my cellphone if I am "out of office", and in > fact, if it's my wife calling, I will forward the call to my mobile > even if I'm "On Vacation". So, presence state of "On Vacation" is > what my local incoming proxy needs. I make it a watcher, and Surely you can do as you wish. But it is probably unwise to act in ways inconsistent with the presence information you publish. It will simply confuse things. And if you do it enough, your buddies will cease to trust your presence. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 10 16:25:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16819 for ; Fri, 10 Jan 2003 16:25:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ALcAP31400 for simple-archive@odin.ietf.org; Fri, 10 Jan 2003 16:38:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ALc9J31397 for ; Fri, 10 Jan 2003 16:38:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16792 for ; Fri, 10 Jan 2003 16:25:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ALc6J31377; Fri, 10 Jan 2003 16:38:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ALbcJ31334 for ; Fri, 10 Jan 2003 16:37:38 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16781 for ; Fri, 10 Jan 2003 16:24:46 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA25869; Fri, 10 Jan 2003 16:28:02 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA13507; Fri, 10 Jan 2003 16:28:03 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Jan 2003 16:28:02 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D0E@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" Cc: "'Jonathan Rosenberg'" , "Vijay K. Gurbani" , simple@ietf.org Subject: RE: [Simple] Extending for presence MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 16:28:00 -0500 I think we are talking past one another. I expect that my incoming SIP (voice) proxy will become a watcher to my presence. I will change call forwarding for incoming calls based on my presence. There is no way for callerprefs and CPL to do that (well, my CPL implementation could have presence as an input, and I could mechanize the actual call forwarding implementation in CPL). The point is that callER prefs don't have anything to do with it. It depends on "calling" presence. If you, as an acquaintance of mine, have both my sip uri and my mobile phone number, and you become a watcher to my presence, and I show as "Out of Office", you have the option to call me on my mobile number, which I may or may not answer. That is not an automaton, and doesn't need fine grained presence. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, January 10, 2003 3:57 PM > To: Rosen, Brian > Cc: 'Jonathan Rosenberg'; Vijay K. Gurbani; simple@ietf.org > Subject: Re: [Simple] Extending for presence > > > > > Rosen, Brian wrote: > > >>I think this is a case where you don't really want "on vacation" or > >>"out-of-office" per se, but some kind of more general > purpose status > >>with semantics that imply preferences for one type of > communications > >>device over another. > > > > I don't think so. The presentity sets his state by what he > is actually > > doing. The systems around him react to that appropriately. > > This is one approach. But not the only one. > > When I publish that I am "on vacation", I leave it up to the presence > client to decide if it is ok to call or not. I might prefer > not to share > that kind of info with the public, but instead simply say > whether I am > answering the phone or not. > > > I don't want to have a caller know what is happening (although he > > might care, the note would work to tell him what to expect when he > > places a call), but I want my system to decide if it should ring > > my desk, my cell or my home phone depending on who is calling and > > what my presence state is. > > The behavior you describe here doesn't require presence at > all. This is > what callerprefs plus CPL are for. > > Presence permits the caller to take over some of this. It is > exactly why > we are trying to get all the callerprefs info into presence. > > It is interesting to consider a proxy that makes routing > decisions based > on presence rather than a location service and callerprefs. I firmly > believe that this is what would happen if we were starting > over with sip > - we would use this instead of registration. But given where we are > today, I don't think that presence will replace registration > any time soon. > > > It's up to me (the presentity) to decide if I will in fact forward > > a call from you to my cellphone if I am "out of office", and in > > fact, if it's my wife calling, I will forward the call to my mobile > > even if I'm "On Vacation". So, presence state of "On Vacation" is > > what my local incoming proxy needs. I make it a watcher, and > > Surely you can do as you wish. But it is probably unwise to > act in ways > inconsistent with the presence information you publish. It > will simply > confuse things. And if you do it enough, your buddies will cease to > trust your presence. > > Paul > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 10 17:20:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18191 for ; Fri, 10 Jan 2003 17:20:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0AMX7l02110 for simple-archive@odin.ietf.org; Fri, 10 Jan 2003 17:33:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AMX7J02107 for ; Fri, 10 Jan 2003 17:33:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18180 for ; Fri, 10 Jan 2003 17:20:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AMX4J02099; Fri, 10 Jan 2003 17:33:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AMWoJ02076 for ; Fri, 10 Jan 2003 17:32:50 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18177 for ; Fri, 10 Jan 2003 17:19:56 -0500 (EST) Received: from cs.columbia.edu (slip-32-103-192-36.tx.us.prserv.net [32.103.192.36]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0AMMoSY005214 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 10 Jan 2003 17:22:53 -0500 (EST) Message-ID: <3E1F4727.7080506@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Paul Kyzivat , "Vijay K. Gurbani" , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <3E1E008C.7080802@lucent.com> <3E1E05D9.90408@cisco.com> <3E1F05E1.9060105@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 17:20:23 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Some more about this. We've had extensive discussions for quite a while > on this. The general conclusion, I think, is that things like "out to > lunch" are best done by a note which is consumed by a person. You only > need new status types if they are consumed by an automata. Its not clear > to anyone that an automata would ever need to know that you are out to > lunch, as opposed to simply not available, where CLOSED would suffice. > > One potential usage for these statuses is the display of an icon on the > watcher's system. I am intimately familiar with Yahoo, which today has > three icons. These indicate available, not-available, and idle. That > does beg the question if we need to have an idle status. > > I suppose another way to handle icons is to send a URI as part of the > presence which poitns to the icon. However, I can imagine that you'd > want to render the icons differently on different devices; a PC might be > ok with a 20x20 jpeg, but that is not going to fly on a wireless phone, > which needs something smaller. In that case, sending a status with a > defined meaning, which each local watcher can map to a > device-appropriate icon, would make more sense. > > So, would someone ever want to build a system with an "out-to-lunch" > icon? Possibly. Certainly not outside the realm of possibility. Where to > draw the line is always the question... Generally, I find systems that have tokens far better than systems that try to guess at human-entered strings. (We have far too many conventions for this in email subject lines, from Urgent to ADV.) What is the disadvantage of registering a number of status indications? If an entity doesn't know the particular status, it can always use the default rendering for open/closed. Beyond the icon problem, text has the disadvantage that it is very hard to internationalize and much harder, except by error-prone heuristics, to render into non-text items, such as particular sounds (for ADA compliance) and such. My suggestion would be three things: An extensible list of status objects, including the ability to provide things like com.dynamicsoft.at_ietf, a "hint" for an icon (like you suggest) and a note for human consumption. The problem with the icon hint that it can provide a leaky backchannel to see when somebody looked at your presence information. From that, you can probably deduce the watcher's presence information... Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 10 18:47:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20167 for ; Fri, 10 Jan 2003 18:47:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0B00AU07151 for simple-archive@odin.ietf.org; Fri, 10 Jan 2003 19:00:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0B00AJ07148 for ; Fri, 10 Jan 2003 19:00:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20161 for ; Fri, 10 Jan 2003 18:47:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0B006J07138; Fri, 10 Jan 2003 19:00:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ANxPJ07089 for ; Fri, 10 Jan 2003 18:59:25 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20149 for ; Fri, 10 Jan 2003 18:46:31 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0ANoJNV026289; Fri, 10 Jan 2003 18:50:19 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX72758; Fri, 10 Jan 2003 18:54:38 -0500 (EST) Message-ID: <3E1F5C10.2020403@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Jonathan Rosenberg'" , "Vijay K. Gurbani" , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D0E@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 18:49:36 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian - inline. Paul Rosen, Brian wrote: > I think we are talking past one another. Yes, I think so. But what follows helps in figuring out where you are coming from. But not enough yet. > > I expect that my incoming SIP (voice) proxy will become > a watcher to my presence. You say "incoming SIP (voice) proxy" as if that is somehow different than your incoming SIP IM proxy, or presence proxy. You may have different devices responsible for voice and IM, but why would you want them to use a different proxy or registrar, or have a different Address of Record? Then they may all be publishing components of presence status for the same presentity (= AoR). If so, you only have one presence, perhaps with multiple tuples, perhaps not, depending on how you want to expose your presence status. Now you could still build a proxy that routes based on presence. But because it also sees all the devices as contacts on the AoR it can also route without presence - just using callerprefs logic. > I will change call forwarding > for incoming calls based on my presence. There is no > way for callerprefs and CPL to do that I am still confused by how you see this working. Are you saying that the address the proxy is processing is distinct from the contacts in the tuples of the presence document? That there are no REGISTERed contacts for that address (except perhaps for the presence server)? I suppose that would be one way to skin the cat, but not a way I have been considering, or am inclined to favor. > (well, my CPL > implementation could have presence as an input, and I > could mechanize the actual call forwarding implementation > in CPL). The point is that callER prefs don't have > anything to do with it. It depends on "calling" presence. Huh? "calling" presence? > > If you, as an acquaintance of mine, have both my sip uri > and my mobile phone number, and you become a watcher to > my presence, and I show as "Out of Office", you have the > option to call me on my mobile number, which I may or > may not answer. That is not an automaton, and doesn't > need fine grained presence. Why would I want to know both of your numbers? I would much prefer to call sip:brian.rosen@marconi.com regardless and have it go to whichever of your phones you choose to answer. We already have a mechanism to do that in sip - you can register both phones as contacts of sip:brian.rosen@marconi.com. Your proxy can parallel fork to both for everybody, or serially fork to the mobile after trying the office. Or it can, with something like CPL, only try your mobile phone when its a friend calling. Or, I as a caller could specify a callerpref of mobility="mobile", and explicitly select your mobile phone. > > Brian > > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Friday, January 10, 2003 3:57 PM >>To: Rosen, Brian >>Cc: 'Jonathan Rosenberg'; Vijay K. Gurbani; simple@ietf.org >>Subject: Re: [Simple] Extending for presence >> >> >> >> >>Rosen, Brian wrote: >> >> >>>>I think this is a case where you don't really want "on vacation" or >>>>"out-of-office" per se, but some kind of more general >>> >>purpose status >> >>>>with semantics that imply preferences for one type of >>> >>communications >> >>>>device over another. >>> >>>I don't think so. The presentity sets his state by what he >> >>is actually >> >>>doing. The systems around him react to that appropriately. >> >>This is one approach. But not the only one. >> >>When I publish that I am "on vacation", I leave it up to the presence >>client to decide if it is ok to call or not. I might prefer >>not to share >>that kind of info with the public, but instead simply say >>whether I am >>answering the phone or not. >> >> >>>I don't want to have a caller know what is happening (although he >>>might care, the note would work to tell him what to expect when he >>>places a call), but I want my system to decide if it should ring >>>my desk, my cell or my home phone depending on who is calling and >>>what my presence state is. >> >>The behavior you describe here doesn't require presence at >>all. This is >>what callerprefs plus CPL are for. >> >>Presence permits the caller to take over some of this. It is >>exactly why >>we are trying to get all the callerprefs info into presence. >> >>It is interesting to consider a proxy that makes routing >>decisions based >>on presence rather than a location service and callerprefs. I firmly >>believe that this is what would happen if we were starting >>over with sip >>- we would use this instead of registration. But given where we are >>today, I don't think that presence will replace registration >>any time soon. >> >> >>>It's up to me (the presentity) to decide if I will in fact forward >>>a call from you to my cellphone if I am "out of office", and in >>>fact, if it's my wife calling, I will forward the call to my mobile >>>even if I'm "On Vacation". So, presence state of "On Vacation" is >>>what my local incoming proxy needs. I make it a watcher, and >> >>Surely you can do as you wish. But it is probably unwise to >>act in ways >>inconsistent with the presence information you publish. It >>will simply >>confuse things. And if you do it enough, your buddies will cease to >>trust your presence. >> >> Paul >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 10 19:06:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20557 for ; Fri, 10 Jan 2003 19:06:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0B0J9L08232 for simple-archive@odin.ietf.org; Fri, 10 Jan 2003 19:19:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0B0J9J08229 for ; Fri, 10 Jan 2003 19:19:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20532 for ; Fri, 10 Jan 2003 19:06:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0B0J3J08221; Fri, 10 Jan 2003 19:19:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0B0I5J08200 for ; Fri, 10 Jan 2003 19:18:05 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20514 for ; Fri, 10 Jan 2003 19:05:10 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h0B06u53025438; Fri, 10 Jan 2003 19:07:00 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Jan 2003 18:08:21 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6440A@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Rosen, Brian'" , Jonathan Rosenberg Cc: Paul Kyzivat , "Vijay K. Gurbani" , simple@ietf.org Subject: RE: [Simple] Extending for presence MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Jan 2003 18:08:20 -0600 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > I don't think so. The presentity sets his state by what he > is actually > doing. The systems around him react to that appropriately. > I don't want to have a caller know what is happening (although he > might care, the note would work to tell him what to expect when he > places a call), but I want my system to decide if it should ring > my desk, my cell or my home phone depending on who is calling and > what my presence state is. > > It's up to me (the presentity) to decide if I will in fact forward > a call from you to my cellphone if I am "out of office", and in > fact, if it's my wife calling, I will forward the call to my mobile > even if I'm "On Vacation". So, presence state of "On Vacation" is > what my local incoming proxy needs. I make it a watcher, and This application seems a little orthagonal to the whole presence issue in the "PIM" context. Don't get me wrong; it's cool. I just think that there are cleaner ways to do it, probably even in ways that preserve the user experience you have in mind. It seems that we already have tools that can provide this orthagonal call processing (or, at least, are aware of the problems and are actively working on them). For example, you could acheive the same effect as you propose by setting your presence state to CLOSED, adding a human-readable string of "Out of Office", and uploading a new CPL script to your registrar to route calls according to the rules you outline. Of course, this would all be transparent to the user, who has simply clicked on the "Out of Office" menu option. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sat Jan 11 10:24:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13018 for ; Sat, 11 Jan 2003 10:24:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0BFbEJ27142 for simple-archive@odin.ietf.org; Sat, 11 Jan 2003 10:37:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BFbEJ27133 for ; Sat, 11 Jan 2003 10:37:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13011 for ; Sat, 11 Jan 2003 10:24:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BFbBJ27009; Sat, 11 Jan 2003 10:37:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BFafJ26753 for ; Sat, 11 Jan 2003 10:36:42 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13007 for ; Sat, 11 Jan 2003 10:23:28 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0BFQjSY029100 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 11 Jan 2003 10:26:46 -0500 (EST) Message-ID: <3E2037B8.7070008@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 11 Jan 2003 10:26:48 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There seem to be two uses for fine-grained status: - Informing the watchers so that they can adjust their behavior. This is not simply expressible by CPL, say, since the callee really has no good way of judging the importance of communications. Thus, for my department secretary, it is very helpful to know whether I'm in a grad student meeting, at lunch, in an oral exam (interruptible only under the most dire of circumstances), or in a committee meeting (I can easily duck out for a few minutes). I don't know whether I'd want that fine-grained a distinction, but why shouldn't I be allowed to do this, in a locally semantically meaningful way? I'm sure that each specific domain has its own set of status indications that are meaningful within that domain. In a hospital, it might be useful to indicate "doing an operation" vs. "in an administrative meeting", etc. - We've also proposed presence extensions to CPL that take status into account. Again, having enumerated values is much better than trying to do a regexp on a free-form text field. Having explicitly enumerated status indications also allows a separation of concerns. My CPL generator can subscribe to my presence and generate new CPL that fits the situation. That seems much easier and cleaner than having my UA try to update the CPL. Also, the status provides an informal indication of the duration of unavailability. "Out to lunch" makes it likely that the user will return within an hour or so. "On vacation" has a very different implication. Rosen, Brian wrote: > Jonathan > > Suppose your voicemail greeting depended on your presence status? > Out-to-lunch might then be quite useful. > > I actually don't think this particular example is great, but I do > think that there is a use for "On Vacation" vs. "Out of Office". > Here, I would forward (at least some) calls to a cellphone for > the latter, but not the former. Fine grained presence state is > very useful. > > Brian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sat Jan 11 10:29:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13144 for ; Sat, 11 Jan 2003 10:29:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0BFg6J27577 for simple-archive@odin.ietf.org; Sat, 11 Jan 2003 10:42:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BFg6J27574 for ; Sat, 11 Jan 2003 10:42:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13135 for ; Sat, 11 Jan 2003 10:28:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BFg2J27564; Sat, 11 Jan 2003 10:42:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0BFfWJ27545 for ; Sat, 11 Jan 2003 10:41:32 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13126 for ; Sat, 11 Jan 2003 10:28:18 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0BFVaXZ002924 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 11 Jan 2003 10:31:36 -0500 (EST) Message-ID: <3E2038DA.6030601@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E2037B8.7070008@cs.columbia.edu> In-Reply-To: <3E2037B8.7070008@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 11 Jan 2003 10:31:38 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In a previous incarnation of this discussion, a number of people gathered information on what status indications other systems have. I had collected this information at http://www.cs.columbia.edu/sip/drafts/status.txt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sat Jan 11 22:35:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23911 for ; Sat, 11 Jan 2003 22:35:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0C3mae28878 for simple-archive@odin.ietf.org; Sat, 11 Jan 2003 22:48:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0C3maJ28875 for ; Sat, 11 Jan 2003 22:48:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23904 for ; Sat, 11 Jan 2003 22:35:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0C3mWJ28864; Sat, 11 Jan 2003 22:48:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0C3l7J28835 for ; Sat, 11 Jan 2003 22:47:07 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23879 for ; Sat, 11 Jan 2003 22:33:38 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.152]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0C3axYH029222; Sat, 11 Jan 2003 22:36:59 -0500 (EST) Message-ID: <3E20E2D8.7050205@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Rosen, Brian'" , Paul Kyzivat , "Vijay K. Gurbani" , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <9BF66EBF6BEFD942915B4D4D45C051F3A6440A@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 11 Jan 2003 22:36:56 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Adam Roach wrote: >>-----Original Message----- >>From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >> >>I don't think so. The presentity sets his state by what he >>is actually >>doing. The systems around him react to that appropriately. >>I don't want to have a caller know what is happening (although he >>might care, the note would work to tell him what to expect when he >>places a call), but I want my system to decide if it should ring >>my desk, my cell or my home phone depending on who is calling and >>what my presence state is. >> >>It's up to me (the presentity) to decide if I will in fact forward >>a call from you to my cellphone if I am "out of office", and in >>fact, if it's my wife calling, I will forward the call to my mobile >>even if I'm "On Vacation". So, presence state of "On Vacation" is >>what my local incoming proxy needs. I make it a watcher, and > > > This application seems a little orthagonal to the whole presence > issue in the "PIM" context. Don't get me wrong; it's cool. I just > think that there are cleaner ways to do it, probably even > in ways that preserve the user experience you have in mind. I would not be so quick to dismiss presence-based call-routing. I think its an important application, and one we should allow to be properly built. > > It seems that we already have tools that can provide this > orthagonal call processing (or, at least, are aware of the > problems and are actively working on them). For example, you > could acheive the same effect as you propose by setting your > presence state to CLOSED, adding a human-readable string > of "Out of Office", and uploading a new CPL script to your > registrar to route calls according to the rules you outline. The fatal assumption here is that, whenever presence changes in a way which may affect call routing, it is also possible at that time to upload a new CPL. I see several problems here: (1) The thing which is changing the presence state may not know the actual call routing application. For example, consider some nicely fancy call routing application provided by an operator, which is NOT CPL-based (it requires more than CPL can do). This application needs presence. (2) The thing which is changing the presence state may have nothing to do with the entities which can upload a CPL script. Consider the case of an HLR publishing geolocation information as part of my presence. I'd like a call routing application that directs calls to the dynamicsoft TX main number if I am physically in the vicinity of the office (because there is no cell coverage there), to my cell otherwise. The thing publishing my presence has no authority to upload CPL scripts. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sat Jan 11 22:40:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23995 for ; Sat, 11 Jan 2003 22:40:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0C3r3H28977 for simple-archive@odin.ietf.org; Sat, 11 Jan 2003 22:53:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0C3r3J28974 for ; Sat, 11 Jan 2003 22:53:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23977 for ; Sat, 11 Jan 2003 22:39:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0C3r0J28966; Sat, 11 Jan 2003 22:53:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0C3qHJ28946 for ; Sat, 11 Jan 2003 22:52:17 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23966 for ; Sat, 11 Jan 2003 22:38:48 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.152]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0C3g9YH029225; Sat, 11 Jan 2003 22:42:10 -0500 (EST) Message-ID: <3E20E40E.4060904@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: "Rosen, Brian" , "Vijay K. Gurbani" , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 11 Jan 2003 22:42:06 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: > >> >> Well, I could argue for TTS applied to the note, but clearly a set of >> known statuses would work better (you could have recorded audio for >> each of them rather than attempting TTS on arbitrary text). This is >> actually a pretty good example use case. > > > If your really want to do this, then TTS seems like a good solution to > me. Trying to define distinct status values for every interesting state > that you might want to advertise seems like a slippery slope to a mess. Just because the scope of a problem is large, does not mean that one cannot attack a small piece of it. IMHO, the TTS version of this will simply not work suffiently well to be deployable. Internationalization issues, spelling issues, presence of other characters in the subject, etc.,etc. will make this insufficiently robust. As an example: note="0n vactn. :)" To a human, it is clear what this means. To a TTS engine its garbage. > > Given the definition of PIDF, there is nothing to stop anybody from > doing this, but I certainly don't want to take the SIMPLE group there. I guess it really does come down to the scope of the work. As Henning pointed out, we don't want to define statuses for things that a hospital or a university alone will want. But that doesn't mean we should do nothing. If we can enable a set of statuses that is common in existing systems, as a start, I think that perhaps that is a worthwhile goal. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Sat Jan 11 22:57:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24196 for ; Sat, 11 Jan 2003 22:57:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0C4A6329994 for simple-archive@odin.ietf.org; Sat, 11 Jan 2003 23:10:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0C4A6J29991 for ; Sat, 11 Jan 2003 23:10:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24181 for ; Sat, 11 Jan 2003 22:56:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0C4A3J29982; Sat, 11 Jan 2003 23:10:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0C49fJ29939 for ; Sat, 11 Jan 2003 23:09:41 -0500 Received: from mtiwmhc12.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24175 for ; Sat, 11 Jan 2003 22:56:12 -0500 (EST) Received: from cs.columbia.edu ([12.85.3.147]) by mtiwmhc12.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030112035930.CBV12483.mtiwmhc12.worldnet.att.net@cs.columbia.edu>; Sun, 12 Jan 2003 03:59:30 +0000 Message-ID: <3E20E78D.8000203@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 11 Jan 2003 22:57:01 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I guess it really does come down to the scope of the work. As Henning > pointed out, we don't want to define statuses for things that a hospital > or a university alone will want. But that doesn't mean we should do The point was that while me shouldn't ask doctors for their favorite list of pastimes and whereabouts, there is no reason (that I can see) that we should not allow domain-specific status sets, of the edu.columbia variety. There's no collision possibility, and it relieves pressure on IANA and avoids endless discussions as to who needs it. To amplify: I'm not so much concerned about Microsoft and Dynamicsoft adding software-specific status codes, but rather the ability of end-user affinity groups to do so. This seems no harder than adding MIME types. The cell phone industry survives by selling ring tones; maybe they can stay out of Chapter 11 a bit longer by selling cute status icons and sounds :-) > nothing. If we can enable a set of statuses that is common in existing > systems, as a start, I think that perhaps that is a worthwhile goal. I agree. The harm of being inclusive is not obvious to me. Even the longest list of status items in existing systems is well short of a dozen. > > -Jonathan R. > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 13 12:59:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18100 for ; Mon, 13 Jan 2003 12:59:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DIDOO11081 for simple-archive@odin.ietf.org; Mon, 13 Jan 2003 13:13:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DIDOJ11078 for ; Mon, 13 Jan 2003 13:13:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18088 for ; Mon, 13 Jan 2003 12:59:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DIDGJ11069; Mon, 13 Jan 2003 13:13:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DICLJ11047 for ; Mon, 13 Jan 2003 13:12:21 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18080 for ; Mon, 13 Jan 2003 12:58:05 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0DI1Ku06567; Mon, 13 Jan 2003 13:01:20 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA15556; Mon, 13 Jan 2003 12:01:19 -0600 (CST) Message-ID: <3E22FEA1.4010802@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Jan 2003 12:00:01 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > I agree. The harm of being inclusive is not obvious to me. Even the > longest list of status items in existing systems is well short of a dozen. Okay -- so taking this a little further and distilling the status codes from Henning's list (http://www.cs.columbia.edu/sip/drafts/status.txt), we arrive at the following: CLOSED Offline (invisible, lurking) OPEN Available Away (1) Busy-interrupt (2) Busy-no-interrupt (3) Busy-interrupt-authority (4) Custom (1) "Be right back", "Extended away" can all be subsumed in "Away". (2) "On the phone" can be subsumed here if the UA alternate comm- unication capablities (like IM). (3) "Do not disturb" and other domain specific semantics that Henning hinted at (e.g. "surgeon in a surgery; cannot be disturbed") can be subsumed by this sub-status. (4) Here is where other domain specific semantics that Henning mentioned can be subsumed; e.g. "professor in an oral; can be distrubed if the need is paramount". Basically, only those with authority (i.e. a secretary) can interrupt the presentity. Furthermore, I think that for "Busy-no-interrupt" and "Busy-interrupt-with-authority", the specification has to provide some guidance to the software designer. The presentity's UA should *not* even display IMs for the presentity if it in "Busy-no-interrupt" mode. Likewise, if the presentity's UA is in "Busy-interrupt-authority" status, only those IMs from an authorized user (i.e. department secretary, hospital administrator, etc.) should be displayed. Comments? - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 13 13:16:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18544 for ; Mon, 13 Jan 2003 13:16:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DIUBf11699 for simple-archive@odin.ietf.org; Mon, 13 Jan 2003 13:30:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DIUBJ11696 for ; Mon, 13 Jan 2003 13:30:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18511 for ; Mon, 13 Jan 2003 13:15:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DIU6J11684; Mon, 13 Jan 2003 13:30:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DITtJ11656 for ; Mon, 13 Jan 2003 13:29:55 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18507 for ; Mon, 13 Jan 2003 13:15:39 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0DIIpSY027539 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 13 Jan 2003 13:18:52 -0500 (EST) Message-ID: <3E230327.4060705@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E22FEA1.4010802@lucent.com> In-Reply-To: <3E22FEA1.4010802@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Jan 2003 13:19:19 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Based on your summary, there may well be two axes of presence information. One identifies my interruptibility ("busy-no-interrupt") or reachability ("away"), the other the cause of the interruptibility or reachability. In the list quoted, "out to lunch" or "on the phone" are examples of such indications. I think you've covered the first category reasonably well. There still may be value to conveying the second category as enumerated tokens, as they provide useful context. For example, 'extended away' will cause very different behavior than 'out to lunch'. For the former, I will find a substitute person to deal with the issue, for the latter, I'll wait an hour. > Okay -- so taking this a little further and distilling the status codes > from Henning's list (http://www.cs.columbia.edu/sip/drafts/status.txt), > we arrive at the following: > > CLOSED > Offline (invisible, lurking) > > OPEN > Available > Away (1) > Busy-interrupt (2) > Busy-no-interrupt (3) > Busy-interrupt-authority (4) > Custom > > (1) "Be right back", "Extended away" can all be subsumed in "Away". > (2) "On the phone" can be subsumed here if the UA alternate comm- > unication capablities (like IM). > (3) "Do not disturb" and other domain specific semantics that Henning > hinted at (e.g. "surgeon in a surgery; cannot be disturbed") > can be subsumed by this sub-status. > (4) Here is where other domain specific semantics that Henning > mentioned can be subsumed; e.g. "professor in an oral; can be > distrubed if the need is paramount". Basically, only those with > authority (i.e. a secretary) can interrupt the presentity. > > Furthermore, I think that for "Busy-no-interrupt" and > "Busy-interrupt-with-authority", the specification has to provide > some guidance to the software designer. The presentity's UA should > *not* even display IMs for the presentity if it in "Busy-no-interrupt" > mode. Likewise, if the presentity's UA is in "Busy-interrupt-authority" > status, only those IMs from an authorized user (i.e. department > secretary, hospital administrator, etc.) should be displayed. > > Comments? > > - vijay _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 13 13:28:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18952 for ; Mon, 13 Jan 2003 13:28:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DIg9412816 for simple-archive@odin.ietf.org; Mon, 13 Jan 2003 13:42:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DIg9J12813 for ; Mon, 13 Jan 2003 13:42:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18925 for ; Mon, 13 Jan 2003 13:27:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DIg4J12804; Mon, 13 Jan 2003 13:42:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DIfbJ12757 for ; Mon, 13 Jan 2003 13:41:37 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18904 for ; Mon, 13 Jan 2003 13:27:20 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0DIVCFF028241; Mon, 13 Jan 2003 13:31:12 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX79938; Mon, 13 Jan 2003 13:35:29 -0500 (EST) Message-ID: <3E2305C3.5090709@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Jan 2003 13:30:27 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have no problem with interest groups defining their own statuses. Hopefully they will have the wisdom to define suitable ones for their needs. In terms of general ones, my concern is that the kinds of status that I see bandied about are often not clearly distinguished, and the set of them is open ended in nature, so new ones may be invented at any time. This doesn't lend itself well to configuring the handling of these: - I may be able to figure out what kind of automated handling to do for 'Out To Lunch', but then I discover that some people use 'Stepped Out' instead. In the end, this just degenerates into something that can only be handled by human interpretation, so we might was well just use a text message to describe. - One of the big issues seems to be gatewaying between systems that each have their own notion of what set of statuses to offer. We will make the problem worse rather than better if we simply accept every status with a different name as a unique. And accepting every status with the same name as the same is likely wrong too - because often the intended semantics are not quite the same. I believe we are better off sparingly adopting a set of statuses that are more fine grained, and that are orthogonal to one another in meaning, which can be combined in different ways to express the overall status. So, instead of having a status like "In a Meeting", where the buddy must decide the implications, I would prefer to declare the implications. E.g.: - emergency voice calls will be accepted live - all other voice calls go to voicemail - I will accept IM of a business nature, or high priority personal IM - a text status of "In a Meeting" It would be quite feasible for the UI of my system to have an "In meeting" state for me to select that would set all of this up. Paul Henning Schulzrinne wrote: > >> I guess it really does come down to the scope of the work. As Henning >> pointed out, we don't want to define statuses for things that a >> hospital or a university alone will want. But that doesn't mean we >> should do > > > The point was that while me shouldn't ask doctors for their favorite > list of pastimes and whereabouts, there is no reason (that I can see) > that we should not allow domain-specific status sets, of the > edu.columbia variety. There's no collision possibility, and it relieves > pressure on IANA and avoids endless discussions as to who needs it. To > amplify: I'm not so much concerned about Microsoft and Dynamicsoft > adding software-specific status codes, but rather the ability of > end-user affinity groups to do so. This seems no harder than adding MIME > types. > > The cell phone industry survives by selling ring tones; maybe they can > stay out of Chapter 11 a bit longer by selling cute status icons and > sounds :-) > >> nothing. If we can enable a set of statuses that is common in existing >> systems, as a start, I think that perhaps that is a worthwhile goal. > > > I agree. The harm of being inclusive is not obvious to me. Even the > longest list of status items in existing systems is well short of a dozen. > >> >> -Jonathan R. >> >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 13 13:54:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19799 for ; Mon, 13 Jan 2003 13:54:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DJ84v14726 for simple-archive@odin.ietf.org; Mon, 13 Jan 2003 14:08:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DJ84J14723 for ; Mon, 13 Jan 2003 14:08:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19776 for ; Mon, 13 Jan 2003 13:53:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DJ81J14715; Mon, 13 Jan 2003 14:08:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DJ7IJ14470 for ; Mon, 13 Jan 2003 14:07:18 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19756 for ; Mon, 13 Jan 2003 13:53:01 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0DIuFSY025530 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 13 Jan 2003 13:56:16 -0500 (EST) Message-ID: <3E230BEA.7020403@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> In-Reply-To: <3E2305C3.5090709@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Jan 2003 13:56:42 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > I have no problem with interest groups defining their own statuses. > Hopefully they will have the wisdom to define suitable ones for their > needs. And if they don't, they get to suffer the consequences themselves... > - I may be able to figure out what kind of automated handling to do for > 'Out To Lunch', but then I discover that some people use 'Stepped Out' > instead. In the end, this just degenerates into something that can only > be handled by human interpretation, so we might was well just use a text > message to describe. That's why it's important to have a somewhat-stable general set, i.e., where additions are managed so that new things get introduced only rarely. > > - One of the big issues seems to be gatewaying between systems that each > have their own notion of what set of statuses to offer. We will make the > problem worse rather than better if we simply accept every status with a > different name as a unique. And accepting every status with the same > name as the same is likely wrong too - because often the intended > semantics are not quite the same. I don't see how this makes things worse. Either there is match, or there is none. In the latter case, you're no worse off than without having the qualification. Are you arguing that Yahoo's "out to lunch" has a subtly different meaning from some other system that uses the same dscription? > > I believe we are better off sparingly adopting a set of statuses that > are more fine grained, and that are orthogonal to one another in > meaning, which can be combined in different ways to express the overall > status. See my last email on one such division. > > So, instead of having a status like "In a Meeting", where the buddy must > decide the implications, I would prefer to declare the implications. E.g.: > - emergency voice calls will be accepted live > - all other voice calls go to voicemail > - I will accept IM of a business nature, or high priority personal IM > - a text status of "In a Meeting" This is along Vijay's line of thought, it seems. > > It would be quite feasible for the UI of my system to have an "In > meeting" state for me to select that would set all of this up. > > Paul > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 13 14:20:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20775 for ; Mon, 13 Jan 2003 14:20:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DJYGp15894 for simple-archive@odin.ietf.org; Mon, 13 Jan 2003 14:34:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DJYGJ15891 for ; Mon, 13 Jan 2003 14:34:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20739 for ; Mon, 13 Jan 2003 14:19:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DJYAJ15857; Mon, 13 Jan 2003 14:34:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DJXaJ15824 for ; Mon, 13 Jan 2003 14:33:36 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20672 for ; Mon, 13 Jan 2003 14:19:18 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0DJNAHm009102; Mon, 13 Jan 2003 14:23:11 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX80553; Mon, 13 Jan 2003 14:27:27 -0500 (EST) Message-ID: <3E2311F1.7010809@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Jan 2003 14:22:25 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > >> - One of the big issues seems to be gatewaying between systems that >> each have their own notion of what set of statuses to offer. We will >> make the problem worse rather than better if we simply accept every >> status with a different name as a unique. And accepting every status >> with the same name as the same is likely wrong too - because often the >> intended semantics are not quite the same. > > I don't see how this makes things worse. Either there is match, or there > is none. In the latter case, you're no worse off than without having the > qualification. > > Are you arguing that Yahoo's "out to lunch" has a subtly different > meaning from some other system that uses the same dscription? Not that one, because I haven't found an "out to lunch". But while I haven't been able to verify this, I have heard that "offline" users in Yahoo can still be sent messages that will be displayed later, while offline users in MSN can't. >> I believe we are better off sparingly adopting a set of statuses that >> are more fine grained, and that are orthogonal to one another in >> meaning, which can be combined in different ways to express the >> overall status. > > See my last email on one such division. Yes, that is one division that may be helpful - distinguish What from Why. The Why can easily be discarded if not understood. Other than possibly presenting a pretty icon, its not very likely that much if any automated processing will typically be conditioned on it. I prefer to put more attention into getting the What part well defined. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 13 14:28:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20974 for ; Mon, 13 Jan 2003 14:28:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DJg4u16949 for simple-archive@odin.ietf.org; Mon, 13 Jan 2003 14:42:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DJg4J16945 for ; Mon, 13 Jan 2003 14:42:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20962 for ; Mon, 13 Jan 2003 14:27:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DJg1J16933; Mon, 13 Jan 2003 14:42:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DJfRJ16908 for ; Mon, 13 Jan 2003 14:41:27 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20938 for ; Mon, 13 Jan 2003 14:27:09 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0DJUOSY020073 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 13 Jan 2003 14:30:25 -0500 (EST) Message-ID: <3E2313EB.1010706@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E2311F1.7010809@cisco.com> In-Reply-To: <3E2311F1.7010809@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Jan 2003 14:30:51 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Not that one, because I haven't found an "out to lunch". But while I > haven't been able to verify this, I have heard that "offline" users in > Yahoo can still be sent messages that will be displayed later, while > offline users in MSN can't. I agree that we should define terms precisely. > Yes, that is one division that may be helpful - distinguish What from > Why. The Why can easily be discarded if not understood. Other than > possibly presenting a pretty icon, its not very likely that much if any > automated processing will typically be conditioned on it. I prefer to > put more attention into getting the What part well defined. Agreed; beyond icons and sounds, the major reason is probably internationalization and indirect usage by other parties. For example, I may automatically change my CPL script to go to a secretary for 'extended absence', but let it go to voicemail for 'lunch' since the secretary is better at judging urgency, but worse at capturing detailed messages (and likely out to lunch at roughly the same time...). > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 13 14:48:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21516 for ; Mon, 13 Jan 2003 14:48:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DK1uc17785 for simple-archive@odin.ietf.org; Mon, 13 Jan 2003 15:01:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DK1uJ17782 for ; Mon, 13 Jan 2003 15:01:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21492 for ; Mon, 13 Jan 2003 14:47:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DK03J17676; Mon, 13 Jan 2003 15:00:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DJxNJ17624 for ; Mon, 13 Jan 2003 14:59:23 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21448 for ; Mon, 13 Jan 2003 14:45:04 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0DJmqIk015052; Mon, 13 Jan 2003 14:48:52 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX80823; Mon, 13 Jan 2003 14:53:10 -0500 (EST) Message-ID: <3E2317F8.3000805@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Henning Schulzrinne , Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E22FEA1.4010802@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Jan 2003 14:48:08 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > Henning Schulzrinne wrote: > >> I agree. The harm of being inclusive is not obvious to me. Even the >> longest list of status items in existing systems is well short of a >> dozen. > > > Okay -- so taking this a little further and distilling the status codes > from Henning's list (http://www.cs.columbia.edu/sip/drafts/status.txt), > we arrive at the following: > > CLOSED > Offline (invisible, lurking) Note that while I might want to distinguish my own status as really-offline or online-but-invisible, this isn't a distinction that is shared with those that receive my status, at least until we start distinguishing between what is presented to different people. Conceivably I might be seen as some variant on OPEN to my secretary while I am CLOSED to everybody else. But in that case my secretary might also need to know that I am trying to be invisible to others. I don't see quite how to fit that into presence status. > > OPEN > Available > Away (1) > Busy-interrupt (2) > Busy-no-interrupt (3) > Busy-interrupt-authority (4) > Custom > > (1) "Be right back", "Extended away" can all be subsumed in "Away". > (2) "On the phone" can be subsumed here if the UA alternate comm- > unication capablities (like IM). > (3) "Do not disturb" and other domain specific semantics that Henning > hinted at (e.g. "surgeon in a surgery; cannot be disturbed") > can be subsumed by this sub-status. > (4) Here is where other domain specific semantics that Henning > mentioned can be subsumed; e.g. "professor in an oral; can be > distrubed if the need is paramount". Basically, only those with > authority (i.e. a secretary) can interrupt the presentity. The trouble with these "interrupt" kinds of statuses is that there are many nuances. An important one is that my availability may well vary by medium even with a single contact/tuple. Using SIMPLE, I can use the same address for voice, IM, video, etc. When I'm in a meeting voice may not be available at all, or at least will be perceived as an interruption, while IM may be perfectly ok. This suggests that the availability be describable on a per-media basis. > > Furthermore, I think that for "Busy-no-interrupt" and > "Busy-interrupt-with-authority", the specification has to provide > some guidance to the software designer. The presentity's UA should > *not* even display IMs for the presentity if it in "Busy-no-interrupt" > mode. Likewise, if the presentity's UA is in "Busy-interrupt-authority" > status, only those IMs from an authorized user (i.e. department > secretary, hospital administrator, etc.) should be displayed. I can go along with "guidance". The presentity is deciding what status to publish, and must ultimately decide what to do when requests arrive. I do think we need to provide some guidance regarding what the client/buddy should *assume* will happen depending on the status. It is not *required* that the presentity act in accord with that, but if they don't, they will eventually annoy their buddies. So for instance, if I see that you are advertized as offline, I can expect that an invitation will fail. I am still free to try of course. And you are free to answer my call if I do try. But if I often can successfully call you when your presence status is offline, then I will simply learn not to trust presence, which is counterproductive. Some IM clients modify the gui based on the presence status of a buddy. For example, I may not be given a simple option to send a message to someone who is offline. There ought to be enough of a contract so that this makes sense. But I don't think this need be a firm contract. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 13 15:02:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21907 for ; Mon, 13 Jan 2003 15:02:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DKGAg19083 for simple-archive@odin.ietf.org; Mon, 13 Jan 2003 15:16:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKGAJ19080 for ; Mon, 13 Jan 2003 15:16:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21866 for ; Mon, 13 Jan 2003 15:01:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKG5J19068; Mon, 13 Jan 2003 15:16:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKFNJ19030 for ; Mon, 13 Jan 2003 15:15:23 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21854 for ; Mon, 13 Jan 2003 15:01:03 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0DK50L0018393; Mon, 13 Jan 2003 15:05:01 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX80970; Mon, 13 Jan 2003 15:09:18 -0500 (EST) Message-ID: <3E231BC0.3070107@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Adam Roach , "'Rosen, Brian'" , "Vijay K. Gurbani" , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <9BF66EBF6BEFD942915B4D4D45C051F3A6440A@DYN-TX-EXCH-001.dynamicsoft.com> <3E20E2D8.7050205@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Jan 2003 15:04:16 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > I would not be so quick to dismiss presence-based call-routing. I think > its an important application, and one we should allow to be properly built. I too am interested in presence-based routing. I had thought the world wasn't ready for it yet, and so have postponed discussing it publicly. But maybe I was wrong, and it is time to discuss it. One place where this is very interesting is for call-center routing. For this you may have a proxy trying to select one among many (hundreds, thousands) of presentities, each characterized by various sorts of presence status. This will typically involve some call-center specific status values having to do with things like skill in dealing with certain topics. But it also involves some of the more general things we are talking about here. For instance, a call-center agent on a voice call typically can't take another call at the same time. But a call center agent handling an IM call may well be able to take another one. And if the one agent skilled in a particular topic is away momentarily, it may be better to have a call wait than assign it to a less skilled agent. The key here is that typically this kind of routing is across a number of presentities. In this form it doesn't compete with normal proxy routing across the multiple contacts of a single Address of Record. Taken to the extreme, presence based routing could replace registration altogether. But I doubt we want to go there, at least yet. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 13 15:14:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22503 for ; Mon, 13 Jan 2003 15:14:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DKSHd19683 for simple-archive@odin.ietf.org; Mon, 13 Jan 2003 15:28:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKSHJ19680 for ; Mon, 13 Jan 2003 15:28:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22479 for ; Mon, 13 Jan 2003 15:14:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKS6J19672; Mon, 13 Jan 2003 15:28:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKRXJ19649 for ; Mon, 13 Jan 2003 15:27:33 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22436 for ; Mon, 13 Jan 2003 15:13:13 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0DKGRj00486; Mon, 13 Jan 2003 15:16:27 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA24411; Mon, 13 Jan 2003 14:16:26 -0600 (CST) Message-ID: <3E231E4B.5090606@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne , Paul Kyzivat CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Jan 2003 14:15:07 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Paul Kyzivat wrote: > >> I have no problem with interest groups defining their own statuses. >> Hopefully they will have the wisdom to define suitable ones for their >> needs. > > And if they don't, they get to suffer the consequences themselves... Agreed. Paul Kyzivat wrote: > - One of the big issues seems to be gatewaying between systems that > each have their own notion of what set of statuses to offer. We will > make the problem worse rather than better if we simply accept every > status with a different name as a unique. And accepting every status > with the same name as the same is likely wrong too - because often the > intended semantics are not quite the same. The best gateway is no gateway, of course. Given that xmpp and simple work is being done right here in IETF, hopefully we can reach a consensus for a set of status codes between the two (maybe in impp WG)? That leaves Yahoo! Messenger, AOL, and Microsoft. Presumably, Microsoft supports simple, so that leaves Yahoo! and AOL. Gateway'ing will then be needed between IETF standardized sytems and Yahoo! and AOL. Just for completion, IETF is not interested in definining gateway procedures *between* Yahoo! and AOL. Henning Schulzrinne wrote: > Paul Kyzivat wrote: >> So, instead of having a status like "In a Meeting", where the buddy >> must decide the implications, I would prefer to declare the >> implications. E.g.: >> - emergency voice calls will be accepted live >> - all other voice calls go to voicemail >> - I will accept IM of a business nature, or high priority personal IM >> - a text status of "In a Meeting" > > This is along Vijay's line of thought, it seems. Yes; if we can do this by having such primitive status codes, we should. I don't think anyone argues that we should have fine grained status beyond OPEN and CLOSED. CLOSED is very simple to deal with; the big problem is how to (sub)classify OPEN. We can take the list I proposed and Henning's response to that as a start. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 13 15:24:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22870 for ; Mon, 13 Jan 2003 15:24:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DKc8e20792 for simple-archive@odin.ietf.org; Mon, 13 Jan 2003 15:38:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKc8J20789 for ; Mon, 13 Jan 2003 15:38:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22863 for ; Mon, 13 Jan 2003 15:23:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKc2J20750; Mon, 13 Jan 2003 15:38:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKZfJ19988 for ; Mon, 13 Jan 2003 15:35:41 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22757 for ; Mon, 13 Jan 2003 15:21:23 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0DKOej03217; Mon, 13 Jan 2003 15:24:40 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA27984; Mon, 13 Jan 2003 14:24:39 -0600 (CST) Message-ID: <3E232038.8030804@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Paul Kyzivat , Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E2311F1.7010809@cisco.com> <3E2313EB.1010706@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Jan 2003 14:23:20 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: >> Yes, that is one division that may be helpful - distinguish What from >> Why. The Why can easily be discarded if not understood. Other than >> possibly presenting a pretty icon, its not very likely that much if >> any automated processing will typically be conditioned on it. I prefer >> to put more attention into getting the What part well defined. > > Agreed; beyond icons and sounds, the major reason is probably > internationalization and indirect usage by other parties. For example, I > may automatically change my CPL script to go to a secretary for > 'extended absence', but let it go to voicemail for 'lunch' since the > secretary is better at judging urgency, but worse at capturing detailed > messages (and likely out to lunch at roughly the same time...). I have no problems separating the 'What' from 'Why'; however, I think a tacit assumption we are all making is that the presence information is to be used for call (or session) routing (maybe because IM and P are so conjoined to begin with). While this is definitely an advantage, I think that in many instances, presence information stands on its own -- just knowing that my spouse/wife/co-worker is out to lunch is enough. As I have noticed (and Paul, too), Yahoo! Messenger allows one to send an IM to a presentity that is not even online. When the presentitiy comes online, the IM is delivered to it. It just seems to me that we should decouple the need to establish sessions from representing the notion of presence itself. If we carve out the status codes nicely, maybe establishing a session will fall automatically into place based on the primitives we posit. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 13 15:43:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23501 for ; Mon, 13 Jan 2003 15:43:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DKv8U21656 for simple-archive@odin.ietf.org; Mon, 13 Jan 2003 15:57:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKv8J21653 for ; Mon, 13 Jan 2003 15:57:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23488 for ; Mon, 13 Jan 2003 15:42:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKv4J21638; Mon, 13 Jan 2003 15:57:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKuZJ21619 for ; Mon, 13 Jan 2003 15:56:35 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23478 for ; Mon, 13 Jan 2003 15:42:17 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0DKjYj11639; Mon, 13 Jan 2003 15:45:34 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA07085; Mon, 13 Jan 2003 14:45:33 -0600 (CST) Message-ID: <3E23251E.9090200@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Henning Schulzrinne , Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E22FEA1.4010802@lucent.com> <3E2317F8.3000805@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Jan 2003 14:44:14 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: >> CLOSED >> Offline (invisible, lurking) > > Note that while I might want to distinguish my own status as > really-offline or online-but-invisible, this isn't a distinction that is > shared with those that receive my status, at least until we start > distinguishing between what is presented to different people. No; I am not advocating sharing the 'invisible' or 'lurking' state with other users. It's good for the system to know; to the users, the presntitiy is CLOSED (Unavailable, Offline, whatever...) > Conceivably I might be seen as some variant on OPEN to my secretary > while I am CLOSED to everybody else. But in that case my secretary might > also need to know that I am trying to be invisible to others. I don't > see quite how to fit that into presence status. If my secretary needs to contact me (i.e. I am OPEN to my secretary and CLOSED to everyone else) then, the presence status is "Busy-interrupt-authority". More inline. >> >> OPEN >> Available >> Away (1) >> Busy-interrupt (2) >> Busy-no-interrupt (3) >> Busy-interrupt-authority (4) >> Custom >> >> (1) "Be right back", "Extended away" can all be subsumed in "Away". >> (2) "On the phone" can be subsumed here if the UA alternate comm- >> unication capablities (like IM). >> (3) "Do not disturb" and other domain specific semantics that Henning >> hinted at (e.g. "surgeon in a surgery; cannot be disturbed") >> can be subsumed by this sub-status. >> (4) Here is where other domain specific semantics that Henning >> mentioned can be subsumed; e.g. "professor in an oral; can be >> distrubed if the need is paramount". Basically, only those with >> authority (i.e. a secretary) can interrupt the presentity. > > The trouble with these "interrupt" kinds of statuses is that there are > many nuances. > > An important one is that my availability may well vary by medium even > with a single contact/tuple. Using SIMPLE, I can use the same address > for voice, IM, video, etc. When I'm in a meeting voice may not be > available at all, or at least will be perceived as an interruption, > while IM may be perfectly ok. > This suggests that the availability be describable on a per-media basis. As IM, like voice, becomes a dominant communication channel, the nuances of the "interrupt" kind really boil down to 2 media types -- IM, and voice/video/gaming communications. I can accept IM even when I am "Busy-interrupt", but I cannot accept voice/video sessions in that state. Definitely doable, I think. Even while accepting IM, I can only accept IMs in "pager" mode, rather than "session" mode. >> Furthermore, I think that for "Busy-no-interrupt" and >> "Busy-interrupt-with-authority", the specification has to provide >> some guidance to the software designer. The presentity's UA should >> *not* even display IMs for the presentity if it in "Busy-no-interrupt" >> mode. Likewise, if the presentity's UA is in "Busy-interrupt-authority" >> status, only those IMs from an authorized user (i.e. department >> secretary, hospital administrator, etc.) should be displayed. > > I can go along with "guidance". The presentity is deciding what status > to publish, and must ultimately decide what to do when requests arrive. > > I do think we need to provide some guidance regarding what the > client/buddy should *assume* will happen depending on the status. It is > not *required* that the presentity act in accord with that, but if they > don't, they will eventually annoy their buddies. > > So for instance, if I see that you are advertized as offline, I can > expect that an invitation will fail. I am still free to try of course. > And you are free to answer my call if I do try. But if I often can > successfully call you when your presence status is offline, then I will > simply learn not to trust presence, which is counterproductive. Hence the need to decouple establishing sessions from representing the notion of presence itself. Maybe Yahoo! Messenger has trained its users to send IM to people who appear offline, but the tacit understanding there is that the receiver of the IM is offline, so don't expect an immediate response (I am not sure what the system does -- i.e. does it deliver the IM to a presentity that is lurking or invisible? I think not.) However, the notion of voice/video communications is more subtle -- it cannot be queued, so to speak, while the receiver is offline. Both parties need to be present at the same time for an interactive voice/video session to succeed. I think that as a first cut, we should focus on representing the various states of OPEN based simply on the premise of presence itself; not necessarily on the intent of establishing a session. Once we have that list of status codes, we can see if they aid (or hinder) in if session establishing semantics are applied to them. > Some IM clients modify the gui based on the presence status of a buddy. > For example, I may not be given a simple option to send a message to > someone who is offline. There ought to be enough of a contract so that > this makes sense. But I don't think this need be a firm contract. I for one have gotten used to sending an IM to a Yahoo! Buddy who is offline because I know the system will queue it up and deliver it later. However, as used as I am to this behavior, I would not think of establishing an interactive communication session (be it an IM "session mode" or voice/video session) with an offline presentity. The contract maybe as simple as simple as providing some hints on establishing interactive media sessions based on presence information. While "pager" mode IMs maybe okay, "session" mode IMs or interactive voice/video/gaming sessions probably do not make sense if the receipient is showing an offline status. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 13 16:21:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24708 for ; Mon, 13 Jan 2003 16:21:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DLZAw23895 for simple-archive@odin.ietf.org; Mon, 13 Jan 2003 16:35:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DLZAJ23892 for ; Mon, 13 Jan 2003 16:35:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24676 for ; Mon, 13 Jan 2003 16:20:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DLZ6J23884; Mon, 13 Jan 2003 16:35:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DLYeJ23853 for ; Mon, 13 Jan 2003 16:34:40 -0500 Received: from marionberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24670 for ; Mon, 13 Jan 2003 16:20:21 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0DLNWli014538 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 13 Jan 2003 16:23:33 -0500 (EST) Message-ID: <3E232E6F.2020305@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Paul Kyzivat , Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E22FEA1.4010802@lucent.com> <3E2317F8.3000805@cisco.com> <3E23251E.9090200@lucent.com> In-Reply-To: <3E23251E.9090200@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Jan 2003 16:23:59 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > If my secretary needs to contact me (i.e. I am OPEN to my secretary > and CLOSED to everyone else) then, the presence status is > "Busy-interrupt-authority". I guess you'd use the Contact field to provide the secretary name? > As IM, like voice, becomes a dominant communication channel, the nuances > of the "interrupt" kind really boil down to 2 media types -- IM, and > voice/video/gaming communications. I can accept IM even when I am Usually, it would be audio or anything-else (one could imagine that somebody could write notes on their whiteboard and point a camera at it, or my wife could use sign language since she can talk and sign at the same time...). However, we had discussed various sidebar conferences, where I can put my main conference in the background. > "Busy-interrupt", but I cannot accept voice/video sessions in that > state. Definitely doable, I think. Even while accepting IM, I can > only accept IMs in "pager" mode, rather than "session" mode. Why shouldn't I have two IM sessions going at the same time, at least as a multitasking teenager? > The contract maybe as simple as simple as providing some hints on > establishing interactive media sessions based on presence information. > While "pager" mode IMs maybe okay, "session" mode IMs or interactive > voice/video/gaming sessions probably do not make sense if the receipient > is showing an offline status. > > Regards, > > - vijay _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 13 18:09:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27695 for ; Mon, 13 Jan 2003 18:09:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DNNAj31402 for simple-archive@odin.ietf.org; Mon, 13 Jan 2003 18:23:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DNNAJ31399 for ; Mon, 13 Jan 2003 18:23:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27692 for ; Mon, 13 Jan 2003 18:08:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DNN6J31371; Mon, 13 Jan 2003 18:23:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DNMxJ31352 for ; Mon, 13 Jan 2003 18:22:59 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27685 for ; Mon, 13 Jan 2003 18:08:36 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h0DNAPeV004458; Mon, 13 Jan 2003 18:10:25 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Jan 2003 17:11:52 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64410@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , Adam Roach Cc: "'Rosen, Brian'" , Paul Kyzivat , "Vijay K. Gurbani" , simple@ietf.org Subject: RE: [Simple] Extending for presence MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Jan 2003 17:11:47 -0600 > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > The fatal assumption here is that, whenever presence changes in a way > which may affect call routing, it is also possible at that time to > upload a new CPL. I see several problems here... Yep. Good points. Given that, it makes sense at some level that we want machine-readable presence information that conveys more than just "OPEN" and "CLOSED". Vijay's list seems like a reasonable starting point. (For the sake of finer grained control, I'd like something more along the lines of "Available/Away/Busy", where "Busy" further has a "priority" parameter or similar that indicates the interruptability of the user). Henning proposes that this is one of two axes that need to be nailed down -- that of reachability. The second he identifies is cause. I would argue that cause is inherently human consumable, and should be a free-form non-machine-interpreted string. So, how do we end up triggering different behavior for "Out to Lunch" versus "On Vacation?" I think it would be useful to explore what the *parameters* are that make these situations different, as opposed to inferring semantics from the meanings of the actual phrases. In this particular case, the fundamental difference is the period of time for which a user will be gone. So, that would point to adding an optional "duration" parameter to "away" (and "busy") that would be used to indicate -- at least, on an order of magnitude, how long the condition is expected to continue. I wouldn't expect to include, say, an actual number of seconds, as much as, for example, knowing the unit of time that would be appropriate. Literally, you would communicate the difference between "Out to Lunch" and "On Vacation" as "duration=minutes" versus "duration=days". I'm reasonably certain that, with a minor effort, we could flesh out additional parameters to apply to the basic "Available/Away/Busy" statuses that would be sufficient to convey a suitably rich set of statuses. Comments on whether this is a direction the group would be interested in exploring? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 13 18:34:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28360 for ; Mon, 13 Jan 2003 18:34:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0DNmEv00352 for simple-archive@odin.ietf.org; Mon, 13 Jan 2003 18:48:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DNmDJ00349 for ; Mon, 13 Jan 2003 18:48:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28340 for ; Mon, 13 Jan 2003 18:33:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DNm7J00340; Mon, 13 Jan 2003 18:48:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DNlVJ00318 for ; Mon, 13 Jan 2003 18:47:31 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28334 for ; Mon, 13 Jan 2003 18:33:08 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0DNatmV029055; Mon, 13 Jan 2003 18:36:55 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX82636; Mon, 13 Jan 2003 18:41:13 -0500 (EST) Message-ID: <3E234D6A.20200@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Henning Schulzrinne , Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E22FEA1.4010802@lucent.com> <3E2317F8.3000805@cisco.com> <3E23251E.9090200@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Jan 2003 18:36:10 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > Paul Kyzivat wrote: > >>> CLOSED >>> Offline (invisible, lurking) >> >> >> Note that while I might want to distinguish my own status as >> really-offline or online-but-invisible, this isn't a distinction that >> is shared with those that receive my status, at least until we start >> distinguishing between what is presented to different people. > > No; I am not advocating sharing the 'invisible' or 'lurking' state with > other users. It's good for the system to know; to the users, the > presntitiy is CLOSED (Unavailable, Offline, whatever...) OK - at least we agree it isn't shared with buddies. But I'm concerned what you mean by "good for the system to know". I think its helpful/necessary for the UAC representing the user to know. It is not necessarily necessary for anything else to know. In particular, the presence server representing the user's presentity may not know. Presence servers representing your buddies may be aware that you have active subscriptions to their presence, and so are active in some sense, but they may or may be be able to infer anything useful from that. It certainly isn't an explicit indication of your presence. >> The trouble with these "interrupt" kinds of statuses is that there are >> many nuances. >> >> An important one is that my availability may well vary by medium even >> with a single contact/tuple. Using SIMPLE, I can use the same address >> for voice, IM, video, etc. When I'm in a meeting voice may not be >> available at all, or at least will be perceived as an interruption, >> while IM may be perfectly ok. >> This suggests that the availability be describable on a per-media basis. > > > As IM, like voice, becomes a dominant communication channel, the nuances > of the "interrupt" kind really boil down to 2 media types -- IM, and > voice/video/gaming communications. Why do you split it this way? (IM and Other). Certainly gaming is independent of the others. And the coupling between voice and video isn't complete. (While video is frequently assumed to require voice, voice certainly doesn't require video.) Suppose I have something to show you, and so only want to call you when you are at a video phone. Your presence at an audio phone isn't good enough for me. > I can accept IM even when I am > "Busy-interrupt", but I cannot accept voice/video sessions in that > state. Definitely doable, I think. Even while accepting IM, I can > only accept IMs in "pager" mode, rather than "session" mode. But these are not absolute rules. Maybe you can accept video too, just not voice. (So your assistant can send you text and a video view of the riot happening outside your office while you are in a meeting with the CEO.) >> So for instance, if I see that you are advertized as offline, I can >> expect that an invitation will fail. I am still free to try of course. >> And you are free to answer my call if I do try. But if I often can >> successfully call you when your presence status is offline, then I >> will simply learn not to trust presence, which is counterproductive. > > Hence the need to decouple establishing sessions from representing > the notion of presence itself. I'm not convinced we can/should do that. Maybe we don't want to restrict it to "establishing sessions", but at least to communicating with the presentity via its contacts. Without grounding ourselves in a purpose for the presence, there is no way to scope what we mean by presence. Is it ok for me to describe part of my presence state as "traveling the South Seas for a year", or "retired in Florida"? It is especially important to focus in this way when defining SIMPLE extensions - there might be a broader scope for PIDF in general. > Maybe Yahoo! Messenger has trained > its users to send IM to people who appear offline, but the tacit > understanding there is that the receiver of the IM is offline, so > don't expect an immediate response (I am not sure what the system > does -- i.e. does it deliver the IM to a presentity that is > lurking or invisible? I think not.) However, the notion of > voice/video communications is more subtle -- it cannot be queued, > so to speak, while the receiver is offline. Certainly it can. That is what voicemail is for. If I have voicemail, my presentity is probably never entirely offline for voice. However something should distinguish between being online live and being online with voicemail. > Both parties need to > be present at the same time for an interactive voice/video session to > succeed. > > I think that as a first cut, we should focus on representing the > various states of OPEN based simply on the premise of presence itself; > not necessarily on the intent of establishing a session. Once we > have that list of status codes, we can see if they aid (or hinder) in > if session establishing semantics are applied to them. Reason I disagree above. >> Some IM clients modify the gui based on the presence status of a >> buddy. For example, I may not be given a simple option to send a >> message to someone who is offline. There ought to be enough of a >> contract so that this makes sense. But I don't think this need be a >> firm contract. > > I for one have gotten used to sending an IM to a Yahoo! Buddy who is > offline because I know the system will queue it up and deliver it > later. However, as used as I am to this behavior, I would not think > of establishing an interactive communication session (be it an IM > "session mode" or voice/video session) with an offline presentity. As these "systems" start to interoperate using SIMPLE (I hope), you won't know whether you are talking to a Yahoo user or an MSN user. So you had better not need to know before deciding to send a message. What will you do if you see a presence status of Do Not Disturb? Most IM systems will at least make it difficult for you to initiate communication. But you could still pick up the phone and call, and maybe it would ring. It this stuff is all well integrated, Do Not Disturb should be correlated with a UA that will actually refuse incoming calls of all sorts. > > The contract maybe as simple as simple as providing some hints on > establishing interactive media sessions based on presence information. > While "pager" mode IMs maybe okay, "session" mode IMs or interactive > voice/video/gaming sessions probably do not make sense if the receipient > is showing an offline status. I think some work is required to sort out how we represent the distinction between page and session mode IM. If we aren't careful, page mode will be abused to get around restrictions is session mode. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 14 09:38:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25302 for ; Tue, 14 Jan 2003 09:38:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EEr9c01200 for simple-archive@odin.ietf.org; Tue, 14 Jan 2003 09:53:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EEr9J01197 for ; Tue, 14 Jan 2003 09:53:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25272 for ; Tue, 14 Jan 2003 09:38:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EEr2J01170; Tue, 14 Jan 2003 09:53:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EEpYJ01105 for ; Tue, 14 Jan 2003 09:51:34 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25224 for ; Tue, 14 Jan 2003 09:36:50 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0EEgHt04168 for ; Tue, 14 Jan 2003 16:42:17 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 14 Jan 2003 16:40:07 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 16:40:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] PUBLISH requirements Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD17A@esebe013.ntc.nokia.com> Thread-Topic: [Simple] PUBLISH requirements Thread-Index: AcKiaYVlbbH5Y74PQaucmgoM89CYawT6gUBQ To: X-OriginalArrivalTime: 14 Jan 2003 14:40:06.0877 (UTC) FILETIME=[D4E3F8D0:01C2BBDA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0EEpYJ01106 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Jan 2003 16:40:06 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit [Resending - was using the old list the last time] Hi, Comments inline. > aki.niemi@nokia.com wrote: > > > The discussion in the SIMPLE session in Atlanta lead us towards > > another round of PUBLISH requirements. I think it would be good to > > look at some requirements that might be arising from the fact that > > the dynamics of publishing are distinctly different from > the dynamics > > of notification. > > Yes, I agree. Makes you glad we didn't go for NOTIFY as the > publication > mechanism... > > In order for the composer to make a > > coherent, single presence document out of the information > coming from > > many sources, the composer should be able to identify the published > > information uniquely across all of the PUAs of a presentity. > > The information is needed by others too. A presentity might want to > setup a policy that says "only Joe and Bob can see my cell > phone". That > requires some unique way for the composer to identify which > tuple is the > cell phone. Exactly. And in addition, I think there is actually some hard state that needs to be configured along with such a policy. For example, if none of my PUAs are publishing, what will my presence document say? Will it have an offline "cell-phone" tuple, or no such tuple at all. This sort of configuration of a presence "profile" (I know, horribly mis/overused term, but can't think of a better one now...), including some sort of default state or fall-back tuple, attached policy and such really seems not to fit the current scope of PUBLISH, although seems to be implicitly in there. So how about clearly separating the requirements for the soft-state updating, and any hard-state, or configuration of presence, and then see what is in scope for the PUBLISH mechanism? > > For example, if we say that a tuple is the base data unit of > > published presence information, then a specific tuple has to have a > > common ID across all PUAs of a presentity. In other words, the > > tuple-id needs to have semantics associated with it. This way the > > composer can merge two "im-inbox" publications into one single > > presence document tuple. This seems like an additional requirement > > for PIDF when it is used in publishing presence state. > > I think this is a slightly different issue than above. One > requirement > is just identification of the tuples whose scope is broader > than the id > attribute. What you are suggesting here, I think, is almost to define > different classes of tuples. THis way, if I have two PCs, > each of which > has an "im-inbox", the composer could know to combine (or > treat in the > appropriate manner) those two tuples. That seems more of a > slippery slope. It very well may be. But yes, that is pretty much what I was suggesting. But I do realize that this sort of configuration is really not in the scope of PUBLISH, although so far has sort of been implicitly included as the "composer policy". For clarity's sake, I think we will also need to document the hard-state portion of the presence publishing requirements. > > In addition to this, I think there may also be other requirements > > there related to expiration of state, and the fact that not all > > presence information is wrapped into a element. E.g., the > > presentity level element is not dependent of any > tuples. How > > does one only publish a ? Or remove it? > > Well, PIDF is going to change to allow a document with just a note. I > raised this issue in IMPP and folks were ok with the change. > > Now, to remove a note, you'd presumably publish an empty document. > > That is, the assumption is that, as far as each publication > instance is > concerned, each publication represents the complete presence > state from > that instance. I guess the ability to only publish the note portion of a PIDF doc solves the problem, at least most of it. I'd still like to get a handle on exactly how this jives with expiration. I.e., I go on vacation and publish a note saying exactly that. This note should be persistent over any publication in the mean time that has no note element in it... Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 14 10:45:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28569 for ; Tue, 14 Jan 2003 10:45:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EFxIm06571 for simple-archive@odin.ietf.org; Tue, 14 Jan 2003 10:59:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EFxHJ06568 for ; Tue, 14 Jan 2003 10:59:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28501 for ; Tue, 14 Jan 2003 10:44:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EFx6J06557; Tue, 14 Jan 2003 10:59:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EFwrJ06525 for ; Tue, 14 Jan 2003 10:58:53 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28442 for ; Tue, 14 Jan 2003 10:44:10 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0EFlS217753; Tue, 14 Jan 2003 10:47:28 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA20132; Tue, 14 Jan 2003 09:47:27 -0600 (CST) Message-ID: <3E2430BB.40203@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E22FEA1.4010802@lucent.com> <3E2317F8.3000805@cisco.com> <3E23251E.9090200@lucent.com> <3E234D6A.20200@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Jan 2003 09:46:03 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Trimming CC list] Paul Kyzivat wrote: > > > Vijay K. Gurbani wrote: > >> No; I am not advocating sharing the 'invisible' or 'lurking' state with >> other users. It's good for the system to know; to the users, the >> presntitiy is CLOSED (Unavailable, Offline, whatever...) > > > OK - at least we agree it isn't shared with buddies. > > But I'm concerned what you mean by "good for the system to know". I > think its helpful/necessary for the UAC representing the user to know. > It is not necessarily necessary for anything else to know. In an end-to-end system, true. Only the UAC representing the user needs to know. But I have a feeling that systems like Yahoo! Messenger also store central state -- I just checked. On Yahoo! Messenger, I can send an IM to a buddy that appears offline to me but is, in fact, online and invisible. The system does deliver the IM to the lurking buddy; but it will queue it up if the buddy is actually offline. >> As IM, like voice, becomes a dominant communication channel, the nuances >> of the "interrupt" kind really boil down to 2 media types -- IM, and >> voice/video/gaming communications. > > Why do you split it this way? (IM and Other). Merely on the basis of establishing an interactive communication channel or not. Pager mode IM does not need interactive presence of all participants; voice/video/gaming sessions do. > Suppose I have something to show you, and so only want to call you when > you are at a video phone. Your presence at an audio phone isn't good > enough for me. That's where presence and routing conflate, IMHO. While my presence at an audio phone may not suffice your requirements, it may provide a lot of value to someone else who is interested in it. But I am realizing that de-coupling presence and routing at this point in time is too late. For instance, itself includes a "priority" parameter to the element to aid in routing, not to mention a Contact URI. In my naive world, each presentity would be represented by multiple devices, each such device merely representing its presence state in richer primitives than "OPEN", "CLOSED". Then, when we add routing to the mix, we would do so in a separate namespace for each device. >> Hence the need to decouple establishing sessions from representing >> the notion of presence itself. > > I'm not convinced we can/should do that. Maybe we don't want to restrict > it to "establishing sessions", but at least to communicating with the > presentity via its contacts. I had in mind, as a base set, the absolute primitive notion of presence. No implications on any sort of communications. These would be overlayed as separate namespaces. But, as I said above, it is too late for that and I will not argue for it. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 14 11:06:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29931 for ; Tue, 14 Jan 2003 11:06:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EGL6L08543 for simple-archive@odin.ietf.org; Tue, 14 Jan 2003 11:21:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGL6J08540 for ; Tue, 14 Jan 2003 11:21:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29919 for ; Tue, 14 Jan 2003 11:06:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGL3J08512; Tue, 14 Jan 2003 11:21:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGKZJ08465 for ; Tue, 14 Jan 2003 11:20:35 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29908 for ; Tue, 14 Jan 2003 11:05:53 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18913; Tue, 14 Jan 2003 11:09:10 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23406; Tue, 14 Jan 2003 11:09:10 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Jan 2003 11:09:10 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D10@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" , "Vijay K. Gurbani" Cc: Henning Schulzrinne , Jonathan Rosenberg , simple@ietf.org Subject: RE: [Simple] Extending for presence MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Jan 2003 11:09:10 -0500 > Note that while I might want to distinguish my own status as > really-offline or online-but-invisible, this isn't a > distinction that is > shared with those that receive my status, at least until we start > distinguishing between what is presented to different people. Now, please. Several systems do some form of this now. Our system will "filter" presence states to watchers. We classify users into groups, and have a filter rule for each group. The rule is a simple substitution of one state for another. Basically, you implement a very fine grained presence state, but may show much coarser grained state to different users. In the context of this discussion, the only implication is that the "coarser" states are actually represented. So far, most of the proposals do that. That characteristic also allows simpler presence systems to remain within the standards, which is a good thing. > > Conceivably I might be seen as some variant on OPEN to my secretary > while I am CLOSED to everybody else. But in that case my > secretary might > also need to know that I am trying to be invisible to others. I don't > see quite how to fit that into presence status. I don't think you need to. Some day, we may need some semantics to allow someone like your secretary to query the presence service to find out what your presence state as viewed by a particular watcher, but so far we haven't found that to be necessary. ....snip.... > > Furthermore, I think that for "Busy-no-interrupt" and > > "Busy-interrupt-with-authority", the specification has to provide > > some guidance to the software designer. The presentity's UA should > > *not* even display IMs for the presentity if it in > "Busy-no-interrupt" > > mode. Likewise, if the presentity's UA is in > "Busy-interrupt-authority" > > status, only those IMs from an authorized user (i.e. department > > secretary, hospital administrator, etc.) should be displayed. We do this by mapping busy-interrupt-with-authority to either busy or busy-interruptable depending on who you are. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 14 11:36:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02370 for ; Tue, 14 Jan 2003 11:36:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EGp9q11766 for simple-archive@odin.ietf.org; Tue, 14 Jan 2003 11:51:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGp9J11763 for ; Tue, 14 Jan 2003 11:51:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02358 for ; Tue, 14 Jan 2003 11:36:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EGp4J11755; Tue, 14 Jan 2003 11:51:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E6X5J23601 for ; Tue, 14 Jan 2003 01:33:05 -0500 Received: from ams-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06438 for ; Tue, 14 Jan 2003 01:18:35 -0500 (EST) Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0E6KNSq009917; Tue, 14 Jan 2003 07:20:24 +0100 (MET) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 14 Jan 2003 07:21:52 +0100 Received: from cisco.com ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 14 Jan 2003 07:21:52 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: simple@ietf.org, Ned Freed To: Jonathan Rosenberg , Robert Sparks From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Transfer-Encoding: 7bit Message-Id: <7725B4F8-2788-11D7-AFF5-0003934B2128@cisco.com> X-Mailer: Apple Mail (2.551) X-OriginalArrivalTime: 14 Jan 2003 06:21:52.0537 (UTC) FILETIME=[3A79B090:01C2BB95] Content-Transfer-Encoding: 7bit Subject: [Simple] Fwd: draft-ietf-simple-winfo-format-03.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Jan 2003 07:21:49 +0100 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Question from IANA. paf Begin forwarded message: > In the IANA Considerations section is says that > this document "registers a new XML namespace". > > I'm not sure if this is staring me right in the > face or not, but I can not tell exactly where > this registration will go. > > Can you clarify? > > Thanks!! > > Michelle > IANA _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 14 12:12:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03645 for ; Tue, 14 Jan 2003 12:12:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EHR7i14653 for simple-archive@odin.ietf.org; Tue, 14 Jan 2003 12:27:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EHR7J14650 for ; Tue, 14 Jan 2003 12:27:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03622 for ; Tue, 14 Jan 2003 12:12:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EHR4J14637; Tue, 14 Jan 2003 12:27:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EHPwJ14524 for ; Tue, 14 Jan 2003 12:25:58 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03590 for ; Tue, 14 Jan 2003 12:11:14 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.7]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0EHEYYH000721; Tue, 14 Jan 2003 12:14:35 -0500 (EST) Message-ID: <3E244573.9070000@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: Robert Sparks , simple@ietf.org, Ned Freed Subject: Re: [Simple] Fwd: draft-ietf-simple-winfo-format-03.txt References: <7725B4F8-2788-11D7-AFF5-0003934B2128@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Jan 2003 12:14:27 -0500 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Section 8.2 provides a reference to the document which creates the registry. It is still an I-D, and so the registry has not been created yet. The document is: http://www.ietf.org/internet-drafts/draft-mealling-iana-xmlns-registry-04.txt It is currently under IESG review. I am assuming that this document is progressing, and so I can use the registries it creates. If that is not the case, please let me know. Thanks, Jonathan R. Patrik Fältström wrote: > Question from IANA. > > paf > > Begin forwarded message: > >> In the IANA Considerations section is says that >> this document "registers a new XML namespace". >> >> I'm not sure if this is staring me right in the >> face or not, but I can not tell exactly where >> this registration will go. >> >> Can you clarify? >> >> Thanks!! >> >> Michelle >> IANA > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 14 13:19:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05634 for ; Tue, 14 Jan 2003 13:19:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EIYAj19555 for simple-archive@odin.ietf.org; Tue, 14 Jan 2003 13:34:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EIYAJ19552 for ; Tue, 14 Jan 2003 13:34:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05574 for ; Tue, 14 Jan 2003 13:19:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EIY6J19536; Tue, 14 Jan 2003 13:34:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EIXaJ19509 for ; Tue, 14 Jan 2003 13:33:36 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05560 for ; Tue, 14 Jan 2003 13:18:50 -0500 (EST) From: krisztian.kiss@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0EILF013400 for ; Tue, 14 Jan 2003 20:21:15 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 14 Jan 2003 20:22:10 +0200 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 20:22:10 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Jan 2003 20:22:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Thread-Topic: [Simple] PUBLISH requirements Thread-Index: AcKiaYVlbbH5Y74PQaucmgoM89CYawT6gUBQAWQlsYA= To: X-OriginalArrivalTime: 14 Jan 2003 18:22:09.0976 (UTC) FILETIME=[DA138B80:01C2BBF9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0EIXaJ19510 Subject: [Simple] Content filtering for winfo Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Jan 2003 20:22:09 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit All, During IETF55's SIPPING session it was discussed how to proceed with the content filtering work. It was concluded that SIMPLE WG will produce event specific content filtering for the presence package (requirements & solution). I am wondering whether this work also covers content filtering for the winfo template-package. If yes, it is also a question whether this issue should be addressed separately from the presence package (in different documents) or together with it. As a background, winfo-package-04 mentions the issue of filtering and defines that SUBSCRIBE may contain a body for filtering the watcherinfo subscription. Similarly to presence, the actual filter definition for winfo is left out of the scope. In the I-D there is one example mentioned, a filter indicating that notifications should contain full state every time instead of the default policy to send partial updates. Additionally to this, I think filters could be defined e.g. to select the active watchers, new or unauthorized watchers, and also watcher history information could be collected with the help of filters. Comments are welcome! Thanks, Krisztian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 14 13:35:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06123 for ; Tue, 14 Jan 2003 13:35:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EIoAA21049 for simple-archive@odin.ietf.org; Tue, 14 Jan 2003 13:50:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EIoAJ21046 for ; Tue, 14 Jan 2003 13:50:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06111 for ; Tue, 14 Jan 2003 13:35:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EIo3J21032; Tue, 14 Jan 2003 13:50:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EInvJ21006 for ; Tue, 14 Jan 2003 13:49:57 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06090 for ; Tue, 14 Jan 2003 13:35:06 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0EIcd5f011387; Tue, 14 Jan 2003 13:38:40 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX87509; Tue, 14 Jan 2003 13:42:52 -0500 (EST) Message-ID: <3E2458FE.2020506@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <9BF66EBF6BEFD942915B4D4D45C051F3A64410@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Jan 2003 13:37:50 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Adam - comments below. Paul Adam Roach wrote: > So, how do we end up triggering different behavior for > "Out to Lunch" versus "On Vacation?" I think it would be > useful to explore what the *parameters* are that make > these situations different, as opposed to inferring > semantics from the meanings of the actual phrases. > > In this particular case, the fundamental difference is the > period of time for which a user will be gone. So, that > would point to adding an optional "duration" parameter to > "away" (and "busy") that would be used to indicate -- > at least, on an order of magnitude, how long the condition > is expected to continue. I wouldn't expect to include, > say, an actual number of seconds, as much as, for example, > knowing the unit of time that would be appropriate. Literally, > you would communicate the difference between "Out to Lunch" > and "On Vacation" as "duration=minutes" versus "duration=days". There is a fundamental problem with simply attaching a duration - when does it begin? You need to know when the state began that the duration applied to, for it to mean anything. For instance, "Out to Lunch" might be intended to imply being gone for the duration of a lunch (lets say an hour). If you leave at 12 and set this status, and I log on and notice your state at 12:55, do I know you are probably about to return, or do I think you will be gone for another hour? If we want to attempt to do this at all, then I think we need to specify the absolute time interval that the status applies to, or at least the time it will cease to apply. UIs can be responsible for providing shortcuts and configuration to make it simple to set statuses that encode the proper values. So you could presumably still select an "Out to Lunch" status from your UI, and it could figure out to say you will be unavailable for the next hour. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 14 14:29:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08584 for ; Tue, 14 Jan 2003 14:29:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EJi6I25384 for simple-archive@odin.ietf.org; Tue, 14 Jan 2003 14:44:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJi6J25381 for ; Tue, 14 Jan 2003 14:44:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08576 for ; Tue, 14 Jan 2003 14:29:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJi3J25373; Tue, 14 Jan 2003 14:44:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJhkJ25326 for ; Tue, 14 Jan 2003 14:43:46 -0500 Received: from oe-im1.bizmailsrvcs.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08555 for ; Tue, 14 Jan 2003 14:28:58 -0500 (EST) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-im1.bizmailsrvcs.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030114193219.KWSN20946.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Tue, 14 Jan 2003 13:32:19 -0600 Received: from diacakist ([12.253.90.102]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with SMTP id <20030114193219.JWXQ8904.oe-ismta1.bizmailsrvcs.net@diacakist>; Tue, 14 Jan 2003 13:32:19 -0600 Message-ID: <014c01c2bc03$a6b92330$6401a8c0@myopwv.com> From: "Thanos Diacakis" To: "Vijay K. Gurbani" , "Henning Schulzrinne" Cc: "Jonathan Rosenberg" , References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E22FEA1.4010802@lucent.com> Subject: Re: [Simple] Extending for presence MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Jan 2003 12:31:17 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Why would "Busy-no-interrupt" and "Away" fall in the OPEN category and not in the CLOSED? Perhaps if we go down that thought path, we will discover that my IM inbox status is orthogonal to my current (personal) status/activity... For example, some people want to leave their inbox OPEN while they're away (or offline), and some want to leave it CLOSED. What is then the point of mapping those to OPEN or CLOSED? Thanos --- Thanos Diacakis Openwave Systems thanos.diacakis@openwave.com +1-303 385 6705 ----- Original Message ----- From: "Vijay K. Gurbani" To: "Henning Schulzrinne" Cc: "Jonathan Rosenberg" ; Sent: Monday, January 13, 2003 11:00 AM Subject: Re: [Simple] Extending for presence > Henning Schulzrinne wrote: > > I agree. The harm of being inclusive is not obvious to me. Even the > > longest list of status items in existing systems is well short of a dozen. > > Okay -- so taking this a little further and distilling the status codes > from Henning's list (http://www.cs.columbia.edu/sip/drafts/status.txt), > we arrive at the following: > > CLOSED > Offline (invisible, lurking) > > OPEN > Available > Away (1) > Busy-interrupt (2) > Busy-no-interrupt (3) > Busy-interrupt-authority (4) > Custom > > (1) "Be right back", "Extended away" can all be subsumed in "Away". > (2) "On the phone" can be subsumed here if the UA alternate comm- > unication capablities (like IM). > (3) "Do not disturb" and other domain specific semantics that Henning > hinted at (e.g. "surgeon in a surgery; cannot be disturbed") > can be subsumed by this sub-status. > (4) Here is where other domain specific semantics that Henning > mentioned can be subsumed; e.g. "professor in an oral; can be > distrubed if the need is paramount". Basically, only those with > authority (i.e. a secretary) can interrupt the presentity. > > Furthermore, I think that for "Busy-no-interrupt" and > "Busy-interrupt-with-authority", the specification has to provide > some guidance to the software designer. The presentity's UA should > *not* even display IMs for the presentity if it in "Busy-no-interrupt" > mode. Likewise, if the presentity's UA is in "Busy-interrupt-authority" > status, only those IMs from an authorized user (i.e. department > secretary, hospital administrator, etc.) should be displayed. > > Comments? > > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Wireless Networks Group/Internet Software and Services > Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 0216 > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 14 14:43:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09110 for ; Tue, 14 Jan 2003 14:43:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EJw8D26359 for simple-archive@odin.ietf.org; Tue, 14 Jan 2003 14:58:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJw8J26356 for ; Tue, 14 Jan 2003 14:58:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09088 for ; Tue, 14 Jan 2003 14:43:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJw5J26348; Tue, 14 Jan 2003 14:58:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EJveJ26309 for ; Tue, 14 Jan 2003 14:57:40 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09062 for ; Tue, 14 Jan 2003 14:42:52 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0EJkuR7026060; Tue, 14 Jan 2003 14:46:56 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX88180; Tue, 14 Jan 2003 14:51:13 -0500 (EST) Message-ID: <3E246903.3080305@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thanos Diacakis CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E22FEA1.4010802@lucent.com> <014c01c2bc03$a6b92330$6401a8c0@myopwv.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Jan 2003 14:46:11 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Whether these fall into OPEN or CLOSED depends on the assumptions you make. At least in the case of Away, I think there is generally the implication that you may send a message and it will be available to the user when they return. (In the case of voice, this would mean that you could leave a voicemail message.) So the question is how this should be represented. In the case of IM, often the same contact is used in this case. So the status should be OPEN, indicating that you may indeed communicate with this address. In the case of voice, the same may also be true as long as the diversion of the call to voicemail occurs behind the same contact address. OTOH, some may choose to configure things so that a voicemail server has its own contact and tuple. In that case, the tuple where the person typically is would either go away or be CLOSED, while the one for the voicemail would be OPEN. Some of the same considerations may apply to busy-no-interrupt, but I don't feel I understand the intended semantics well enough to suggest exactly how it ought to look. Paul Thanos Diacakis wrote: > Why would "Busy-no-interrupt" and "Away" fall in the OPEN category and not > in the CLOSED? > > Perhaps if we go down that thought path, we will discover that my IM inbox > status is orthogonal to my current (personal) status/activity... For > example, some people want to leave their inbox OPEN while they're away (or > offline), and some want to leave it CLOSED. > > What is then the point of mapping those to OPEN or CLOSED? > > Thanos _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 14 14:49:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09287 for ; Tue, 14 Jan 2003 14:49:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EK44m26681 for simple-archive@odin.ietf.org; Tue, 14 Jan 2003 15:04:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EK44J26678 for ; Tue, 14 Jan 2003 15:04:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09231 for ; Tue, 14 Jan 2003 14:49:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EK40J26663; Tue, 14 Jan 2003 15:04:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EK3KJ26615 for ; Tue, 14 Jan 2003 15:03:20 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09211 for ; Tue, 14 Jan 2003 14:48:32 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0EJprO10336; Tue, 14 Jan 2003 14:51:53 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA15225; Tue, 14 Jan 2003 13:51:52 -0600 (CST) Message-ID: <3E246A08.5040205@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thanos Diacakis CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E22FEA1.4010802@lucent.com> <014c01c2bc03$a6b92330$6401a8c0@myopwv.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Jan 2003 13:50:32 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Trimmed CC list] Thanos Diacakis wrote: > Why would "Busy-no-interrupt" and "Away" fall in the OPEN category and > not in the CLOSED? Because "Busy-no-interrupt" and "Away" still denote that I am present, although not available. This is still very useful for people who simply want to subscribe to my presence state only, not necessarily with the intention of actually contacting me. The CLOSED category implies that I am not present at all, period. > What is then the point of mapping those to OPEN or CLOSED? Unless I grossly misunderstand your question above, the PIDF document only describes two basic states -- OPEN and CLOSED -- for presence status. Everything else has to be added on as an extension. Cheers, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 14 15:00:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09698 for ; Tue, 14 Jan 2003 15:00:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EKFCB27989 for simple-archive@odin.ietf.org; Tue, 14 Jan 2003 15:15:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKFCJ27986 for ; Tue, 14 Jan 2003 15:15:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09693 for ; Tue, 14 Jan 2003 15:00:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKF5J27974; Tue, 14 Jan 2003 15:15:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKEpJ27943 for ; Tue, 14 Jan 2003 15:14:51 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09685 for ; Tue, 14 Jan 2003 15:00:02 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.7]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0EK3PYH000810; Tue, 14 Jan 2003 15:03:26 -0500 (EST) Message-ID: <3E246D09.1090804@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: krisztian.kiss@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Content filtering for winfo References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Jan 2003 15:03:21 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. krisztian.kiss@nokia.com wrote: > All, > > During IETF55's SIPPING session it was discussed how to proceed with > the content filtering work. It was concluded that SIMPLE WG will > produce event specific content filtering for the presence package > (requirements & solution). I am wondering whether this work also > covers content filtering for the winfo template-package. If yes, it > is also a question whether this issue should be addressed separately > from the presence package (in different documents) or together with > it. I believe its a separate problem. The conclusion was, as I recall, that there is very little that is common across packages in terms of filters. Thus, we will develop, in sipping, a specific solution just for rate limiting, and then each particular package would get its own filter type. So, I believe there is a filter needed for winfo. Most implementations I am aware of, in fact, are already filtering on winfo - they just want the list of pending subscribers. So, here are the set of things I would like to be able to specify in the filter language: * include only watchers in a specific state [i.e., give me only pending watchers] * include only watchers that transitioned from a specific state to another state [i.e., only watchers that just transitioned from active to terminated] * include only watchers from a particular domain [who are the watchers from my enterprise?] * include only watchers who have been in a specified state for less than some duration [useful to only ask for the watcher whose state JUST went to pending because they just subscribed] * include only the Nth through Mth watcher, assuming some ordering can be applied to them at the server [useful for fetching a long list of your watchers - you can ask for ten at a time] Doing this in XML is easy, I think. You could specify a set of filters, eahc of which is an XML tag. There are filters for states, filters for domains, filters for duration, and so on. Filters nest, creating an AND rule. Sequences of filters create OR rules. So, if you want the set of watchers from either dynamicsoft.com or from microsoft.com: and to specify watchers that just transitioned to pending, who are from dynamicsoft.com: The processing rule at the server is easy. Start with all watchers at the root of the XML tree. Each node (element) specifies a reduction operation to be applied. Apply it, and take the remaining elements as input to the next tags. The union of the watchers that remain at the leaves of the XML tree represent the set which is to be sent in the notify. Note that, in the terminology proposed by Moran, the filter above does not separate content and trigger criteria. The model is that at each event transition, there is a set of watchers that would be present in the notify. THe filter is applied. If any watchers remain, a notification is sent. If none remain, none is sent. Certainly there are things you cannot do as a result (send me all the watchers whenever one watcher transitions from active to terminated). Not sure we are missing any important cases. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 14 15:38:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10748 for ; Tue, 14 Jan 2003 15:38:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EKr8B30893 for simple-archive@odin.ietf.org; Tue, 14 Jan 2003 15:53:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKr7J30890 for ; Tue, 14 Jan 2003 15:53:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10731 for ; Tue, 14 Jan 2003 15:38:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKr2J30882; Tue, 14 Jan 2003 15:53:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EKq7J30819 for ; Tue, 14 Jan 2003 15:52:07 -0500 Received: from oe-im2.bizmailsrvcs.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10717 for ; Tue, 14 Jan 2003 15:37:17 -0500 (EST) Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27]) by oe-im2.bizmailsrvcs.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030114204029.JWJZ2493.oe-im2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>; Tue, 14 Jan 2003 14:40:29 -0600 Received: from diacakist ([12.253.90.102]) by oe-ismta2.bizmailsrvcs.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with SMTP id <20030114201954.JRFE13955.oe-ismta2.bizmailsrvcs.net@diacakist>; Tue, 14 Jan 2003 14:19:54 -0600 Message-ID: <003001c2bc0a$4ac38e60$6401a8c0@myopwv.com> From: "Thanos Diacakis" To: "Vijay K. Gurbani" Cc: References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E22FEA1.4010802@lucent.com> <014c01c2bc03$a6b92330$6401a8c0@myopwv.com> <3E246A08.5040205@lucent.com> Subject: Re: [Simple] Extending for presence MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Jan 2003 13:18:58 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit With the excerpts below in mind, see comments inline. RFC 2778 states: STATUS is further defined by the model to have at least two states that interact with INSTANT MESSAGE delivery -- OPEN, in which INSTANT MESSAGES will be accepted, and CLOSED, in which INSTANT MESSAGES will not be accepted. PIDF states: 4.1.4. The element The element contains one of the following strings: "open" or "closed". The values "open" and "closed" has the same meaning as OPEN and CLOSED defined in RFC 2778 respectively, and stand for availability of receiving instant messages if the is for an instant messaging address. ----- Original Message ----- From: "Vijay K. Gurbani" To: "Thanos Diacakis" Cc: Sent: Tuesday, January 14, 2003 12:50 PM Subject: Re: [Simple] Extending for presence > [Trimmed CC list] > > Thanos Diacakis wrote: > > Why would "Busy-no-interrupt" and "Away" fall in the OPEN category and > > not in the CLOSED? > > Because "Busy-no-interrupt" and "Away" still denote that I am present, > although not available. This is still very useful for people who > simply want to subscribe to my presence state only, not necessarily > with the intention of actually contacting me. The CLOSED category > implies that I am not present at all, period. CLOSED only means that my IM inbox is closed. Nothing more, nothing less. One can define a "user status"/activity, say, "Busy-no-interrupt" and map that to OPEN, but someone else can map that to CLOSED. For example, I'd really prefer my inbox to be CLOSED when I'm away. I don't like IMs piling up in my inbox. > > What is then the point of mapping those to OPEN or CLOSED? > > Unless I grossly misunderstand your question above, the PIDF document > only describes two basic states -- OPEN and CLOSED -- for presence > status. Everything else has to be added on as an extension. I'm not arguing against extensions. I'm just trying to see if those can be mapped to OPEN or CLOSED and it seems they cannot. As per my previous email, I think that RFC 2778 status may be orthogonal to the status/activity element that is being discussed in this thread. (Well, if this is true, they're not really "extensions"... they're a different presence information element). Thanos --- Thanos Diacakis Openwave Systems thanos.diacakis@openwave.com +1-303 385 6705 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 14 16:19:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12173 for ; Tue, 14 Jan 2003 16:19:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ELY6C03043 for simple-archive@odin.ietf.org; Tue, 14 Jan 2003 16:34:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ELY6J03040 for ; Tue, 14 Jan 2003 16:34:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12157 for ; Tue, 14 Jan 2003 16:19:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ELY3J03031; Tue, 14 Jan 2003 16:34:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ELXBJ02990 for ; Tue, 14 Jan 2003 16:33:11 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12147 for ; Tue, 14 Jan 2003 16:18:23 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0ELLfK27910; Tue, 14 Jan 2003 16:21:42 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA23816; Tue, 14 Jan 2003 15:21:40 -0600 (CST) Message-ID: <3E247F14.1070701@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thanos Diacakis CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E22FEA1.4010802@lucent.com> <014c01c2bc03$a6b92330$6401a8c0@myopwv.com> <3E246A08.5040205@lucent.com> <003001c2bc0a$4ac38e60$6401a8c0@myopwv.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Jan 2003 15:20:20 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanos Diacakis wrote: > CLOSED only means that my IM inbox is closed. Nothing more, nothing less. > One can define a "user status"/activity, say, "Busy-no-interrupt" and map > that to OPEN, but someone else can map that to CLOSED. For example, I'd > really prefer my inbox to be CLOSED when I'm away. I don't like IMs > piling up in my inbox. Conceivably there could be multiple tuples associated with the presentity. The IM tuple could be CLOSED, while a tuple without any contact (thus representing the presentity itself) could be left OPEN and fine grained to "Away". What I am unsure of is if we do this in PIDF (it is syntactically possible), will it have the desired effect (i.e. are the semantics of PIDF rich enough so that a tuple without any Contact element represents the presentity itself?) > I'm not arguing against extensions. I'm just trying to see if those can > be mapped to OPEN or CLOSED and it seems they cannot. As per my previou > email, I think that RFC 2778 status may be orthogonal to the > status/activity element that is being discussed in this thread. (Well, > if this is true, they're not really "extensions"... they're a different > presence information element). I don't believe it is as much orthogonal as it is grounded in the fact that presence is used as a precursor to communications (IMs, in rfc2778's case). - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 14 16:43:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12657 for ; Tue, 14 Jan 2003 16:43:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0ELw7404623 for simple-archive@odin.ietf.org; Tue, 14 Jan 2003 16:58:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ELw6J04620 for ; Tue, 14 Jan 2003 16:58:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12652 for ; Tue, 14 Jan 2003 16:43:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ELw4J04610; Tue, 14 Jan 2003 16:58:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ELvIJ04565 for ; Tue, 14 Jan 2003 16:57:18 -0500 Received: from oe-im2.bizmailsrvcs.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12624 for ; Tue, 14 Jan 2003 16:42:29 -0500 (EST) Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27]) by oe-im2.bizmailsrvcs.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030114214549.KKJJ2493.oe-im2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>; Tue, 14 Jan 2003 15:45:49 -0600 Received: from diacakist ([12.253.90.102]) by oe-ismta2.bizmailsrvcs.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with SMTP id <20030114201949.JREQ13955.oe-ismta2.bizmailsrvcs.net@diacakist>; Tue, 14 Jan 2003 14:19:49 -0600 Message-ID: <002f01c2bc0a$4765bd60$6401a8c0@myopwv.com> From: "Thanos Diacakis" To: "Paul Kyzivat" Cc: References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E22FEA1.4010802@lucent.com> <014c01c2bc03$a6b92330$6401a8c0@myopwv.com> <3E246903.3080305@cisco.com> Subject: Re: [Simple] Extending for presence MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Jan 2003 13:10:45 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline ----- Original Message ----- From: "Paul Kyzivat" To: "Thanos Diacakis" Cc: Sent: Tuesday, January 14, 2003 12:46 PM Subject: Re: [Simple] Extending for presence > Whether these fall into OPEN or CLOSED depends on the assumptions you make. Exactly my point. And given that, we cannot map a particular (RFC 2778) status to a activity/status, as it depends on what the application is trying to express. > At least in the case of Away, I think there is generally the implication > that you may send a message and it will be available to the user when > they return. (In the case of voice, this would mean that you could leave > a voicemail message.) As above, yes, that's one way of doing it. Nothing annoys me more than coming back and having tons of IMs to sort through, so I'd want mine to be CLOSED when I'm away. Thanos _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 14 17:02:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13359 for ; Tue, 14 Jan 2003 17:02:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0EMH9v06790 for simple-archive@odin.ietf.org; Tue, 14 Jan 2003 17:17:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EMH9J06787 for ; Tue, 14 Jan 2003 17:17:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13354 for ; Tue, 14 Jan 2003 17:02:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EMH5J06779; Tue, 14 Jan 2003 17:17:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EMGZJ06752 for ; Tue, 14 Jan 2003 17:16:35 -0500 Received: from oe-im2.bizmailsrvcs.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13342 for ; Tue, 14 Jan 2003 17:01:46 -0500 (EST) Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27]) by oe-im2.bizmailsrvcs.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030114220418.KNXZ2493.oe-im2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>; Tue, 14 Jan 2003 16:04:18 -0600 Received: from diacakist ([12.253.90.102]) by oe-ismta2.bizmailsrvcs.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with SMTP id <20030114220413.KGWW13955.oe-ismta2.bizmailsrvcs.net@diacakist>; Tue, 14 Jan 2003 16:04:13 -0600 Message-ID: <00eb01c2bc18$e31275b0$6401a8c0@myopwv.com> From: "Thanos Diacakis" To: "Vijay K. Gurbani" Cc: References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E22FEA1.4010802@lucent.com> <014c01c2bc03$a6b92330$6401a8c0@myopwv.com> <3E246A08.5040205@lucent.com> <003001c2bc0a$4ac38e60$6401a8c0@myopwv.com> <3E247F14.1070701@lucent.com> Subject: Re: [Simple] Extending for presence MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Jan 2003 15:03:57 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Vijay, There are at least a couple of ways in expressing what you want in PIDF. The one is defining a tuple with some extensions inside that make it presentity specific, i.e. that tuple can only exist once within the presence document. The other way is putting that information outside a tuple, again as an extension. This is probably not allowed by RFC2778 as a strict interpretation of that doc would lead us believe that "Other Markup" is only allowed within tuples. However, we've violated that in PIDF at least twice: once in section 4.2.3 by allowing XML elements to appear anywhere in the presence doc as extension and by having the presentity specific "note" outside a tuple. That may solve the "how". Back to the "what/why": As I think I have established in my previous mail, RFC2778 status pertains to IM inboxes being OPEN or CLOSED, and can vary independently (hence the orthogonality) from a user activity, such as Online, Out To Lunch, Away, Busy, Offline, etc., depending on the application. Therefore, assigning a *fixed* mapping, that says "Busy" will be OPEN, "Offline" will be CLOSED, "Away" will be OPEN, etc. doesn't make sense. That is not to say that those "activities" are invalid or irrelevant, they are very much required for, say, an IM service. However, we need to much better define what they do mean and what they don't mean, and it seems that they don't mean RFC2778 OPEN or CLOSED. Thanos --- Thanos Diacakis Openwave Systems thanos.diacakis@openwave.com +1-303 385 6705 ----- Original Message ----- From: "Vijay K. Gurbani" To: "Thanos Diacakis" Cc: Sent: Tuesday, January 14, 2003 2:20 PM Subject: Re: [Simple] Extending for presence > Thanos Diacakis wrote: > > CLOSED only means that my IM inbox is closed. Nothing more, nothing less. > > One can define a "user status"/activity, say, "Busy-no-interrupt" and map > > that to OPEN, but someone else can map that to CLOSED. For example, I'd > > really prefer my inbox to be CLOSED when I'm away. I don't like IMs > > piling up in my inbox. > > Conceivably there could be multiple tuples associated with the > presentity. The IM tuple could be CLOSED, while a tuple without any > contact (thus representing the presentity itself) could be left > OPEN and fine grained to "Away". What I am unsure of is if we do > this in PIDF (it is syntactically possible), will it have the > desired effect (i.e. are the semantics of PIDF rich enough so that > a tuple without any Contact element represents the presentity itself?) > > > I'm not arguing against extensions. I'm just trying to see if those can > > be mapped to OPEN or CLOSED and it seems they cannot. As per my previou > > email, I think that RFC 2778 status may be orthogonal to the > > status/activity element that is being discussed in this thread. (Well, > > if this is true, they're not really "extensions"... they're a different > > presence information element). > > I don't believe it is as much orthogonal as it is grounded in the fact > that presence is used as a precursor to communications (IMs, in > rfc2778's case). > > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Wireless Networks Group/Internet Software and Services > Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 0216 > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 14 23:40:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22326 for ; Tue, 14 Jan 2003 23:40:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0F4tKS31054 for simple-archive@odin.ietf.org; Tue, 14 Jan 2003 23:55:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F4tKJ31051 for ; Tue, 14 Jan 2003 23:55:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22323 for ; Tue, 14 Jan 2003 23:40:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F4tGJ31029; Tue, 14 Jan 2003 23:55:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F4s6J30984 for ; Tue, 14 Jan 2003 23:54:06 -0500 Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22304 for ; Tue, 14 Jan 2003 23:39:07 -0500 (EST) From: hbhondwe@hss.hns.com Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id h0F4Ffa27192; Wed, 15 Jan 2003 09:45:41 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256CAF.00196DBF ; Wed, 15 Jan 2003 10:07:44 +0530 X-Lotus-FromDomain: HSSBLR To: simple@ietf.org cc: jdrosen@dynamicsoft.com Message-ID: <65256CAF.00196CE1.00@sampark.hss.hns.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Simple] minor comment: draft-ietf-simple-winfo-package-04.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Jan 2003 10:07:42 +0530 Hi, A minor comment on Figure 1: Subscription State Machine. The following events are listed as events leading to the transition from the Waiting state to the Terminated state: noresource rejected deactivated probation giveup approved However, deactivated and probation events need to be removed from this list because the waiting state is entered after the expiry of the subscription and these two events do not have a significance after the subscription has expired. thanks Harsh This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 15 07:20:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23564 for ; Wed, 15 Jan 2003 07:20:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FCZB504854 for simple-archive@odin.ietf.org; Wed, 15 Jan 2003 07:35:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FCZAJ04851 for ; Wed, 15 Jan 2003 07:35:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23550 for ; Wed, 15 Jan 2003 07:20:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FCZ5J04839; Wed, 15 Jan 2003 07:35:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FCYiJ04810 for ; Wed, 15 Jan 2003 07:34:44 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23538 for ; Wed, 15 Jan 2003 07:19:36 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0FCLx023928 for ; Wed, 15 Jan 2003 14:21:59 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Jan 2003 14:22:56 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 14:22:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Extending for presence Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7128@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Extending for presence Thread-Index: AcK7/D8XYvYJ/XgYRlihf42CIuEsXAAk116w To: , Cc: X-OriginalArrivalTime: 15 Jan 2003 12:22:56.0218 (UTC) FILETIME=[D572D3A0:01C2BC90] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0FCYiJ04811 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Jan 2003 14:22:55 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Just thought to mention that Yahoo actually tells you how long someone has been idle for in hours, mins and seconds. This information, I am assuming, is calculated at the server, not publisher. A similar thing could be done for "out to lunch", using SIMPLE of course. Is there a for the publisher (PUA) to keep publishing presence only to update a time that can be calculated by the server? Perhaps not. Regards, Hisham > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, January 14, 2003 8:38 PM > To: Adam Roach > Cc: simple@ietf.org > Subject: Re: [Simple] Extending for presence > > > Adam - comments below. > > Paul > > Adam Roach wrote: > > So, how do we end up triggering different behavior for > > "Out to Lunch" versus "On Vacation?" I think it would be > > useful to explore what the *parameters* are that make > > these situations different, as opposed to inferring > > semantics from the meanings of the actual phrases. > > > > In this particular case, the fundamental difference is the > > period of time for which a user will be gone. So, that > > would point to adding an optional "duration" parameter to > > "away" (and "busy") that would be used to indicate -- > > at least, on an order of magnitude, how long the condition > > is expected to continue. I wouldn't expect to include, > > say, an actual number of seconds, as much as, for example, > > knowing the unit of time that would be appropriate. Literally, > > you would communicate the difference between "Out to Lunch" > > and "On Vacation" as "duration=minutes" versus "duration=days". > > There is a fundamental problem with simply attaching a > duration - when > does it begin? You need to know when the state began that the > duration > applied to, for it to mean anything. > > For instance, "Out to Lunch" might be intended to imply being > gone for > the duration of a lunch (lets say an hour). If you leave at > 12 and set > this status, and I log on and notice your state at 12:55, do > I know you > are probably about to return, or do I think you will be gone > for another > hour? > > If we want to attempt to do this at all, then I think we need > to specify > the absolute time interval that the status applies to, or at > least the > time it will cease to apply. UIs can be responsible for providing > shortcuts and configuration to make it simple to set statuses that > encode the proper values. So you could presumably still > select an "Out > to Lunch" status from your UI, and it could figure out to say > you will > be unavailable for the next hour. > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 15 10:10:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29311 for ; Wed, 15 Jan 2003 10:10:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FFPTf17105 for simple-archive@odin.ietf.org; Wed, 15 Jan 2003 10:25:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFPTJ17102 for ; Wed, 15 Jan 2003 10:25:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29302 for ; Wed, 15 Jan 2003 10:10:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFPQJ17094; Wed, 15 Jan 2003 10:25:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFK9J16876 for ; Wed, 15 Jan 2003 10:20:09 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29223 for ; Wed, 15 Jan 2003 10:04:58 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0FF93dn022351; Wed, 15 Jan 2003 10:09:04 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX93035; Wed, 15 Jan 2003 10:13:20 -0500 (EST) Message-ID: <3E257962.4090708@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thanos Diacakis CC: "Vijay K. Gurbani" , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E22FEA1.4010802@lucent.com> <014c01c2bc03$a6b92330$6401a8c0@myopwv.com> <3E246A08.5040205@lucent.com> <003001c2bc0a$4ac38e60$6401a8c0@myopwv.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Jan 2003 10:08:18 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanos, A few observations: - while is currently only defined for IM, I believe that part of defining a profile and extensions for SIMPLE is to extend the definition of beyond IM, to other applications of SIP, such as voice. - I agree with you that open/closed is orthogonal to whether you as a person are busy. - But the situation of mapping statuses is different when we start discussing specific status values of particular IM systems. For instance, Sametime has a "Do Not Disturb" status. It also has a specific meaning for that - it refuses to establish a new IM session while in that state. So, when mapped to PIDF it would correspond to CLOSED. ICQ also has a Do Not Disturb state. I don't know how it works, but conceivably it could work in a way that corresponds to OPEN. Paul Thanos Diacakis wrote: > With the excerpts below in mind, see comments inline. > > RFC 2778 states: > > STATUS is further defined by the model to have at least two states > that interact with INSTANT MESSAGE delivery -- OPEN, in which INSTANT > MESSAGES will be accepted, and CLOSED, in which INSTANT MESSAGES will > not be accepted. > > PIDF states: > > 4.1.4. The element > > The element contains one of the following strings: "open" or > "closed". The values "open" and "closed" has the same meaning as > OPEN and CLOSED defined in RFC 2778 respectively, and stand for > availability of receiving instant messages if the is for an > instant messaging address. [snip] > CLOSED only means that my IM inbox is closed. Nothing more, nothing less. > One can define a "user status"/activity, say, "Busy-no-interrupt" and map > that to OPEN, but someone else can map that to CLOSED. For example, I'd > really prefer my inbox to be CLOSED when I'm away. I don't like IMs piling > up in my inbox. [snip] > I'm not arguing against extensions. I'm just trying to see if those can be > mapped to OPEN or CLOSED and it seems they cannot. As per my previous > email, I think that RFC 2778 status may be orthogonal to the status/activity > element that is being discussed in this thread. (Well, if this is true, > they're not really "extensions"... they're a different presence information > element). _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 15 10:43:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00500 for ; Wed, 15 Jan 2003 10:43:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FFw8B19764 for simple-archive@odin.ietf.org; Wed, 15 Jan 2003 10:58:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFw8J19761 for ; Wed, 15 Jan 2003 10:58:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00445 for ; Wed, 15 Jan 2003 10:42:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFw3J19750; Wed, 15 Jan 2003 10:58:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFulJ19620 for ; Wed, 15 Jan 2003 10:56:47 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00396 for ; Wed, 15 Jan 2003 10:41:34 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0FFjVCV027892; Wed, 15 Jan 2003 10:45:31 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX93374; Wed, 15 Jan 2003 10:49:48 -0500 (EST) Message-ID: <3E2581EE.6000608@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: adam@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Extending for presence References: <2038BCC78B1AD641891A0D1AE133DBB7FE7128@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Jan 2003 10:44:46 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hisham, PIDF already provides similar information - it provides the element in each , giving the time the status last changed. The limitation is that this pertains to the tuple as a whole, not individual elements within the tuple. This is probably good enough for some purposes, but maybe not all. Going beyond this would require timestamping individual status values. Hopefully that isn't necessary. So, I suppose we can attach a duration to some status value and measure its expiration relative to the timestamp of the tuple. Potentially this gives a way to say *why* I am in the presence state I am in, and when that state is likely to change. Other status values may indicate *what* I am willing/able to do in the current state, such as receive IM messages and save them for later display. But is that enough? I think the presence client also may need some hint of how presence state may change in the future. For example: Suppose my presence status is as above - I'm out to lunch, and accepting IM for later viewing. It also either doesn't mention voice, or explicitly indicates that voice is not currently accepted. You need to contact me, but don't need to do so live - you would be happy to leave me a message. All you have is your fancy new wireless sip phone with IM and presence support. You can see my presence, and know that I should be done with lunch in 5 minutes. You can either wait 5 minutes and make a voice call to me, or you can send me an IM right now. But entering the IM on the phone keypad is a pain you would prefer to avoid. Your choice of which to do depends on knowing whether I will be accepting voice calls when I get back from lunch. (If I don't have any voice capability you might as well start thumbing in that IM message now.) How can you tell that? There seems to be some need to describe capabilities that aren't currently available but that may be when status changes. Paul hisham.khartabil@nokia.com wrote: > Just thought to mention that Yahoo actually tells you how long someone has been idle for in hours, mins and seconds. This information, I am assuming, is calculated at the server, not publisher. A similar thing could be done for "out to lunch", using SIMPLE of course. Is there a for the publisher (PUA) to keep publishing presence only to update a time that can be calculated by the server? Perhaps not. > > Regards, > Hisham > > >>-----Original Message----- >>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Tuesday, January 14, 2003 8:38 PM >>To: Adam Roach >>Cc: simple@ietf.org >>Subject: Re: [Simple] Extending for presence >> >> >>Adam - comments below. >> >> Paul >> >>Adam Roach wrote: >> >>>So, how do we end up triggering different behavior for >>>"Out to Lunch" versus "On Vacation?" I think it would be >>>useful to explore what the *parameters* are that make >>>these situations different, as opposed to inferring >>>semantics from the meanings of the actual phrases. >>> >>>In this particular case, the fundamental difference is the >>>period of time for which a user will be gone. So, that >>>would point to adding an optional "duration" parameter to >>>"away" (and "busy") that would be used to indicate -- >>>at least, on an order of magnitude, how long the condition >>>is expected to continue. I wouldn't expect to include, >>>say, an actual number of seconds, as much as, for example, >>>knowing the unit of time that would be appropriate. Literally, >>>you would communicate the difference between "Out to Lunch" >>>and "On Vacation" as "duration=minutes" versus "duration=days". >> >>There is a fundamental problem with simply attaching a >>duration - when >>does it begin? You need to know when the state began that the >>duration >>applied to, for it to mean anything. >> >>For instance, "Out to Lunch" might be intended to imply being >>gone for >>the duration of a lunch (lets say an hour). If you leave at >>12 and set >>this status, and I log on and notice your state at 12:55, do >>I know you >>are probably about to return, or do I think you will be gone >>for another >>hour? >> >>If we want to attempt to do this at all, then I think we need >>to specify >>the absolute time interval that the status applies to, or at >>least the >>time it will cease to apply. UIs can be responsible for providing >>shortcuts and configuration to make it simple to set statuses that >>encode the proper values. So you could presumably still >>select an "Out >>to Lunch" status from your UI, and it could figure out to say >>you will >>be unavailable for the next hour. >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 15 10:56:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00844 for ; Wed, 15 Jan 2003 10:56:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FGAo921126 for simple-archive@odin.ietf.org; Wed, 15 Jan 2003 11:10:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGAnJ21118 for ; Wed, 15 Jan 2003 11:10:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00817 for ; Wed, 15 Jan 2003 10:55:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGAjJ21088; Wed, 15 Jan 2003 11:10:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FG4xJ20173 for ; Wed, 15 Jan 2003 11:04:59 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00680 for ; Wed, 15 Jan 2003 10:49:46 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0FFqrYH001214; Wed, 15 Jan 2003 10:52:56 -0500 (EST) Message-ID: <3E253030.5060409@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Henning Schulzrinne , Paul Kyzivat , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Jan 2003 04:56:00 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Vijay K. Gurbani wrote: > Henning Schulzrinne wrote: >>> So, instead of having a status like "In a Meeting", where the buddy >>> must decide the implications, I would prefer to declare the >>> implications. E.g.: >>> - emergency voice calls will be accepted live >>> - all other voice calls go to voicemail >>> - I will accept IM of a business nature, or high priority personal IM >>> - a text status of "In a Meeting" >> >> >> This is along Vijay's line of thought, it seems. > > > Yes; if we can do this by having such primitive status codes, we should. > I don't think anyone argues that we should have fine grained status > beyond OPEN and CLOSED. CLOSED is very simple to deal with; the big > problem is how to (sub)classify OPEN. We can take the list I proposed > and Henning's response to that as a start. I still believe we need both the "callerprefs" style PIDF status that Paul has been talking about, but ALSO the well-defined base list of statuses, such as "away" or "out to lunch". We need both because we clearly have several applications that are being driven by presence. One application is setting up sessions, and that is ideally addressed by the callerprefs stuff. Another is icons, or locally translated text. That is ideally handled by this list of statuses. Based on this, the semantics of these statuses are simple. They are nothing more than an indication of "why", suitable for consumption by automata which wish to render this information in an access specific way. By access, I mean things like PC application, mobile application, IVR, and so on. I further believe that these status types (callerprefs, basic, and the enumerated list) are orthogonal to each other. It is perfectly reasonable to be "out to lunch" and have a basic status of CLOSED, or be "out to lunch" and have a status of OPEN. OPEN/CLOSED refer to whether I can receive communications or not, and that is generally orthogonal to a descrtive status. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 15 11:13:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01522 for ; Wed, 15 Jan 2003 11:13:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FGSPq22162 for simple-archive@odin.ietf.org; Wed, 15 Jan 2003 11:28:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGSPJ22159 for ; Wed, 15 Jan 2003 11:28:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01497 for ; Wed, 15 Jan 2003 11:13:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGSMJ22136; Wed, 15 Jan 2003 11:28:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGIaJ21536 for ; Wed, 15 Jan 2003 11:18:36 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01117 for ; Wed, 15 Jan 2003 11:03:25 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0FG6aYH001233; Wed, 15 Jan 2003 11:06:39 -0500 (EST) Message-ID: <3E2586FA.5000003@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hbhondwe@hss.hns.com CC: simple@ietf.org References: <65256CAE.004587D1.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: minor comment: draft-ietf-simple-winfo-package-04.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Jan 2003 11:06:18 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Good point. I'll make this change in the next rev, which includes iesg comments as well. Thanks, Jonathan R. hbhondwe@hss.hns.com wrote: > > Hi, > > A minor comment on Figure 1: Subscription State Machine. > The following events are listed as events leading to the transition > from the Waiting state to the Terminated state: > > noresource > rejected > deactivated > probation > giveup > approved > > However, deactivated and probation events need to be removed from > this list because the waiting state is entered after the expiry of the > subscription and these two events do not have a significance after > the subscription has expired. > > thanks > Harsh > > > > > > > > This message is proprietary to Hughes Software Systems Limited (HSS) and is > intended solely for the use of the individual to whom it is addressed. It > may contain privileged or confidential information and should not be > circulated or used for any purpose other than for what it is intended. If > you have received this message in error, please notify the originator > immediately. If you are not the intended recipient, you are notified that > you are strictly prohibited from using, copying, altering, or disclosing > the contents of this message. HSS accepts no responsibility for loss or > damage arising from the use of the information transmitted by this email > including damage from virus. > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 15 11:21:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01908 for ; Wed, 15 Jan 2003 11:21:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FGa9122792 for simple-archive@odin.ietf.org; Wed, 15 Jan 2003 11:36:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGa9J22789 for ; Wed, 15 Jan 2003 11:36:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01900 for ; Wed, 15 Jan 2003 11:20:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGa2J22777; Wed, 15 Jan 2003 11:36:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGZxJ22763 for ; Wed, 15 Jan 2003 11:35:59 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01893 for ; Wed, 15 Jan 2003 11:20:48 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0FGNa71004259; Wed, 15 Jan 2003 11:23:36 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX93774; Wed, 15 Jan 2003 11:27:53 -0500 (EST) Message-ID: <3E258ADB.70204@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Vijay K. Gurbani" , Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Jan 2003 11:22:51 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree with Jonathan, as long as these are indeed orthogonal. In fact, we may need even more dimensions: - I see one status type with values of {ACTIVE, INACTIVE} that is typically inferred by observing behavior - Another status type is explicitly set, with values of {AVAILABLE, DO-NOT-DISTURB, AWAY}. This can also carry an estimate of when it is expected to change. It is easy to see why these are orthogonal. I can certainly be either active or inactive while not wanting to be disturbed. But I can also have indicated that I am AWAY (Out to Lunch is a special case of this), but actually be eating at my desk, so that I may appear either active or inactive. The orthogonality also means that Do Not Disturb shouldn't be enforced (at least not vigorously) by the UAC. In general it should be up to me to decide if I want to violate your wishes. If you want it enforced, you can couple it with CLOSED. Paul Jonathan Rosenberg wrote: > > I still believe we need both the "callerprefs" style PIDF status that > Paul has been talking about, but ALSO the well-defined base list of > statuses, such as "away" or "out to lunch". We need both because we > clearly have several applications that are being driven by presence. One > application is setting up sessions, and that is ideally addressed by the > callerprefs stuff. Another is icons, or locally translated text. That is > ideally handled by this list of statuses. > > Based on this, the semantics of these statuses are simple. They are > nothing more than an indication of "why", suitable for consumption by > automata which wish to render this information in an access specific > way. By access, I mean things like PC application, mobile application, > IVR, and so on. > > I further believe that these status types (callerprefs, basic, and the > enumerated list) are orthogonal to each other. It is perfectly > reasonable to be "out to lunch" and have a basic status of CLOSED, or be > "out to lunch" and have a status of OPEN. OPEN/CLOSED refer to whether I > can receive communications or not, and that is generally orthogonal to a > descrtive status. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 15 11:35:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02651 for ; Wed, 15 Jan 2003 11:35:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FGo9p24493 for simple-archive@odin.ietf.org; Wed, 15 Jan 2003 11:50:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGo9J24490 for ; Wed, 15 Jan 2003 11:50:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02623 for ; Wed, 15 Jan 2003 11:34:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGo4J24477; Wed, 15 Jan 2003 11:50:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGniJ24429 for ; Wed, 15 Jan 2003 11:49:44 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02591 for ; Wed, 15 Jan 2003 11:34:33 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0FGcJcp006476; Wed, 15 Jan 2003 11:38:20 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX93934; Wed, 15 Jan 2003 11:42:36 -0500 (EST) Message-ID: <3E258E4E.8090908@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Vijay K. Gurbani" , Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E22FEA1.4010802@lucent.com> <3E2317F8.3000805@cisco.com> <3E253B8F.5060304@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Jan 2003 11:37:34 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit response at the end. Jonathan Rosenberg wrote: > a small note inline. > > > Paul Kyzivat wrote: > >> > >> >> The trouble with these "interrupt" kinds of statuses is that there are >> many nuances. >> >> An important one is that my availability may well vary by medium even >> with a single contact/tuple. Using SIMPLE, I can use the same address >> for voice, IM, video, etc. When I'm in a meeting voice may not be >> available at all, or at least will be perceived as an interruption, >> while IM may be perfectly ok. >> >> This suggests that the availability be describable on a per-media basis. > > > To me, this suggests that my device is modeled as two separate tuples. > One for voice, with a status of CLOSED, and one with IM, with a status > of open. This would, perhaps, need some way to allow the watcher to > correlate these two so as to know that they represent the same physical > device. Indeed, one might envision "device" as another status itself! So: > > > OPEN > Cell Phone > IM allowed > > > > CLOSED > Cell Phone > voice not allowed except high priority > > > Device could be an enumerated type, or perhaps even just a textual string. Well, there are many ways to skin a cat. Is there any value to beyond ? If I can compare two devices for equality I can just as easily compare two contact addresses for equality. It seems to me a lot easier to understand if each tuple with a contact represents a distinct communication target, so I can decide whether it is useful to me independently of all the others. Otherwise, things get messy if I potentially want to use multiple media. Then I have to look for all tuples representing the same device and combine their statuses before deciding if the device is suitable for my needs. And then I must still deal with the potential for conflicting status values between those tuples. It isn't an unsolvable problem, but is it better than simply permitting availablility information for each medium? The callerprefs stuff can already do that. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 15 11:41:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00843 for ; Wed, 15 Jan 2003 10:56:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FGAoR21122 for simple-archive@odin.ietf.org; Wed, 15 Jan 2003 11:10:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGAnJ21117 for ; Wed, 15 Jan 2003 11:10:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00815 for ; Wed, 15 Jan 2003 10:55:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGAkJ21104; Wed, 15 Jan 2003 11:10:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FG5LJ20193 for ; Wed, 15 Jan 2003 11:05:21 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00687 for ; Wed, 15 Jan 2003 10:50:09 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0FFrEYH001217; Wed, 15 Jan 2003 10:53:19 -0500 (EST) Message-ID: <3E253B8F.5060304@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: "Vijay K. Gurbani" , Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E22FEA1.4010802@lucent.com> <3E2317F8.3000805@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Jan 2003 05:44:31 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit a small note inline. Paul Kyzivat wrote: > > > The trouble with these "interrupt" kinds of statuses is that there are > many nuances. > > An important one is that my availability may well vary by medium even > with a single contact/tuple. Using SIMPLE, I can use the same address > for voice, IM, video, etc. When I'm in a meeting voice may not be > available at all, or at least will be perceived as an interruption, > while IM may be perfectly ok. > > This suggests that the availability be describable on a per-media basis. To me, this suggests that my device is modeled as two separate tuples. One for voice, with a status of CLOSED, and one with IM, with a status of open. This would, perhaps, need some way to allow the watcher to correlate these two so as to know that they represent the same physical device. Indeed, one might envision "device" as another status itself! So: OPEN Cell Phone IM allowed CLOSED Cell Phone voice not allowed except high priority Device could be an enumerated type, or perhaps even just a textual string. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 15 12:12:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03730 for ; Wed, 15 Jan 2003 12:12:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FHRDc27269 for simple-archive@odin.ietf.org; Wed, 15 Jan 2003 12:27:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHRCJ27266 for ; Wed, 15 Jan 2003 12:27:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03709 for ; Wed, 15 Jan 2003 12:12:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHR5J27232; Wed, 15 Jan 2003 12:27:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHLCJ26863 for ; Wed, 15 Jan 2003 12:21:12 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03376 for ; Wed, 15 Jan 2003 12:06:00 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0FH9I516114; Wed, 15 Jan 2003 12:09:18 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA06532; Wed, 15 Jan 2003 11:09:17 -0600 (CST) Message-ID: <3E25956B.5050006@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Jan 2003 11:07:55 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The more I think through these discussions, the more convinced I get that we ought to maintain the presence state of the presentity itself distinct from that of any of the devices that can be used to communicate with it. The only first class citizen in the presence domain is the presentity itself; without it, all the devices associated with it are useless. My interpretation of rfc2778 yields an implicit coupling between presence and IM; the former is used to drive the latter. It has been argued that presence needs to be grounded in a purpose in order to scope it. But the discussions so far appear to point that the state of a presentity is far richer then the individual state of the devices it commands. I think we are doing the same thing in simple -- letting the various devices dictate presence/absence of the entity. Thus we have states which are interpreted by different applications in different ways; for example, being "out to lunch" and having a basic status of CLOSED is equally valid, as is "being out to lunch" and having a basic status of OPEN. On the other hand, if we posit that "being out to lunch" is a status associated with the presentity itself, then the basic status is always OPEN. The next thing to do is to see if the presentity can accept any communication sessions while in this state. That is easy -- go through the devices and see which ones are OPEN or CLOSED or have q values or priorities associated with them. I don't think we have lost any flexibility here, as far as I can see it. Paul Kyzivat wrote: > The orthogonality also means that Do Not Disturb shouldn't be enforced > (at least not vigorously) by the UAC. In general it should be up to me > to decide if I want to violate your wishes. If you want it enforced, > you can couple it with CLOSED. If we do NOT infer the state of the presentity from its devices, "Do not Disturb" is easily enforcable. The state of the presentity itself is OPEN, but that of all of its devices is CLOSED. I think that if we provide a "Do Not Disturb", it should be enforced. Otherwise, as has been pointed out before, others will learn to distrust ones presence status. Paul Kyzivat further writes: > - I see one status type with values of {ACTIVE, INACTIVE} that is > typically inferred by observing behavio > - Another status type is explicitly set, with values of {AVAILABLE, > DO-NOT-DISTURB, AWAY}. This can also carry an estimate of when it is > expected to change. All these status values -- ACTIVE, INACTIVE, DO-NOT-DISTURB, AWAY -- refer to the state of the presentity itself; and furthermore, I will go out on a limb and say that these correspond to OPEN. If this is the case, why not actually provide means for this in simple (as in the WG) extensions to PIDF? Cheers, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 15 13:25:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05901 for ; Wed, 15 Jan 2003 13:25:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FIe6V32763 for simple-archive@odin.ietf.org; Wed, 15 Jan 2003 13:40:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FIe6J32760 for ; Wed, 15 Jan 2003 13:40:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05876 for ; Wed, 15 Jan 2003 13:24:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FIe1J32740; Wed, 15 Jan 2003 13:40:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FIbPJ32490 for ; Wed, 15 Jan 2003 13:37:25 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05723 for ; Wed, 15 Jan 2003 13:22:10 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0FIRet17183 for ; Wed, 15 Jan 2003 20:27:40 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Jan 2003 20:25:30 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 20:25:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBE4F@esebe004.ntc.nokia.com> Thread-Topic: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt Thread-Index: AcKOyPgSUyTQYy5eSfWJRu4U5OI9jAsTdeWw To: , Cc: X-OriginalArrivalTime: 15 Jan 2003 18:25:29.0844 (UTC) FILETIME=[7B9EBB40:01C2BCC3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0FIbPJ32491 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Jan 2003 20:25:29 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Back to this old topic. Inline: > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 18 November, 2002 08:09 > To: Paul Kyzivat > Cc: Lonnfors Mikko (NRC/Helsinki); simple@mailman.dynamicsoft.com > Subject: Re: [Simple] FW: I-D > ACTION:draft-lonnfors-simple-prescaps-ext-00.txt > > > > >> w3c has done a lot of work in describing capabilities > (CC/PP, RDF), > >> all of which is XML-based. I wonder if there is a better fit here > >> to use that kind of syntax? > > > -Jonathan R. I have been looking if RDF or CC/PP could be utilized to represent caller preferences information instead of using our own XML format. Basically situation seems to be that RDF may not be the best choice for us in this situation. RDF defines a framework which can be used to represent metadata about resources. It defines simple model for describing relationships among resources in terms of named properties and values. It cannot by itself be used to represent data required by specific applications and so it needs an additional vocabulary for each application. CC/PP defines one set of vocabulary (based on RDF) which is a description of device capabilities and user preferences that can be used to guide the adaptation of content presented to that device. CC/PP defines things like display size, terminal software, and browser capabilities. These don't provide much help for items needed for caller preferences. So, if we would like to utilize RDF it would have following consequences: 1) We would probably need to define a new vocabulary. It is a bit unclear if this should be done in W3C or in IETF 2) UAs would need to have support for RDF aware parsers. RDF representation is based on XML but parsers need to understand whole RDF schema. Currently such parsers are not widely available. If the whole presence info would be build utilizing RDF (PIDF would be based on RDF) then it would make sense to use RDF but probably not in this situation. I would propose that for now we stick with our own XML format. Best Regards - Mikko _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 15 14:23:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07178 for ; Wed, 15 Jan 2003 14:23:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FJcGE03948 for simple-archive@odin.ietf.org; Wed, 15 Jan 2003 14:38:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FJcFJ03945 for ; Wed, 15 Jan 2003 14:38:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07148 for ; Wed, 15 Jan 2003 14:23:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FJc9J03932; Wed, 15 Jan 2003 14:38:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F3erJ27229 for ; Tue, 14 Jan 2003 22:40:53 -0500 Received: from hss.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20633 for ; Tue, 14 Jan 2003 22:25:50 -0500 (EST) From: hbhondwe@hss.hns.com Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id h0F325a26892; Wed, 15 Jan 2003 08:32:09 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256CAF.0012AF38 ; Wed, 15 Jan 2003 08:54:05 +0530 X-Lotus-FromDomain: HSSBLR To: simple@ietf.org cc: jdrosen@dynamicsoft.com Message-ID: <65256CAF.0012AE5F.00@sampark.hss.hns.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Simple] minor comment: draft-ietf-simple-winfo-package-04.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Jan 2003 08:54:02 +0530 Hi, A minor comment on Figure 1: Subscription State Machine. The following events are listed as events leading to the transition from the Waiting state to the Terminated state: noresource rejected deactivated probation giveup approved However, deactivated and probation events need to be removed from this list because the waiting state is entered after the expiry of the subscription and these two events do not have a significance after the subscription has expired. thanks Harsh This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 15 14:34:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07495 for ; Wed, 15 Jan 2003 14:34:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FJn7c04537 for simple-archive@odin.ietf.org; Wed, 15 Jan 2003 14:49:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FJn7J04534 for ; Wed, 15 Jan 2003 14:49:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07479 for ; Wed, 15 Jan 2003 14:33:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FJn3J04509; Wed, 15 Jan 2003 14:49:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FJmfJ04474 for ; Wed, 15 Jan 2003 14:48:41 -0500 Received: from oe-im1.bizmailsrvcs.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07469 for ; Wed, 15 Jan 2003 14:33:25 -0500 (EST) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-im1.bizmailsrvcs.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030115193646.RKMA20946.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Wed, 15 Jan 2003 13:36:46 -0600 Received: from diacakist ([63.67.207.249]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with SMTP id <20030115193646.PXNU8904.oe-ismta1.bizmailsrvcs.net@diacakist>; Wed, 15 Jan 2003 13:36:46 -0600 Message-ID: <00e601c2bccd$70a3dd60$40071e0a@myopwv.com> From: "Thanos Diacakis" To: "Paul Kyzivat" Cc: "Vijay K. Gurbani" , References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E22FEA1.4010802@lucent.com> <014c01c2bc03$a6b92330$6401a8c0@myopwv.com> <3E246A08.5040205@lucent.com> <003001c2bc0a$4ac38e60$6401a8c0@myopwv.com> <3E257962.4090708@cisco.com> Subject: Re: [Simple] Extending for presence MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Jan 2003 12:27:06 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul, Paul Kyzivat wrote: > - But the situation of mapping statuses is different when we start > discussing specific status values of particular IM systems. For > instance, Sametime has a "Do Not Disturb" status. It also has a specific > meaning for that - it refuses to establish a new IM session while in > that state. So, when mapped to PIDF it would correspond to CLOSED. ICQ > also has a Do Not Disturb state. I don't know how it works, but > conceivably it could work in a way that corresponds to OPEN. Agreed. Applications can take the two orthogonal variables, combine (map) them as they please and create other "status" value that have a specific assigned meaning... However, the mapping is an application level problem, not a protocol level problem. Of course, if we define a protocol for a particular application, i.e. one that is narrow enough, that might be appropriate. But the stuff that we've been discussing here is way too general for any concrete mappings to be broadly applicable. Thanos _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 15 14:34:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07507 for ; Wed, 15 Jan 2003 14:34:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FJn8904552 for simple-archive@odin.ietf.org; Wed, 15 Jan 2003 14:49:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FJn8J04549 for ; Wed, 15 Jan 2003 14:49:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07482 for ; Wed, 15 Jan 2003 14:33:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FJn4J04525; Wed, 15 Jan 2003 14:49:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FJmkJ04480 for ; Wed, 15 Jan 2003 14:48:46 -0500 Received: from oe-im1.bizmailsrvcs.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07472 for ; Wed, 15 Jan 2003 14:33:30 -0500 (EST) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-im1.bizmailsrvcs.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030115193652.RKMP20946.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Wed, 15 Jan 2003 13:36:52 -0600 Received: from diacakist ([63.67.207.249]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with SMTP id <20030115193651.PXOH8904.oe-ismta1.bizmailsrvcs.net@diacakist>; Wed, 15 Jan 2003 13:36:51 -0600 Message-ID: <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> From: "Thanos Diacakis" To: "Vijay K. Gurbani" , "Paul Kyzivat" Cc: "Jonathan Rosenberg" , "Henning Schulzrinne" , References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> Subject: Re: [Simple] Extending for presence MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Jan 2003 12:35:46 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay, Vijay Gurbani wrote: > If we do NOT infer the state of the presentity from its devices, "Do > not Disturb" is easily enforcable. The state of the presentity itself > is OPEN, but that of all of its devices is CLOSED. I think that if > we provide a "Do Not Disturb", it should be enforced. Otherwise, as > has been pointed out before, others will learn to distrust ones presence > status. Currently the presentity cannot have a OPEN or CLOSED status, simply because we haven't defined what that means. What do you have in mind when you say that a presentity is OPEN or CLOSED? > All these status values -- ACTIVE, INACTIVE, DO-NOT-DISTURB, AWAY -- > refer to the state of the presentity itself; and furthermore, I will > go out on a limb and say that these correspond to OPEN. If this is the > case, why not actually provide means for this in simple (as in the > WG) extensions to PIDF? Again, I'm having trouble with some of those. "DND" is fairly easy: the person that the presentity represents does not want to be disturbed. What does that status of a *presentity* mean if it is "Away", or "Active/Inactive"? Away from what? Inactive how? I can understand if the status of a *device* is "Away", that could be defined to mean that there is no human using that device at that instant. Similarly, "Active" could be defined as the *device* is being used, but not sure what an active presentity is... Thoughts? Thanos --- Thanos Diacakis Openwave Systems thanos.diacakis@openwave.com +1-303 385 6705 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 15 16:18:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10370 for ; Wed, 15 Jan 2003 16:18:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FLX8410551 for simple-archive@odin.ietf.org; Wed, 15 Jan 2003 16:33:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLX8J10548 for ; Wed, 15 Jan 2003 16:33:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10346 for ; Wed, 15 Jan 2003 16:17:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLX4J10540; Wed, 15 Jan 2003 16:33:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLWhJ10506 for ; Wed, 15 Jan 2003 16:32:43 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10339 for ; Wed, 15 Jan 2003 16:17:24 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0FLLUKL020532; Wed, 15 Jan 2003 16:21:30 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX96565; Wed, 15 Jan 2003 16:25:46 -0500 (EST) Message-ID: <3E25D0AC.3020807@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thanos Diacakis CC: "Vijay K. Gurbani" , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E22FEA1.4010802@lucent.com> <014c01c2bc03$a6b92330$6401a8c0@myopwv.com> <3E246A08.5040205@lucent.com> <003001c2bc0a$4ac38e60$6401a8c0@myopwv.com> <3E257962.4090708@cisco.com> <00e601c2bccd$70a3dd60$40071e0a@myopwv.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Jan 2003 16:20:44 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanos, I think we are in violent agreement. I agree that mapping of the status values used by particular IM applications to/from PIDF status values is an application problem. The point of talking about it here and now is because those applications and their status values exist today, while our new PIDF status values are still being defined. I believe it is important to define PIDF status values that can reasonably map to/from the common IM systems. If we can't demonstrate a reasonable mapping then there will probably be difficulty in getting PIDF accepted. OR, each vendor may define its own mapping, using proprietary elements, and interoperation will be a mess. I expect we will eventually want to document mappings in the same way that mappings have been defined between sip and other telephony protocols. Paul Thanos Diacakis wrote: > Paul, > > Paul Kyzivat wrote: > >>- But the situation of mapping statuses is different when we start >>discussing specific status values of particular IM systems. For >>instance, Sametime has a "Do Not Disturb" status. It also has a specific >>meaning for that - it refuses to establish a new IM session while in >>that state. So, when mapped to PIDF it would correspond to CLOSED. ICQ >>also has a Do Not Disturb state. I don't know how it works, but >>conceivably it could work in a way that corresponds to OPEN. > > > Agreed. Applications can take the two orthogonal variables, combine (map) > them as they please and create other "status" value that have a specific > assigned meaning... > > However, the mapping is an application level problem, not a protocol level > problem. Of course, if we define a protocol for a particular application, > i.e. one that is narrow enough, that might be appropriate. But the stuff > that we've been discussing here is way too general for any concrete mappings > to be broadly applicable. > > Thanos > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 15 16:43:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10954 for ; Wed, 15 Jan 2003 16:43:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FLwHL12244 for simple-archive@odin.ietf.org; Wed, 15 Jan 2003 16:58:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLwGJ12241 for ; Wed, 15 Jan 2003 16:58:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10949 for ; Wed, 15 Jan 2003 16:42:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLw5J12231; Wed, 15 Jan 2003 16:58:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FLvuJ12216 for ; Wed, 15 Jan 2003 16:57:56 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10946 for ; Wed, 15 Jan 2003 16:42:36 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0FLkN8U024374; Wed, 15 Jan 2003 16:46:23 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX96870; Wed, 15 Jan 2003 16:50:39 -0500 (EST) Message-ID: <3E25D681.2050507@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thanos Diacakis CC: "Vijay K. Gurbani" , Jonathan Rosenberg , Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Jan 2003 16:45:37 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Again I am mostly in agreement with Thanos. Comments inline. Paul Thanos Diacakis wrote: > Vijay, > > Vijay Gurbani wrote: > >>If we do NOT infer the state of the presentity from its devices, "Do >>not Disturb" is easily enforcable. The state of the presentity itself >>is OPEN, but that of all of its devices is CLOSED. I think that if >>we provide a "Do Not Disturb", it should be enforced. Otherwise, as >>has been pointed out before, others will learn to distrust ones presence >>status. This makes no sense to me. What does it possibly mean to say the state of the presentity is OPEN but the state of all the devices is closed? In what way would things be changes if we then changed the state of the presentity to CLOSED? The meaning of OPEN and CLOSED is defined in terms of what can be done with the devices. > > > Currently the presentity cannot have a OPEN or CLOSED status, simply because > we haven't defined what that means. What do you have in mind when you say > that a presentity is OPEN or CLOSED? > > >>All these status values -- ACTIVE, INACTIVE, DO-NOT-DISTURB, AWAY -- >>refer to the state of the presentity itself; and furthermore, I will >>go out on a limb and say that these correspond to OPEN. If this is the >>case, why not actually provide means for this in simple (as in the >>WG) extensions to PIDF? I was my intent that these (or something similar) be part of the extensions we are defining. I have now been convinced that they are useful in addition to state explicitly defining what kinds of communication are permitted. I think ACTIVE/INACTIVE is an observation about the user of a device. It is intended as a predictive indicator of whether the user would respond if attempts were made to communicate via the device. In principle it could be provided in conjunction with CLOSED, though it might not be very useful in that case. > Again, I'm having trouble with some of those. "DND" is fairly easy: the > person that the presentity represents does not want to be disturbed. What > does that status of a *presentity* mean if it is "Away", or > "Active/Inactive"? Away from what? Inactive how? I can understand if the > status of a *device* is "Away", that could be defined to mean that there is > no human using that device at that instant. Similarly, "Active" could be > defined as the *device* is being used, but not sure what an active > presentity is... Thoughts? I agree with all of this. As soon as it is possible to describe the status of two devices, presence can be different at each. If you want to have a single notion of presence, describe everything in terms of one device. It can be a virtual device - a sip AoR with multiple contact addresses to different physical devices. As long as you describe it as a single tuple referencing the AoR, it has a single set of status values. But if you choose to represent it with a separate tuple for each contact address then each tuple might have conflicting status values. In this latter case I think status for the presentity as a whole is simply ambiguous. > > Thanos > --- > Thanos Diacakis > Openwave Systems > thanos.diacakis@openwave.com > +1-303 385 6705 > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 15 17:00:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11354 for ; Wed, 15 Jan 2003 17:00:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FMFDf13946 for simple-archive@odin.ietf.org; Wed, 15 Jan 2003 17:15:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMFDJ13943 for ; Wed, 15 Jan 2003 17:15:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11325 for ; Wed, 15 Jan 2003 16:59:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMF9J13923; Wed, 15 Jan 2003 17:15:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMAJJ13706 for ; Wed, 15 Jan 2003 17:10:19 -0500 Received: from web20705.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11206 for ; Wed, 15 Jan 2003 16:54:59 -0500 (EST) Message-ID: <20030115215821.42828.qmail@web20705.mail.yahoo.com> Received: from [207.46.137.250] by web20705.mail.yahoo.com via HTTP; Wed, 15 Jan 2003 13:58:21 PST From: Sean Olson Subject: Re: [Simple] Extending for presence To: Jonathan Rosenberg , Paul Kyzivat Cc: "Vijay K. Gurbani" , Henning Schulzrinne , simple@ietf.org In-Reply-To: <3E253B8F.5060304@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Jan 2003 13:58:21 -0800 (PST) > To me, this suggests that my device is modeled as > two separate tuples. > One for voice, with a status of CLOSED, and one with > IM, with a status > of open. This would, perhaps, need some way to allow > the watcher to > correlate these two so as to know that they > represent the same physical > device. Indeed, one might envision "device" as > another status itself! So: > > > OPEN > Cell Phone > IM allowed > > > > CLOSED > Cell Phone > voice not allowed except high > priority > > > Device could be an enumerated type, or perhaps even > just a textual string. > > -Jonathan R. Why should the tuple ID be distinct from device? The opposite approach is to define a basic status for the device and sub-status for each media type that that device supports: OPEN voice not allowed except high priority CLOSED OPEN OPEN /sean __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 15 17:21:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12145 for ; Wed, 15 Jan 2003 17:21:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FMa8S15447 for simple-archive@odin.ietf.org; Wed, 15 Jan 2003 17:36:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMa7J15441 for ; Wed, 15 Jan 2003 17:36:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12133 for ; Wed, 15 Jan 2003 17:20:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMa4J15426; Wed, 15 Jan 2003 17:36:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMZLJ15361 for ; Wed, 15 Jan 2003 17:35:21 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12090 for ; Wed, 15 Jan 2003 17:20:02 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0FMNtAC029627; Wed, 15 Jan 2003 17:23:55 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAX97180; Wed, 15 Jan 2003 17:28:12 -0500 (EST) Message-ID: <3E25DF4E.6070808@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean Olson CC: Jonathan Rosenberg , "Vijay K. Gurbani" , Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <20030115215821.42828.qmail@web20705.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Jan 2003 17:23:10 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sean Olson wrote: > Why should the tuple ID be distinct from device? > The opposite approach is to define a basic status > for the device and sub-status for each media type > that that device supports: > > > OPEN > voice not allowed except high > priority > CLOSED > OPEN > OPEN > We already have proposed a way to do this in draft-lonnfors-simple-prescaps-ext-00.txt. It is: OPEN voice not allowed except high priority false true true (I'm not sure what media type to use for T.120 - just guessing.) Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 15 18:43:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14844 for ; Wed, 15 Jan 2003 18:43:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0FNw5v22405 for simple-archive@odin.ietf.org; Wed, 15 Jan 2003 18:58:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FNw5J22402 for ; Wed, 15 Jan 2003 18:58:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14835 for ; Wed, 15 Jan 2003 18:42:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FNw2J22386; Wed, 15 Jan 2003 18:58:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FNvYJ22347 for ; Wed, 15 Jan 2003 18:57:34 -0500 Received: from dyn-tx-app-007.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14825 for ; Wed, 15 Jan 2003 18:42:13 -0500 (EST) Received: from TXADAM (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.12.5/8.12.5) with SMTP id h0FNiM9Z005424; Wed, 15 Jan 2003 17:44:46 -0600 Message-ID: <03ef01c2bcf0$1bdc98d0$bd346b83@dynamicsoft.com> From: "Adam Roach" To: "Paul Kyzivat" Cc: References: <9BF66EBF6BEFD942915B4D4D45C051F3A64410@DYN-TX-EXCH-001.dynamicsoft.com> <3E2458FE.2020506@cisco.com> Subject: Re: [Simple] Extending for presence MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Jan 2003 17:44:19 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Paul Kyzivat" writes: > If we want to attempt to do this at all, then I think we need to specify > the absolute time interval that the status applies to, or at least the > time it will cease to apply. UIs can be responsible for providing > shortcuts and configuration to make it simple to set statuses that > encode the proper values. So you could presumably still select an "Out > to Lunch" status from your UI, and it could figure out to say you will > be unavailable for the next hour. You make a good point, but I fear you may have missed mine. I don't want to get hung up on the exact details of the two parameters I propose. What I'd like to have is a short meta-conversation about whether this is the *sort* of thing we'd like to do. To reiterate my primary question: does anyone else see value to attempting to define explicit parameters associated with presence states instead of attempting to imply (or proscribe) semantics for pre-defined settings like "out to lunch" or "on vacation"? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 03:41:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04806 for ; Thu, 16 Jan 2003 03:41:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0G8uZS01765 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 03:56:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G8uYJ01762 for ; Thu, 16 Jan 2003 03:56:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04800 for ; Thu, 16 Jan 2003 03:41:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G8uQJ01750; Thu, 16 Jan 2003 03:56:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0G8r5J01580 for ; Thu, 16 Jan 2003 03:53:06 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04754 for ; Thu, 16 Jan 2003 03:37:32 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0G8h2t01733 for ; Thu, 16 Jan 2003 10:43:02 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 16 Jan 2003 10:40:51 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Jan 2003 10:40:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Extending for presence Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7133@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Extending for presence Thread-Index: AcK8ucUHsC8D7fXjTpaT3+IJ3xy+dwAf/Z2g To: , Cc: , , X-OriginalArrivalTime: 16 Jan 2003 08:40:51.0748 (UTC) FILETIME=[F9DBCE40:01C2BD3A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0G8r6J01581 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 10:40:50 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit If a tuple is representing a device, the OPEN and CLOSED means that the device is available for communication (to the extent that I could tell if the device is turned on or it is off). The list of elements that follow tells you which communication means are available and which are not: Using draft-lonnfors-simple-prescaps-ext-00.txt. It is: OPEN voice not allowed except high priority false true true Active/Inactive could mean that even though my device is open, I, as a presentity, am inactive on that device. Where did those active/inactive come from? What was the original need for them? Regards, Hisham > -----Original Message----- > From: ext Vijay K. Gurbani [mailto:vkg@lucent.com] > Sent: Wednesday, January 15, 2003 7:08 PM > To: Paul Kyzivat > Cc: Jonathan Rosenberg; Henning Schulzrinne; simple@ietf.org > Subject: Re: [Simple] Extending for presence > > > The more I think through these discussions, the more convinced I get > that we ought to maintain the presence state of the presentity > itself distinct from that of any of the devices that can be used to > communicate with it. The only first class citizen in the presence > domain is the presentity itself; without it, all the devices > associated > with it are useless. My interpretation of rfc2778 yields an implicit > coupling between presence and IM; the former is used to drive the > latter. It has been argued that presence needs to be grounded in a > purpose in order to scope it. But the discussions so far appear to > point that the state of a presentity is far richer then the > individual state of the devices it commands. > > I think we are doing the same thing in simple -- letting the various > devices dictate presence/absence of the entity. Thus we have states > which are interpreted by different applications in different ways; for > example, being "out to lunch" and having a basic status of CLOSED is > equally valid, as is "being out to lunch" and having a basic status of > OPEN. > > On the other hand, if we posit that "being out to lunch" is a status > associated with the presentity itself, then the basic status is always > OPEN. The next thing to do is to see if the presentity can accept any > communication sessions while in this state. That is easy -- > go through > the devices and see which ones are OPEN or CLOSED or have q values or > priorities associated with them. > > I don't think we have lost any flexibility here, as far as I > can see it. > > Paul Kyzivat wrote: > > The orthogonality also means that Do Not Disturb shouldn't > be enforced > > (at least not vigorously) by the UAC. In general it should > be up to me > > to decide if I want to violate your wishes. If you want it > enforced, > > you can couple it with CLOSED. > > If we do NOT infer the state of the presentity from its devices, "Do > not Disturb" is easily enforcable. The state of the presentity itself > is OPEN, but that of all of its devices is CLOSED. I think that if > we provide a "Do Not Disturb", it should be enforced. Otherwise, as > has been pointed out before, others will learn to distrust > ones presence > status. > > Paul Kyzivat further writes: > > - I see one status type with values of {ACTIVE, INACTIVE} that is > > typically inferred by observing behavio > > - Another status type is explicitly set, with values of {AVAILABLE, > > DO-NOT-DISTURB, AWAY}. This can also carry an estimate of > when it is > > expected to change. > > All these status values -- ACTIVE, INACTIVE, DO-NOT-DISTURB, AWAY -- > refer to the state of the presentity itself; and furthermore, I will > go out on a limb and say that these correspond to OPEN. If > this is the > case, why not actually provide means for this in simple (as in the > WG) extensions to PIDF? > > Cheers, > > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Wireless Networks Group/Internet Software and Services > Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 0216 > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 06:12:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07147 for ; Thu, 16 Jan 2003 06:12:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GBR9m12494 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 06:27:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GBR9J12491 for ; Thu, 16 Jan 2003 06:27:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07137 for ; Thu, 16 Jan 2003 06:11:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GBR5J12467; Thu, 16 Jan 2003 06:27:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GBQ1J12394 for ; Thu, 16 Jan 2003 06:26:01 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07118 for ; Thu, 16 Jan 2003 06:10:27 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0GBDgYH001720; Thu, 16 Jan 2003 06:13:43 -0500 (EST) Message-ID: <3E2693D1.4030404@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Thanos Diacakis , "Vijay K. Gurbani" , Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E25D681.2050507@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 06:13:21 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: >> Again, I'm having trouble with some of those. "DND" is fairly easy: the >> person that the presentity represents does not want to be disturbed. >> What >> does that status of a *presentity* mean if it is "Away", or >> "Active/Inactive"? Away from what? Inactive how? I can understand >> if the >> status of a *device* is "Away", that could be defined to mean that >> there is >> no human using that device at that instant. Similarly, "Active" could be >> defined as the *device* is being used, but not sure what an active >> presentity is... Thoughts? > > > I agree with all of this. As soon as it is possible to describe the > status of two devices, presence can be different at each. > > If you want to have a single notion of presence, describe everything in > terms of one device. It can be a virtual device - a sip AoR with > multiple contact addresses to different physical devices. As long as you > describe it as a single tuple referencing the AoR, it has a single set > of status values. But if you choose to represent it with a separate > tuple for each contact address then each tuple might have conflicting > status values. In this latter case I think status for the presentity as > a whole is simply ambiguous. A few words are perhaps in order here on rfc2778. It is my recollection as it was developed that the idea was that rfc2778 could serve as a MODEL for presence systems. That is, it was sufficiently general that existing systems could be mapped to it. Thus, the concept of a "tuple" is just a way of modeling various things. So, the issue we are running into here is that there are many things which a tuple could potentially represent. So far, we have talked about a tuple representing: * a device * one of many logical targets of communications on a device * a presentity One can imagine a tuple representing other things, like a group of presentities, for example (sip:customer-support@example.com). So, the questions are: (1) do we need to standardize what these tuples represent, and (2) do we need to standardize the relationships between them. On (1), I think perhaps no, but on (2), I think maybe yes. Perhaps what we need is the ability to represent things in a hierarchy. So, you could have a tuple, and within it, some more tuples, and within those, more tuples. The meaning of the hierarchy may only be important to a user, and thus represented by notes. For example, the top level tuple might represent a presentity, and it may have its own basic status, which just indicates whether the presentity is willing to be contacted. If none is provided, it might be "derived" from the basic status elements of its child tuples. While its not clear to me what a basic status of OPEN for a presentity means when each of its child tuples (the devices) are CLOSED, there are most definitely attributes, such as "out to lunch" which make more sense for a tuple that represents a presentity, than for a tuple that represents a device. Just a thought... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 06:18:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07197 for ; Thu, 16 Jan 2003 06:18:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GBX5e12771 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 06:33:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GBX5J12768 for ; Thu, 16 Jan 2003 06:33:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07189 for ; Thu, 16 Jan 2003 06:17:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GBX1J12759; Thu, 16 Jan 2003 06:33:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GBW7J12721 for ; Thu, 16 Jan 2003 06:32:07 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07185 for ; Thu, 16 Jan 2003 06:16:33 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0GBJlYH001723; Thu, 16 Jan 2003 06:19:47 -0500 (EST) Message-ID: <3E26953D.9000508@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Paul Kyzivat , Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 06:19:25 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > Paul Kyzivat wrote: > > The orthogonality also means that Do Not Disturb shouldn't be enforced > > (at least not vigorously) by the UAC. In general it should be up to me > > to decide if I want to violate your wishes. If you want it enforced, > > you can couple it with CLOSED. > > If we do NOT infer the state of the presentity from its devices, "Do > not Disturb" is easily enforcable. The state of the presentity itself > is OPEN, but that of all of its devices is CLOSED. I think that if > we provide a "Do Not Disturb", it should be enforced. Otherwise, as > has been pointed out before, others will learn to distrust ones presence > status. I disagree. We are just talking about presence. The decision to reject a call (or an IM) when someone is "do not disturb" in their presence, is an APPLICATION of presence. Indeed, it may be a multiplicity of applications - something that blocks IM, as part of a messaging app, something that forwards calls to voicemail, as a voice app, and so on. I do not know how one can mandate the deployment of certain applications of presence. The most we can do is describe the semantic of what these things mean. IMHO, "do not disturb" simply means that the user does not wish to be contacted at this time. Thats all it means. Applications can consume this, and do things with it, appropriate for its semantic. As an example, a PC application could render an icon. An IM app could reject IMs. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 06:28:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07396 for ; Thu, 16 Jan 2003 06:28:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GBh6h13925 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 06:43:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GBh6J13922 for ; Thu, 16 Jan 2003 06:43:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07392 for ; Thu, 16 Jan 2003 06:27:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GBh3J13913; Thu, 16 Jan 2003 06:43:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GBgEJ13893 for ; Thu, 16 Jan 2003 06:42:14 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07380 for ; Thu, 16 Jan 2003 06:26:39 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0GBTsYH001727; Thu, 16 Jan 2003 06:29:55 -0500 (EST) Message-ID: <3E26979D.7000002@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: "Vijay K. Gurbani" , Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E22FEA1.4010802@lucent.com> <3E2317F8.3000805@cisco.com> <3E253B8F.5060304@dynamicsoft.com> <3E258E4E.8090908@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 06:29:33 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: >> To me, this suggests that my device is modeled as two separate tuples. >> One for voice, with a status of CLOSED, and one with IM, with a status >> of open. This would, perhaps, need some way to allow the watcher to >> correlate these two so as to know that they represent the same >> physical device. Indeed, one might envision "device" as another status >> itself! So: >> >> >> OPEN >> Cell Phone >> IM allowed >> >> >> >> CLOSED >> Cell Phone >> voice not allowed except high priority >> >> >> Device could be an enumerated type, or perhaps even just a textual >> string. > > > Well, there are many ways to skin a cat. > > Is there any value to beyond ? If I can compare two > devices for equality I can just as easily compare two contact addresses > for equality. Sure, there is a difference. The Contact may very well be different. For example, the "IM" piece of my phone could perhaps be addressed as sip:im-app@1.2.3.4, and the "voice" piece as sip:voice-app@1.2.3.4. These might represent different resources on the same device. > > It seems to me a lot easier to understand if each tuple with a contact > represents a distinct communication target, so I can decide whether it > is useful to me independently of all the others. See my previous note on this; I think our trouble is that we are unsure of what a tuple really is modelling. > > Otherwise, things get messy if I potentially want to use multiple media. > Then I have to look for all tuples representing the same device and > combine their statuses before deciding if the device is suitable for my > needs. And then I must still deal with the potential for conflicting > status values between those tuples. It isn't an unsolvable problem, but > is it better than simply permitting availablility information for each > medium? The callerprefs stuff can already do that. The issue is whether or not I want to provide multiple status values for each medium. You are basically saying that, if all I want is to indicate OPEN/CLOSED, I can equally do that with the callreprefs stuff by indicating false for video or audio, as the case may be. What about other statuses we come up with? Perhaps there are no examples, and so this point is moot. Not clear to me yet. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 06:47:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07718 for ; Thu, 16 Jan 2003 06:47:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GC2Bj14835 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 07:02:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GC2BJ14832 for ; Thu, 16 Jan 2003 07:02:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07713 for ; Thu, 16 Jan 2003 06:46:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GC26J14822; Thu, 16 Jan 2003 07:02:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GC1rJ14794 for ; Thu, 16 Jan 2003 07:01:53 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07709 for ; Thu, 16 Jan 2003 06:46:18 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0GBndYH001737; Thu, 16 Jan 2003 06:49:40 -0500 (EST) Message-ID: <3E269C3E.7080309@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, adam@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Extending for presence References: <2038BCC78B1AD641891A0D1AE133DBB7FE7128@esebe019.ntc.nokia.com> <3E2581EE.6000608@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 06:49:18 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: > Hisham, > > PIDF already provides similar information - it provides the > element in each , giving the time the status last changed. > > The limitation is that this pertains to the tuple as a whole, not > individual elements within the tuple. This is probably good enough for > some purposes, but maybe not all. Going beyond this would require > timestamping individual status values. Hopefully that isn't necessary. I think it may be. Lets say we have three status types - basic, "activity", which includes out-to-lucnh, in-a-meeting and so on, and the caller prefs things. The timestamp on the tuple indicates the last time anything changed. Lets say I go into a meeting, and so I change my "activity" to "in a meeting". Then, an hour into the meeting, things begin to get fierce, so I change my basic status to CLOSED. Activity remains as "in a meeting". WHen I change basic status to closed, the timestamp changes too. I think it would be very useful to know when I set JUST the activity status to "in a meeting". Perhaps this need is specific to this activity status, and less important for things like basic or the caller prefs stuff. But I do see a need for multiple timestamps. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 08:41:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10628 for ; Thu, 16 Jan 2003 08:41:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GDuEH22978 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 08:56:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GDuEJ22975 for ; Thu, 16 Jan 2003 08:56:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10618 for ; Thu, 16 Jan 2003 08:40:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GDu7J22963; Thu, 16 Jan 2003 08:56:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GDttJ22938 for ; Thu, 16 Jan 2003 08:55:55 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10612 for ; Thu, 16 Jan 2003 08:40:16 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0GDhcYH001784; Thu, 16 Jan 2003 08:43:39 -0500 (EST) Message-ID: <3E26B704.3060303@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com CC: pkyzivat@cisco.com, simple@ietf.org Subject: Re: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt References: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBE4F@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 08:43:32 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I am fine with this conclusion. From my own glance through RDF it seems like quite a bit of overkill for the very simple things we are doing now. -Jonathan R. mikko.lonnfors@nokia.com wrote: > Hi, > > Back to this old topic. > Inline: > > >>-----Original Message----- >>From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Sent: 18 November, 2002 08:09 >>To: Paul Kyzivat >>Cc: Lonnfors Mikko (NRC/Helsinki); simple@mailman.dynamicsoft.com >>Subject: Re: [Simple] FW: I-D >>ACTION:draft-lonnfors-simple-prescaps-ext-00.txt >> >> > >> >> w3c has done a lot of work in describing capabilities >>(CC/PP, RDF), >> >> all of which is XML-based. I wonder if there is a better fit here >> >> to use that kind of syntax? >> > >>-Jonathan R. > > > I have been looking if RDF or CC/PP could be utilized to represent caller preferences information instead of using our own XML format. Basically situation seems to be that RDF may not be the best choice for us in this situation. RDF defines a framework which can be used to represent metadata about resources. It defines simple model for describing relationships among resources in terms of named properties and values. It cannot by itself be used to represent data required by specific applications and so it needs an additional vocabulary for each application. > CC/PP defines one set of vocabulary (based on RDF) which is a description of device capabilities and user preferences that can be used to guide the adaptation of content presented to that device. CC/PP defines things like display size, terminal software, and browser capabilities. These don't provide much help for items needed for caller preferences. So, if we would like to utilize RDF it would have following consequences: > 1) We would probably need to define a new vocabulary. It is a bit unclear if this should be done in W3C or in IETF > 2) UAs would need to have support for RDF aware parsers. RDF representation is based on XML but parsers need to understand whole RDF schema. Currently such parsers are not widely available. > > If the whole presence info would be build utilizing RDF (PIDF would be based on RDF) then it would make sense to use RDF but probably not in this situation. I would propose that for now we stick with our own XML format. > > Best Regards > - Mikko > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 09:01:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11153 for ; Thu, 16 Jan 2003 09:01:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GEH5T24690 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 09:17:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEH5J24687 for ; Thu, 16 Jan 2003 09:17:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11098 for ; Thu, 16 Jan 2003 09:01:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEH2J24679; Thu, 16 Jan 2003 09:17:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEGhJ24626 for ; Thu, 16 Jan 2003 09:16:43 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11075 for ; Thu, 16 Jan 2003 09:01:05 -0500 (EST) Received: from cs.columbia.edu (APh-Aug-102-2-1-12.abo.wanadoo.fr [193.252.40.12]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0GE4O26015214 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 16 Jan 2003 09:04:26 -0500 (EST) Message-ID: <3E26BB52.4020303@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <3E26953D.9000508@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 09:01:54 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Stepping back a bit, maybe we should ask what kind of questions presence about a person can answer. (1) Is the person available for communications and, if so, on what media? Here, in general, we only care about the media that are available, not all the media that the user doesn't have right now, since that list is unbounded once you add applications ("No, I'm not available for Doom, Chess, SimCity, ..."). We might conceivably care about how long a media might still be available ("leaving in 15 minutes, better call quickly") or when it might be available again ("meeting ends in 20 minutes"). (2) What is the person doing right now? We might want to know not just the start time (how long already), but also how long until anticipated completion. Note that many calendar systems (such as RFC 2445 or Yahoo calendar) allow for categories of activities. Some are free-text (but often definable as a list for a particular software), others are pre-defined. (3) How is the person feeling right now (calm and relaxed, stressed, hopping mad) - very useful to know for the calling party and easily derived from a real-time blood-pressure input. (:-), if that's needed.) Obviously, there could be many other pieces of information that might be useful to others, such as location, level of distraction ("watching TV"), etc., but I suspect we all agree that those are beyond the current discussion. Note that you can easily get to the point where you are effectively sending an iCal (or xCal draft-ietf-calsch-many-xcal-02.txt) entry describing the activity. This may be a better, more general solution. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 09:09:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11491 for ; Thu, 16 Jan 2003 09:09:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GEP5g25108 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 09:25:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEP5J25105 for ; Thu, 16 Jan 2003 09:25:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11484 for ; Thu, 16 Jan 2003 09:09:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEP2J25089; Thu, 16 Jan 2003 09:25:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GEOGJ25049 for ; Thu, 16 Jan 2003 09:24:16 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11473 for ; Thu, 16 Jan 2003 09:08:37 -0500 (EST) Received: from cs.columbia.edu (APh-Aug-102-2-1-12.abo.wanadoo.fr [193.252.40.12]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0GEBv26021153 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 16 Jan 2003 09:11:59 -0500 (EST) Message-ID: <3E26BD18.2090501@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <3E26953D.9000508@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 09:09:28 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Another dimension: availability for communication can probably be classified into three rough classes: - available real-time - available store-and-forward (message store of some sort, e.g., voicemail or IMs that are stored somewhere for retrieval) - not available _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 09:55:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12879 for ; Thu, 16 Jan 2003 09:55:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GFABo28695 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 10:10:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFABJ28692 for ; Thu, 16 Jan 2003 10:10:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12851 for ; Thu, 16 Jan 2003 09:54:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFA5J28681; Thu, 16 Jan 2003 10:10:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GF9lJ28649 for ; Thu, 16 Jan 2003 10:09:47 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12804 for ; Thu, 16 Jan 2003 09:54:07 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0GEvQx02017; Thu, 16 Jan 2003 09:57:27 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA07576; Thu, 16 Jan 2003 08:57:26 -0600 (CST) Message-ID: <3E26C801.4020305@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thanos Diacakis CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 08:56:01 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanos Diacakis wrote: > Currently the presentity cannot have a OPEN or CLOSED status, > simply because we haven't defined what that means. What do you have > in mind when you say that a presentity is OPEN or CLOSED? Simply that a presentity itself is online or offline, without any reference to its devices. Thus a presentity that is online, but does not want to be disturbed has *its* status as OPEN while all the devices it commands are CLOSED. As I have been saying, many times the notion of presence in and of itself is sufficient. I would like to know if my manager is in the office before I cross the campus to meet him. If he has not turned on his cell phone or his started his SIP UA, does that mean that he is not present? >>All these status values -- ACTIVE, INACTIVE, DO-NOT-DISTURB, AWAY -- >>refer to the state of the presentity itself; and furthermore, I will >>go out on a limb and say that these correspond to OPEN. If this is >>the case, why not actually provide means for this in simple (as in the >>WG) extensions to PIDF? > > > Again, I'm having trouble with some of those. "DND" is fairly easy: > the person that the presentity represents does not want to be > disturbed. What does that status of a *presentity* mean if it is > "Away", or "Active/Inactive"? Away from what? Inactive how? I can > understand if the status of a *device* is "Away", that could be > defined to mean that there is no human using that device at that > instant. Similarly, "Active" could be defined as the *device* is > being used, but not sure what an active presentity is... Thoughts? We are looking at this through a device-centric lens; hence you argue that "Away" implies that there is no human using the device. However, to me, "Away" implies that the presentity itself is away from all of its devices; it is still present, per se. For instance, the status "Away" qualified by a location extension of "Office" allows one to deduce that the presentity is in the office, although not near any of its devices right now. The main actor in presence should be the presentity, not the device. If we take that model, then status strings like "Busy-interrupt" that I proposed earlier make eminent sense. We are quantifying the state of the presentity -- "Busy-interrupt" would imply that the presentity is currently busy, but try sending an invitation for communication anyway; if it is important enought, it may get answered. Cheers, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 10:03:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13142 for ; Thu, 16 Jan 2003 10:03:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GFIAM29161 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 10:18:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFIAJ29158 for ; Thu, 16 Jan 2003 10:18:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13100 for ; Thu, 16 Jan 2003 10:02:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFI4J29150; Thu, 16 Jan 2003 10:18:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFHNJ29091 for ; Thu, 16 Jan 2003 10:17:23 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13080 for ; Thu, 16 Jan 2003 10:01:43 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0GF53x06886; Thu, 16 Jan 2003 10:05:03 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA10573; Thu, 16 Jan 2003 09:05:03 -0600 (CST) Message-ID: <3E26C9CA.2070908@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Thanos Diacakis , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E25D681.2050507@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 09:03:38 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: >> Vijay Gurbani wrote: >> >>> If we do NOT infer the state of the presentity from its devices, "Do >>> not Disturb" is easily enforcable. The state of the presentity itself >>> is OPEN, but that of all of its devices is CLOSED. I think that if >>> we provide a "Do Not Disturb", it should be enforced. Otherwise, as >>> has been pointed out before, others will learn to distrust ones presence >>> status. >> > > This makes no sense to me. What does it possibly mean to say the state > of the presentity is OPEN but the state of all the devices is closed? Because it makes it easy to model DND, for instance. Our model of presence right now is device-centric; I am arguing for a presentity- centric model, where the presentity is the main actor. Thus, a status of OPEN for the presentity and CLOSED for all the devices authoritatively implies DND. We do not leave it to the application to decide if it should interrup the presentity or not. The presentity- centric model also makes it easier to represent "Busy-Interrupt"; it is the presentity that is busy, but willing to be interrupted. Not the device. > In > what way would things be changes if we then changed the state of the > presentity to CLOSED? That is simple (no pun intended :-)) -- a state of CLOSED for the presentity implies that the presentity is offline and not accessible through any interactive communication means (I would not consider voice- mail as interactive communications here). > The meaning of OPEN and CLOSED is defined in terms of what can be done > with the devices. I think if we view this from a different angle and apply it to the presentity as well, the model becomes that much more powerful. Cheers, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 10:06:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13242 for ; Thu, 16 Jan 2003 10:06:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GFM6Z29389 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 10:22:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFM6J29386 for ; Thu, 16 Jan 2003 10:22:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13216 for ; Thu, 16 Jan 2003 10:06:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFM2J29378; Thu, 16 Jan 2003 10:22:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFLcJ29353 for ; Thu, 16 Jan 2003 10:21:38 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13205 for ; Thu, 16 Jan 2003 10:05:57 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0GF9Hx09449; Thu, 16 Jan 2003 10:09:17 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA12281; Thu, 16 Jan 2003 09:09:16 -0600 (CST) Message-ID: <3E26CAC8.8000105@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: Paul Kyzivat , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <9BF66EBF6BEFD942915B4D4D45C051F3A64410@DYN-TX-EXCH-001.dynamicsoft.com> <3E2458FE.2020506@cisco.com> <03ef01c2bcf0$1bdc98d0$bd346b83@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 09:07:52 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Adam Roach wrote: > To reiterate my primary question: does anyone else see value to > attempting to define explicit parameters associated with > presence states instead of attempting to imply (or proscribe) > semantics for pre-defined settings like "out to lunch" or > "on vacation"? Yes, most definitely. What you write implicitly refers to the status of the presentity itself, which is what I have been arguing for all along. It is the presentity that is "Out to lunch", "Away" or "On vacation", not the devices. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 10:15:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13444 for ; Thu, 16 Jan 2003 10:15:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GFUF229968 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 10:30:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFUFJ29965 for ; Thu, 16 Jan 2003 10:30:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13431 for ; Thu, 16 Jan 2003 10:14:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFU8J29954; Thu, 16 Jan 2003 10:30:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFTKJ29907 for ; Thu, 16 Jan 2003 10:29:20 -0500 Received: from oe-im2.bizmailsrvcs.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13422 for ; Thu, 16 Jan 2003 10:13:38 -0500 (EST) Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27]) by oe-im2.bizmailsrvcs.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030116151657.FLOY24803.oe-im2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>; Thu, 16 Jan 2003 09:16:57 -0600 Received: from diacakist ([12.253.90.102]) by oe-ismta2.bizmailsrvcs.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with SMTP id <20030116151652.TCFV13955.oe-ismta2.bizmailsrvcs.net@diacakist>; Thu, 16 Jan 2003 09:16:52 -0600 Message-ID: <007c01c2bd72$4c1fd070$6401a8c0@myopwv.com> From: "Thanos Diacakis" To: "Vijay K. Gurbani" Cc: References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E26C801.4020305@lucent.com> Subject: Re: [Simple] Extending for presence MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 08:16:03 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think you are proposing that the presentity status be defined as follows: If one or more devices are OPEN, then the presentity is OPEN, else if all devices are CLOSED, the presentity is CLOSED. If this is what you are saying, then it is redundant, as that information can easily be determine from looking at the tuples. Having it as a separate item, doesn't achieve anything. Your definition of "Busy-interrupt" is a sensible one (though there could be others). The point here is that the activity variable ("busy-interrupt") and status (OPEN/CLOSED) variables, are orthogonal to eachother. However, the particular value for the activity (busy-interrupt), under your definition, would only apply though if the status variable has an OPEN value. Thanos --- Thanos Diacakis Openwave Systems thanos.diacakis@openwave.com +1-303 385 6705 ----- Original Message ----- From: "Vijay K. Gurbani" To: "Thanos Diacakis" Cc: Sent: Thursday, January 16, 2003 7:56 AM Subject: Re: [Simple] Extending for presence > Thanos Diacakis wrote: > > Currently the presentity cannot have a OPEN or CLOSED status, > > simply because we haven't defined what that means. What do you have > > in mind when you say that a presentity is OPEN or CLOSED? > > Simply that a presentity itself is online or offline, without any > reference to its devices. Thus a presentity that is online, but > does not want to be disturbed has *its* status as OPEN while > all the devices it commands are CLOSED. > > As I have been saying, many times the notion of presence in and of > itself is sufficient. I would like to know if my manager is in the > office before I cross the campus to meet him. If he has not turned on > his cell phone or his started his SIP UA, does that mean that he is not > present? > > >>All these status values -- ACTIVE, INACTIVE, DO-NOT-DISTURB, AWAY -- > >>refer to the state of the presentity itself; and furthermore, I will > >>go out on a limb and say that these correspond to OPEN. If this is > >>the case, why not actually provide means for this in simple (as in the > >>WG) extensions to PIDF? > > > > > > Again, I'm having trouble with some of those. "DND" is fairly easy: > > the person that the presentity represents does not want to be > > disturbed. What does that status of a *presentity* mean if it is > > "Away", or "Active/Inactive"? Away from what? Inactive how? I can > > understand if the status of a *device* is "Away", that could be > > defined to mean that there is no human using that device at that > > instant. Similarly, "Active" could be defined as the *device* is > > being used, but not sure what an active presentity is... Thoughts? > > We are looking at this through a device-centric lens; hence you argue > that "Away" implies that there is no human using the device. However, > to me, "Away" implies that the presentity itself is away from all of > its devices; it is still present, per se. For instance, the status > "Away" qualified by a location extension of "Office" allows one to > deduce that the presentity is in the office, although not near any > of its devices right now. The main actor in presence should be the > presentity, not the device. > > If we take that model, then status strings like "Busy-interrupt" that > I proposed earlier make eminent sense. We are quantifying the state > of the presentity -- "Busy-interrupt" would imply that the presentity > is currently busy, but try sending an invitation for communication > anyway; if it is important enought, it may get answered. > > Cheers, > > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Wireless Networks Group/Internet Software and Services > Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 0216 > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 10:18:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13570 for ; Thu, 16 Jan 2003 10:18:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GFY6C30306 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 10:34:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFY6J30303 for ; Thu, 16 Jan 2003 10:34:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13561 for ; Thu, 16 Jan 2003 10:18:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFY1J30275; Thu, 16 Jan 2003 10:34:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFXBJ30217 for ; Thu, 16 Jan 2003 10:33:11 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13532 for ; Thu, 16 Jan 2003 10:17:30 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0GFKax16986; Thu, 16 Jan 2003 10:20:36 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA16960; Thu, 16 Jan 2003 09:20:35 -0600 (CST) Message-ID: <3E26CD6E.1070905@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: simple@ietf.org, Henning Schulzrinne , Paul Kyzivat Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <3E26953D.9000508@dynamicsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 09:19:10 -0600 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Jonathan Rosenberg wrote: > Vijay K. Gurbani wrote: >> If we do NOT infer the state of the presentity from its devices, "Do >> not Disturb" is easily enforcable. The state of the presentity itself >> is OPEN, but that of all of its devices is CLOSED. I think that if >> we provide a "Do Not Disturb", it should be enforced. Otherwise, as >> has been pointed out before, others will learn to distrust ones presence >> status. > > > I disagree. > > We are just talking about presence. The decision to reject a call (or an > IM) when someone is "do not disturb" in their presence, is an > APPLICATION of presence. Indeed, it may be a multiplicity of > applications - something that blocks IM, as part of a messaging app, > something that forwards calls to voicemail, as a voice app, and so on. Then DND is a misnomer. DND implies to me that I as a presentity do not want to be disturbed -- akin to closing my office door and putting a "Go Away" sign on it during office hours. If what we want to represent is that voice calls are blocked but IM can get through, then we should use some other status value, like "Busy Interrupt". The problem with leaving interpretation to application is that each app may choose to inerpret it in a different manner, leading to all kinds of user expectation problems. If I am used to presence app A's behavior of DND, I will be rather upset when I use presence app B and it's behavior differs from A's. We are representing status through tokens which have well defined cultural nuances (irrespective of the language). When you hang a card containing "Do Not Disturb" or "Ne dérangez pas, sil vous plait", or "No disturbe, por favor" on the hotel door, you might be upset if the maid opened the door and came in anyway, right? Why then the dichotomy to the same token when it is applied to an electronic medium? We do not have a paucity of tokens to choose from to represent status. I would rather choose something like "Busy but interruptible" to make clear my intention rather than a "Do Not Disturb". Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 10:21:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13638 for ; Thu, 16 Jan 2003 10:21:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GFb7A30618 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 10:37:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFb6J30612 for ; Thu, 16 Jan 2003 10:37:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13630 for ; Thu, 16 Jan 2003 10:21:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFb1J30490; Thu, 16 Jan 2003 10:37:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFaFJ30440 for ; Thu, 16 Jan 2003 10:36:15 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13611 for ; Thu, 16 Jan 2003 10:20:34 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0GFNsx19194; Thu, 16 Jan 2003 10:23:54 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA18143; Thu, 16 Jan 2003 09:23:53 -0600 (CST) Message-ID: <3E26CE34.50503@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Paul Kyzivat , Thanos Diacakis , Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E25D681.2050507@cisco.com> <3E2693D1.4030404@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 09:22:28 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Inline. Jonathan Rosenberg wrote: > So, the issue we are running into here is that there are many things > which a tuple could potentially represent. So far, we have talked about > a tuple representing: > > * a device > * one of many logical targets of communications on a device > * a presentity [...] > So, the questions are: (1) do we need to standardize what these tuples > represent, and (2) do we need to standardize the relationships between > them. On (1), I think perhaps no, but on (2), I think maybe yes. Perhaps > what we need is the ability to represent things in a hierarchy. So, you > could have a tuple, and within it, some more tuples, and within those, > more tuples. The meaning of the hierarchy may only be important to a > user, and thus represented by notes. For example, the top level tuple > might represent a presentity, and it may have its own basic status, > which just indicates whether the presentity is willing to be contacted. > If none is provided, it might be "derived" from the basic status > elements of its child tuples. Exactly! That is what I have been arguing for all along. It is the presentity that is the main actor in this domain, not the devices. > While its not clear to me what a basic > status of OPEN for a presentity means when each of its child tuples (the > devices) are CLOSED, Easy to represent DND. > there are most definitely attributes, such as "out > to lunch" which make more sense for a tuple that represents a > presentity, than for a tuple that represents a device. Exactly. Thanks! - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 10:37:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14036 for ; Thu, 16 Jan 2003 10:37:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GFr6B31832 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 10:53:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFr6J31829 for ; Thu, 16 Jan 2003 10:53:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14031 for ; Thu, 16 Jan 2003 10:37:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFr2J31821; Thu, 16 Jan 2003 10:53:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GFqoJ31805 for ; Thu, 16 Jan 2003 10:52:50 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14024 for ; Thu, 16 Jan 2003 10:37:09 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0GFeUx29201; Thu, 16 Jan 2003 10:40:30 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA25533; Thu, 16 Jan 2003 09:40:29 -0600 (CST) Message-ID: <3E26D219.2020708@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thanos Diacakis CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E26C801.4020305@lucent.com> <007c01c2bd72$4c1fd070$6401a8c0@myopwv.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 09:39:05 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanos Diacakis wrote: > I think you are proposing that the presentity status be defined as > follows: > > If one or more devices are OPEN, then the presentity is OPEN, else if > all devices are CLOSED, the presentity is CLOSED. > > If this is what you are saying, then it is redundant, as that information > can easily be determine from looking at the tuples. Having it as a > separate item, doesn't achieve anything. I think it does. If I want to unambiguously represent DND from a presentity-centric view, then the status of the presentity is OPEN, but that of all its devices is CLOSED. The presentity status of OPEN, coupled with a qualifier like "In meeting with CEO" informs all watchers about the presentity's state in no uncertain terms. Thus it is important that the presence state of the presentity be represented in a tuple. Deducing it can lead to ambiguity. > Your definition of "Busy-interrupt" is a sensible one (though there could > be others). The point here is that the activity variable > ("busy-interrupt") and status (OPEN/CLOSED) variables, are orthogonal to > eachother. However, the particular value for the activity > (busy-interrupt), under your definition, would only apply though if the > status variable has an OPEN value. Yes, exactly. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 10:50:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14354 for ; Thu, 16 Jan 2003 10:50:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GG65132576 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 11:06:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GG65J32573 for ; Thu, 16 Jan 2003 11:06:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14314 for ; Thu, 16 Jan 2003 10:50:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GG61J32548; Thu, 16 Jan 2003 11:06:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GG5XJ32522 for ; Thu, 16 Jan 2003 11:05:33 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14300 for ; Thu, 16 Jan 2003 10:49:52 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0GFrDx06290; Thu, 16 Jan 2003 10:53:13 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA01783; Thu, 16 Jan 2003 09:53:12 -0600 (CST) Message-ID: <3E26D514.8030105@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <3E26953D.9000508@dynamicsoft.com> <3E26BD18.2090501@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 09:51:48 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Another dimension: availability for communication can probably be > classified into three rough classes: > > - available real-time > - available store-and-forward (message store of some sort, e.g., > voicemail or IMs that are stored somewhere for retrieval) > - not available I would like to add one more: - Busy but interruptible (i.e. try getting in touch with me, I may answer if I can). There is one more, but I am unsure if it is a status in its own right or something that can be derived by applying filters: - Busy, but only available to certain people (this will include the domain-specific examples you had earlier -- professor in an oral, only department secretary can interrupt him, etc.) Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 13:03:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18460 for ; Thu, 16 Jan 2003 13:03:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GIJ9d10902 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 13:19:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIJ9J10899 for ; Thu, 16 Jan 2003 13:19:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18430 for ; Thu, 16 Jan 2003 13:03:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIJ5J10887; Thu, 16 Jan 2003 13:19:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIJ0J10853 for ; Thu, 16 Jan 2003 13:19:00 -0500 Received: from oe-im1.bizmailsrvcs.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18418 for ; Thu, 16 Jan 2003 13:03:17 -0500 (EST) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-im1.bizmailsrvcs.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030116180639.WTNZ20946.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Thu, 16 Jan 2003 12:06:39 -0600 Received: from diacakist ([63.67.207.249]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with SMTP id <20030116180638.UTPV8904.oe-ismta1.bizmailsrvcs.net@diacakist>; Thu, 16 Jan 2003 12:06:38 -0600 Message-ID: <05f901c2bd8a$03b2ef30$40071e0a@myopwv.com> From: "Thanos Diacakis" To: "Vijay K. Gurbani" , "Paul Kyzivat" Cc: References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E25D681.2050507@cisco.com> <3E26C9CA.2070908@lucent.com> Subject: Re: [Simple] Extending for presence MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 11:02:53 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit comments inline. ----- Original Message ----- From: "Vijay K. Gurbani" To: "Paul Kyzivat" Cc: "Thanos Diacakis" ; Sent: Thursday, January 16, 2003 8:03 AM Subject: Re: [Simple] Extending for presence > Paul Kyzivat wrote: > >> Vijay Gurbani wrote: > >> > >>> If we do NOT infer the state of the presentity from its devices, "Do > >>> not Disturb" is easily enforcable. The state of the presentity itself > >>> is OPEN, but that of all of its devices is CLOSED. I think that if > >>> we provide a "Do Not Disturb", it should be enforced. Otherwise, as > >>> has been pointed out before, others will learn to distrust ones presence > >>> status. > >> > > > > This makes no sense to me. What does it possibly mean to say the state > > of the presentity is OPEN but the state of all the devices is closed? > > Because it makes it easy to model DND, for instance. Our model of > presence right now is device-centric; I am arguing for a presentity- > centric model, where the presentity is the main actor. Thus, a status > of OPEN for the presentity and CLOSED for all the devices > authoritatively implies DND. We do not leave it to the application to > decide if it should interrup the presentity or not. The presentity- > centric model also makes it easier to represent "Busy-Interrupt"; it > is the presentity that is busy, but willing to be interrupted. Not the > device. Erm, then I have misunderstood your definition as per my previous email. Please clarify what that is, because the above paragraph is ambiguous to me. > > In > > what way would things be changes if we then changed the state of the > > presentity to CLOSED? > > That is simple (no pun intended :-)) -- a state of CLOSED for the > presentity implies that the presentity is offline and not accessible > through any interactive communication means (I would not consider voice- > mail as interactive communications here). Again, what does the "presentity" (i.e. the person) being "offline" mean? Thanos --- Thanos Diacakis Openwave Systems thanos.diacakis@openwave.com +1-303 385 6705 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 13:04:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18512 for ; Thu, 16 Jan 2003 13:04:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GIK5k11031 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 13:20:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIK5J11027 for ; Thu, 16 Jan 2003 13:20:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18503 for ; Thu, 16 Jan 2003 13:04:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIK2J10998; Thu, 16 Jan 2003 13:20:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIJ5J10881 for ; Thu, 16 Jan 2003 13:19:05 -0500 Received: from oe-im1.bizmailsrvcs.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18425 for ; Thu, 16 Jan 2003 13:03:22 -0500 (EST) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-im1.bizmailsrvcs.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030116180643.WTOF20946.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Thu, 16 Jan 2003 12:06:43 -0600 Received: from diacakist ([63.67.207.249]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with SMTP id <20030116180643.UTQA8904.oe-ismta1.bizmailsrvcs.net@diacakist>; Thu, 16 Jan 2003 12:06:43 -0600 Message-ID: <05fa01c2bd8a$069b1b00$40071e0a@myopwv.com> From: "Thanos Diacakis" To: "Vijay K. Gurbani" , "Adam Roach" Cc: "Paul Kyzivat" , References: <9BF66EBF6BEFD942915B4D4D45C051F3A64410@DYN-TX-EXCH-001.dynamicsoft.com> <3E2458FE.2020506@cisco.com> <03ef01c2bcf0$1bdc98d0$bd346b83@dynamicsoft.com> <3E26CAC8.8000105@lucent.com> Subject: Re: [Simple] Extending for presence MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 11:05:56 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > Yes, most definitely. What you write implicitly refers to the status > of the presentity itself, which is what I have been arguing for all > along. It is the presentity that is "Out to lunch", "Away" or > "On vacation", not the devices. The presenity can be "out to lunch" or "on vacation", but it CANNOT be "Away". "Away" means object A is geographically separated from object B. A presentity needs to be "Away" from *SOMETHING*. In the context that we usually use "Away", we refer to the separation between Presenity and Device. Thanos --- Thanos Diacakis Openwave Systems thanos.diacakis@openwave.com +1-303 385 6705 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 13:21:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19038 for ; Thu, 16 Jan 2003 13:21:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GIbAA12242 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 13:37:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIbAJ12235 for ; Thu, 16 Jan 2003 13:37:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19007 for ; Thu, 16 Jan 2003 13:21:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIb6J12102; Thu, 16 Jan 2003 13:37:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIWQJ11653 for ; Thu, 16 Jan 2003 13:32:26 -0500 Received: from oe-im1.bizmailsrvcs.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18798 for ; Thu, 16 Jan 2003 13:16:42 -0500 (EST) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-im1.bizmailsrvcs.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030116182004.WVSC20946.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Thu, 16 Jan 2003 12:20:04 -0600 Received: from diacakist ([63.67.207.249]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with SMTP id <20030116182003.UVSG8904.oe-ismta1.bizmailsrvcs.net@diacakist>; Thu, 16 Jan 2003 12:20:03 -0600 Message-ID: <062a01c2bd8b$e3993e50$40071e0a@myopwv.com> From: "Thanos Diacakis" To: "Vijay K. Gurbani" , "Jonathan Rosenberg" Cc: "Paul Kyzivat" , "Henning Schulzrinne" , References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E25D681.2050507@cisco.com> <3E2693D1.4030404@dynamicsoft.com> <3E26CE34.50503@lucent.com> Subject: Re: [Simple] Extending for presence MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 11:13:36 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Gurbani wrote: > > While its not clear to me what a basic > > status of OPEN for a presentity means when each of its child tuples (the > > devices) are CLOSED, > > Easy to represent DND. No! My "activity" (DND in this case) is orthogonal to the OPEN/CLOSED status of my devices and we cannot represent the one using the other. We need a separate variable/tuple/field to do so. Thanos --- Thanos Diacakis Openwave Systems thanos.diacakis@openwave.com +1-303 385 6705 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 13:21:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19044 for ; Thu, 16 Jan 2003 13:21:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GIbBC12257 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 13:37:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIbBJ12254 for ; Thu, 16 Jan 2003 13:37:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19012 for ; Thu, 16 Jan 2003 13:21:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIb7J12151; Thu, 16 Jan 2003 13:37:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIWVJ11657 for ; Thu, 16 Jan 2003 13:32:31 -0500 Received: from oe-im1.bizmailsrvcs.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18803 for ; Thu, 16 Jan 2003 13:16:48 -0500 (EST) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-im1.bizmailsrvcs.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030116182010.WVSK20946.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Thu, 16 Jan 2003 12:20:10 -0600 Received: from diacakist ([63.67.207.249]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with SMTP id <20030116182009.UVSL8904.oe-ismta1.bizmailsrvcs.net@diacakist>; Thu, 16 Jan 2003 12:20:09 -0600 Message-ID: <062b01c2bd8b$e70ae570$40071e0a@myopwv.com> From: "Thanos Diacakis" To: "Vijay K. Gurbani" Cc: References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E26C801.4020305@lucent.com> <007c01c2bd72$4c1fd070$6401a8c0@myopwv.com> <3E26D219.2020708@lucent.com> Subject: Re: [Simple] Extending for presence MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 11:16:21 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit What I'm trying to get to for the past few emails, is what you mean by a presentity being OPEN or CLOSED. Can you clarify this item in unambiguous terms? Thanks Thanos --- Thanos Diacakis Openwave Systems thanos.diacakis@openwave.com +1-303 385 6705 ----- Original Message ----- From: "Vijay K. Gurbani" To: "Thanos Diacakis" Cc: Sent: Thursday, January 16, 2003 8:39 AM Subject: Re: [Simple] Extending for presence > Thanos Diacakis wrote: > > I think you are proposing that the presentity status be defined as > > follows: > > > > If one or more devices are OPEN, then the presentity is OPEN, else if > > all devices are CLOSED, the presentity is CLOSED. > > > > If this is what you are saying, then it is redundant, as that information > > can easily be determine from looking at the tuples. Having it as a > > separate item, doesn't achieve anything. > > I think it does. If I want to unambiguously represent DND from a > presentity-centric view, then the status of the presentity is OPEN, but > that of all its devices is CLOSED. The presentity status of OPEN, > coupled with a qualifier like "In meeting with CEO" informs all watchers > about the presentity's state in no uncertain terms. > > Thus it is important that the presence state of the presentity be > represented in a tuple. Deducing it can lead to ambiguity. > > > Your definition of "Busy-interrupt" is a sensible one (though there could > > be others). The point here is that the activity variable > > ("busy-interrupt") and status (OPEN/CLOSED) variables, are orthogonal to > > eachother. However, the particular value for the activity > > (busy-interrupt), under your definition, would only apply though if the > > status variable has an OPEN value. > > Yes, exactly. > > Regards, > > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Wireless Networks Group/Internet Software and Services > Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 0216 > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 13:22:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19071 for ; Thu, 16 Jan 2003 13:22:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GIbD012301 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 13:37:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIbDJ12289 for ; Thu, 16 Jan 2003 13:37:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19017 for ; Thu, 16 Jan 2003 13:21:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIb8J12180; Thu, 16 Jan 2003 13:37:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GIWZJ11661 for ; Thu, 16 Jan 2003 13:32:35 -0500 Received: from oe-im1.bizmailsrvcs.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18807 for ; Thu, 16 Jan 2003 13:16:52 -0500 (EST) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-im1.bizmailsrvcs.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030116182013.WVSR20946.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Thu, 16 Jan 2003 12:20:13 -0600 Received: from diacakist ([63.67.207.249]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with SMTP id <20030116182013.UVSR8904.oe-ismta1.bizmailsrvcs.net@diacakist>; Thu, 16 Jan 2003 12:20:13 -0600 Message-ID: <062c01c2bd8b$e96688b0$40071e0a@myopwv.com> From: "Thanos Diacakis" To: "Jonathan Rosenberg" , "Paul Kyzivat" Cc: , , References: <2038BCC78B1AD641891A0D1AE133DBB7FE7128@esebe019.ntc.nokia.com> <3E2581EE.6000608@cisco.com> <3E269C3E.7080309@dynamicsoft.com> Subject: Re: [Simple] Extending for presence MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 11:19:27 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan, Wouldn't the tuple describing the activity ("in a meeting"), have to be different from the OPEN/CLOSED tuple (which I assume is associated with some device), and therefore have different timestamps? If OPEN/CLOSED is associated with the tuple, then we're back to the question of "What does that mean?"... Thanos --- Thanos Diacakis Openwave Systems thanos.diacakis@openwave.com +1-303 385 6705 ----- Original Message ----- From: "Jonathan Rosenberg" To: "Paul Kyzivat" Cc: ; ; Sent: Thursday, January 16, 2003 4:49 AM Subject: Re: [Simple] Extending for presence > inline. > > Paul Kyzivat wrote: > > Hisham, > > > > PIDF already provides similar information - it provides the > > element in each , giving the time the status last changed. > > > > The limitation is that this pertains to the tuple as a whole, not > > individual elements within the tuple. This is probably good enough for > > some purposes, but maybe not all. Going beyond this would require > > timestamping individual status values. Hopefully that isn't necessary. > > I think it may be. > > Lets say we have three status types - basic, "activity", which includes > out-to-lucnh, in-a-meeting and so on, and the caller prefs things. The > timestamp on the tuple indicates the last time anything changed. Lets > say I go into a meeting, and so I change my "activity" to "in a > meeting". Then, an hour into the meeting, things begin to get fierce, so > I change my basic status to CLOSED. Activity remains as "in a meeting". > WHen I change basic status to closed, the timestamp changes too. > > I think it would be very useful to know when I set JUST the activity > status to "in a meeting". Perhaps this need is specific to this activity > status, and less important for things like basic or the caller prefs > stuff. But I do see a need for multiple timestamps. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 14:26:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21547 for ; Thu, 16 Jan 2003 14:26:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GJfFD17434 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 14:41:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJfFJ17431 for ; Thu, 16 Jan 2003 14:41:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21543 for ; Thu, 16 Jan 2003 14:25:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJf9J17423; Thu, 16 Jan 2003 14:41:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJeBJ17387 for ; Thu, 16 Jan 2003 14:40:11 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21524 for ; Thu, 16 Jan 2003 14:24:26 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0GJRlI21955; Thu, 16 Jan 2003 14:27:47 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA21309; Thu, 16 Jan 2003 13:27:46 -0600 (CST) Message-ID: <3E27075D.3000708@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thanos Diacakis CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E26C801.4020305@lucent.com> <007c01c2bd72$4c1fd070$6401a8c0@myopwv.com> <3E26D219.2020708@lucent.com> <062b01c2bd8b$e70ae570$40071e0a@myopwv.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 13:26:21 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanos Diacakis wrote: > What I'm trying to get to for the past few emails, is what you mean by a > presentity being OPEN or CLOSED. Can you clarify this item in unambiguous > terms? Sure. As a basic premise I assume that detecting and imparting the presence of the presentity itself is sufficient in many cases. There isn't any need to establish communication, just knowing if a presentity is present is all that many users will care about. Now, if we were to model this, every presentity should have OPEN or CLOSED status, roughly corresponding to being online and offline, respectively. Extensions can specify the exact state of the presentity if it is OPEN (i.e. "Out to lunch", "In a meeting", ...) I agree that presence has to be grounded in something, so the need to establish a communication channel with the presentity comes next. This can be modeled by a heirarchy of tuples. Within the presentity tuple are other tuples representing devices. Now, if I as a user behind the presentity does not want to be disturbed, I simply check a radio button on the UI that has the effect of publishing my presence as "Presentity is OPEN (Do not disturb), but all interactive communication devices are CLOSED" (I write "interactive communication devices" because people should still be able to leave me voicemail or send me IMs that can be bufferred for later delivery). Thus no one can contact me in an interactive fashion, but watchers can still see that I am online; and if we have a location extension, watchers can deduce that I am online at my office (vs. at home). On the other hand, if I (again, as a user behind the presentity) get a SIP call and answer it with my SIP UA, the presence information can be published as "Presentity is OPEN (Busy but interruptible), some devices (SIP phone) are busy but others can accept communications". I am arguing that the state of the presentity should dictate the state of the *interactive* devices that the presentity commands, not the other way around. Note that I make a distinction between interactive devices since even if a presentity is CLOSED, people should still be able to leave a voice mail, for instance. This maps to two of the three rough classes of communication that Henning proposed earlier: > - available real-time > - available store-and-forward (message store of some sort, e.g., > voicemail or IMs that are stored somewhere for retrieval) I hope this makes sense. Cheers, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 14:36:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21815 for ; Thu, 16 Jan 2003 14:36:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GJqA317909 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 14:52:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJq9J17906 for ; Thu, 16 Jan 2003 14:52:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21812 for ; Thu, 16 Jan 2003 14:36:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJq6J17898; Thu, 16 Jan 2003 14:52:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJp8J17832 for ; Thu, 16 Jan 2003 14:51:08 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21796 for ; Thu, 16 Jan 2003 14:35:22 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0GJcaYH002065; Thu, 16 Jan 2003 14:38:37 -0500 (EST) Message-ID: <3E270A1F.1030101@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thanos Diacakis CC: "Vijay K. Gurbani" , Paul Kyzivat , Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E25D681.2050507@cisco.com> <3E2693D1.4030404@dynamicsoft.com> <3E26CE34.50503@lucent.com> <062a01c2bd8b$e3993e50$40071e0a@myopwv.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 14:38:07 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Thanos Diacakis wrote: > Vijay Gurbani wrote: > >>>While its not clear to me what a basic >>>status of OPEN for a presentity means when each of its child tuples (the >>>devices) are CLOSED, >> >>Easy to represent DND. > > > No! My "activity" (DND in this case) is orthogonal to the OPEN/CLOSED > status of my devices and we cannot represent the one using the other. We > need a separate variable/tuple/field to do so. I am with Thanos here, in that I am not understanding Vijay's definition of DND, or what his interpretation of OPEN/CLOSED for a presentity means. I REALLY don't understand what it means for a presentity to be online or offline. Last I checked, my fist doesn't have an ethernet connector that allows me to "log in". Devices are online or offline. People are not online/offline. I think, really, we simply have the case that some statuses make sense for tuples that model devices (caller prefs parameters, basic status), some statuses make sense for tuples that model presentities (the thing Henning called "what is the person doing right now"), and some make sense for both (geolocation). Now, an interesting question is - does a presentity need to be a person? I think we have an implicit assumption that the answer was yes. But, clearly, it does not. A presentity could, for example, represent a bot, in which case one might argue that online/offline for the bot does make sense. Bots, unlike people, do have ethernet connections :) -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 14:38:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21866 for ; Thu, 16 Jan 2003 14:38:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GJs5918025 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 14:54:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJs5J18022 for ; Thu, 16 Jan 2003 14:54:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21855 for ; Thu, 16 Jan 2003 14:38:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJs1J18009; Thu, 16 Jan 2003 14:54:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJrsJ17973 for ; Thu, 16 Jan 2003 14:53:54 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21850 for ; Thu, 16 Jan 2003 14:38:08 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0GJfUYH002068; Thu, 16 Jan 2003 14:41:31 -0500 (EST) Message-ID: <3E270ACD.7080601@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thanos Diacakis CC: Paul Kyzivat , hisham.khartabil@nokia.com, adam@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Extending for presence References: <2038BCC78B1AD641891A0D1AE133DBB7FE7128@esebe019.ntc.nokia.com> <3E2581EE.6000608@cisco.com> <3E269C3E.7080309@dynamicsoft.com> <062c01c2bd8b$e96688b0$40071e0a@myopwv.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 14:41:01 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Lets separate these things out here. Forget about OPEN/CLOSED. Lets assume I have a status for geolocation. That geoloc changes often, so there is an updated presence doc and an updated tuple timestamp. But, I've been in the meeting for some time. I'd like to convey how long. -Jonathan R. Thanos Diacakis wrote: > Jonathan, > > Wouldn't the tuple describing the activity ("in a meeting"), have to be > different from the OPEN/CLOSED tuple (which I assume is associated with some > device), and therefore have different timestamps? > > If OPEN/CLOSED is associated with the tuple, then we're back to the question > of "What does that mean?"... > > Thanos > --- > Thanos Diacakis > Openwave Systems > thanos.diacakis@openwave.com > +1-303 385 6705 > > ----- Original Message ----- > From: "Jonathan Rosenberg" > To: "Paul Kyzivat" > Cc: ; ; > Sent: Thursday, January 16, 2003 4:49 AM > Subject: Re: [Simple] Extending for presence > > > >>inline. >> >>Paul Kyzivat wrote: >> >>>Hisham, >>> >>>PIDF already provides similar information - it provides the >>>element in each , giving the time the status last changed. >>> >>>The limitation is that this pertains to the tuple as a whole, not >>>individual elements within the tuple. This is probably good enough for >>>some purposes, but maybe not all. Going beyond this would require >>>timestamping individual status values. Hopefully that isn't necessary. >> >>I think it may be. >> >>Lets say we have three status types - basic, "activity", which includes >>out-to-lucnh, in-a-meeting and so on, and the caller prefs things. The >>timestamp on the tuple indicates the last time anything changed. Lets >>say I go into a meeting, and so I change my "activity" to "in a >>meeting". Then, an hour into the meeting, things begin to get fierce, so >>I change my basic status to CLOSED. Activity remains as "in a meeting". >>WHen I change basic status to closed, the timestamp changes too. >> >>I think it would be very useful to know when I set JUST the activity >>status to "in a meeting". Perhaps this need is specific to this activity >>status, and less important for things like basic or the caller prefs >>stuff. But I do see a need for multiple timestamps. >> >>-Jonathan R. >> >>-- >>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >>Chief Scientist First Floor >>dynamicsoft East Hanover, NJ 07936 >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 14:57:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22293 for ; Thu, 16 Jan 2003 14:57:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GKCFJ19452 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 15:12:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GKCFJ19449 for ; Thu, 16 Jan 2003 15:12:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22272 for ; Thu, 16 Jan 2003 14:56:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GKCBJ19436; Thu, 16 Jan 2003 15:12:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GKBkJ19386 for ; Thu, 16 Jan 2003 15:11:46 -0500 Received: from oe-im1.bizmailsrvcs.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22251 for ; Thu, 16 Jan 2003 14:56:00 -0500 (EST) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-im1.bizmailsrvcs.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030116195921.XLOB20946.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Thu, 16 Jan 2003 13:59:21 -0600 Received: from diacakist ([63.67.207.249]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with SMTP id <20030116195921.VKME8904.oe-ismta1.bizmailsrvcs.net@diacakist>; Thu, 16 Jan 2003 13:59:21 -0600 Message-ID: <065a01c2bd99$c3588700$40071e0a@myopwv.com> From: "Thanos Diacakis" To: "Vijay K. Gurbani" Cc: References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E26C801.4020305@lucent.com> <007c01c2bd72$4c1fd070$6401a8c0@myopwv.com> <3E26D219.2020708@lucent.com> <062b01c2bd8b$e70ae570$40071e0a@myopwv.com> <3E27075D.3000708@lucent.com> Subject: Re: [Simple] Extending for presence MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 12:59:05 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay, I understand the overall concept that you're explaining (though not necessarily agree with all of it) but I still don't understand certain elements. See below: > Sure. As a basic premise I assume that detecting and imparting the > presence of the presentity itself is sufficient in many cases. There > isn't any need to establish communication, just knowing if a presentity > is present is all that many users will care about. What does a "presentity" being "present" mean? > Now, if we were to model this, every presentity should have OPEN or > CLOSED status, roughly corresponding to being online and offline, > respectively. Extensions can specify the exact state of the > presentity if it is OPEN (i.e. "Out to lunch", "In a meeting", ...) What does a presentity being "online" or "offline" mean? As Jonathan put it, people don't have Ethernet ports sticking out of anywhere.... Thanos --- Thanos Diacakis Openwave Systems thanos.diacakis@openwave.com +1-303 385 6705 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 15:22:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23002 for ; Thu, 16 Jan 2003 15:22:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GKc7W21499 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 15:38:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GKc7J21496 for ; Thu, 16 Jan 2003 15:38:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22990 for ; Thu, 16 Jan 2003 15:22:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GKc2J21485; Thu, 16 Jan 2003 15:38:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GKbAJ21035 for ; Thu, 16 Jan 2003 15:37:10 -0500 Received: from oe-im1.bizmailsrvcs.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22955 for ; Thu, 16 Jan 2003 15:21:23 -0500 (EST) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-im1.bizmailsrvcs.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030116202445.XPUC20946.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Thu, 16 Jan 2003 14:24:45 -0600 Received: from diacakist ([63.67.207.249]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.05.20 201-253-122-126-120-20021101) with SMTP id <20030116202441.VOLY8904.oe-ismta1.bizmailsrvcs.net@diacakist>; Thu, 16 Jan 2003 14:24:41 -0600 Message-ID: <06aa01c2bd9d$4db025e0$40071e0a@myopwv.com> From: "Thanos Diacakis" To: "Jonathan Rosenberg" Cc: "Paul Kyzivat" , , , References: <2038BCC78B1AD641891A0D1AE133DBB7FE7128@esebe019.ntc.nokia.com> <3E2581EE.6000608@cisco.com> <3E269C3E.7080309@dynamicsoft.com> <062c01c2bd8b$e96688b0$40071e0a@myopwv.com> <3E270ACD.7080601@dynamicsoft.com> Subject: Re: [Simple] Extending for presence MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 13:24:39 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There are quite a few ways that this could play out. Here's one: Assumptions: - I don't have any fancy electronics implanted so the geoloc comes from my cell phone. - We've defined a type of tuple to describe the presence, location, etc. information of cell-phones. - We've defined a type of tuple to describe the presentity Tuple 1: - Tuple type: cell-phone - Address: my cellphone # - Status: Open <- open/closed doesn't make sense for cell-phone, see next example. - Location: x,y,z Tuple 2: - Tuple type: presentity - Activity: in meeting If I want to extend this example, to make it more interesting I could do this: (Additional assumption that I've defined a tuple that describes the presence of a deskop PC.) Tuple 1: - Tuple type: cell-phone - Address: my cellphone # - Voice Status: on circuit switched data call - Call Waiting: available - SMS Status: accepting - Location: x,y,z - Incoming Voice: cannot take <- indicating DND status for the device/media type - Incoming SMS: will take Tuple 2: - Tuple type: desktop PC - Interaction status: Idle 3456 seconds - IM status: not accepting - Email address: my@email.address - Email status: accepting Tuple 3: - Tuple type: presentity - Activity: in meeting - Mood: bored out of my head - Body Temp: 36.6C I think this covers Henning's dimensions. I'm not sure about the store-and-forward. What does it really mean? It means that the user is not there to read the message immediately. Then it is redundant, as I could determine that from the status of the device, i.e. is the user currently using the device. That is closed is "not available", open is "available", and open and idle, is "store-and-forward". Thanos --- Thanos Diacakis Openwave Systems thanos.diacakis@openwave.com +1-303 385 6705 ----- Original Message ----- From: "Jonathan Rosenberg" To: "Thanos Diacakis" Cc: "Paul Kyzivat" ; ; ; Sent: Thursday, January 16, 2003 12:41 PM Subject: Re: [Simple] Extending for presence > Lets separate these things out here. Forget about OPEN/CLOSED. Lets > assume I have a status for geolocation. That geoloc changes often, so > there is an updated presence doc and an updated tuple timestamp. But, > I've been in the meeting for some time. I'd like to convey how long. > > -Jonathan R. > > Thanos Diacakis wrote: > > Jonathan, > > > > Wouldn't the tuple describing the activity ("in a meeting"), have to be > > different from the OPEN/CLOSED tuple (which I assume is associated with some > > device), and therefore have different timestamps? > > > > If OPEN/CLOSED is associated with the tuple, then we're back to the question > > of "What does that mean?"... > > > > Thanos > > --- > > Thanos Diacakis > > Openwave Systems > > thanos.diacakis@openwave.com > > +1-303 385 6705 > > > > ----- Original Message ----- > > From: "Jonathan Rosenberg" > > To: "Paul Kyzivat" > > Cc: ; ; > > Sent: Thursday, January 16, 2003 4:49 AM > > Subject: Re: [Simple] Extending for presence > > > > > > > >>inline. > >> > >>Paul Kyzivat wrote: > >> > >>>Hisham, > >>> > >>>PIDF already provides similar information - it provides the > >>>element in each , giving the time the status last changed. > >>> > >>>The limitation is that this pertains to the tuple as a whole, not > >>>individual elements within the tuple. This is probably good enough for > >>>some purposes, but maybe not all. Going beyond this would require > >>>timestamping individual status values. Hopefully that isn't necessary. > >> > >>I think it may be. > >> > >>Lets say we have three status types - basic, "activity", which includes > >>out-to-lucnh, in-a-meeting and so on, and the caller prefs things. The > >>timestamp on the tuple indicates the last time anything changed. Lets > >>say I go into a meeting, and so I change my "activity" to "in a > >>meeting". Then, an hour into the meeting, things begin to get fierce, so > >>I change my basic status to CLOSED. Activity remains as "in a meeting". > >>WHen I change basic status to closed, the timestamp changes too. > >> > >>I think it would be very useful to know when I set JUST the activity > >>status to "in a meeting". Perhaps this need is specific to this activity > >>status, and less important for things like basic or the caller prefs > >>stuff. But I do see a need for multiple timestamps. > >> > >>-Jonathan R. > >> > >>-- > >>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > >>Chief Scientist First Floor > >>dynamicsoft East Hanover, NJ 07936 > >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 > >>http://www.jdrosen.net PHONE: (973) 952-5000 > >>http://www.dynamicsoft.com > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 15:39:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23313 for ; Thu, 16 Jan 2003 15:39:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GKt7B22307 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 15:55:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GKt7J22304 for ; Thu, 16 Jan 2003 15:55:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23297 for ; Thu, 16 Jan 2003 15:39:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GKt2J22296; Thu, 16 Jan 2003 15:55:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GKt0J22276 for ; Thu, 16 Jan 2003 15:55:00 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23292 for ; Thu, 16 Jan 2003 15:39:12 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0GKgq2a017665; Thu, 16 Jan 2003 15:42:52 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY03210; Thu, 16 Jan 2003 15:47:08 -0500 (EST) Message-ID: <3E27191E.70005@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Jonathan Rosenberg , simple@ietf.org, Henning Schulzrinne Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <3E26953D.9000508@dynamicsoft.com> <3E26CD6E.1070905@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 15:42:06 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Damn! I go away from my email for half a day and I'm vastly behind on this one thread! :-) I'm trying to read and catch up before replying, but I just have to reply to this, and Vijay's earlier discussion on status of the presentity independent of a device. Vijay K. Gurbani wrote: > Jonathan Rosenberg wrote: > >> Vijay K. Gurbani wrote: >> >>> If we do NOT infer the state of the presentity from its devices, "Do >>> not Disturb" is easily enforcable. The state of the presentity itself >>> is OPEN, but that of all of its devices is CLOSED. I think that if >>> we provide a "Do Not Disturb", it should be enforced. Otherwise, as >>> has been pointed out before, others will learn to distrust ones presence >>> status. >> >> >> >> I disagree. >> >> We are just talking about presence. The decision to reject a call (or >> an IM) when someone is "do not disturb" in their presence, is an >> APPLICATION of presence. Indeed, it may be a multiplicity of >> applications - something that blocks IM, as part of a messaging app, >> something that forwards calls to voicemail, as a voice app, and so on. > > > Then DND is a misnomer. DND implies to me that I as a presentity do not > want to be disturbed -- akin to closing my office door and putting a > "Go Away" sign on it during office hours. If what we want to represent > is that voice calls are blocked but IM can get through, then we should > use some other status value, like "Busy Interrupt". I assert that DND is everyday life is always device dependent. If you close your door and hand a Go Away sign on it, you are expressing a desire. There is no enforcement. Indeed you don't want absolute enforcement. If the building catches on fire, you don't want the fireman that comes in to pass you by. Also, the sign on your door really only applies to one device (the door). It doesn't affect your phone or your pager, or the IM on your PC. > > The problem with leaving interpretation to application is that each > app may choose to inerpret it in a different manner, leading to all > kinds of user expectation problems. If I am used to presence app A's > behavior of DND, I will be rather upset when I use presence app B and > it's behavior differs from A's. You want that interpretation. The fireman, your subordinates, your assistant, and the CEO of your company probably interpret it different ways, and you want them to. In an earlier note, you said you want to associate a status like "Away" to the presentity as a whole, independent of any device. But that requires you to define what the presentity is away from. Human being are always *somewhere*, so they are never abstractly away. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 16:08:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23982 for ; Thu, 16 Jan 2003 16:08:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GLNQP24344 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 16:23:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GLNQJ24340 for ; Thu, 16 Jan 2003 16:23:26 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23974 for ; Thu, 16 Jan 2003 16:07:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GLNNJ24329; Thu, 16 Jan 2003 16:23:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GLMvJ24281 for ; Thu, 16 Jan 2003 16:22:57 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23969 for ; Thu, 16 Jan 2003 16:07:10 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0GLB5nT022469; Thu, 16 Jan 2003 16:11:05 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY03482; Thu, 16 Jan 2003 16:15:21 -0500 (EST) Message-ID: <3E271FBB.7000505@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: vkg@lucent.com, jdrosen@dynamicsoft.com, hgs@cs.columbia.edu, simple@ietf.org Subject: Re: [Simple] Extending for presence References: <2038BCC78B1AD641891A0D1AE133DBB7FE7133@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 16:10:19 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hisham, I'm not sure who you were addressing, but I will assume it was me. I didn't originally factor active/inactive into my view, but have been convinced that it is distinct and relevant. Most of the popular IM systems have this in one form or another. It is typically used to deal with the case where you are online and present for IM, but then wander away from your system without doing anything to change your presence. In this case, the IM client on your system notices that you seem inactive - often by monitoring your use of the mouse or keyboard - and changes your presence status. It may then also change its own behavior - perhaps sending an automatic reply to incoming messages. In general this is tied to a device. If you do IM on your pc but get phone calls on your cell phone, then the fact that you became inactive on your pc doesn't imply anything about your status relative to your cell phone. Paul hisham.khartabil@nokia.com wrote: > If a tuple is representing a device, the OPEN and CLOSED means that the device is available for communication (to the extent that I could tell if the device is turned on or it is off). The list of elements that follow tells you which communication means are available and which are not: > > Using draft-lonnfors-simple-prescaps-ext-00.txt. It is: > > > OPEN > voice not allowed except high > priority > > > false > > > true > > > true > > > > > Active/Inactive could mean that even though my device is open, I, as a presentity, am inactive on that device. Where did those active/inactive come from? What was the original need for them? > > Regards, > Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 16:31:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24486 for ; Thu, 16 Jan 2003 16:31:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GLlEB25969 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 16:47:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GLlEJ25966 for ; Thu, 16 Jan 2003 16:47:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24466 for ; Thu, 16 Jan 2003 16:31:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GLl5J25951; Thu, 16 Jan 2003 16:47:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GLkUJ25921 for ; Thu, 16 Jan 2003 16:46:30 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24443 for ; Thu, 16 Jan 2003 16:30:41 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0GLYbMB025891; Thu, 16 Jan 2003 16:34:37 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY03698; Thu, 16 Jan 2003 16:38:53 -0500 (EST) Message-ID: <3E27253F.5060802@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Thanos Diacakis , "Vijay K. Gurbani" , Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E25D681.2050507@cisco.com> <3E2693D1.4030404@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 16:33:51 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > A few words are perhaps in order here on rfc2778. It is my recollection > as it was developed that the idea was that rfc2778 could serve as a > MODEL for presence systems. That is, it was sufficiently general that > existing systems could be mapped to it. Thus, the concept of a "tuple" > is just a way of modeling various things. > > So, the issue we are running into here is that there are many things > which a tuple could potentially represent. So far, we have talked about > a tuple representing: > > * a device > * one of many logical targets of communications on a device > * a presentity > > One can imagine a tuple representing other things, like a group of > presentities, for example (sip:customer-support@example.com). I also looked at 2778 to clarify my thinking. A presentity need not represent a person. A single presentity could represent a group. So I would be inclined to say that an address like sip:customer-support@example.com (or pres:customer-support@example.com) should be viewed that way. Such a presentity may have many devices, and each may have independent status - some OPEN, some CLOSED, some AWAY, some DND. Alternately, it would be possible to represent the same group presentity with a single virtual device, and a single set of status values representing the aggregate status of the group. In this case, the contact address of the device might be an Address of Record serviced by a forking proxy, that will route calls, messages, etc. to one of the members of the group. Either approach is valid - two different ways to employ presence. But neither of these has a tuple representing multiple presentities. Tuples by definition all pertain to (parts of) a single presentity. I see no reason to change that. > > So, the questions are: (1) do we need to standardize what these tuples > represent, Not entirely. But it is only standardized representations that are likely to be useful when interoperating between different IM systems. A given IM system, when examining presence status for a buddy, is at best going to look through the tuples, pick out what it understands, and ignore the rest. One level of standardization will be the element. If a contact is present and the system doesn't understand how to use the address, then it will probably ignore the tuple. If it does understand the address, it will look at the other status elements of the tuple to figure out what options to provide its user for interacting with the buddy. Tuples that don't identify a device are more problematic. Do the status values contained merely require display? Do they affect options made available to the user? Do they in some way affect the other tuples? > and (2) do we need to standardize the relationships between > them. On (1), I think perhaps no, but on (2), I think maybe yes. Perhaps > what we need is the ability to represent things in a hierarchy. So, you > could have a tuple, and within it, some more tuples, and within those, > more tuples. The meaning of the hierarchy may only be important to a > user, and thus represented by notes. For example, the top level tuple > might represent a presentity, and it may have its own basic status, > which just indicates whether the presentity is willing to be contacted. > If none is provided, it might be "derived" from the basic status > elements of its child tuples. While its not clear to me what a basic > status of OPEN for a presentity means when each of its child tuples (the > devices) are CLOSED, there are most definitely attributes, such as "out > to lunch" which make more sense for a tuple that represents a > presentity, than for a tuple that represents a device. I'm not sure if you are suggesting an extension that literally permits tuples to be nested within tuples, or some sort of tagging and referencing notation that defines graphs between the tuples. I guess either is technically possible within the scope of the existing PIDF definition. But either way this adds considerable complexity to the model. I am very reluctant to do this without stronger evidence that it is needed. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 16:42:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24720 for ; Thu, 16 Jan 2003 16:42:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GLw9J26381 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 16:58:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GLw9J26378 for ; Thu, 16 Jan 2003 16:58:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24664 for ; Thu, 16 Jan 2003 16:42:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GLw4J26355; Thu, 16 Jan 2003 16:58:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GLvZJ26318 for ; Thu, 16 Jan 2003 16:57:35 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24649 for ; Thu, 16 Jan 2003 16:41:46 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0GLjgip027596; Thu, 16 Jan 2003 16:45:42 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY03784; Thu, 16 Jan 2003 16:49:59 -0500 (EST) Message-ID: <3E2727D9.8090107@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Vijay K. Gurbani" , Henning Schulzrinne , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E22FEA1.4010802@lucent.com> <3E2317F8.3000805@cisco.com> <3E253B8F.5060304@dynamicsoft.com> <3E258E4E.8090908@cisco.com> <3E26979D.7000002@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 16:44:57 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > >>> To me, this suggests that my device is modeled as two separate >>> tuples. One for voice, with a status of CLOSED, and one with IM, with >>> a status of open. This would, perhaps, need some way to allow the >>> watcher to correlate these two so as to know that they represent the >>> same physical device. Indeed, one might envision "device" as another >>> status itself! So: >>> >>> >>> OPEN >>> Cell Phone >>> IM allowed >>> >>> >>> >>> CLOSED >>> Cell Phone >>> voice not allowed except high priority >>> >>> >>> Device could be an enumerated type, or perhaps even just a textual >>> string. ... >> >> Is there any value to beyond ? If I can compare two >> devices for equality I can just as easily compare two contact >> addresses for equality. > > Sure, there is a difference. The Contact may very well be different. For > example, the "IM" piece of my phone could perhaps be addressed as > sip:im-app@1.2.3.4, and the "voice" piece as sip:voice-app@1.2.3.4. > These might represent different resources on the same device. Well, for one thing it seems stupid to put both capabilities in the same device, but give them separate addresses - thereby preventing them from being used together in a single call. But just because it is stupid doesn't mean it won't be done... But in this case is there any value in describing it as one device with two addresses, rather than simply as two devices each with an address? I don't think so. >> It seems to me a lot easier to understand if each tuple with a contact >> represents a distinct communication target, so I can decide whether it >> is useful to me independently of all the others. > > See my previous note on this; I think our trouble is that we are unsure > of what a tuple really is modelling. I don't disagree. I think we can start by at least agreeing on what we mean by tuples that contain a contact address. >> Otherwise, things get messy if I potentially want to use multiple >> media. Then I have to look for all tuples representing the same device >> and combine their statuses before deciding if the device is suitable >> for my needs. And then I must still deal with the potential for >> conflicting status values between those tuples. It isn't an unsolvable >> problem, but is it better than simply permitting availablility >> information for each medium? The callerprefs stuff can already do that. > > The issue is whether or not I want to provide multiple status values for > each medium. You are basically saying that, if all I want is to indicate > OPEN/CLOSED, I can equally do that with the callreprefs stuff by > indicating false for video or audio, as the case may be. What about > other statuses we come up with? Perhaps there are no examples, and so > this point is moot. Not clear to me yet. I am slightly troubled by what if any difference there is between a device that is closed and one that is open but that has indicated no media are available. I am somewhat comforted by 2778, which says that these status values may be implicit. (It gives the example of inferring OPEN or CLOSED by the presence or absence of a COMMUNICATION ADDRESS.) Beyond that I am not sure what you are getting at here. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 16:47:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24926 for ; Thu, 16 Jan 2003 16:47:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GM34e27110 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 17:03:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GM34J27107 for ; Thu, 16 Jan 2003 17:03:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24913 for ; Thu, 16 Jan 2003 16:47:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GM31J27099; Thu, 16 Jan 2003 17:03:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GM2DJ27066 for ; Thu, 16 Jan 2003 17:02:13 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24898 for ; Thu, 16 Jan 2003 16:46:24 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0GLoPQH028251; Thu, 16 Jan 2003 16:50:25 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY03819; Thu, 16 Jan 2003 16:54:41 -0500 (EST) Message-ID: <3E2728F3.5070502@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: hisham.khartabil@nokia.com, adam@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Extending for presence References: <2038BCC78B1AD641891A0D1AE133DBB7FE7128@esebe019.ntc.nokia.com> <3E2581EE.6000608@cisco.com> <3E269C3E.7080309@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 16:49:39 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > >> PIDF already provides similar information - it provides the >> element in each , giving the time the status last >> changed. >> >> The limitation is that this pertains to the tuple as a whole, not >> individual elements within the tuple. This is probably good enough for >> some purposes, but maybe not all. Going beyond this would require >> timestamping individual status values. Hopefully that isn't necessary. > > I think it may be. > > Lets say we have three status types - basic, "activity", which includes > out-to-lucnh, in-a-meeting and so on, and the caller prefs things. The > timestamp on the tuple indicates the last time anything changed. Lets > say I go into a meeting, and so I change my "activity" to "in a > meeting". Then, an hour into the meeting, things begin to get fierce, so > I change my basic status to CLOSED. Activity remains as "in a meeting". > WHen I change basic status to closed, the timestamp changes too. > > I think it would be very useful to know when I set JUST the activity > status to "in a meeting". Perhaps this need is specific to this activity > status, and less important for things like basic or the caller prefs > stuff. But I do see a need for multiple timestamps. I remain open minded about this. Maybe, as you suggest, *some* status values will require timestamps. Right now it certainly seems like overkill to put a timestamp on every status value. It may also turn out that the cases that matter can be represented as multiple tuples. For instance the basic activity things like "out to lunch" can perhaps live in a separate tuple from device specific stuff. If so, a tuple timestamp may be enough. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 17:32:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25592 for ; Thu, 16 Jan 2003 17:32:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GMm9E29939 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 17:48:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GMm9J29936 for ; Thu, 16 Jan 2003 17:48:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25589 for ; Thu, 16 Jan 2003 17:32:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GMm4J29928; Thu, 16 Jan 2003 17:48:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GMlbJ29881 for ; Thu, 16 Jan 2003 17:47:38 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25583 for ; Thu, 16 Jan 2003 17:31:47 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0GMZ8k06670; Thu, 16 Jan 2003 17:35:09 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA08991; Thu, 16 Jan 2003 16:35:07 -0600 (CST) Message-ID: <3E273346.300@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thanos Diacakis , Jonathan Rosenberg CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E26C801.4020305@lucent.com> <007c01c2bd72$4c1fd070$6401a8c0@myopwv.com> <3E26D219.2020708@lucent.com> <062b01c2bd8b$e70ae570$40071e0a@myopwv.com> <3E27075D.3000708@lucent.com> <065a01c2bd99$c3588700$40071e0a@myopwv.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 16:33:42 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanos Diacakis wrote: > What does a presentity being "online" or "offline" mean? Jonathan Rosenberg wrote: > I REALLY don't understand what it means for a presentity to be online > or offline. Okay, so let's tackle this first. Bear in mind the current presence model espoused by Yahoo! Messenger and MSN Messenger. In it, *I* am the presentity. My presence status is offline if I am not available (i.e. I have not logged into Yahoo or MSN Messenger), or it is online (and further qualified) if I am available. This is the model that I find powerful and easy to use. The main actor is the presentity itself (i.e. me); not the PC, or the IM client or any other device. In the current generation of presence systems, the status of the presentity (i.e. the person) can be easily deduced because they simply command only one device -- the PC. Cell phones, PDAs, etc. are distinct communication devices which are currently NOT tied into the presence infrastructure. Thus directives like DND do not work because the cell phone does not know my availability. I believe that in simple WG things are more complex since many more devices besides a PC will contribute to presence (and availability). When the presentity wants to assert its availability (i.e. DND, Busy but interruptible, Available) it should be able to do so by forcing all the devices to comply accordingly -- perhaps by simply uploading a CPL script to a proxy, or actively sending messages to to individual devices telling the phone to redirect calls to the voice mail server and telling the IM UA to save IMs for later delivery. Maybe this is too complex to achieve in real life, but that was my vision of a presentity-centric model. > As Jonathan put it, people don't have Ethernet ports sticking out of > anywhere.... We can easily fix that through chip implants :-) Cheers, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 17:35:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25746 for ; Thu, 16 Jan 2003 17:35:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GMp6430131 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 17:51:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GMp6J30128 for ; Thu, 16 Jan 2003 17:51:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25728 for ; Thu, 16 Jan 2003 17:35:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GMp2J30119; Thu, 16 Jan 2003 17:51:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GMogJ30084 for ; Thu, 16 Jan 2003 17:50:42 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25718 for ; Thu, 16 Jan 2003 17:34:52 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0GMcEk07810; Thu, 16 Jan 2003 17:38:14 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA10088; Thu, 16 Jan 2003 16:38:13 -0600 (CST) Message-ID: <3E273400.1060107@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <2038BCC78B1AD641891A0D1AE133DBB7FE7128@esebe019.ntc.nokia.com> <3E2581EE.6000608@cisco.com> <3E269C3E.7080309@dynamicsoft.com> <3E2728F3.5070502@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 16:36:48 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > It may also turn out that the cases that matter can be represented as > multiple tuples. For instance the basic activity things like "out to > lunch" can perhaps live in a separate tuple from device specific stuff. I think that will be a good start, because qualifiers like out to lunch don't qualify a device, they do however, qualify the person (I will stop using the word 'presentity' in this context since it can represent a bot. My usage of it thus far has been meant to represent a user). - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 17:45:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25853 for ; Thu, 16 Jan 2003 17:45:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GN18E30539 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 18:01:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GN17J30536 for ; Thu, 16 Jan 2003 18:01:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25847 for ; Thu, 16 Jan 2003 17:45:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GN14J30525; Thu, 16 Jan 2003 18:01:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GN0hJ30472 for ; Thu, 16 Jan 2003 18:00:43 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25840 for ; Thu, 16 Jan 2003 17:44:52 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0GMmEk11936; Thu, 16 Jan 2003 17:48:14 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA13356; Thu, 16 Jan 2003 16:48:13 -0600 (CST) Message-ID: <3E273658.60504@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , Thanos Diacakis , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E25D681.2050507@cisco.com> <3E2693D1.4030404@dynamicsoft.com> <3E27253F.5060802@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 16:46:48 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Tuples that don't identify a device are more problematic. Do the status > values contained merely require display? Do they affect options made > available to the user? Do they in some way affect the other tuples? This is what I have been getting at -- a tuple that represents a person. The status values contained certainly need to be displayed, and they should affect other tuples. How they effect them is the question. If I want to represent my status as DND, I would like to tell all my devices to stop accepting calls/IMs/smoke signals, etc. Not sure if we can do this in a standardized manner today. > But either way this adds considerable complexity to the model. I am very > reluctant to do this without stronger evidence that it is needed. The only evidence we have right now is how comfortable is the average user (not us in IETF) to systems like Yahoo Messenger and AOL. The model in these systems revolves around the person, not the devices. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 18:15:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26347 for ; Thu, 16 Jan 2003 18:15:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GNVB032419 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 18:31:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GNVBJ32416 for ; Thu, 16 Jan 2003 18:31:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26338 for ; Thu, 16 Jan 2003 18:15:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GNV7J32408; Thu, 16 Jan 2003 18:31:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GNUNJ32351 for ; Thu, 16 Jan 2003 18:30:23 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26313 for ; Thu, 16 Jan 2003 18:14:33 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0GNIOIN008810; Thu, 16 Jan 2003 18:18:24 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY04488; Thu, 16 Jan 2003 18:22:40 -0500 (EST) Message-ID: <3E273D92.2060300@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <3E26953D.9000508@dynamicsoft.com> <3E26BB52.4020303@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 18:17:38 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Stepping back a bit, maybe we should ask what kind of questions presence > about a person can answer. > > (1) Is the person available for communications and, if so, on what media? > > Here, in general, we only care about the media that are available, not > all the media that the user doesn't have right now, since that list is > unbounded once you add applications ("No, I'm not available for Doom, > Chess, SimCity, ..."). We might conceivably care about how long a media > might still be available ("leaving in 15 minutes, better call quickly") > or when it might be available again ("meeting ends in 20 minutes"). I generally agree with this, though representing all of this information, and making clients that can encode, decode, and utilize it in a productive way may be quite an agressive goal. However I think this category is about the device, not the person. The availability of the person is something separate. (more below) It is definitely necessary to represent media that are not available now but that might be available later to get any value out of a status like "Out to Lunch". I wrote about this earlier. (What value is there in knowing you will be back from lunch soon if I don't know if you are ever capable of communicating in the way I require?) > > (2) What is the person doing right now? > > We might want to know not just the start time (how long already), but > also how long until anticipated completion. I guess "Out to Lunch" falls into this category. It doesn't necessarily imply unavailability to communicate either. (You may be able to call me at my cell phone while I am at lunch if you don't mind listening to me chew.) > > Note that many calendar systems (such as RFC 2445 or Yahoo calendar) > allow for categories of activities. Some are free-text (but often > definable as a list for a particular software), others are pre-defined. Going that far scares me. Pretty much a guarantee that we will never complete this task. > > (3) How is the person feeling right now (calm and relaxed, stressed, > hopping mad) - very useful to know for the calling party and easily > derived from a real-time blood-pressure input. (:-), if that's needed.) Does Do Not Disturb fit in here? I think so. > > Obviously, there could be many other pieces of information that might be > useful to others, such as location, level of distraction ("watching > TV"), etc., but I suspect we all agree that those are beyond the current > discussion. Another one that seems to be important is Active/Inactive - derived from observation of behavior rather than explicitly set. So you can send me a message but I may not respond, or you can call me but I might not answer. > > Note that you can easily get to the point where you are effectively > sending an iCal (or xCal draft-ietf-calsch-many-xcal-02.txt) entry > describing the activity. This may be a better, more general solution. Henning Schulzrinne later wrote: > Another dimension: availability for communication can probably be > classified into three rough classes: > > - available real-time > - available store-and-forward (message store of some sort, e.g., > voicemail or IMs that are stored somewhere for retrieval) > - not availabl I'm not sure this is another dimension, or bits and pieces of other dimensions. Nor am I sure whether you intend this to describe the device or the person. I think there may be value in describing the person (if any) as available/unavailable. This is something like active/inactive but is an explicit assertion rather than inferred. (All combinations of the two are possible.) But available-store-and-forward seems different. This can be represented many different ways. One way is with a separate tuple representing a recorder or voicemail system. This might be a common way to handle it for voicemail. It may also be an appropriate solution for IM in some cases, such as when you are on vacation, or your normal IM device is offline for some other reason. But it may not cover the case where your IM device is online but you are away. In this case the device may simply accept IM on your behalf - in effect it is acting as the independent recording device would, but isn't a separate device. I don't yet see how to describe this. It is a device that both is and isn't an automaton. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 18:27:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26443 for ; Thu, 16 Jan 2003 18:27:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GNh6F00977 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 18:43:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GNh6J00974 for ; Thu, 16 Jan 2003 18:43:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26432 for ; Thu, 16 Jan 2003 18:27:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GNh3J00966; Thu, 16 Jan 2003 18:43:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GNglJ00941 for ; Thu, 16 Jan 2003 18:42:47 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26429 for ; Thu, 16 Jan 2003 18:26:57 -0500 (EST) Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h0GNUHK04423 for ; Thu, 16 Jan 2003 17:30:17 -0600 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Message-Id: <1042759750.912.49.camel@RjS.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Simple] Floor management request for the "Extending " thread Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 16 Jan 2003 17:29:09 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm glad to see we've got good discussion going on one of the important problems we're facing. In fact, we've got enough discussion going that it is in danger of becoming overwhelming. I'm starting to see redundant posts because the thread has split into multiple parallel conversations and those conversations are starting to converge. For the next couple of days, instead of replying to each leaf, please take the time to digest the leaves and build one or two response messages. If you see a leaf that cries for an immediate surgical response, please trim your response carefully so that we preserve a high information/noise ratio. Thanks! RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 18:34:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26554 for ; Thu, 16 Jan 2003 18:34:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GNo9n01188 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 18:50:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GNo9J01185 for ; Thu, 16 Jan 2003 18:50:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26540 for ; Thu, 16 Jan 2003 18:34:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GNo6J01170; Thu, 16 Jan 2003 18:50:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GNn4J01135 for ; Thu, 16 Jan 2003 18:49:04 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26513 for ; Thu, 16 Jan 2003 18:33:15 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0GNbADT010411; Thu, 16 Jan 2003 18:37:10 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY04585; Thu, 16 Jan 2003 18:41:26 -0500 (EST) Message-ID: <3E2741F8.70405@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Jonathan Rosenberg , Thanos Diacakis , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E25D681.2050507@cisco.com> <3E2693D1.4030404@dynamicsoft.com> <3E27253F.5060802@cisco.com> <3E273658.60504@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 18:36:24 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > Paul Kyzivat wrote: > >> Tuples that don't identify a device are more problematic. Do the >> status values contained merely require display? Do they affect options >> made available to the user? Do they in some way affect the other tuples? > > This is what I have been getting at -- a tuple that represents a > person. The status values contained certainly need to be displayed, > and they should affect other tuples. How they effect them is > the question. If I want to represent my status as DND, I would > like to tell all my devices to stop accepting calls/IMs/smoke > signals, etc. Not sure if we can do this in a standardized manner > today. You are leaping to an unjustified conclusion. Just because a tuple doesn't identify a device, that doesn't mean its status applies to the presentity as a whole. It might be a tuple that doesn't identify the device because its status is CLOSED and the device address is irrelevant. It is even more of a leap to assume that a tuple without a device should affect tuples that do have devices. We *might* find we need a way to define hierarchical tuples (as Jonathan suggested). If so, then the status in a parent tuple may affect, supplement, or supercede the status of a child tuple. We have yet to conclude that is a good thing. You are the only one strongly advocating it, and I don't think you have yet convinced anyone else. > >> But either way this adds considerable complexity to the model. I am >> very reluctant to do this without stronger evidence that it is needed. > > > The only evidence we have right now is how comfortable is the average > user (not us in IETF) to systems like Yahoo Messenger and AOL. The > model in these systems revolves around the person, not the devices. The reason it isn't complex in any of those systems is because the presentity and the only device are unified. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 18:44:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26749 for ; Thu, 16 Jan 2003 18:44:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0H007501615 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 19:00:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H007J01612 for ; Thu, 16 Jan 2003 19:00:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26740 for ; Thu, 16 Jan 2003 18:44:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H003J01595; Thu, 16 Jan 2003 19:00:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GNxDJ01545 for ; Thu, 16 Jan 2003 18:59:13 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26719 for ; Thu, 16 Jan 2003 18:43:24 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0GNlNWh011322; Thu, 16 Jan 2003 18:47:24 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY04645; Thu, 16 Jan 2003 18:51:40 -0500 (EST) Message-ID: <3E27445E.1040902@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Thanos Diacakis , Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E26C801.4020305@lucent.com> <007c01c2bd72$4c1fd070$6401a8c0@myopwv.com> <3E26D219.2020708@lucent.com> <062b01c2bd8b$e70ae570$40071e0a@myopwv.com> <3E27075D.3000708@lucent.com> <065a01c2bd99$c3588700$40071e0a@myopwv.com> <3E273346.300@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 18:46:38 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > Thanos Diacakis wrote: > >> What does a presentity being "online" or "offline" mean? > > > Jonathan Rosenberg wrote: > >> I REALLY don't understand what it means for a presentity to be online >> or offline. > > > Okay, so let's tackle this first. Bear in mind the current presence > model espoused by Yahoo! Messenger and MSN Messenger. In it, *I* am > the presentity. My presence status is offline if I am not available > (i.e. I have not logged into Yahoo or MSN Messenger), or it is online > (and further qualified) if I am available. This is the model that I > find powerful and easy to use. The main actor is the presentity itself > (i.e. me); not the PC, or the IM client or any other device. No. The main actor is indeed also the IM client, since the applications are one and the same. > > In the current generation of presence systems, the status of the > presentity (i.e. the person) can be easily deduced because they > simply command only one device -- the PC. Cell phones, PDAs, etc. > are distinct communication devices which are currently NOT tied into > the presence infrastructure. Thus directives like DND do not work > because the cell phone does not know my availability. So far you haven't answered the first question that you said you wanted to answer. > > I believe that in simple WG things are more complex since many more > devices besides a PC will contribute to presence (and availability). > When the presentity wants to assert its availability (i.e. DND, Busy but > interruptible, Available) it should be able to do so by forcing all the > devices to comply accordingly -- perhaps by simply uploading a CPL > script to a proxy, or actively sending messages to to individual devices > telling the phone to redirect calls to the voice mail server and telling > the IM UA to save IMs for later delivery. Maybe this is too complex to > achieve in real life, but that was my vision of a presentity-centric > model. I think you are saying the presentity is online when it is connected to a presence controller. This is irrelevant to any presence client - they are not affected in any way by this - only by the presence status changes. Or maybe you are suggesting that the presentity is online with a device that can control the behavior (not just the status) of all the devices described in the presence of the presentity. As you say, the likelihood of this is slim, but if it were true then the status of the presentity itself wouldn't be necessary because it could explicitly control the presence status of all the devices. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 16 19:23:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27397 for ; Thu, 16 Jan 2003 19:23:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0H0d9A04334 for simple-archive@odin.ietf.org; Thu, 16 Jan 2003 19:39:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H0d9J04331 for ; Thu, 16 Jan 2003 19:39:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27385 for ; Thu, 16 Jan 2003 19:23:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H0d5J04310; Thu, 16 Jan 2003 19:39:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H0cDJ04280 for ; Thu, 16 Jan 2003 19:38:13 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27365 for ; Thu, 16 Jan 2003 19:22:22 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0H0PgYH002438; Thu, 16 Jan 2003 19:25:43 -0500 (EST) Message-ID: <3E274D76.3080604@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= CC: simple@ietf.org, Harald Alvestrand , Allison Mankin Subject: Re: [Simple] Fwd: Evaluation: draft-ietf-simple-winfo-package - A Session Initiation Protocol (SIP)Event Template-Package for Watcher Information to Proposed Standard References: <8AA01134-23F4-11D7-871D-0003934B2128@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 19:25:26 -0500 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sorry for taking so long to respond. They are not obvious issues in fact, so I wanted to ponder them a bit and respond after thinking about it. Anyway, Harald, thanks for the comments, I am glad to have them. Responses inline: Patrik Fältström wrote: >> The simple-presence document says: >> >>> 5 Usage of Presence URIs >>> >>> A presentity is identified in the most general way through a presence >>> URI [3], which is of the form pres:user@domain. These URIs are >>> protocol independent. They are resolved to protocol specific URIs, >>> such as a SIP or SIPS URI, through domain-specific mapping policies. >>> >>> If a subscriber is only aware of the protocol-independent pres URI >>> for a presentity, it follows the procedures defined in [5]. These >>> procedures will result in the placement of the pres URI in the >>> Request-URI of the SIP request, followed by the usage of the DNS >>> procedures defined in [5] to determine the host to send the SIP >>> request to. Of course, a local outbound proxy may alternatively be >>> used, as specified in RFC 3261 [1]. If the subscriber is aware of >>> both the protocol-independent pres URI and the SIP or SIPS URI for >>> the same presentity, it SHOULD use the SIP or SIPS URI. >>> >>> SUBSCRIBE messages also contain logical identifiers that define the >>> originator and recipient of the subscription (the To and From header >>> fields). These SHOULD contain SIP or SIPS URIs whenever possible, but >>> MAY contain a pres URI if a SIP or SIPS URI is not known or >>> available. >> >> >> [5] is D. Crocker et al. , "Address resolution for instant messaging >> and presence," Internet Draft, Internet Engineering Task Force, Oct. >> 2002. Work in progress. >> >> I assume this is draft-ietf-impp-srv-01.txt (same title!). Yes. >> That draft seems to envision DNS entries of the form >> "_pres._sip.example.com" to look up which host to contact when one >> wants to use SIP to contact a presentity named "pres:xyzzy@example.com". >> There's no mapping from one type of URI to another - in either direction. >> >> This has two problems: >> >> 1) If a client uses SIP, he presumably has SIP URIs for himself. So he >> will use that SIP URI in the From field of a SUBSCRIBE, even though he >> also has his own PRES URI. >> If the SUBSCRIBE has to be gatewayed to a non-SIP domain, per CPIM, >> how is the gateway to find the corresponding PRES URI? This is a good question. Unfortunately, this is a case which is unavoidable. We are going to run into cases where a SIMPLE client has no pres URI at all, and so the From field has a SIP URI. Worse yet, there is a great deal of SIMPLE deployed today, and most of it (unsurprisingly) using the URI format native to SIMPLE, the SIP URI. So, what would happen at the gateway? I would imagine that, like happens in email systems today I believe, that when receiving a SUBSCRIBE request with From field sip:jdrosen@dynamicsoft.com, the gateway at gw.example.com would create a pres URI like this: pres:sip%3Ajdrosen%40dynamicsoft.com@gw.example.com Should someone reply to this, it would route to the gateway, which would extract the user part, un-escape it, and send it using the sip URI within. Indeed, gateways might do such conversions directly between the native URIs of the various systems (SIMPLE and Jabber, for example). Well, perhaps we would like to avoid this case as much as possible, even if it cannot be prevented altogether. So, making it a SHOULD to use a pres URI when you know both covers some cases. However, there is a practical issue that many existing presence servers don't use the pres URI at this time, and so there will be potential interop problems or bugs that surface. No doubt this is a transient problem, but it is very possible that it will come up. Thus, I would ask you, in your experience with other protocols, do you feel that given, (1) we will still have the issue you are worried about even if we make it a SHOULD to use the pres URI when you know both, and (2) there may be short term interoperability and deployment problems, that the benefit of this outweighs the cost? >> >> 2) If a client starts with the PRES URI, and later learns the SIP URI >> of someone, and those two identities part way for some reason (perhaps >> the client stops using SIP, or the SIP URI was to a proxy service, or >> something) - how does the client learn that it's time to go back to >> the PRES URI? Another good question. Really, it comes down to how you learn these URI in the first place. I might send a SIP SUBSCRIBE to a pres URI, and the Contact header that comes back in the 200 OK will definitely be a SIP URI. It identifies the specific SIP user agent device I am in contact with. Perhaps you would then use this SIP URI instead for future SUBSCRIBE. However, RFC 3261 intends for the Contact URI to be scoped (in terms of temporal validity) to the duration of the dialog (aka subscription). Combing over the text in RFC3261 its not fabulously clear on this point, but thats the intent. So, there is a built in expiration mechanism which would make it invalid for future use. The SIP redirect response could also provide a SIP URI for the presence URI. Redirect responses have a built in mechanism for declaring the lifetime of the mapping, through the Expires header field. Alternatively, if you somehow got the SIP URI from DNS when looking up the pres URI (note that the SRV spec does NOT give you back the SIP URI, but let us assume it did), the DNS TTLs would tell you when it expires. So, I would argue that the only real way a user can get a hold of both the pres and the SIP URI for the user, and not be sure for how long the SIP URI is valid, is if they were handed to that person, on a business card, or on a web page. In such cases, I would argue that it is not the role of the IETF to dictate which is more authoritative. After all, we do not say that if given an H.323 and a SIP URI you must use the SIP URI. Or, given a tel URI and a SIP URI, you must use the tel. This latter case is actually closer to the pres/sip case, since the tel URI can be looked up in DNS to obtain a SIP URI (using ENUM, RFC 2916). The reason that the draft states a preference here is that within SIP, there will be interoperability problems with placeing the pres URI into the request URI. In many cases, SIP user agents use an outbound proxy, similar to an http proxy. This proxy must understand the request URI format in order to forward the request. If I place the pres URI in the request URI, and this goes to the outbound proxy, and it doesnt understand how to process the pres URI, the subscription will fail. Ultimately, our aim is to use our own native addressing format within SIP networks, since that promotes maximum interoperability. So, once more, I would ask - do you think that the benefits of using the pres URI in the request URI (which are, that it is possibly more authoritative, although I am not so sure), outweigh the drawback of potential interoperability issues? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 17 02:49:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15040 for ; Fri, 17 Jan 2003 02:49:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0H85E207866 for simple-archive@odin.ietf.org; Fri, 17 Jan 2003 03:05:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H85DJ07863 for ; Fri, 17 Jan 2003 03:05:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15036 for ; Fri, 17 Jan 2003 02:49:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H859J07851; Fri, 17 Jan 2003 03:05:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H84MJ07817 for ; Fri, 17 Jan 2003 03:04:22 -0500 Received: from eikenes.alvestrand.no (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15028 for ; Fri, 17 Jan 2003 02:48:21 -0500 (EST) Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 186BA625F6; Fri, 17 Jan 2003 08:51:43 +0100 (CET) From: Harald Tveit Alvestrand To: Jonathan Rosenberg , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: simple@ietf.org, Allison Mankin Subject: Re: [Simple] Fwd: Evaluation: draft-ietf-simple-winfo-package - A Session Initiation Protocol (SIP)Event Template-Package for Watcher Information to Proposed Standard Message-ID: <566820000.1042789903@askvoll.hjemme.alvestrand.no> In-Reply-To: <3E274D76.3080604@dynamicsoft.com> References: <8AA01134-23F4-11D7-871D-0003934B2128@cisco.com> <3E274D76.3080604@dynamicsoft.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Jan 2003 08:51:43 +0100 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --On torsdag, januar 16, 2003 19:25:26 -0500 Jonathan Rosenberg wrote: >>> This has two problems: >>> >>> 1) If a client uses SIP, he presumably has SIP URIs for himself. So he >>> will use that SIP URI in the From field of a SUBSCRIBE, even though he >>> also has his own PRES URI. >>> If the SUBSCRIBE has to be gatewayed to a non-SIP domain, per CPIM, >>> how is the gateway to find the corresponding PRES URI? > > This is a good question. > > Unfortunately, this is a case which is unavoidable. We are going to run > into cases where a SIMPLE client has no pres URI at all, and so the From > field has a SIP URI. This case worries me not at all; if there is no pres: URL, we can't use it, and just have to live with that. > Worse yet, there is a great deal of SIMPLE deployed > today, and most of it (unsurprisingly) using the URI format native to > SIMPLE, the SIP URI. > > So, what would happen at the gateway? I would imagine that, like happens > in email systems today I believe, that when receiving a SUBSCRIBE request > with From field sip:jdrosen@dynamicsoft.com, the gateway at > gw.example.com would create a pres URI like this: > > pres:sip%3Ajdrosen%40dynamicsoft.com@gw.example.com this is not exactly new - those of us who've been using email since the 80s will remember hosts of addresses like user%machine.bitnet@gateway.net and the even more horrifying decwrl!some!where!else!user@gateway. exactly the same problems abound - including "route pinning", gateway traversal authentication and so on (the gatway machine can easily be used as an open relay, with all the problems that causes for spam injection, for instance). If there is value to the pres: format, just as there was value to the user@dns.listed.name format, the pres: URL will eventually become ubiquitous. > Should someone reply to this, it would route to the gateway, which would > extract the user part, un-escape it, and send it using the sip URI > within. Indeed, gateways might do such conversions directly between the > native URIs of the various systems (SIMPLE and Jabber, for example). > > Well, perhaps we would like to avoid this case as much as possible, even > if it cannot be prevented altogether. So, making it a SHOULD to use a > pres URI when you know both covers some cases. However, there is a > practical issue that many existing presence servers don't use the pres > URI at this time, and so there will be potential interop problems or bugs > that surface. No doubt this is a transient problem, but it is very > possible that it will come up. > > Thus, I would ask you, in your experience with other protocols, do you > feel that given, (1) we will still have the issue you are worried about > even if we make it a SHOULD to use the pres URI when you know both, and > (2) there may be short term interoperability and deployment problems, > that the benefit of this outweighs the cost? If we were to change the document to say "SHOULD use pres: when one knows both pres: and sip:", I would be much happier. One may even include an explanatory paragraph that the reason it's not a MUST is for communication to environments with legacy SIP-only systems. If we agree that this is the only problem. >>> 2) If a client starts with the PRES URI, and later learns the SIP URI >>> of someone, and those two identities part way for some reason (perhaps >>> the client stops using SIP, or the SIP URI was to a proxy service, or >>> something) - how does the client learn that it's time to go back to >>> the PRES URI? > > Another good question. > > Really, it comes down to how you learn these URI in the first place. I > might send a SIP SUBSCRIBE to a pres URI, and the Contact header that > comes back in the 200 OK will definitely be a SIP URI. It identifies the > specific SIP user agent device I am in contact with. Perhaps you would > then use this SIP URI instead for future SUBSCRIBE. However, RFC 3261 > intends for the Contact URI to be scoped (in terms of temporal validity) > to the duration of the dialog (aka subscription). Combing over the text > in RFC3261 its not fabulously clear on this point, but thats the intent. > So, there is a built in expiration mechanism which would make it invalid > for future use. The SIP redirect response could also provide a SIP URI > for the presence URI. Redirect responses have a built in mechanism for > declaring the lifetime of the mapping, through the Expires header field. > > Alternatively, if you somehow got the SIP URI from DNS when looking up > the pres URI (note that the SRV spec does NOT give you back the SIP URI, > but let us assume it did), the DNS TTLs would tell you when it expires. I would be happier with this part if it added a note saying something like: "NOTE: For many mechanisms that allow users to learn URIs, there is a validity period implied; for instance, RFC 3261 Contact: headers are implicitly scoped to the duration of the dialog on which they are sent, and URIs that are built using information from the DNS need to respect DNS TTL values." Then it's up to the mechanisms from which you learn URIs to make sure you have a TTL when you query - I guess you have already noted this issue for the next time RFC 3261 is revised....:-) This is really an orthogonal issue to which format you want to give preference to; the problem is equally valid for both possible preferences. > So, I would argue that the only real way a user can get a hold of both > the pres and the SIP URI for the user, and not be sure for how long the > SIP URI is valid, is if they were handed to that person, on a business > card, or on a web page. I'd be hesitant to predict the future. I suspect that there will be many more ways than we currently think of that URIs are handed around. I don't think we added TTL values to LDAP or the EPP protocol, for instance.... but back to arguing about which one should be preferred: > In such cases, I would argue that it is not the > role of the IETF to dictate which is more authoritative. I could agree with this argument, if the current document didn't say the complete opposite.... if the IETF is to give guidance, I want the guidance to be what's best for the Internet..... > After all, we do > not say that if given an H.323 and a SIP URI you must use the SIP URI. > Or, given a tel URI and a SIP URI, you must use the tel. This latter case > is actually closer to the pres/sip case, since the tel URI can be looked > up in DNS to obtain a SIP URI (using ENUM, RFC 2916). [Red herring alert - arguing about analogous cases can lead the discussion far astray..... but anyway.... I don't think they're analogous - someone using a pres: URI will certainly have installed the ._pres. DNS records for his domain, since the pres: URI is meaningless without such installed records. there are lots of reasons why people can have a valid tel: URI without installing records into ENUM (including the fact that the ENUM subtree for my country and your country aren't even delegated yet). If you want analogy, I would rather liken the pres: URI to a telephone number in the format +47 41 44 29 94 (international), while the SIP URI is 41 44 29 94 (national). (Perhaps the analogy even fits.. in the US, I sometimes dial US numbers in international format - it's simply simpler than figuring out what number of digits I have to cut out/revise/add in order to get the right result in *this* particular location....) .... end of analogy discussion] > The reason that the draft states a preference here is that within SIP, > there will be interoperability problems with placeing the pres URI into > the request URI. In many cases, SIP user agents use an outbound proxy, > similar to an http proxy. This proxy must understand the request URI > format in order to forward the request. If I place the pres URI in the > request URI, and this goes to the outbound proxy, and it doesnt > understand how to process the pres URI, the subscription will fail. > Ultimately, our aim is to use our own native addressing format within SIP > networks, since that promotes maximum interoperability. I think this is not the best thing for the Internet. Using the SIP addressing format exclusively within SIP networks promotes maximum interoperability *within SIP networks*. It also promotes "walling off the SIP garden", making the cost of communicating with SIP users higher for people who are not using SIP services, and it does all the lock-in and lack of flexibility that we've seen with explictly-addressed email gateways. (No, I don't want to talk about NATs....) > So, once more, I would ask - do you think that the benefits of using the > pres URI in the request URI (which are, that it is possibly more > authoritative, although I am not so sure), outweigh the drawback of > potential interoperability issues? I think so. No matter what you do, you will have interoperability issues. And if you allow people to avoid supporting pres: URIs in the first rollout of the service (when it can be added at the cost of a few extra DNS lookups), you make it that much harder to add support for it in the next version (when the "installed base" argument is a hundred times larger). At the moment, there is no widely deployed presence service that conforms to the simple-presence document. In a year, we both hope that there will be one. Harald _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 17 03:57:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15897 for ; Fri, 17 Jan 2003 03:57:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0H9DLw12952 for simple-archive@odin.ietf.org; Fri, 17 Jan 2003 04:13:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H9DKJ12949 for ; Fri, 17 Jan 2003 04:13:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15891 for ; Fri, 17 Jan 2003 03:57:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H9DCJ12913; Fri, 17 Jan 2003 04:13:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H981J12369 for ; Fri, 17 Jan 2003 04:08:01 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15825 for ; Fri, 17 Jan 2003 03:51:58 -0500 (EST) Received: from cs.columbia.edu (APh-Aug-102-2-1-12.abo.wanadoo.fr [193.252.40.12]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0H8tF6V028470 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Jan 2003 03:55:17 -0500 (EST) Message-ID: <3E27C45D.6050304@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <3E26953D.9000508@dynamicsoft.com> <3E26BB52.4020303@cs.columbia.edu> <3E273D92.2060300@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Jan 2003 03:52:45 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > However I think this category is about the device, not the person. The > availability of the person is something separate. (more below) I'm assuming that each person has zero or more devices. > I guess "Out to Lunch" falls into this category. It doesn't necessarily > imply unavailability to communicate either. (You may be able to call me > at my cell phone while I am at lunch if you don't mind listening to me > chew.) That's why I separated it into two categories - the two are not orthogonal, but they are not deterministic functions of each other, either. > >> >> Note that many calendar systems (such as RFC 2445 or Yahoo calendar) >> allow for categories of activities. Some are free-text (but often >> definable as a list for a particular software), others are pre-defined. > > > Going that far scares me. Pretty much a guarantee that we will never > complete this task. I should have a proposal soon. I don't think it is that bad. > >> >> (3) How is the person feeling right now (calm and relaxed, stressed, >> hopping mad) - very useful to know for the calling party and easily >> derived from a real-time blood-pressure input. (:-), if that's needed.) > > > Does Do Not Disturb fit in here? I think so. On a per-person basis, I agree. > Another one that seems to be important is Active/Inactive - derived from > observation of behavior rather than explicitly set. So you can send me a > message but I may not respond, or you can call me but I might not answer. Agreed; that's another device property, I believe. >> >> - available real-time >> - available store-and-forward (message store of some sort, e.g., >> voicemail or IMs that are stored somewhere for retrieval) >> - not availabl > > > I'm not sure this is another dimension, or bits and pieces of other > dimensions. Nor am I sure whether you intend this to describe the device > or the person. Device. I may be available in real-time for IM, store-and-forward for voice. > > I think there may be value in describing the person (if any) as > available/unavailable. This is something like active/inactive but is an > explicit assertion rather than inferred. (All combinations of the two > are possible.) This would seem to override all per-device communication availability. > > But available-store-and-forward seems different. This can be represented > many different ways. One way is with a separate tuple representing a > recorder or voicemail system. This might be a common way to handle it > for voicemail. It may also be an appropriate solution for IM in some > cases, such as when you are on vacation, or your normal IM device is > offline for some other reason. But it may not cover the case where your > IM device is online but you are away. In this case the device may simply > accept IM on your behalf - in effect it is acting as the independent > recording device would, but isn't a separate device. This is a device property, orthogonal to the media capability. Thus, each device has this property. The whole point of SIP is not to expose the low-level addresses of all my devices. > > I don't yet see how to describe this. It is a device that both is and > isn't an automaton. Being in s&f mode is a property of the device. This isn't unusual - after all, your phone with a built-in answering machine is also both, depending on my mood, call screening or physical presence. > > Paul > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 17 11:51:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28387 for ; Fri, 17 Jan 2003 11:51:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HH6nq14370 for simple-archive@odin.ietf.org; Fri, 17 Jan 2003 12:06:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HH6mJ14367 for ; Fri, 17 Jan 2003 12:06:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28380 for ; Fri, 17 Jan 2003 11:50:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HH6fJ14358; Fri, 17 Jan 2003 12:06:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HH0MJ13740 for ; Fri, 17 Jan 2003 12:00:22 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28267 for ; Fri, 17 Jan 2003 11:44:09 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0HGkY021964 for ; Fri, 17 Jan 2003 18:46:34 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 17 Jan 2003 18:47:30 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 17 Jan 2003 18:47:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Fwd: Evaluation: draft-ietf-simple-winfo-package - A Session Initiation Protocol (SIP)Event Template-Package for Watcher Information to Proposed Standard Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE714B@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Fwd: Evaluation: draft-ietf-simple-winfo-package - A Session Initiation Protocol (SIP)Event Template-Package for Watcher Information to Proposed Standard Thread-Index: AcK9vyqwfnFbnBbySxOXk5YR6/ttBgAh1CUw To: , Cc: , , X-OriginalArrivalTime: 17 Jan 2003 16:47:29.0816 (UTC) FILETIME=[1FAD2980:01C2BE48] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0HH0MJ13741 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Jan 2003 18:47:29 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit SIP allows any scheme to be carried in the From header. It is up to the entities in the network to understand, interpret and forward that request. eg: SUBSCRIBE xmpp:hisham@nokia.com The sip entity at the edge of the sip network (the request reached there using pre-configured route set, for instance), or any entity on the way needs to know how to parse the xmpp uri and do an SRV lookup on the domain nokia.com. This look up could be _sip.nokia.com, just to find the next hop. If no entity on the network understands the scheme, then an error response is returned. To increase interoperability success, I would think that other protocols derived from IMPP must also support scheme agnostic URIs. In this way, the gateway will just copy the URI in the from-header of a sip SUBSCRIBE into the corresponding from-header of the x-protocol SUBSCRIBE. When a reply comes from x-protocol carrying sip scheme, this time in the corresponding To-header of x-protocol, then an entity in the x-protocol domain must perform the same logic as described above in case of the sip network. Regards, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, January 17, 2003 2:25 AM > To: Patrik Fältström > Cc: simple@ietf.org; Harald Alvestrand; Allison Mankin > Subject: Re: [Simple] Fwd: Evaluation: > draft-ietf-simple-winfo-package - > A Session Initiation Protocol (SIP)Event Template-Package for Watcher > Information to Proposed Standard > > > Sorry for taking so long to respond. They are not obvious issues in > fact, so I wanted to ponder them a bit and respond after > thinking about it. > > Anyway, Harald, thanks for the comments, I am glad to have them. > Responses inline: > > Patrik Fältström wrote: > > >> The simple-presence document says: > >> > >>> 5 Usage of Presence URIs > >>> > >>> A presentity is identified in the most general way > through a presence > >>> URI [3], which is of the form pres:user@domain. These URIs are > >>> protocol independent. They are resolved to protocol > specific URIs, > >>> such as a SIP or SIPS URI, through domain-specific > mapping policies. > >>> > >>> If a subscriber is only aware of the > protocol-independent pres URI > >>> for a presentity, it follows the procedures defined in > [5]. These > >>> procedures will result in the placement of the pres URI in the > >>> Request-URI of the SIP request, followed by the usage > of the DNS > >>> procedures defined in [5] to determine the host to send the SIP > >>> request to. Of course, a local outbound proxy may > alternatively be > >>> used, as specified in RFC 3261 [1]. If the subscriber > is aware of > >>> both the protocol-independent pres URI and the SIP or > SIPS URI for > >>> the same presentity, it SHOULD use the SIP or SIPS URI. > >>> > >>> SUBSCRIBE messages also contain logical identifiers > that define the > >>> originator and recipient of the subscription (the To > and From header > >>> fields). These SHOULD contain SIP or SIPS URIs > whenever possible, but > >>> MAY contain a pres URI if a SIP or SIPS URI is not known or > >>> available. > >> > >> > >> [5] is D. Crocker et al. , "Address resolution for > instant messaging > >> and presence," Internet Draft, Internet Engineering Task > Force, Oct. > >> 2002. Work in progress. > >> > >> I assume this is draft-ietf-impp-srv-01.txt (same title!). > > Yes. > > >> That draft seems to envision DNS entries of the form > >> "_pres._sip.example.com" to look up which host to contact when one > >> wants to use SIP to contact a presentity named > "pres:xyzzy@example.com". > >> There's no mapping from one type of URI to another - in > either direction. > >> > >> This has two problems: > >> > >> 1) If a client uses SIP, he presumably has SIP URIs for > himself. So he > >> will use that SIP URI in the From field of a SUBSCRIBE, > even though he > >> also has his own PRES URI. > >> If the SUBSCRIBE has to be gatewayed to a non-SIP domain, > per CPIM, > >> how is the gateway to find the corresponding PRES URI? > > This is a good question. > > Unfortunately, this is a case which is unavoidable. We are > going to run > into cases where a SIMPLE client has no pres URI at all, and > so the From > field has a SIP URI. Worse yet, there is a great deal of > SIMPLE deployed > today, and most of it (unsurprisingly) using the URI format native to > SIMPLE, the SIP URI. > > So, what would happen at the gateway? I would imagine that, > like happens > in email systems today I believe, that when receiving a SUBSCRIBE > request with From field sip:jdrosen@dynamicsoft.com, the gateway at > gw.example.com would create a pres URI like this: > > pres:sip%3Ajdrosen%40dynamicsoft.com@gw.example.com > > Should someone reply to this, it would route to the gateway, > which would > extract the user part, un-escape it, and send it using the sip URI > within. Indeed, gateways might do such conversions directly > between the > native URIs of the various systems (SIMPLE and Jabber, for example). > > Well, perhaps we would like to avoid this case as much as > possible, even > if it cannot be prevented altogether. So, making it a SHOULD to use a > pres URI when you know both covers some cases. However, there is a > practical issue that many existing presence servers don't use > the pres > URI at this time, and so there will be potential interop problems or > bugs that surface. No doubt this is a transient problem, but > it is very > possible that it will come up. > > Thus, I would ask you, in your experience with other > protocols, do you > feel that given, (1) we will still have the issue you are > worried about > even if we make it a SHOULD to use the pres URI when you know > both, and > (2) there may be short term interoperability and deployment problems, > that the benefit of this outweighs the cost? > > > >> > >> 2) If a client starts with the PRES URI, and later learns > the SIP URI > >> of someone, and those two identities part way for some > reason (perhaps > >> the client stops using SIP, or the SIP URI was to a proxy > service, or > >> something) - how does the client learn that it's time to > go back to > >> the PRES URI? > > Another good question. > > Really, it comes down to how you learn these URI in the first > place. I > might send a SIP SUBSCRIBE to a pres URI, and the Contact header that > comes back in the 200 OK will definitely be a SIP URI. It > identifies the > specific SIP user agent device I am in contact with. Perhaps > you would > then use this SIP URI instead for future SUBSCRIBE. However, RFC 3261 > intends for the Contact URI to be scoped (in terms of > temporal validity) > to the duration of the dialog (aka subscription). Combing > over the text > in RFC3261 its not fabulously clear on this point, but thats > the intent. > So, there is a built in expiration mechanism which would make > it invalid > for future use. The SIP redirect response could also provide > a SIP URI > for the presence URI. Redirect responses have a built in > mechanism for > declaring the lifetime of the mapping, through the Expires > header field. > > Alternatively, if you somehow got the SIP URI from DNS when > looking up > the pres URI (note that the SRV spec does NOT give you back > the SIP URI, > but let us assume it did), the DNS TTLs would tell you when > it expires. > > So, I would argue that the only real way a user can get a > hold of both > the pres and the SIP URI for the user, and not be sure for > how long the > SIP URI is valid, is if they were handed to that person, on > a business > card, or on a web page. In such cases, I would argue that it > is not the > role of the IETF to dictate which is more authoritative. > After all, we > do not say that if given an H.323 and a SIP URI you must use the SIP > URI. Or, given a tel URI and a SIP URI, you must use the tel. This > latter case is actually closer to the pres/sip case, since > the tel URI > can be looked up in DNS to obtain a SIP URI (using ENUM, RFC 2916). > > The reason that the draft states a preference here is that > within SIP, > there will be interoperability problems with placeing the > pres URI into > the request URI. In many cases, SIP user agents use an > outbound proxy, > similar to an http proxy. This proxy must understand the request URI > format in order to forward the request. If I place the pres > URI in the > request URI, and this goes to the outbound proxy, and it doesnt > understand how to process the pres URI, the subscription will fail. > Ultimately, our aim is to use our own native addressing format within > SIP networks, since that promotes maximum interoperability. > > So, once more, I would ask - do you think that the benefits > of using the > pres URI in the request URI (which are, that it is possibly more > authoritative, although I am not so sure), outweigh the drawback of > potential interoperability issues? > > Thanks, > Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 17 12:37:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29467 for ; Fri, 17 Jan 2003 12:37:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HHr6X17492 for simple-archive@odin.ietf.org; Fri, 17 Jan 2003 12:53:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HHr6J17489 for ; Fri, 17 Jan 2003 12:53:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29445 for ; Fri, 17 Jan 2003 12:36:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HHr2J17481; Fri, 17 Jan 2003 12:53:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HHqXJ17434 for ; Fri, 17 Jan 2003 12:52:33 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29418 for ; Fri, 17 Jan 2003 12:36:21 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0HHdeW26359; Fri, 17 Jan 2003 12:39:41 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA26146; Fri, 17 Jan 2003 11:39:39 -0600 (CST) Message-ID: <3E283F85.8060903@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat , Jonathan Rosenberg , Thanos Diacakis CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E25D681.2050507@cisco.com> <3E2693D1.4030404@dynamicsoft.com> <3E27253F.5060802@cisco.com> <3E273658.60504@lucent.com> <3E2741F8.70405@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Jan 2003 11:38:13 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: [...] > You are leaping to an unjustified conclusion. Just because a tuple > doesn't identify a device, that doesn't mean its status applies to the > presentity as a whole. That's because the representation of the tuples is currently not hierarchical. > It is even more of a leap to assume that a tuple without a device should > affect tuples that do have devices. > > We *might* find we need a way to define hierarchical tuples (as Jonathan > suggested). If so, then the status in a parent tuple may affect, > supplement, or supercede the status of a child tuple. We have yet to > conclude that is a good thing. You are the only one strongly advocating > it, and I don't think you have yet convinced anyone else. Not for the lack of trying :-). But seriously, clearly there are status codes like "Out to lunch" (MSN Messenger), "Be Right Back" (MSN Messegner), "Not at home" (Yahoo!), "Not at my desk" (Yahoo!), "On vacation" (Yahoo!) that make no sense for a device at all. They do, however, make sense for a person. So why is there such a push to NOT add a tuple representing the person? And in fact, to make it hierarchical such that the status of the person over-rides that of the individual devices. There will be cases where the state of the person can be deduced from interpolating the state of individual devices ("Busy but interruptible), and cases where the state of the person can be authoritatvely enforced on the devices ("Do not disturb"). The person-centric hierarchical model makes this easy to represent (admittedly not easy to realize currently). Ultimately, regardless of all the devices, it is the presence state and availability of the person that is being sought. That should be the crux of the model. >> The only evidence we have right now is how comfortable is the average >> user (not us in IETF) to systems like Yahoo Messenger and AOL. The >> model in these systems revolves around the person, not the devices. > > The reason it isn't complex in any of those systems is because the > presentity and the only device are unified. Isn't that what we are striving for in simple -- a unified view of the myriad devices that a person commands? Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 17 12:46:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29679 for ; Fri, 17 Jan 2003 12:46:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HI26i17976 for simple-archive@odin.ietf.org; Fri, 17 Jan 2003 13:02:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HI26J17973 for ; Fri, 17 Jan 2003 13:02:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29668 for ; Fri, 17 Jan 2003 12:45:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HI22J17963; Fri, 17 Jan 2003 13:02:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HI1jJ17941 for ; Fri, 17 Jan 2003 13:01:45 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29652 for ; Fri, 17 Jan 2003 12:45:34 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0HHmrW00073; Fri, 17 Jan 2003 12:48:54 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA29694; Fri, 17 Jan 2003 11:48:52 -0600 (CST) Message-ID: <3E2841AE.1030901@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E26C801.4020305@lucent.com> <007c01c2bd72$4c1fd070$6401a8c0@myopwv.com> <3E26D219.2020708@lucent.com> <062b01c2bd8b$e70ae570$40071e0a@myopwv.com> <3E27075D.3000708@lucent.com> <065a01c2bd99$c3588700$40071e0a@myopwv.com> <3E273346.300@lucent.com> <3E27445E.1040902@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Jan 2003 11:47:26 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: [...] > I think you are saying the presentity is online when it is connected to > a presence controller. This is irrelevant to any presence client - they > are not affected in any way by this - only by the presence status changes. But the *user* using the presence client is affected by the changes. A presence client serves to provide presence information of others to someone, most probably a human being, who can be affected by the fact that another user is online or offline. > Or maybe you are suggesting that the presentity is online with a device > that can control the behavior (not just the status) of all the devices > described in the presence of the presentity. As you say, the likelihood > of this is slim, but if it were true then the status of the presentity > itself wouldn't be necessary because it could explicitly control the > presence status of all the devices. Sometimes it may NOT want to control the presence status of all the devices, other times it may. DND is a good example of when a person wants explicit control of all devices. Busy-but-interruptible is an example of when the status of the person can be interpolated from the status of the individual devices. Cheers, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 17 14:36:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02536 for ; Fri, 17 Jan 2003 14:36:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HJqHD25033 for simple-archive@odin.ietf.org; Fri, 17 Jan 2003 14:52:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HJqHJ25030 for ; Fri, 17 Jan 2003 14:52:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02528 for ; Fri, 17 Jan 2003 14:36:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HJqCJ25013; Fri, 17 Jan 2003 14:52:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HJp8J24935 for ; Fri, 17 Jan 2003 14:51:08 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02471 for ; Fri, 17 Jan 2003 14:34:54 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0HJd1Wp029054 for ; Fri, 17 Jan 2003 14:39:01 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY09718; Fri, 17 Jan 2003 14:43:17 -0500 (EST) Message-ID: <3E285BA7.7080102@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E25D681.2050507@cisco.com> <3E2693D1.4030404@dynamicsoft.com> <3E27253F.5060802@cisco.com> <3E273658.60504@lucent.com> <3E2741F8.70405@cisco.com> <3E283F85.8060903@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Jan 2003 14:38:15 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit OK, after thinking about this I have a proposal that covers many of the issues that have emerged. It is influenced by many things, most recently Henning's comments in his "Stepping Back" note. (And Vijay *has* succeeded in convincing me that there are *some* status attributes that aren't associated with any device.) I see the following categories of status attributes: * Device specific status - belongs only in a that also contains a element: - a element as defined in draft-lonnfors-simple-prescaps-ext-00, or equivalent. This includes, among other things, an indication of what media are available at the device to be used right now. - an element (?) indicating activity of the presentity in proximity with the device. (active/inactive). This is intended as an automated hint of likelihood that presentity is attending to the device. - an element (?) indicating explict availability and willingness of the presentity to communicate using this device (available/unavailable). (Perhaps this should be a probability - number between 0-1.) - an element () indicating ability of device to handle communication requests in the absence of the presentity. (available/unavailable). (This is voicemail for voice.) * Status that can go in any tuple: - elements indicating current tasks the presentity is involved with, and/or general willingness to communicate. Chosen from an enumeration (TBD). (This covers "out to lunch", "on vacation", "Do Not Disturb", "On the Phone", etc. These do not imply any particular behavior - that is indicated via device specific status. - geoloc information (TBD) - an element (?) specifying expected future status. This contains an optional timestamp indicating when it will take effect. It also contains other status elements. (If it contains device specific status it must go into a device specific tuple.) The element handles a number of things. If you are Out to Lunch and unavailable right now, it can specify that at 1:00 you will be available. If you are "On the Phone" now, and so are not indicating support for voice, it can indicate that you will be available for voice later, though you can't say when. And if you are going to be leaving the office at 7:00, it can indicate that then you will be unavailable. There is some overlap between the element and the voicemail callerpref. But callerprefs currently can't specify that a single device may handle calls directly or via voicemail. It may be better to fix this in callerprefs and then import that via . Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 20 03:19:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13720 for ; Mon, 20 Jan 2003 03:19:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0K8aPg32753 for simple-archive@odin.ietf.org; Mon, 20 Jan 2003 03:36:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0K8aOJ32750 for ; Mon, 20 Jan 2003 03:36:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13710 for ; Mon, 20 Jan 2003 03:18:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0K8aHJ32740; Mon, 20 Jan 2003 03:36:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0K8ZMJ32676 for ; Mon, 20 Jan 2003 03:35:22 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13703 for ; Mon, 20 Jan 2003 03:17:53 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0K8KJ019195 for ; Mon, 20 Jan 2003 10:20:19 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Jan 2003 10:21:16 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 20 Jan 2003 10:21:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Extending for presence Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE714D@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Extending for presence Thread-Index: AcK9o7ue6QOZbrmzQImhJkf5sobl1gCuPkBw To: Cc: , , , X-OriginalArrivalTime: 20 Jan 2003 08:21:15.0598 (UTC) FILETIME=[E6788EE0:01C2C05C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0K8ZbJ32680 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Jan 2003 10:21:14 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Ok, so we are talking about idle detection. I was confused because "Active" could mean that my device is activated and so just wanted to make sure that we are referring to a presentity. Regards, Hisham > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, January 16, 2003 11:10 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: vkg@lucent.com; jdrosen@dynamicsoft.com; hgs@cs.columbia.edu; > simple@ietf.org > Subject: Re: [Simple] Extending for presence > > > Hisham, > > I'm not sure who you were addressing, but I will assume it was me. > > I didn't originally factor active/inactive into my view, but > have been > convinced that it is distinct and relevant. > > Most of the popular IM systems have this in one form or > another. It is > typically used to deal with the case where you are online and present > for IM, but then wander away from your system without doing > anything to > change your presence. In this case, the IM client on your > system notices > that you seem inactive - often by monitoring your use of the mouse or > keyboard - and changes your presence status. It may then also > change its > own behavior - perhaps sending an automatic reply to incoming > messages. > > In general this is tied to a device. If you do IM on your pc but get > phone calls on your cell phone, then the fact that you became > inactive > on your pc doesn't imply anything about your status relative to your > cell phone. > > Paul > > hisham.khartabil@nokia.com wrote: > > If a tuple is representing a device, the OPEN and CLOSED > means that the device is available for communication (to the > extent that I could tell if the device is turned on or it is > off). The list of elements that follow tells you which > communication means are available and which are not: > > > > Using draft-lonnfors-simple-prescaps-ext-00.txt. It is: > > > > > > OPEN > > voice not allowed except high > > priority > > > > > > false > > > > > > true > > > > > > true > > > > > > > > > > Active/Inactive could mean that even though my device is > open, I, as a presentity, am inactive on that device. Where > did those active/inactive come from? What was the original > need for them? > > > > Regards, > > Hisham > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 20 03:36:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14009 for ; Mon, 20 Jan 2003 03:36:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0K8rDd01678 for simple-archive@odin.ietf.org; Mon, 20 Jan 2003 03:53:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0K8rDJ01675 for ; Mon, 20 Jan 2003 03:53:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14002 for ; Mon, 20 Jan 2003 03:35:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0K8r6J01667; Mon, 20 Jan 2003 03:53:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0K8hfJ01318 for ; Mon, 20 Jan 2003 03:43:41 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13838 for ; Mon, 20 Jan 2003 03:26:12 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0K8Vqt28180 for ; Mon, 20 Jan 2003 10:31:52 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Jan 2003 10:29:35 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 20 Jan 2003 10:29:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Extending for presence Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE714E@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Extending for presence Thread-Index: AcK9lxil9VFxPfWeTeeb0mmQigrMdQCxdV1g To: , Cc: , , , X-OriginalArrivalTime: 20 Jan 2003 08:29:35.0617 (UTC) FILETIME=[10816710:01C2C05E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0K8hfJ01319 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Jan 2003 10:29:34 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, January 16, 2003 9:38 PM > To: Thanos Diacakis > Cc: Vijay K. Gurbani; Paul Kyzivat; Henning Schulzrinne; > simple@ietf.org > Subject: Re: [Simple] Extending for presence > > > inline. > > Thanos Diacakis wrote: > > Vijay Gurbani wrote: > > > >>>While its not clear to me what a basic > >>>status of OPEN for a presentity means when each of its > child tuples (the > >>>devices) are CLOSED, > >> > >>Easy to represent DND. > > > > > > No! My "activity" (DND in this case) is orthogonal to the > OPEN/CLOSED > > status of my devices and we cannot represent the one using > the other. We > > need a separate variable/tuple/field to do so. > > I am with Thanos here, in that I am not understanding Vijay's > definition > of DND, or what his interpretation of OPEN/CLOSED for a > presentity means. > I will try to interpret what Vijay is trying to say with an example: I arrive at my office room in the morning and therefore I become available (OPEN). I still haven't switched any of my electronic devices on, so all of them have a status of CLOSED. So in that sense, I am available in my room where anyone can come knocking on the door, but not on any device. The funny thing is, I need a device to publish the information that I, as a presentity, am available in my office for face to face communication. So Vijay's argument could be tied to devices that publish location information (ankle strap :). That device doesn't convey an communication means, just location. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 20 11:49:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23821 for ; Mon, 20 Jan 2003 11:49:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KH6Bg31540 for simple-archive@odin.ietf.org; Mon, 20 Jan 2003 12:06:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KH6BJ31537 for ; Mon, 20 Jan 2003 12:06:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23803 for ; Mon, 20 Jan 2003 11:48:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KH65J31520; Mon, 20 Jan 2003 12:06:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KH50J31467 for ; Mon, 20 Jan 2003 12:05:00 -0500 Received: from ihemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23782 for ; Mon, 20 Jan 2003 11:47:21 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0KGoic18134; Mon, 20 Jan 2003 11:50:44 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA08382; Mon, 20 Jan 2003 10:50:42 -0600 (CST) Message-ID: <3E2C2887.8080907@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E25D681.2050507@cisco.com> <3E2693D1.4030404@dynamicsoft.com> <3E27253F.5060802@cisco.com> <3E273658.60504@lucent.com> <3E2741F8.70405@cisco.com> <3E283F85.8060903@lucent.com> <3E285BA7.7080102@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Jan 2003 10:49:11 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > OK, after thinking about this I have a proposal that covers many of the > issues that have emerged. It is influenced by many things, most recently > Henning's comments in his "Stepping Back" note. (And Vijay *has* > succeeded in convincing me that there are *some* status attributes that > aren't associated with any device.) Paul: Thanks for the proposal; I think you cover a large part of what has been discussed during the last week. More inline. > I see the following categories of status attributes: > > * Device specific status - belongs only in a that also contains > a element: > > - a element as defined in > draft-lonnfors-simple-prescaps-ext-00, or equivalent. > This includes, among other things, an indication of what > media are available at the device to be used right now. > > - an element (?) indicating activity of the presentity > in proximity with the device. (active/inactive). This > is intended as an automated hint of likelihood that > presentity is attending to the device. > > - an element (?) indicating explict availability > and willingness of the presentity to communicate using this > device (available/unavailable). (Perhaps this should be a > probability - number between 0-1.) If we make it a probability, how does this interact with the attribute 'priority'? If the intent is to represent the presentity's (read: person's) explicit availability and willingness to communicate, I think we should leave it as a binary choice. > - an element () indicating ability of device to > handle communication requests in the absence of the presentity. > (available/unavailable). (This is voicemail for voice.) > > * Status that can go in any tuple: > > - elements indicating current tasks the presentity is involved with, > and/or general willingness to communicate. Chosen from an > enumeration (TBD). (This covers "out to lunch", "on vacation", "Do > Not Disturb", "On the Phone", etc. These do not imply any particular > behavior - that is indicated via device specific status. This tuple will then represent the status of the person itself, right? Strict reading of rfc2778 implies that a PRESENTITY is simply a client that provides presence information to be stored and distribued. The status enumerations you mention above (DND, Out to lunch, ...) apply to what rfc2778 calls a PRINCIPAL. So, a tuple (there should be only one) in a element without any represents the PRINCIPAL. Right? > - geoloc information (TBD) > > - an element (?) specifying expected future status. > This contains an optional timestamp indicating when it will take > effect. It also contains other status elements. (If it contains > device specific status it must go into a device specific tuple.) > > The element handles a number of things. If you are Out > to Lunch and unavailable right now, it can specify that at 1:00 you will > be available. If you are "On the Phone" now, and so are not indicating > support for voice, it can indicate that you will be available for voice > later, though you can't say when. And if you are going to be leaving the > office at 7:00, it can indicate that then you will be unavailable. > > There is some overlap between the element and the > voicemail callerpref. But callerprefs currently can't specify that a > single device may handle calls directly or via voicemail. It may be > better to fix this in callerprefs and then import that via . Cheers, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 20 13:24:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26388 for ; Mon, 20 Jan 2003 13:24:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KIfSW05649 for simple-archive@odin.ietf.org; Mon, 20 Jan 2003 13:41:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KIfSJ05645 for ; Mon, 20 Jan 2003 13:41:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26377 for ; Mon, 20 Jan 2003 13:23:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KIfJJ05622; Mon, 20 Jan 2003 13:41:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KIeGJ05577 for ; Mon, 20 Jan 2003 13:40:16 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26328 for ; Mon, 20 Jan 2003 13:22:34 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0KIQiRr021485; Mon, 20 Jan 2003 13:26:45 -0500 (EST) Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-77.cisco.com [161.44.87.77]) by cia.cisco.com (Mirapoint) with ESMTP id ABN12165; Mon, 20 Jan 2003 13:15:55 -0500 (EST) Message-Id: <4.3.2.7.2.20030120124920.00b6c140@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Vijay K. Gurbani" From: Michael Hammer Subject: Re: [Simple] Extending for presence Cc: Paul Kyzivat , simple@ietf.org In-Reply-To: <3E2C2887.8080907@lucent.com> References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E25D681.2050507@cisco.com> <3E2693D1.4030404@dynamicsoft.com> <3E27253F.5060802@cisco.com> <3E273658.60504@lucent.com> <3E2741F8.70405@cisco.com> <3E283F85.8060903@lucent.com> <3E285BA7.7080102@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Jan 2003 13:25:55 -0500 All, Very interesting reading this thread from beginning to end. A couple of observations: There seems to be three main elements here: 1) Devices are OPEN/CLOSED to communications, note that for the user/group level, to be open means that at least one device type must be OPEN to communicate with, which may infer that a device type of "Face-To-Face" with geo-info is needed; Note: OPEN means your request will be handled, CLOSED means your request will be silently discarded. 2) Devices have ACTIVITY (or lack thereof) associated to them), two possible indications are: a) time since last activity: can be derived and reported automatically b) time when next activity can be expected: can be manually set and reported Note: Each of these activity indicators can be quantitatively detailed as in a timestamp or qualitatively on some order of magnitude time-scale of minutes, hours, days, or "soon", "in a while", or "not for a long time" 3) The device user has a PREDISPOSITION to communicate that may be device associated and corresponds to three different degrees: a) DND is device specific and corresponds to CLOSED, meaning if you send the message or INVITE it will get trashed automatically. That is consistent with its use in telephone networks. DND means my phone won't ring. If you don't want your cell phone going off in church then turn it off. If you set this at presentity level, then that should drive all devices (except maybe for FTF geo=CEO office) to CLOSED state. b) "Busy/Away/Whatever" corresponds to OPEN and depends on the caller or communication purpose. So, a communication attempt will be alerted to the human, but may not result in a positive or immediate response. Or, it will get received and handled according to local policy. A text status can provide for unlimited excuses as to why that presentity/device may not be responsive to real-time attempts. c) "Available" means that any and all "callers" will get through and alert the user, who may or may not be immediately available and may or may not choose to answer the communication request. The above predispositions may be associated with particular devices or to the presentity as a whole, in which case it applies to all devices associated. Last, it might be useful to treat the voice-mail, e-mail, and any other non-interactive store-and-forward mechanism as a separate device. Thus, setting phone device to CLOSED, but leaving voice-mail device OPEN tells any caller what will happen if they call that user. The above three attributes can be automatically or manually controlled through the application. I have attempted to digest the thread through my lenses. Did I not account for anything? Mike Hammer At 10:49 AM 1/20/2003 -0600, Vijay K. Gurbani wrote: >Paul Kyzivat wrote: >>OK, after thinking about this I have a proposal that covers many of the >>issues that have emerged. It is influenced by many things, most recently >>Henning's comments in his "Stepping Back" note. (And Vijay *has* >>succeeded in convincing me that there are *some* status attributes that >>aren't associated with any device.) > >Paul: > >Thanks for the proposal; I think you cover a large part of what has >been discussed during the last week. > >More inline. > >>I see the following categories of status attributes: >>* Device specific status - belongs only in a that also contains >> a element: >> - a element as defined in >> draft-lonnfors-simple-prescaps-ext-00, or equivalent. >> This includes, among other things, an indication of what >> media are available at the device to be used right now. >> - an element (?) indicating activity of the presentity >> in proximity with the device. (active/inactive). This >> is intended as an automated hint of likelihood that >> presentity is attending to the device. >> - an element (?) indicating explict availability >> and willingness of the presentity to communicate using this >> device (available/unavailable). (Perhaps this should be a >> probability - number between 0-1.) > >If we make it a probability, how does this interact with the >attribute 'priority'? If the intent is to represent the presentity's >(read: person's) explicit availability and willingness to communicate, I >think we should leave it as a binary choice. > >> - an element () indicating ability of device to >> handle communication requests in the absence of the presentity. >> (available/unavailable). (This is voicemail for voice.) >>* Status that can go in any tuple: >> - elements indicating current tasks the presentity is involved with, >> and/or general willingness to communicate. Chosen from an >> enumeration (TBD). (This covers "out to lunch", "on vacation", "Do >> Not Disturb", "On the Phone", etc. These do not imply any particular >> behavior - that is indicated via device specific status. > >This tuple will then represent the status of the person itself, right? >Strict reading of rfc2778 implies that a PRESENTITY is simply a client >that provides presence information to be stored and distribued. The >status enumerations you mention above (DND, Out to lunch, ...) apply to >what rfc2778 calls a PRINCIPAL. So, a tuple (there should be only one) >in a element without any represents the PRINCIPAL. >Right? > >> - geoloc information (TBD) >> - an element (?) specifying expected future status. >> This contains an optional timestamp indicating when it will take >> effect. It also contains other status elements. (If it contains >> device specific status it must go into a device specific tuple.) >>The element handles a number of things. If you are Out to >>Lunch and unavailable right now, it can specify that at 1:00 you will be >>available. If you are "On the Phone" now, and so are not indicating >>support for voice, it can indicate that you will be available for voice >>later, though you can't say when. And if you are going to be leaving the >>office at 7:00, it can indicate that then you will be unavailable. >>There is some overlap between the element and the >>voicemail callerpref. But callerprefs currently can't specify that a >>single device may handle calls directly or via voicemail. It may be >>better to fix this in callerprefs and then import that via . > >Cheers, > >- vijay >-- >Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} >Wireless Networks Group/Internet Software and Services >Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 >Naperville, Illinois 60566 Voice: +1 630 224 0216 > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 20 13:50:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27015 for ; Mon, 20 Jan 2003 13:50:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KJ7BS06979 for simple-archive@odin.ietf.org; Mon, 20 Jan 2003 14:07:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KJ7BJ06976 for ; Mon, 20 Jan 2003 14:07:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27007 for ; Mon, 20 Jan 2003 13:49:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KJ75J06762; Mon, 20 Jan 2003 14:07:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KJ6tJ06610 for ; Mon, 20 Jan 2003 14:06:55 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27000 for ; Mon, 20 Jan 2003 13:49:13 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0KIqbX26264; Mon, 20 Jan 2003 13:52:37 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA10261; Mon, 20 Jan 2003 12:52:35 -0600 (CST) Message-ID: <3E2C4518.7060500@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E25D681.2050507@cisco.com> <3E2693D1.4030404@dynamicsoft.com> <3E27253F.5060802@cisco.com> <3E273658.60504@lucent.com> <3E2741F8.70405@cisco.com> <3E283F85.8060903@lucent.com> <3E285BA7.7080102@cisco.com> <4.3.2.7.2.20030120124920.00b6c140@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Jan 2003 12:51:04 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Michael Hammer wrote: > All, > > Very interesting reading this thread from beginning to end. A couple of > observations: [...] Michael: Accurate reading indeed. > a) DND is device specific and corresponds to CLOSED, meaning if you > send the message or INVITE it will get trashed automatically. That is > consistent with its use in telephone networks. > If you set this at presentity level, then that should drive all > devices (except maybe for FTF geo=CEO office) to CLOSED state. [...] > The above predispositions may be associated with particular devices or > to the presentity as a whole, in which case it applies to all devices > associated. That is exactly what I have been arguing in favor of in this thread. The presentity (read as: PRINCIPAL, user, person, ...) is the center of the presence/availability hub. Setting something like DND at the presentity level and having it percolate down to the devices (in either some automagic manner or not) is extremely useful. We may not be able to do this currently, but we should not preclude it from happening in the future. Likewise, providing something like DND-except-dept-secretary is easier to implement (using filters or whatever) if we allow the presentity to actively control it's status at times. Of course, there will be times when the presentity is perfectly fine with letting the system dictate the best way of reaching it. > Last, it might be useful to treat the voice-mail, e-mail, > and any other non-interactive store-and-forward mechanism as a separate > device. Thus, setting phone device to CLOSED, but leaving voice-mail > device OPEN tells any caller what will happen if they call that user. > > The above three attributes can be automatically or manually controlled > through the application. I have attempted to digest the thread through > my lenses. Did I not account for anything? I think this is an excellent synopsis. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 20 13:56:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27297 for ; Mon, 20 Jan 2003 13:56:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KJE9o07577 for simple-archive@odin.ietf.org; Mon, 20 Jan 2003 14:14:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KJE9J07574 for ; Mon, 20 Jan 2003 14:14:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27274 for ; Mon, 20 Jan 2003 13:56:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KJE1J07559; Mon, 20 Jan 2003 14:14:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KJDXJ07524 for ; Mon, 20 Jan 2003 14:13:33 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27269 for ; Mon, 20 Jan 2003 13:55:50 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0KJ02rr026868; Mon, 20 Jan 2003 14:00:02 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY19155; Mon, 20 Jan 2003 14:04:17 -0500 (EST) Message-ID: <3E2C4703.2060404@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E25D681.2050507@cisco.com> <3E2693D1.4030404@dynamicsoft.com> <3E27253F.5060802@cisco.com> <3E273658.60504@lucent.com> <3E2741F8.70405@cisco.com> <3E283F85.8060903@lucent.com> <3E285BA7.7080102@cisco.com> <3E2C2887.8080907@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Jan 2003 13:59:15 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline... Vijay K. Gurbani wrote: > >> I see the following categories of status attributes: >> >> * Device specific status - belongs only in a that also contains >> a element: >> >> - a element as defined in >> draft-lonnfors-simple-prescaps-ext-00, or equivalent. >> This includes, among other things, an indication of what >> media are available at the device to be used right now. >> >> - an element (?) indicating activity of the presentity >> in proximity with the device. (active/inactive). This >> is intended as an automated hint of likelihood that >> presentity is attending to the device. >> >> - an element (?) indicating explict availability >> and willingness of the presentity to communicate using this >> device (available/unavailable). (Perhaps this should be a >> probability - number between 0-1.) > > If we make it a probability, how does this interact with the > attribute 'priority'? If the intent is to represent the presentity's > (read: person's) explicit availability and willingness to communicate, I > think we should leave it as a binary choice. The callerprefs use of Priority doesn't work very well at all. It is backwards in terms of who is in control. The caller is free to specify whatever priority he wants for his request, while the callee gets to specify where requests of a particular priority might go. Jonathan has been able to come up with a couple of use cases where this might provide some untility, but they are pretty contrived, and depend on goodwill of all parties. What I have in mind here isn't like that. It isn't trying to control who will be answered, just the likelihood that a request will be answered. I may not have this characterized quite right yet. The extremes of 0/1 (unavailable/available) are pretty easy to understand. The points inbetween may only be useful in specialized situations. But I have such a specialized situation in mind: I want to use presence for routing calls to agents in a call center. In the case of voice calls, availability in this case is binary - an agent on the phone isn't available for another call. But it isn't necesarily so when the 'calls' are for IM sessions. A call center agent can usually handle more than one IM session at a time. But I would like to be able to distinguish between two otherwise equal agents when one is already in an IM session and another is not. In some sense the one that is already in an IM session may be viewed as less available for another session. > >> - an element () indicating ability of device to >> handle communication requests in the absence of the presentity. >> (available/unavailable). (This is voicemail for voice.) >> >> * Status that can go in any tuple: >> >> - elements indicating current tasks the presentity is involved with, >> and/or general willingness to communicate. Chosen from an >> enumeration (TBD). (This covers "out to lunch", "on vacation", "Do >> Not Disturb", "On the Phone", etc. These do not imply any particular >> behavior - that is indicated via device specific status. > > > This tuple will then represent the status of the person itself, right? > Strict reading of rfc2778 implies that a PRESENTITY is simply a client > that provides presence information to be stored and distribued. The > status enumerations you mention above (DND, Out to lunch, ...) apply to > what rfc2778 calls a PRINCIPAL. So, a tuple (there should be only one) > in a element without any represents the PRINCIPAL. > Right? This is a little tricky. If you read 2778 closely you will see that there is no guaranteed 1:1 relationship between a PRESENTITY and a PRINCIPAL - it may be 1:n. One example of this is a shared 'line' in an office - where any of several people may pick up an incoming call. Another case is a human and a voicemail system both dealing with the same line - both may be considered PRINCIPALS by 2778. I think the only thing we can say about this is that it is status associated with the presentity. I'm not sure we can/should even require that there only be one instance of this kind of status. I believe the interpretation of this will have to be pretty subjective. Some examples: - you may have a presentity (ores:vkg@lucent.com) representing you, with several devices. You might add a separate tuple specifying Out To Lunch. - there may be a presentity representing a shared office line (pres:sales@acme.com) with several devices each representing a sales person at acme.com. Several individual salesmen may specify Out To Lunch, each in the tuple representing their respective device. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 20 14:21:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28237 for ; Mon, 20 Jan 2003 14:21:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KJd8Z09294 for simple-archive@odin.ietf.org; Mon, 20 Jan 2003 14:39:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KJd8J09291 for ; Mon, 20 Jan 2003 14:39:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28229 for ; Mon, 20 Jan 2003 14:21:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KJd1J09262; Mon, 20 Jan 2003 14:39:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KJbfJ09179 for ; Mon, 20 Jan 2003 14:37:41 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28186 for ; Mon, 20 Jan 2003 14:19:58 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0KJO9Kn000455; Mon, 20 Jan 2003 14:24:09 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY19372; Mon, 20 Jan 2003 14:28:25 -0500 (EST) Message-ID: <3E2C4CAA.5080309@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Michael Hammer , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E25D681.2050507@cisco.com> <3E2693D1.4030404@dynamicsoft.com> <3E27253F.5060802@cisco.com> <3E273658.60504@lucent.com> <3E2741F8.70405@cisco.com> <3E283F85.8060903@lucent.com> <3E285BA7.7080102@cisco.com> <4.3.2.7.2.20030120124920.00b6c140@cia.cisco.com> <3E2C4518.7060500@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Jan 2003 14:23:22 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline... Paul Vijay K. Gurbani wrote: > >> a) DND is device specific and corresponds to CLOSED, meaning if you >> send the message or INVITE it will get trashed automatically. That is >> consistent with its use in telephone networks. If you set this at >> presentity level, then that should drive all devices (except maybe for >> FTF geo=CEO office) to CLOSED state. > > [...] > >> The above predispositions may be associated with particular devices or >> to the presentity as a whole, in which case it applies to all devices >> associated. > > That is exactly what I have been arguing in favor of in this thread. > The presentity (read as: PRINCIPAL, user, person, ...) is the center of > the presence/availability hub. Setting something like DND at the > presentity level and having it percolate down to the devices (in either > some automagic manner or not) is extremely useful. We may not be able > to do this currently, but we should not preclude it from happening in > the future. This may indeed be good behavior for an implementation of a communication system that includes presence. But it is out of scope for the presence spec itself. Presence is a protocol for *reporting* presence status, and for receiving those reports. It is not a protocol for controlling the devices described. When I hang a DND sign on my door, I MAY lock the door, disconnect the phone, and put on earplugs so that it is impossible to disturb me. But I may equally well just leave the door unlocked and depend on people to use their best judgement about whether to ignore my preference and barge in. It seems reasonable that the same sorts of options ought to be available to users of presence systems. > Likewise, providing something like DND-except-dept-secretary is easier > to implement (using filters or whatever) if we allow the presentity > to actively control it's status at times. Of course, there will be > times when the presentity is perfectly fine with letting the system > dictate the best way of reaching it. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 20 14:57:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29094 for ; Mon, 20 Jan 2003 14:57:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KKEdU11180 for simple-archive@odin.ietf.org; Mon, 20 Jan 2003 15:14:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KKEdJ11177 for ; Mon, 20 Jan 2003 15:14:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29086 for ; Mon, 20 Jan 2003 14:56:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KKE9J11157; Mon, 20 Jan 2003 15:14:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KKDRJ11127 for ; Mon, 20 Jan 2003 15:13:27 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29063 for ; Mon, 20 Jan 2003 14:55:43 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0KJxsC8006276; Mon, 20 Jan 2003 14:59:55 -0500 (EST) Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-77.cisco.com [161.44.87.77]) by cia.cisco.com (Mirapoint) with ESMTP id ABN13333; Mon, 20 Jan 2003 14:49:05 -0500 (EST) Message-Id: <4.3.2.7.2.20030120143614.00b376a8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Paul Kyzivat From: Michael Hammer Subject: Re: [Simple] Extending for presence Cc: "Vijay K. Gurbani" , simple@ietf.org In-Reply-To: <3E2C4CAA.5080309@cisco.com> References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E25D681.2050507@cisco.com> <3E2693D1.4030404@dynamicsoft.com> <3E27253F.5060802@cisco.com> <3E273658.60504@lucent.com> <3E2741F8.70405@cisco.com> <3E283F85.8060903@lucent.com> <3E285BA7.7080102@cisco.com> <4.3.2.7.2.20030120124920.00b6c140@cia.cisco.com> <3E2C4518.7060500@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Jan 2003 14:59:05 -0500 Paul, Agree that the mechanism for enforcing is out of scope. But the presence indication/report should: say what you mean, and (enforcement) mean what you say. The other party should have some degree of assurance of what will happen on your end based on the status they get. Otherwise such statuses might as well be randomly set. If you report DND, but allow alerting the user who then answers the phone, the other parties will soon learn to ignore such an indication. To me, the question is one of whether the device will alert the user or not. Alerting, by its very nature IS disturbing. This is a contradiction in terms. Thus, if the other party is expecting to be able to initiate a communication request, but can expect that there is a slight chance of response, then call it something else, e.g. Predisposition=policy-based-alerting-only. (Your call might alert me, but might not, depending on my policy.) Maybe this is mincing definitions. You probably want something like "DND-with-exceptions" that would leave the status as OPEN with some requests, but CLOSED to others. Mike At 02:23 PM 1/20/2003 -0500, Paul Kyzivat wrote: >inline... > > Paul > >Vijay K. Gurbani wrote: >> >>> a) DND is device specific and corresponds to CLOSED, meaning if you >>> send the message or INVITE it will get trashed automatically. That is >>> consistent with its use in telephone networks. If you set this at >>> presentity level, then that should drive all devices (except maybe for >>> FTF geo=CEO office) to CLOSED state. >>[...] >> >>>The above predispositions may be associated with particular devices or >>>to the presentity as a whole, in which case it applies to all devices >>>associated. >>That is exactly what I have been arguing in favor of in this thread. >>The presentity (read as: PRINCIPAL, user, person, ...) is the center of >>the presence/availability hub. Setting something like DND at the >>presentity level and having it percolate down to the devices (in either >>some automagic manner or not) is extremely useful. We may not be able >>to do this currently, but we should not preclude it from happening in >>the future. > >This may indeed be good behavior for an implementation of a communication >system that includes presence. But it is out of scope for the presence >spec itself. > >Presence is a protocol for *reporting* presence status, and for receiving >those reports. It is not a protocol for controlling the devices described. > >When I hang a DND sign on my door, I MAY lock the door, disconnect the >phone, and put on earplugs so that it is impossible to disturb me. But I >may equally well just leave the door unlocked and depend on people to use >their best judgement about whether to ignore my preference and barge in. >It seems reasonable that the same sorts of options ought to be available >to users of presence systems. > >>Likewise, providing something like DND-except-dept-secretary is easier >>to implement (using filters or whatever) if we allow the presentity >>to actively control it's status at times. Of course, there will be >>times when the presentity is perfectly fine with letting the system >>dictate the best way of reaching it. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 20 16:15:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAB01232 for ; Mon, 20 Jan 2003 16:15:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KLWCi15797 for simple-archive@odin.ietf.org; Mon, 20 Jan 2003 16:32:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KLWCJ15794 for ; Mon, 20 Jan 2003 16:32:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01208 for ; Mon, 20 Jan 2003 16:14:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KLW7J15774; Mon, 20 Jan 2003 16:32:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KI65J02704 for ; Mon, 20 Jan 2003 13:06:05 -0500 Received: from hotsip.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25299; Mon, 20 Jan 2003 12:48:25 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: Thread-Topic: SIPit registration time extended Thread-Index: AcLArJu7uMGtcxaUT1qHfZ2tYaJ1WA== From: "Christian Jansson" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0KI65J02706 Subject: [Simple] SIPit registration time extended Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Jan 2003 18:51:49 +0100 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Don't forget to register with the 12th SIPit event. The registration time has been extended until January 24th to give the last minute planners some more time. Everyone implementing products that are up to date with the most recent SIMPLE work should consider to participate since there will be breakout sessions testing against these specifications to let interoperability become a reality also among presence and IM systems! Registration and other useful information is found at: http://www.hotsip.com/sipit12/ If you have questions, contact sipit12@hotsip.com Welcome! The SIPit 12 team. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 20 16:15:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01235 for ; Mon, 20 Jan 2003 16:15:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KLWDZ15812 for simple-archive@odin.ietf.org; Mon, 20 Jan 2003 16:32:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KLWDJ15809 for ; Mon, 20 Jan 2003 16:32:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01210 for ; Mon, 20 Jan 2003 16:14:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KLW5J15742; Mon, 20 Jan 2003 16:32:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GCk2J17681 for ; Thu, 16 Jan 2003 07:46:02 -0500 Received: from fmis401r.omnitel.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08245 for ; Thu, 16 Jan 2003 07:30:25 -0500 (EST) From: loretosa@vizzavi.it Received: from fmis440.omnitel.it by fmis401r.omnitel.it via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 16 Jan 2003 12:33:47 UT Received: (private information removed) Received: (private information removed) Content-Class: urn:content-classes:message To: Message-ID: <60d701c2bd5a$f3518ef0$5dde010a@omnitel.it> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Microsoft CDO for Windows 2000 Thread-Index: AcK9WvNRJZJ51Y7zRzGwtkNppn+0BQ== X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0GCk2J17682 Subject: [Simple] state of the art Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 16 Jan 2003 13:29:44 +0100 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi all, please can someone help me to do a summary about the state of the art of SIP, SIPPING, and SIMPLE: what are the open issues ? what are the problems and priorities about this standard in 3GPP ? what are the outlooks about the use of this protocol ? Sal _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 20 16:15:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01262 for ; Mon, 20 Jan 2003 16:15:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KLWLO15829 for simple-archive@odin.ietf.org; Mon, 20 Jan 2003 16:32:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KLWKJ15825 for ; Mon, 20 Jan 2003 16:32:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01219 for ; Mon, 20 Jan 2003 16:14:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KLW6J15758; Mon, 20 Jan 2003 16:32:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KHj0J01906 for ; Mon, 20 Jan 2003 12:45:00 -0500 Received: from hotsip.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24769; Mon, 20 Jan 2003 12:27:20 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: Thread-Topic: SIPit registration time extended Thread-Index: AcLAqanTmh13NaQSR/+3nYBqRZc8WQ== From: "Christian Jansson" To: , , Reply-To: "Sipit 12" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0KHj0J01907 Subject: [Simple] SIPit registration time extended Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Jan 2003 18:30:45 +0100 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Don't forget to register with the 12th SIPit event. The registration time has been extended until January 24th to give the last minute planners some more time. Everyone implementing products that are up to date with the most recent SIMPLE work should consider to participate since there will be breakout sessions testing against these specifications to let interoperability become a reality also among presence and IM systems! Registration and other useful information is found at: http://www.hotsip.com/sipit12/ If you have questions, contact sipit12@hotsip.com Welcome! The SIPit 12 team. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 20 16:20:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01423 for ; Mon, 20 Jan 2003 16:20:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KLc9w16764 for simple-archive@odin.ietf.org; Mon, 20 Jan 2003 16:38:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KLc9J16761 for ; Mon, 20 Jan 2003 16:38:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01394 for ; Mon, 20 Jan 2003 16:20:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KLc0J16743; Mon, 20 Jan 2003 16:38:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KLb4J16169 for ; Mon, 20 Jan 2003 16:37:04 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01372 for ; Mon, 20 Jan 2003 16:19:04 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0KLMOYH004471; Mon, 20 Jan 2003 16:22:29 -0500 (EST) Message-ID: <3E2C688C.2030907@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E25D681.2050507@cisco.com> <3E2693D1.4030404@dynamicsoft.com> <3E27253F.5060802@cisco.com> <3E273658.60504@lucent.com> <3E2741F8.70405@cisco.com> <3E283F85.8060903@lucent.com> <3E285BA7.7080102@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Jan 2003 16:22:20 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This seems like a good capture of much of what is being discussed. It is definitely hard to follow these threads since we are covering a lot of really different topics all interspersed. In addition to what you have below, there has also been a bunch of discussion on DND, and how that relates. Also, much discussion on the need for hierarchies of tuples and what they represent. Really, our first task in SIMPLE here is to scope this work. Hopefully, some of that will result from distilling concepts into uses of a small set of status types. Others we will simply need to declare out of scope for now. A few comments on selected points: ON AVAILABILITY I'd like to first comment on this available status you discuss. I don't see how it is different from the basic OPEN/CLOSED status. I also don't see how the probability helps. Paul had given an example use case: > I want to use presence for routing calls to agents in a call center. > In the case of voice calls, availability in this case is binary - an > agent on the phone isn't available for another call. But it isn't > necesarily so when the 'calls' are for IM sessions. A call center > agent can usually handle more than one IM session at a time. But I > would like to be able to distinguish between two otherwise equal > agents when one is already in an IM session and another is not. In > some sense the one that is already in an IM session may be viewed as > less available for another session. To me, this is not really a probability, so much as an expression that availability is conditional on some other characteristics of the call. It is this kind of need which motivated my proposal to support "virtual devices". The primary purpose of those virtual devices would be to represent (using the callerprefs attributes) the conditions to which the OPEN/CLOSED status would apply. ON ACTIVITY I'd next like to comment on what you call "activity". I think there is a need for some type of standardization to support this concept. There are several different ways in which the concept can be quantified: * the amount of TIME since the presentity last interacted with the device * the physical DISTANCE of the presentity from the device * the PROBABILITY that a communications request to the device will be answered by the presentity I think existing IM systems very much rely on the TIME definition. However, in my experience that definition is heavily tied to the concept of a PC application. On a cell phone, where the user normally does not interact with the device continously, this tends to a poor definition. For cell phones, the DISTANCE is a better measure, but even that is not neccesarily a good one. The phone may be near me, but its tucked away into a laptop bag and so I really am idle with respect to it, since I can't hear it or reach it. Arguably, one approach is to separate the means for measuring "activity" or "idleness" from its representation. Using something like a probability, for example, would allow the metric to work across devices, and for it to be measured differently for different devices. Another issue to be factored into the decision about how to represent idleness is how frequently it needs to be reported to the watcher in order to be useful. A time-based measure has the nice benefit that the watcher can continously know how long the presentity has been idle, simply by conveying the time of last activity in the presence notifications. One final point on activity. Some have stated that the defining characteristic of this status is that it is implicitly computed by the system. I disagree. I think it may be perfectly valid to set it explicitly. ON DND DND has received a bit of discussion on this thread. To be honest, I am at a loss as to why it is not really a combination of two things: (1) basic status of CLOSED for each device, and (2) a "task" of "do not disturb". Paul has defined these tasks as things that describe what the presentity is doing, such as "out-to-lunch". "do not disturb" seems like another example. It is the usage of the basic status of CLOSED that really captures the essence of DND - that attempts to contact with that user across their devices will fail. ON STORE_AND_FORWARD Paul has proposed that store-and-forward (what he calls autoresposne) become a special status type for a device. An alternative is to use the caller prefs attribute for this (formerly voicemail, now called msg-server). THis is not quite the same thing. The voicemail/msg-server attribute says "this device IS a voicemail server", and not "if you contact this device, and no one answers, the call will go to voicemail". The latter is an expression of application logic running in a proyx which cannot be concretely known by the device itself. Thus, its not appropriate IMHO as something to represent in caller prefs. It may very well be useful to represent in PIDF, since it is the type of thing that a PA might know, as it has a broader view of the presentity across all devices. Indeed, "auto-response" is just an expression of an application that is running on calls to that device. THere are other applications running that might be of interest. Lets say I have a cell phone and a home phone. I am running CFNA on my home phone, to my cell phone. Perhaps we might like to express in PIDF that this will happen. Supporting such things would argue for representing "voicemail" as another device, and then defining extensions that indicate that call forwarding logic occurs from one device to another. Such a capability in PIDF would capture both the autoresponder semantic and inter-device forwarding rules. What about other applications, such as voice recorders or call blocking applicatoins? DO we need to signal those too? As a matter of scope, I am inclined to treat this whole set (including auto-responder) as out of scope for this first cut. ON HIERARCHIES I have proposed that another axis of extension for PIDF is to allow hierarchies of tuples. This is a superst of the concept Vijay G has been advocating, of defining a special type of tuple to represent a person. On this point, Paul K wrote: > I also looked at 2778 to clarify my thinking. A presentity need not > represent a person. A single presentity could represent a group. So I > would be inclined to say that an address like > sip:customer-support@example.com (or > pres:customer-support@example.com) should be viewed that way. Such a > presentity may have many devices, and each may have independent > status - some OPEN, some CLOSED, some AWAY, some DND. Ultimately the group presentity is represented through multiple devices, but those devices each "belong" to other, different presentities. The value in the hierarchy is being able to express the relationships between these things. I think its valuable to be able to subscribe to pres:customer-support@example.com, and for notifications to be capable of indicating any of the following: * customer support is available now for calls and IM, here is the cotnact address. * customer support is available, and is made up of bob, judy and bill. Here are the contact addresses for bob, judy and bill as presentities * customer support is available, is made of up of bob, judy and bill. Bob has a cell phone and IM device. He is available on the IM device, but not the cell phone. A "group" presentity differs from a "user" presentity in that it can have "user" presentity sub-tuples, and that certain status types apply to it alone. For example, I would like to have a "percentage OPEN" status, which indicates the percentage of the members of the group which are available right now. That definition makes sense for a group, but not a single user presentity. > I'm not sure if you are suggesting an extension that literally > permits tuples to be nested within tuples, or some sort of tagging > and referencing notation that defines graphs between the tuples. I > guess either is technically possible within the scope of the existing > PIDF definition. I had in mind literal nesting, as this is natural for XML. Of course either would work. Its a detail. It is far more important to determine if hierarchical tuples are a useful concept, and if we wish to pursue them now or later. -Jonathan R. Paul Kyzivat wrote: > OK, after thinking about this I have a proposal that covers many of > the issues that have emerged. It is influenced by many things, most > recently Henning's comments in his "Stepping Back" note. (And Vijay > *has* succeeded in convincing me that there are *some* status > attributes that aren't associated with any device.) > > I see the following categories of status attributes: > > * Device specific status - belongs only in a that also > contains a element: > > - a element as defined in > draft-lonnfors-simple-prescaps-ext-00, or equivalent. This includes, > among other things, an indication of what media are available at the > device to be used right now. > > - an element (?) indicating activity of the presentity in > proximity with the device. (active/inactive). This is intended as an > automated hint of likelihood that presentity is attending to the > device. > > - an element (?) indicating explict availability and > willingness of the presentity to communicate using this device > (available/unavailable). (Perhaps this should be a probability - > number between 0-1.) > > - an element () indicating ability of device to handle > communication requests in the absence of the presentity. > (available/unavailable). (This is voicemail for voice.) > > * Status that can go in any tuple: > > - elements indicating current tasks the presentity is involved with, > and/or general willingness to communicate. Chosen from an enumeration > (TBD). (This covers "out to lunch", "on vacation", "Do Not > Disturb", "On the Phone", etc. These do not imply any particular > behavior - that is indicated via device specific status. > > - geoloc information (TBD) > > - an element (?) specifying expected future status. > This contains an optional timestamp indicating when it will take > effect. It also contains other status elements. (If it contains > device specific status it must go into a device specific tuple.) > > The element handles a number of things. If you are > Out to Lunch and unavailable right now, it can specify that at 1:00 > you will be available. If you are "On the Phone" now, and so are not > indicating support for voice, it can indicate that you will be > available for voice later, though you can't say when. And if you are > going to be leaving the office at 7:00, it can indicate that then you > will be unavailable. > > There is some overlap between the element and the > voicemail callerpref. But callerprefs currently can't specify that a > single device may handle calls directly or via voicemail. It may be > better to fix this in callerprefs and then import that via > . > > Paul > > _______________________________________________ Simple mailing list > Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 20 16:22:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01468 for ; Mon, 20 Jan 2003 16:22:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KLdEt16859 for simple-archive@odin.ietf.org; Mon, 20 Jan 2003 16:39:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KLdEJ16856 for ; Mon, 20 Jan 2003 16:39:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01460 for ; Mon, 20 Jan 2003 16:21:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KLd2J16836; Mon, 20 Jan 2003 16:39:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KLcuJ16799 for ; Mon, 20 Jan 2003 16:38:56 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01449 for ; Mon, 20 Jan 2003 16:21:12 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0KLPMhP019661; Mon, 20 Jan 2003 16:25:23 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY20459; Mon, 20 Jan 2003 16:29:38 -0500 (EST) Message-ID: <3E2C6913.8000508@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: "Vijay K. Gurbani" , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E25D681.2050507@cisco.com> <3E2693D1.4030404@dynamicsoft.com> <3E27253F.5060802@cisco.com> <3E273658.60504@lucent.com> <3E2741F8.70405@cisco.com> <3E283F85.8060903@lucent.com> <3E285BA7.7080102@cisco.com> <4.3.2.7.2.20030120124920.00b6c140@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Jan 2003 16:24:35 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Michael Hammer wrote: > All, > > Very interesting reading this thread from beginning to end. A couple of > observations: > > There seems to be three main elements here: > > 1) Devices are OPEN/CLOSED to communications, note that for the > user/group level, to be open means that at least one device type must be > OPEN to communicate with, which may infer that a device type of > "Face-To-Face" with geo-info is needed; Hmm. That seems a little odd. OPEN is currently defined relative to communication with a . What kind of communication can you specify if you have the geoloc but no functional url? Interestingly, 2778 suggests that OPEN might be encoded implicitly, such as via the presence or absence of a contact. Perhaps geoloc could be be represented via a URL that encodes spatial coordinates, and with that sort of URL open/closed is dependent solely on presence of the contact. > Note: OPEN means your request will be handled, > CLOSED means your request will be silently discarded. I don't think you can be that specific about CLOSED. When you go home at night, you may want to report the status of your desk phone as CLOSED, but it may well still ring if called. Or do you think the phone in that state ought to be OPEN & UNAVAILABLE? > 2) Devices have ACTIVITY (or lack thereof) associated to them), two > possible indications are: > a) time since last activity: can be derived and reported automatically > b) time when next activity can be expected: can be manually set and > reported > > Note: Each of these activity indicators can be > quantitatively detailed as in a timestamp or > qualitatively on some order of magnitude time-scale of > minutes, hours, days, or "soon", "in a while", or "not for a long > time" I don't think activity has to do with the device itself. It has more to do with the PRINCIPAL that controls the device. (a) and (b) are independent variables. My device may notice I am active, yet I may still refuse to communicate. (E.g. I'm eating lunch at my desk, and refusing to answer the phone.) However, while they are in principle independent, a presence UA may manage them in a way that couples them - such as refusing to report current activity when its been told that I'm unavailable. > 3) The device user has a PREDISPOSITION to communicate that may be > device associated and corresponds to three different degrees: > > a) DND is device specific and corresponds to CLOSED, meaning if you > send the message or INVITE it will get trashed automatically. That is > consistent with its use in telephone networks. DND means my phone won't > ring. If you don't want your cell phone going off in church then turn > it off. If you set this at presentity level, then that should drive all > devices (except maybe for FTF geo=CEO office) to CLOSED state. I agree that a DND button on a phone may both set presence to DND, disable the ringer, and possible cause a 486 or 401 to be returned automatically. But I'm not convinced we can or should require that behavior. I might instead want my DND button to disable the ringer but still discretely flash a light. > > b) "Busy/Away/Whatever" corresponds to OPEN and depends on the caller > or communication purpose. So, a communication attempt will be alerted > to the human, but may not result in a positive or immediate response. > Or, it will get received and handled according to local policy. A text > status can provide for unlimited excuses as to why that > presentity/device may not be responsive to real-time attempts. I think you are coupling too many things. If DND doesn't imply CLOSED, then DND+CLOSED means one thing, while DND+OPEN means something different. A specific status for DND+OPEN is probably better than simply using OPEN+UNAVAILABLE+TEXT because it can be more easily internationalized. > > c) "Available" means that any and all "callers" will get through and > alert the user, who may or may not be immediately available and may or > may not choose to answer the communication request. It isn't enough to have Available mean "will ring". We need a way to distinguish between Will Probably Be Answered and Will Ring But Probably Won't Be Ansereed. I believe that AVAILABLE+ACTIVE means Will Probably Be Answered, while both UNAVAILABLE and AVAILABLE+INACTIVE mean Will Ring But Probably Won't Be Answered. > The above predispositions may be associated with particular devices or > to the presentity as a whole, in which case it applies to all devices > associated. There is currently no way in PIDF to associate statuses with the presentity as a whole - every tuple stands on its own. > Last, it might be useful to treat the voice-mail, e-mail, > and any other non-interactive store-and-forward mechanism as a separate > device. Thus, setting phone device to CLOSED, but leaving voice-mail > device OPEN tells any caller what will happen if they call that user. If these are in fact distinctly addressable devices then this is already possible, and they can be distinguished via callerprefs. This is problematic if you reach both through the same device. Using two tuples with the same address raises messy issues of how to combine the statuses when a device address is repeated. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 20 17:32:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03088 for ; Mon, 20 Jan 2003 17:32:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KMnSg21225 for simple-archive@odin.ietf.org; Mon, 20 Jan 2003 17:49:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KMnSJ21222 for ; Mon, 20 Jan 2003 17:49:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03065 for ; Mon, 20 Jan 2003 17:31:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KMn8J21207; Mon, 20 Jan 2003 17:49:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KMmoJ21178 for ; Mon, 20 Jan 2003 17:48:50 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03040 for ; Mon, 20 Jan 2003 17:31:04 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0KMZ7Q0029512; Mon, 20 Jan 2003 17:35:07 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY21000; Mon, 20 Jan 2003 17:39:22 -0500 (EST) Message-ID: <3E2C796B.3000104@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E25D681.2050507@cisco.com> <3E2693D1.4030404@dynamicsoft.com> <3E27253F.5060802@cisco.com> <3E273658.60504@lucent.com> <3E2741F8.70405@cisco.com> <3E283F85.8060903@lucent.com> <3E285BA7.7080102@cisco.com> <3E2C688C.2030907@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Jan 2003 17:34:19 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan & others, I've trimmed and reordered Jonathan't message for clarity of response. Comments inline. Paul Jonathan Rosenberg wrote: ... > ON HIERARCHIES ... > I had in mind literal nesting, as this is natural for XML. Of course > either would work. Its a detail. It is far more important to determine > if hierarchical tuples are a useful concept, and if we wish to pursue > them now or later. Of all the points you raise, I think this has the most potential impact, because it makes a larger change to the model defined by 2778. (For instance, introducing hierarchical tuple structures also affects how they might be selectively updated.) There are a fair number of things that can be accomplished without introducing hierarchies, but there are also goodies that are only possible with them. We need to decide if the benefits justify the cost in added complexity. On one hand I like the representational power, which would be good for complex applications of presence that I am pursuing. But, it may make the construction of a simple presence client so complex and obscure that SIMPLE isn't adopted by popular presence clients. That would be very bad. As we have been talking about all the alternatives, I have been trying to imagine how one of the existing presence/IM clients could evolve to set and display this information. The setting side is a bit simpler, because it isn't necessary to provide a way to set every weird combination of status values that is legal. But the displaying of buddies is important, because some of those buddies will have their status constructed using features this client doesn't set for itself. Just representing a buddy with multiple tuples is somewhat of a challenge. But I think it can in general still map to a single line per presentity on a display, with multiple icons representing status elements from all the tuples, together with some simple grouping notation. Of course that will start to break down as the number of tuples goes up. Maybe hierarchical tuples can be handled the same way, but the size will start to get out of hand sooner. Maybe this could be handled with a sort of 'tree control' such as is used by file browsers. I'm not sure how good the human factors could be made for this. (Do I have to drill down to find something I can actually send a message to? It depends on whether my client is or is not willing to take on the role of a forking proxy.) > I have proposed that another axis of extension for PIDF is to allow > hierarchies of tuples. This is a superst of the concept Vijay G has been > advocating, of defining a special type of tuple to represent a person. > > On this point, Paul K wrote: > > I also looked at 2778 to clarify my thinking. A presentity need not > > represent a person. A single presentity could represent a group. So I > > would be inclined to say that an address like > > sip:customer-support@example.com (or > > pres:customer-support@example.com) should be viewed that way. Such a > > presentity may have many devices, and each may have independent > > status - some OPEN, some CLOSED, some AWAY, some DND. > > Ultimately the group presentity is represented through multiple devices, > but those devices each "belong" to other, different presentities. They are controlled by different PRINCIPALs, but they are only represented by different PRESENTITYs if we make the changes to support that. You can make a viable system without that, and in some cases you really don't want those principals to have independent presence. > The > value in the hierarchy is being able to express the relationships > between these things. I think its valuable to be able to subscribe to > pres:customer-support@example.com, and for notifications to be capable > of indicating any of the following: > > * customer support is available now for calls and IM, here is the > cotnact address. > * customer support is available, and is made up of bob, judy and > bill. Here are the contact addresses for bob, judy and bill as presentities Both of the above are representable with the existing two level hierarchy of presentity/tuple. (Except that in the 2nd case it isn't their addresses as presentities that you are providing - it is their sip address - probably address of record - that you give.) > * customer support is available, is made of up of bob, judy and bill. > Bob has a cell phone and IM device. He is available on the IM device, > but not the cell phone. This could perhaps be represented by specifying three tuples, each containing a pres: url. But that is a bit of a stretch. This is the case that seems to cry out for hierarchical tuples. I guess my personal preference is to go ahead and define hierarchies. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 20 17:36:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03154 for ; Mon, 20 Jan 2003 17:36:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KMrIY21372 for simple-archive@odin.ietf.org; Mon, 20 Jan 2003 17:53:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KMrIJ21369 for ; Mon, 20 Jan 2003 17:53:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03150 for ; Mon, 20 Jan 2003 17:35:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KMr1J21350; Mon, 20 Jan 2003 17:53:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KMqCJ21322 for ; Mon, 20 Jan 2003 17:52:12 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03129 for ; Mon, 20 Jan 2003 17:34:25 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0KMbaYH004503; Mon, 20 Jan 2003 17:37:41 -0500 (EST) Message-ID: <3E2C7A2B.90208@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harald Tveit Alvestrand CC: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , simple@ietf.org, Allison Mankin Subject: Re: [Simple] Fwd: Evaluation: draft-ietf-simple-winfo-package - A Session Initiation Protocol (SIP)Event Template-Package for Watcher Information to Proposed Standard References: <8AA01134-23F4-11D7-871D-0003934B2128@cisco.com> <3E274D76.3080604@dynamicsoft.com> <566820000.1042789903@askvoll.hjemme.alvestrand.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Jan 2003 17:37:31 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit thanks for the quick response. Followups inline. Harald Tveit Alvestrand wrote: > > > --On torsdag, januar 16, 2003 19:25:26 -0500 Jonathan Rosenberg > wrote: > >>>> This has two problems: >>>> >>>> 1) If a client uses SIP, he presumably has SIP URIs for himself. So he >>>> will use that SIP URI in the From field of a SUBSCRIBE, even though he >>>> also has his own PRES URI. >>>> If the SUBSCRIBE has to be gatewayed to a non-SIP domain, per CPIM, >>>> how is the gateway to find the corresponding PRES URI? >>> >> >> Thus, I would ask you, in your experience with other protocols, do you >> feel that given, (1) we will still have the issue you are worried about >> even if we make it a SHOULD to use the pres URI when you know both, and >> (2) there may be short term interoperability and deployment problems, >> that the benefit of this outweighs the cost? > > > If we were to change the document to say "SHOULD use pres: when one > knows both pres: and sip:", I would be much happier. One may even > include an explanatory paragraph that the reason it's not a MUST is for > communication to environments with legacy SIP-only systems. If we agree > that this is the only problem. I think its the only problem, with the caveat that there are a lot of mini-problems encapsulated within it. For example, there is a whole body of work going on in the area of identity assertion. We have one RFC on this topic, RFC 3325, which specifies a private extension (not for general use on the Internet), for asserted identity across trusted elements. Interestingly, that mechanism as defined only supports the sip and tel URI. They would not be able to use it to assert a pres URI as an identity. Whether thats good or bad depends on whether you are a fan of that mechanism or not ;) The more general work, using cryptographic identities: http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-00.txt runs into an issue too. How does the authentication service (which asserts an identity by signing a SIP message fragment whose From header identifies the user) determine WHICH identity to assert? Does it assert the pres or sip URI? That depends on what the user is trying to do. I suppose it could assume that if it was signing a SUBSCRIBE request with the event presence, it should assert a pres URI. Anyway, given the benefits of the pres URI over the @gateway approach, I would propose to go with your proposal, making it a SHOULD to use the pres URI. I'd also like to add a bunch of explanatory text around this. Here is my proposed text: > {\SUBSCRIBE} messages also contain logical identifiers that define the > originator and recipient of the subscription (the \header{To} and > \header{From} header fields). These headers can take either a pres or > SIP URI. When the subscriber is aware of both a pres and SIP URI for > its own identity, it SHOULD use the pres URI in the From header > field. Similarly, when the subscriber is aware of both a pres and a > SIP URI for the desired presentity, it SHOULD use the pres URI in the > To header field. The usage of the pres URI supports interoperability through > gateways to other CPP-compliant systems. It provides a > protocol-independent form of identification which can be passed > between systems. Without such an identity, gateways would be forced to > map SIP URIs into the addressing format of other protocols. Generally, > this is done by converting the SIP URI to the form > :@. This is > commonly done in email systems, and has many known problems. The usage > of the pres URI is a SHOULD, and not a MUST, to allow for cases where > it is known that there are no gateways present, or where the usage of > the pres URI will cause interoperability problems with SIP components > that do not support the pres URI. Harald further writes: > >>>> 2) If a client starts with the PRES URI, and later learns the SIP URI >>>> of someone, and those two identities part way for some reason (perhaps >>>> the client stops using SIP, or the SIP URI was to a proxy service, or >>>> something) - how does the client learn that it's time to go back to >>>> the PRES URI? >>> >> >> Another good question. >> >> Really, it comes down to how you learn these URI in the first place. I >> might send a SIP SUBSCRIBE to a pres URI, and the Contact header that >> comes back in the 200 OK will definitely be a SIP URI. It identifies the >> specific SIP user agent device I am in contact with. Perhaps you would >> then use this SIP URI instead for future SUBSCRIBE. However, RFC 3261 >> intends for the Contact URI to be scoped (in terms of temporal validity) >> to the duration of the dialog (aka subscription). Combing over the text >> in RFC3261 its not fabulously clear on this point, but thats the intent. >> So, there is a built in expiration mechanism which would make it invalid >> for future use. The SIP redirect response could also provide a SIP URI >> for the presence URI. Redirect responses have a built in mechanism for >> declaring the lifetime of the mapping, through the Expires header field. >> >> Alternatively, if you somehow got the SIP URI from DNS when looking up >> the pres URI (note that the SRV spec does NOT give you back the SIP URI, >> but let us assume it did), the DNS TTLs would tell you when it expires. > > > I would be happier with this part if it added a note saying something like: > "NOTE: For many mechanisms that allow users to learn URIs, there is a > validity period implied; for instance, RFC 3261 Contact: headers are > implicitly scoped to the duration of the dialog on which they are sent, > and URIs that are built using information from the DNS need to respect > DNS TTL values." > > Then it's up to the mechanisms from which you learn URIs to make sure > you have a TTL when you query - I guess you have already noted this > issue for the next time RFC 3261 is revised....:-) > > This is really an orthogonal issue to which format you want to give > preference to; the problem is equally valid for both possible preferences. I agree that it is orthogonal. I've added the following text that discusses the issue genreally: > In some instances, a user starts with one URI format, such as the pres > URI, and learns a URI in a different format through some protocol > means. As an example, a SUBSCRIBE request sent to a pres URI will > result in learning a SIP or SIPS URI for the presentity from the > Contact header field of the 200 OK to the SUBSCRIBE request. As > another example, a DNS mechanism might be defined that would allow > lookup of a pres URI to obtain a SIP or SIPS URI. In cases where one > URI is learned from another through protocol means, those means will > often provide some kind of scoping that limit the lifetime of the > learned URI. DNS, for example, provides a TTL which would limit the > scope of the URI. These scopes are very useful to avoid stale or > conflicting URIs for identifying the same resource. To ensure that a > user can always determine whether a learned URI is still valid, it is > RECOMMENDED that systems which provide lookup services for presence > URIs have some kind of scoping mechanism. > >> So, I would argue that the only real way a user can get a hold of both >> the pres and the SIP URI for the user, and not be sure for how long the >> SIP URI is valid, is if they were handed to that person, on a business >> card, or on a web page. > > > I'd be hesitant to predict the future. I suspect that there will be many > more ways than we currently think of that URIs are handed around. I > don't think we added TTL values to LDAP or the EPP protocol, for > instance.... True. Such things would exist as part of the schema, though. Indeed, the point of the above text is that your LDAP schema should include some kind of expiration. >> In such cases, I would argue that it is not the >> role of the IETF to dictate which is more authoritative. > > > I could agree with this argument, if the current document didn't say the > complete opposite.... if the IETF is to give guidance, I want the > guidance to be what's best for the Internet..... I was trying to argue that generally, I didn't want to impose a rule on determining which was authoritative, except to the extent that there were specific technical issues that would cause you to prefer one over the other. > >> After all, we do >> not say that if given an H.323 and a SIP URI you must use the SIP URI. >> Or, given a tel URI and a SIP URI, you must use the tel. This latter case >> is actually closer to the pres/sip case, since the tel URI can be looked >> up in DNS to obtain a SIP URI (using ENUM, RFC 2916). > > > [Red herring alert - arguing about analogous cases can lead the > discussion far astray..... but anyway.... > > I don't think they're analogous - someone using a pres: URI will > certainly have installed the ._pres. DNS records for his > domain, since the pres: URI is meaningless without such installed records. > there are lots of reasons why people can have a valid tel: URI without > installing records into ENUM (including the fact that the ENUM subtree > for my country and your country aren't even delegated yet). Sure. In fact, [and now we are really getting off topic] I have argued on the iptel list that I felt that the tel URI as defined was really capturing two different functions. One was a true URN, where the implied semantics were to do a lookup in the DNS (using enum) to resolve it. The second was to identify a telephone network endpoint, so that the implied semantics were to connect to that endpoint on the telephone network. I argued to create two URI to represent these separately, in fact. But, like I said, that is really a separate discussion, which, if you are interested in, I welcome you to comment on on the iptel list. >> The reason that the draft states a preference here is that within SIP, >> there will be interoperability problems with placeing the pres URI into >> the request URI. In many cases, SIP user agents use an outbound proxy, >> similar to an http proxy. This proxy must understand the request URI >> format in order to forward the request. If I place the pres URI in the >> request URI, and this goes to the outbound proxy, and it doesnt >> understand how to process the pres URI, the subscription will fail. >> Ultimately, our aim is to use our own native addressing format within SIP >> networks, since that promotes maximum interoperability. > > > I think this is not the best thing for the Internet. > > Using the SIP addressing format exclusively within SIP networks promotes > maximum interoperability *within SIP networks*. It also promotes > "walling off the SIP garden", making the cost of communicating with SIP > users higher for people who are not using SIP services, and it does all > the lock-in and lack of flexibility that we've seen with > explictly-addressed email gateways. (No, I don't want to talk about > NATs....) > >> So, once more, I would ask - do you think that the benefits of using the >> pres URI in the request URI (which are, that it is possibly more >> authoritative, although I am not so sure), outweigh the drawback of >> potential interoperability issues? > > > I think so. > > No matter what you do, you will have interoperability issues. And if you > allow people to avoid supporting pres: URIs in the first rollout of the > service (when it can be added at the cost of a few extra DNS lookups), > you make it that much harder to add support for it in the next version > (when the "installed base" argument is a hundred times larger). OK, I will buy the argument that it is harder now than later. I changed the text to make usage of the pres URI a SHOULD. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 20 18:28:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04337 for ; Mon, 20 Jan 2003 18:28:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0KNkA424721 for simple-archive@odin.ietf.org; Mon, 20 Jan 2003 18:46:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KNkAJ24718 for ; Mon, 20 Jan 2003 18:46:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04330 for ; Mon, 20 Jan 2003 18:28:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KNk3J24709; Mon, 20 Jan 2003 18:46:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0KNjFJ24679 for ; Mon, 20 Jan 2003 18:45:15 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04326 for ; Mon, 20 Jan 2003 18:27:27 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0KNVXZh005958; Mon, 20 Jan 2003 18:31:34 -0500 (EST) Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-77.cisco.com [161.44.87.77]) by cia.cisco.com (Mirapoint) with ESMTP id ABN15794; Mon, 20 Jan 2003 18:20:45 -0500 (EST) Message-Id: <4.3.2.7.2.20030120174858.03eebb48@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Paul Kyzivat From: Michael Hammer Subject: Re: [Simple] Extending for presence Cc: "Vijay K. Gurbani" , simple@ietf.org In-Reply-To: <3E2C6913.8000508@cisco.com> References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E25D681.2050507@cisco.com> <3E2693D1.4030404@dynamicsoft.com> <3E27253F.5060802@cisco.com> <3E273658.60504@lucent.com> <3E2741F8.70405@cisco.com> <3E283F85.8060903@lucent.com> <3E285BA7.7080102@cisco.com> <4.3.2.7.2.20030120124920.00b6c140@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Jan 2003 18:29:44 -0500 Inline. At 04:24 PM 1/20/2003 -0500, Paul Kyzivat wrote: >Michael Hammer wrote: >>All, >>Very interesting reading this thread from beginning to end. A couple of >>observations: >>There seems to be three main elements here: >>1) Devices are OPEN/CLOSED to communications, note that for the >>user/group level, to be open means that at least one device type must be >>OPEN to communicate with, which may infer that a device type of >>"Face-To-Face" with geo-info is needed; > >Hmm. That seems a little odd. OPEN is currently defined relative to >communication with a . What kind of communication can you specify >if you have the geoloc but no functional url? > >Interestingly, 2778 suggests that OPEN might be encoded implicitly, such >as via the presence or absence of a contact. Perhaps geoloc could be be >represented via a URL that encodes spatial coordinates, and with that sort >of URL open/closed is dependent solely on presence of the contact. OK, I confess I was coloring outside the lines. I was responding to the idea that a presentity could be OPEN with all network devices in a CLOSED state. Didn't know if there was some sort of abstract placeholder for human communication modes. >> Note: OPEN means your request will be handled, >> CLOSED means your request will be silently discarded. > >I don't think you can be that specific about CLOSED. When you go home at >night, you may want to report the status of your desk phone as CLOSED, but >it may well still ring if called. > >Or do you think the phone in that state ought to be OPEN & UNAVAILABLE? If it is able to ring and someone could answer it, then it is OPEN and available. An inactivity indication that a call hasn't been completed in 9 hours (assuming a last call at 6pm as of 3am) would give the presentity viewer the clue that it is unlikely that I will answer. >>2) Devices have ACTIVITY (or lack thereof) associated to them), two >>possible indications are: >> a) time since last activity: can be derived and reported automatically >> b) time when next activity can be expected: can be manually set and >> reported >> Note: Each of these activity indicators can be >> quantitatively detailed as in a timestamp or >> qualitatively on some order of magnitude time-scale of >> minutes, hours, days, or "soon", "in a while", or "not for a long >> time" > >I don't think activity has to do with the device itself. It has more to do >with the PRINCIPAL that controls the device. It could be at both levels. But activity on one of my associated devices should trigger an update to my last activity indicator as an overall presence. >(a) and (b) are independent variables. My device may notice I am active, >yet I may still refuse to communicate. (E.g. I'm eating lunch at my desk, >and refusing to answer the phone.) However, while they are in principle >independent, a presence UA may manage them in a way that couples them - >such as refusing to report current activity when its been told that I'm >unavailable. I see them as independent. But, on second thought b) may be more of a predisposition type of indication. I'm not sure what unavailable means. Is that same as CLOSED or an indication of pre-disposition to not answer even though the device can accept calls? >>3) The device user has a PREDISPOSITION to communicate that may be device >>associated and corresponds to three different degrees: >> a) DND is device specific and corresponds to CLOSED, meaning if you >> send the message or INVITE it will get trashed automatically. That is >> consistent with its use in telephone networks. DND means my phone won't >> ring. If you don't want your cell phone going off in church then turn >> it off. If you set this at presentity level, then that should drive all >> devices (except maybe for FTF geo=CEO office) to CLOSED state. > >I agree that a DND button on a phone may both set presence to DND, disable >the ringer, and possible cause a 486 or 401 to be returned automatically. >But I'm not convinced we can or should require that behavior. > >I might instead want my DND button to disable the ringer but still >discretely flash a light. This begs the question of what constitutes a disturbance. What about the converse? If my IM is DND, does it ring instead of popping up on a screen? :) Maybe I'm being draconian, but I would hope that a DND would prevent any attempts, while a lesser state may allow privileged persons to have a hope of getting through. But as long as the semantic description and the expected behavior upon receipt of a subsequent attempt are consistent, then OK. Is it not possible that two different presence recipients might get different indications with corresponding treatments upon attempts? >> b) "Busy/Away/Whatever" corresponds to OPEN and depends on the caller >> or communication purpose. So, a communication attempt will be alerted >> to the human, but may not result in a positive or immediate response. >>Or, it will get received and handled according to local policy. A text >>status can provide for unlimited excuses as to why that presentity/device >>may not be responsive to real-time attempts. > >I think you are coupling too many things. If DND doesn't imply CLOSED, >then DND+CLOSED means one thing, while DND+OPEN means something different. I was not agreeing with that premise. >A specific status for DND+OPEN is probably better than simply using >OPEN+UNAVAILABLE+TEXT because it can be more easily internationalized. True, but I only suggested text to give vent to the various reason types that people have attachment to. >> c) "Available" means that any and all "callers" will get through and >> alert the user, who may or may not be immediately available and may or >> may not choose to answer the communication request. > >It isn't enough to have Available mean "will ring". We need a way to >distinguish between Will Probably Be Answered and Will Ring But Probably >Won't Be Ansereed. I believe that AVAILABLE+ACTIVE means Will Probably Be >Answered, while both UNAVAILABLE and AVAILABLE+INACTIVE mean Will Ring But >Probably Won't Be Answered. This is where I saw the predisposition giving an explicit hint and the recent activity indication giving an implicit hint about probably. Otherwise, it seems like a SWAG on the part of the application. >>The above predispositions may be associated with particular devices or to >>the presentity as a whole, in which case it applies to all devices associated. > >There is currently no way in PIDF to associate statuses with the >presentity as a whole - every tuple stands on its own. > > > Last, it might be useful to treat the voice-mail, e-mail, >>and any other non-interactive store-and-forward mechanism as a separate >>device. Thus, setting phone device to CLOSED, but leaving voice-mail >>device OPEN tells any caller what will happen if they call that user. > >If these are in fact distinctly addressable devices then this is already >possible, and they can be distinguished via callerprefs. This is >problematic if you reach both through the same device. Using two tuples >with the same address raises messy issues of how to combine the statuses >when a device address is repeated. Hmmm, I thought that each tuple would stand on its own and not necessarily get combined. > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 21 02:02:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16515 for ; Tue, 21 Jan 2003 02:02:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0L7KFA25609 for simple-archive@odin.ietf.org; Tue, 21 Jan 2003 02:20:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L7KEJ25606 for ; Tue, 21 Jan 2003 02:20:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15833 for ; Tue, 21 Jan 2003 02:02:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L7K8J25586; Tue, 21 Jan 2003 02:20:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L7JvJ25548 for ; Tue, 21 Jan 2003 02:19:57 -0500 Received: from il-tlv-smtpout2.icomverse.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15455 for ; Tue, 21 Jan 2003 02:02:00 -0500 (EST) Received: from il-tlv-mbdg1.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h0L75JT28160 for ; Tue, 21 Jan 2003 09:05:19 +0200 Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55) id ; Tue, 21 Jan 2003 09:05:23 +0200 Message-ID: <385D702A9C11D511A9E90008C7160AD5043BCB53@ismail1.comverse.com> From: Cnaan Oded To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C11B.71773BF4" Subject: [Simple] Content indirection - Uploading large messages Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Jan 2003 09:05:13 +0200 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_01C2C11B.71773BF4 Content-Type: text/plain; charset="windows-1255" The content-indirection draft (the latest I could find was draft-ietf-sipping-content-indirect-02.txt) describes how messages or notifications carry a URL in order to allow the UA to retrieve the (usually large) content over other transports (e.g., HTTP). The draft however does not specify how large content is uploaded from the UA to the server. Using HTTP per se is not sufficient for uploading messages over HTTP as there is some meta-data that needs to be attached to the document such as sender, recipient(s), message type etc. The MMS standard have already solved these details in their MM1 protocol (over HTTP as well). Note also that using the MESSAGE method is not a good practice as well as it would generate huge load on the CSCFs (in mobile networks that deploy IMS/MMD infrastructure), denying them from performing call control tasks. 1. How should large messages be sent from the UA to the server? any specific draft? 2. Does the SIMPLE WG intend to reuse the MM1 specifications or invent a new one? 3. What's the status of this work within the SIMPLE WG? Are there any concrete contributions? Thanks, Oded Cnaan Comverse ------_=_NextPart_001_01C2C11B.71773BF4 Content-Type: text/html; charset="windows-1255"
The content-indirection draft (the latest I could find was draft-ietf-sipping-content-indirect-02.txt) describes how messages or notifications carry a URL in order to allow the UA to retrieve the (usually large) content over other transports (e.g., HTTP). The draft however does not specify how large content is uploaded from the UA to the server.
 
Using HTTP per se is not sufficient for uploading messages over HTTP as there is some meta-data that needs to be attached to the document such as sender, recipient(s), message type etc. The MMS standard have already solved these details in their MM1 protocol (over HTTP as well).
 
Note also that using the MESSAGE method is not a good practice as well as it would generate huge load on the CSCFs (in mobile networks that deploy IMS/MMD infrastructure), denying them from performing call control tasks.
 
1. How should large messages be sent from the UA to the server? any specific draft?
2. Does the SIMPLE WG intend to reuse the MM1 specifications or invent a new one?
3. What's the status of this work within the SIMPLE WG? Are there any concrete contributions?
 
Thanks,
Oded Cnaan
Comverse
 
------_=_NextPart_001_01C2C11B.71773BF4-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 21 02:40:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23095 for ; Tue, 21 Jan 2003 02:40:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0L7wHi28203 for simple-archive@odin.ietf.org; Tue, 21 Jan 2003 02:58:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L7wGJ28200 for ; Tue, 21 Jan 2003 02:58:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23091 for ; Tue, 21 Jan 2003 02:40:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L7w7J28192; Tue, 21 Jan 2003 02:58:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L7vkJ28158 for ; Tue, 21 Jan 2003 02:57:46 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23082 for ; Tue, 21 Jan 2003 02:39:47 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0L7gE022476 for ; Tue, 21 Jan 2003 09:42:14 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Jan 2003 09:43:12 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 21 Jan 2003 09:43:11 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 21 Jan 2003 09:43:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Extending for presence Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7162@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Extending for presence Thread-Index: AcLAykX1hJX6v554QAyUYKS4swdx9wAVTXcw To: , Cc: X-OriginalArrivalTime: 21 Jan 2003 07:43:11.0481 (UTC) FILETIME=[BF71B690:01C2C120] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0L7vkJ28159 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Jan 2003 09:43:10 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I would like to throw in one more: A lot of discussion in this thread was about tying the device behaviour with the presence state. If device is CLOSED, then it will not ring. So, I wanted to bring in authorisation policies and polite blocking into the formula. If a watcher gets false information due to a policy indicating so. Does the device need to know NOT to ring for that person or group that the presentity is lying to? I might show out-to-lunch for someone who I don't want to talk to right now, my show available to my good friends. How is the device controlled in this case? I guess the real question is: Can the device be controlled by presence state? or it like just like Paul's example; you hang a do-not-disturb sign on the door and hope for the best? Regards, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, January 20, 2003 11:22 PM > To: Paul Kyzivat > Cc: simple@ietf.org > Subject: Re: [Simple] Extending for presence > > > This seems like a good capture of much of what is being > discussed. It is > definitely hard to follow these threads since we are covering a lot of > really different topics all interspersed. > > In addition to what you have below, there has also been a bunch of > discussion on DND, and how that relates. Also, much discussion on the > need for hierarchies of tuples and what they represent. > > Really, our first task in SIMPLE here is to scope this work. > Hopefully, > some of that will result from distilling concepts into uses of a small > set of status types. Others we will simply need to declare > out of scope > for now. > > A few comments on selected points: > > ON AVAILABILITY > > I'd like to first comment on this available status you > discuss. I don't > see how it is different from the basic OPEN/CLOSED status. I > also don't > see how the probability helps. Paul had given an example use case: > > > I want to use presence for routing calls to agents in a > call center. > > In the case of voice calls, availability in this case is > binary - an > > agent on the phone isn't available for another call. But it isn't > > necesarily so when the 'calls' are for IM sessions. A call center > > agent can usually handle more than one IM session at a time. But I > > would like to be able to distinguish between two otherwise equal > > agents when one is already in an IM session and another is not. In > > some sense the one that is already in an IM session may be > viewed as > > less available for another session. > > To me, this is not really a probability, so much as an expression that > availability is conditional on some other characteristics of the call. > It is this kind of need which motivated my proposal to > support "virtual > devices". The primary purpose of those virtual devices would be to > represent (using the callerprefs attributes) the conditions > to which the > OPEN/CLOSED status would apply. > > ON ACTIVITY > > I'd next like to comment on what you call "activity". I think > there is a > need for some type of standardization to support this > concept. There are > several different ways in which the concept can be quantified: > > * the amount of TIME since the presentity last interacted > with the device > * the physical DISTANCE of the presentity from the device > * the PROBABILITY that a communications request to the > device will be > answered by the presentity > > I think existing IM systems very much rely on the TIME definition. > However, in my experience that definition is heavily tied to > the concept > of a PC application. On a cell phone, where the user normally does not > interact with the device continously, this tends to a poor definition. > For cell phones, the DISTANCE is a better measure, but even > that is not > neccesarily a good one. The phone may be near me, but its tucked away > into a laptop bag and so I really am idle with respect to it, since I > can't hear it or reach it. > > Arguably, one approach is to separate the means for measuring > "activity" > or "idleness" from its representation. Using something like a > probability, for example, would allow the metric to work > across devices, > and for it to be measured differently for different devices. > > Another issue to be factored into the decision about how to represent > idleness is how frequently it needs to be reported to the watcher in > order to be useful. A time-based measure has the nice benefit that the > watcher can continously know how long the presentity has been idle, > simply by conveying the time of last activity in the presence > notifications. > > One final point on activity. Some have stated that the defining > characteristic of this status is that it is implicitly computed by the > system. I disagree. I think it may be perfectly valid to set > it explicitly. > > ON DND > > DND has received a bit of discussion on this thread. To be > honest, I am > at a loss as to why it is not really a combination of two things: (1) > basic status of CLOSED for each device, and (2) a "task" of "do not > disturb". Paul has defined these tasks as things that > describe what the > presentity is doing, such as "out-to-lunch". "do not disturb" > seems like > another example. > > It is the usage of the basic status of CLOSED that really captures the > essence of DND - that attempts to contact with that user across their > devices will fail. > > ON STORE_AND_FORWARD > > Paul has proposed that store-and-forward (what he calls autoresposne) > become a special status type for a device. An alternative is > to use the > caller prefs attribute for this (formerly voicemail, now called > msg-server). THis is not quite the same thing. The > voicemail/msg-server > attribute says "this device IS a voicemail server", and not "if you > contact this device, and no one answers, the call will go to > voicemail". > The latter is an expression of application logic running in a proyx > which cannot be concretely known by the device itself. Thus, its not > appropriate IMHO as something to represent in caller prefs. > It may very > well be useful to represent in PIDF, since it is the type of > thing that > a PA might know, as it has a broader view of the presentity across all > devices. > > Indeed, "auto-response" is just an expression of an > application that is > running on calls to that device. THere are other applications running > that might be of interest. Lets say I have a cell phone and a home > phone. I am running CFNA on my home phone, to my cell phone. > Perhaps we > might like to express in PIDF that this will happen. Supporting such > things would argue for representing "voicemail" as another device, and > then defining extensions that indicate that call forwarding > logic occurs > from one device to another. Such a capability in PIDF would > capture both > the autoresponder semantic and inter-device forwarding rules. > > What about other applications, such as voice recorders or > call blocking > applicatoins? DO we need to signal those too? As a matter of > scope, I am > inclined to treat this whole set (including auto-responder) as out of > scope for this first cut. > > ON HIERARCHIES > > I have proposed that another axis of extension for PIDF is to allow > hierarchies of tuples. This is a superst of the concept Vijay > G has been > advocating, of defining a special type of tuple to represent a person. > > On this point, Paul K wrote: > > I also looked at 2778 to clarify my thinking. A presentity need not > > represent a person. A single presentity could represent a > group. So I > > would be inclined to say that an address like > > sip:customer-support@example.com (or > > pres:customer-support@example.com) should be viewed that > way. Such a > > presentity may have many devices, and each may have independent > > status - some OPEN, some CLOSED, some AWAY, some DND. > > Ultimately the group presentity is represented through > multiple devices, > but those devices each "belong" to other, different presentities. The > value in the hierarchy is being able to express the relationships > between these things. I think its valuable to be able to subscribe to > pres:customer-support@example.com, and for notifications to be capable > of indicating any of the following: > > * customer support is available now for calls and IM, here is the > cotnact address. > * customer support is available, and is made up of bob, judy and > bill. Here are the contact addresses for bob, judy and bill > as presentities > * customer support is available, is made of up of bob, > judy and bill. > Bob has a cell phone and IM device. He is available on the IM device, > but not the cell phone. > > A "group" presentity differs from a "user" presentity in that it can > have "user" presentity sub-tuples, and that certain status types apply > to it alone. For example, I would like to have a "percentage OPEN" > status, which indicates the percentage of the members of the > group which > are available right now. That definition makes sense for a group, but > not a single user presentity. > > > I'm not sure if you are suggesting an extension that literally > > permits tuples to be nested within tuples, or some sort of tagging > > and referencing notation that defines graphs between the tuples. I > > guess either is technically possible within the scope of > the existing > > PIDF definition. > > I had in mind literal nesting, as this is natural for XML. Of course > either would work. Its a detail. It is far more important to > determine > if hierarchical tuples are a useful concept, and if we wish to pursue > them now or later. > > -Jonathan R. > > > Paul Kyzivat wrote: > > OK, after thinking about this I have a proposal that covers many of > > the issues that have emerged. It is influenced by many things, most > > recently Henning's comments in his "Stepping Back" note. (And Vijay > > *has* succeeded in convincing me that there are *some* status > > attributes that aren't associated with any device.) > > > > I see the following categories of status attributes: > > > > * Device specific status - belongs only in a that also > > contains a element: > > > > - a element as defined in > > draft-lonnfors-simple-prescaps-ext-00, or equivalent. This > includes, > > among other things, an indication of what media are > available at the > > device to be used right now. > > > > - an element (?) indicating activity of the presentity in > > proximity with the device. (active/inactive). This is > intended as an > > automated hint of likelihood that presentity is attending to the > > device. > > > > - an element (?) indicating explict availability and > > willingness of the presentity to communicate using this device > > (available/unavailable). (Perhaps this should be a probability - > > number between 0-1.) > > > > - an element () indicating ability of device > to handle > > communication requests in the absence of the presentity. > > (available/unavailable). (This is voicemail for voice.) > > > > * Status that can go in any tuple: > > > > - elements indicating current tasks the presentity is > involved with, > > and/or general willingness to communicate. Chosen from an > enumeration > > (TBD). (This covers "out to lunch", "on vacation", "Do Not > > Disturb", "On the Phone", etc. These do not imply any particular > > behavior - that is indicated via device specific status. > > > > - geoloc information (TBD) > > > > - an element (?) specifying expected future status. > > This contains an optional timestamp indicating when it will take > > effect. It also contains other status elements. (If it contains > > device specific status it must go into a device specific tuple.) > > > > The element handles a number of things. If you are > > Out to Lunch and unavailable right now, it can specify that at 1:00 > > you will be available. If you are "On the Phone" now, and > so are not > > indicating support for voice, it can indicate that you will be > > available for voice later, though you can't say when. And > if you are > > going to be leaving the office at 7:00, it can indicate > that then you > > will be unavailable. > > > > There is some overlap between the element and the > > voicemail callerpref. But callerprefs currently can't > specify that a > > single device may handle calls directly or via voicemail. It may be > > better to fix this in callerprefs and then import that via > > . > > > > Paul > > > > _______________________________________________ Simple mailing list > > Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 21 02:43:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23145 for ; Tue, 21 Jan 2003 02:43:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0L817428351 for simple-archive@odin.ietf.org; Tue, 21 Jan 2003 03:01:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L817J28346 for ; Tue, 21 Jan 2003 03:01:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23136 for ; Tue, 21 Jan 2003 02:43:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L812J28336; Tue, 21 Jan 2003 03:01:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L80OJ28307 for ; Tue, 21 Jan 2003 03:00:24 -0500 Received: from smtp018.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA23126 for ; Tue, 21 Jan 2003 02:42:26 -0500 (EST) Received: from 12-235-146-159.client.attbi.com (HELO cranberry) (seancolson@12.235.146.159 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 21 Jan 2003 07:45:52 -0000 Reply-To: From: "Sean Olson" To: "'Cnaan Oded'" , Subject: RE: [Simple] Content indirection - Uploading large messages Message-ID: <001b01c2c121$21bbea00$6501a8c0@cranberry> 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.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <385D702A9C11D511A9E90008C7160AD5043BCB53@ismail1.comverse.com> Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 20 Jan 2003 23:45:55 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The draft intentionally does not address the how the content is placed on the content server to begin with. That is a separate problem that has many disparate solutions and does not necessarily need to be standardized. The interesting thing about standardizing the content-indirection mechanism is that it involves two SIP entities and directly impacts the SIP signaling. The transfer of content, either from the UA to the server, or between UAs is best handled outside of SIP ... the very point of the draft. Some important things to note: 1) The "server" does not have to be distinct from the UA. They can be one in the same. 2) The URL does not have to be an HTTP URL, though this will be probably be one of the more common schemes used. For example, an LDAP URL might very be appropriate for certain types of content 3) HTTP is ideal for conveying meta-data about the content it carries, but that argument is best handled outside of SIMPLE 4) It was never envisoned that MESSAGE would be used to send these large payloads -- the entire point of content indirection is to offload this to a non-SIP carrier. 5) There is nothing mutually exclusive of content-indirection and MMS. Nor is there anything that compels one to use MMS for this task in the draft. It's simply outside the scope of this draft. 6) Is there something particularly non-concrete about the draft? ;-) 7) This mechanism is not tied to any particular architecture, though some architectures may have more pressing need for it than others. cheers, sean -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Cnaan Oded Sent: Monday, January 20, 2003 11:05 PM To: 'simple@ietf.org' Subject: [Simple] Content indirection - Uploading large messages The content-indirection draft (the latest I could find was draft-ietf-sipping-content-indirect-02.txt) describes how messages or notifications carry a URL in order to allow the UA to retrieve the (usually large) content over other transports (e.g., HTTP). The draft however does not specify how large content is uploaded from the UA to the server. Using HTTP per se is not sufficient for uploading messages over HTTP as there is some meta-data that needs to be attached to the document such as sender, recipient(s), message type etc. The MMS standard have already solved these details in their MM1 protocol (over HTTP as well). Note also that using the MESSAGE method is not a good practice as well as it would generate huge load on the CSCFs (in mobile networks that deploy IMS/MMD infrastructure), denying them from performing call control tasks. 1. How should large messages be sent from the UA to the server? any specific draft? 2. Does the SIMPLE WG intend to reuse the MM1 specifications or invent a new one? 3. What's the status of this work within the SIMPLE WG? Are there any concrete contributions? Thanks, Oded Cnaan Comverse _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 21 04:49:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24603 for ; Tue, 21 Jan 2003 04:49:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LA6Zm03206 for simple-archive@odin.ietf.org; Tue, 21 Jan 2003 05:06:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LA6ZJ03203 for ; Tue, 21 Jan 2003 05:06:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24600 for ; Tue, 21 Jan 2003 04:48:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LA6QJ03195; Tue, 21 Jan 2003 05:06:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LA5OJ03135 for ; Tue, 21 Jan 2003 05:05:24 -0500 Received: from il-tlv-smtpout1.icomverse.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24593 for ; Tue, 21 Jan 2003 04:47:23 -0500 (EST) Received: from il-tlv-mbdg2.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id h0L9od322924 for ; Tue, 21 Jan 2003 11:50:39 +0200 Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2655.55) id ; Tue, 21 Jan 2003 11:50:46 +0200 Message-ID: <385D702A9C11D511A9E90008C7160AD5043BCB58@ismail1.comverse.com> From: Cnaan Oded To: simple@ietf.org Cc: Rapaport Orly Subject: RE: [Simple] Content indirection - Uploading large messages MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C132.9157DBD8" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Jan 2003 11:50:45 +0200 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_01C2C132.9157DBD8 Content-Type: text/plain; charset="iso-8859-1" Sean, Thanks for the prompt reply. You may be right that the details of how large payloads are sent from the UA to the server (in case these are not the same entities and that there is a network based server) are outside SIMPLE scope but it seems to me that the first hurdle SIMPLE will face would be -interoperability. If you leave this question open for proprietary solutions, applications from different vendors will not be able to co-exist on the same network. If you look at the WG charter, you will find that "The IETF has committed to producing an interoperable standard for these services ". The charter also refers to RFC 2778 and CPIM which require defining how messages are sent from UAs to servers, regardless of their size. Moreover, if you look at 3GPP requirements from SIMPLE (e.g., draft-niemi-simple-im-wireless-reqs-00) they require that "The content size MUST NOT be limited by the Instant Messaging, or message session protocols" - SIMPLE must be able to specify how this is done. I believe SIMPLE WG should define at least a 'default' behavior for these cases, or refer to an external standard, such as MM1. Oded Cnaan -----Original Message----- From: Sean Olson [mailto:seancolson@yahoo.com] Sent: Tuesday, January 21, 2003 9:46 AM To: 'Cnaan Oded'; simple@ietf.org Subject: RE: [Simple] Content indirection - Uploading large messages The draft intentionally does not address the how the content is placed on the content server to begin with. That is a separate problem that has many disparate solutions and does not necessarily need to be standardized. The interesting thing about standardizing the content-indirection mechanism is that it involves two SIP entities and directly impacts the SIP signaling. The transfer of content, either from the UA to the server, or between UAs is best handled outside of SIP ... the very point of the draft. Some important things to note: 1) The "server" does not have to be distinct from the UA. They can be one in the same. 2) The URL does not have to be an HTTP URL, though this will be probably be one of the more common schemes used. For example, an LDAP URL might very be appropriate for certain types of content 3) HTTP is ideal for conveying meta-data about the content it carries, but that argument is best handled outside of SIMPLE 4) It was never envisoned that MESSAGE would be used to send these large payloads -- the entire point of content indirection is to offload this to a non-SIP carrier. 5) There is nothing mutually exclusive of content-indirection and MMS. Nor is there anything that compels one to use MMS for this task in the draft. It's simply outside the scope of this draft. 6) Is there something particularly non-concrete about the draft? ;-) 7) This mechanism is not tied to any particular architecture, though some architectures may have more pressing need for it than others. cheers, sean -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Cnaan Oded Sent: Monday, January 20, 2003 11:05 PM To: 'simple@ietf.org' Subject: [Simple] Content indirection - Uploading large messages The content-indirection draft (the latest I could find was draft-ietf-sipping-content-indirect-02.txt) describes how messages or notifications carry a URL in order to allow the UA to retrieve the (usually large) content over other transports (e.g., HTTP). The draft however does not specify how large content is uploaded from the UA to the server. Using HTTP per se is not sufficient for uploading messages over HTTP as there is some meta-data that needs to be attached to the document such as sender, recipient(s), message type etc. The MMS standard have already solved these details in their MM1 protocol (over HTTP as well). Note also that using the MESSAGE method is not a good practice as well as it would generate huge load on the CSCFs (in mobile networks that deploy IMS/MMD infrastructure), denying them from performing call control tasks. 1. How should large messages be sent from the UA to the server? any specific draft? 2. Does the SIMPLE WG intend to reuse the MM1 specifications or invent a new one? 3. What's the status of this work within the SIMPLE WG? Are there any concrete contributions? Thanks, Oded Cnaan Comverse ------_=_NextPart_001_01C2C132.9157DBD8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Content indirection - Uploading large = messages

Sean,

Thanks for the prompt reply.

You may be right that the details of how large = payloads are sent from the UA to the server (in case these are not the = same entities and that there is a network based server) are outside = SIMPLE scope but it seems to me that the first hurdle SIMPLE will face = would be -interoperability. If you leave this question open for = proprietary solutions, applications from different vendors will not be = able to co-exist on the same network. If you look at the WG charter, = you will find that "The IETF has committed to producing an = interoperable standard for these services ".

The charter also refers to RFC 2778 and CPIM which = require defining how messages are sent from UAs to servers, regardless = of their size.

Moreover, if you look at 3GPP requirements from = SIMPLE (e.g., draft-niemi-simple-im-wireless-reqs-00)  they = require that "The content size MUST NOT be limited by the Instant = Messaging, or message session protocols" - SIMPLE must be able to = specify how this is done.

I believe SIMPLE WG should define at least a = 'default' behavior for these cases, or refer to an external standard, = such as MM1.

Oded Cnaan


-----Original Message-----
From: Sean Olson [mailto:seancolson@yahoo.com]
Sent: Tuesday, January 21, 2003 9:46 AM
To: 'Cnaan Oded'; simple@ietf.org
Subject: RE: [Simple] Content indirection - = Uploading large messages


The draft intentionally does not address the how the = content is placed
on the content server to begin with.
That is a separate problem that has many disparate = solutions and does
not necessarily need to be standardized.
The interesting thing about standardizing the = content-indirection
mechanism is that it involves two SIP = entities
and directly impacts the SIP signaling. The transfer = of content, either
from the UA to the server, or between UAs
is best handled outside of SIP ... the very point of = the draft.

Some important things to note:

1) The "server" does not have to be = distinct from the UA. They can be
one in the same.
2) The URL does not have to be an HTTP URL, though = this will be probably
be one of the more common schemes used.
   For example, an LDAP URL might very be = appropriate for certain types
of content
3) HTTP is ideal for conveying meta-data about the = content it carries,
but that argument is best handled outside of = SIMPLE
4) It was never envisoned that MESSAGE would be used = to send these large
payloads -- the entire point of content
   indirection is to offload this to a = non-SIP carrier.
5) There is nothing mutually exclusive of = content-indirection and MMS.
Nor is there anything that compels one to use
   MMS for this task in the draft. It's = simply outside the scope of this
draft.
6) Is there something particularly non-concrete = about the draft? ;-)
7) This mechanism is not tied to any particular = architecture, though
some architectures may have more pressing need = for
   it than others.

cheers,
sean

-----Original Message-----
From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] = On Behalf Of
Cnaan Oded
Sent: Monday, January 20, 2003 11:05 PM
To: 'simple@ietf.org'
Subject: [Simple] Content indirection - Uploading = large messages

The content-indirection draft (the latest I could = find was
draft-ietf-sipping-content-indirect-02.txt) = describes how messages or
notifications carry a URL in order to allow the UA = to retrieve the
(usually large) content over other transports (e.g., = HTTP). The draft
however does not specify how large content is = uploaded from the UA to
the server.

Using HTTP per se is not sufficient for uploading = messages over HTTP as
there is some meta-data that needs to be attached to = the document such
as sender, recipient(s), message type etc. The MMS = standard have already
solved these details in their MM1 protocol (over = HTTP as well).

Note also that using the MESSAGE method is not a good = practice as well
as it would generate huge load on the CSCFs (in = mobile networks that
deploy IMS/MMD infrastructure), denying them from = performing call
control tasks.

1. How should large messages be sent from the UA to = the server? any
specific draft?
2. Does the SIMPLE WG intend to reuse the MM1 = specifications or invent a
new one?
3. What's the status of this work within the SIMPLE = WG? Are there any
concrete contributions?

Thanks,
Oded Cnaan
Comverse

------_=_NextPart_001_01C2C132.9157DBD8-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 21 04:56:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24689 for ; Tue, 21 Jan 2003 04:56:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LAEAL04076 for simple-archive@odin.ietf.org; Tue, 21 Jan 2003 05:14:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LAEAJ04073 for ; Tue, 21 Jan 2003 05:14:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24683 for ; Tue, 21 Jan 2003 04:56:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LAE3J04062; Tue, 21 Jan 2003 05:14:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LADQJ04042 for ; Tue, 21 Jan 2003 05:13:26 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24677 for ; Tue, 21 Jan 2003 04:55:26 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0LA17t03873 for ; Tue, 21 Jan 2003 12:01:07 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Jan 2003 11:58:50 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 21 Jan 2003 11:58:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C133.B211AF68" Subject: RE: [Simple] Content indirection - Uploading large messages Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7169@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Content indirection - Uploading large messages Thread-Index: AcLBMs/sUPSOeItcSiK7IzZ8qe1ucgAANGCQ To: , Cc: X-OriginalArrivalTime: 21 Jan 2003 09:58:50.0143 (UTC) FILETIME=[B276FAF0:01C2C133] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Jan 2003 11:58:49 +0200 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2C133.B211AF68 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please take a look at http://www.ietf.org/internet-drafts/draft-khartabil-sip-congestionsafe-ci= -01.txt I'm planning to update this to include a UA posting (eg: contents for = PUBLISH or MESSAGE). Regards, Hisham -----Original Message----- From: ext Cnaan Oded [mailto:Oded.Cnaan@comverse.com] Sent: Tuesday, January 21, 2003 11:51 AM To: simple@ietf.org Cc: Rapaport Orly Subject: RE: [Simple] Content indirection - Uploading large messages Sean,=20 Thanks for the prompt reply.=20 You may be right that the details of how large payloads are sent from = the UA to the server (in case these are not the same entities and that = there is a network based server) are outside SIMPLE scope but it seems = to me that the first hurdle SIMPLE will face would be -interoperability. = If you leave this question open for proprietary solutions, applications = from different vendors will not be able to co-exist on the same network. = If you look at the WG charter, you will find that "The IETF has = committed to producing an interoperable standard for these services ".=20 The charter also refers to RFC 2778 and CPIM which require defining how = messages are sent from UAs to servers, regardless of their size. Moreover, if you look at 3GPP requirements from SIMPLE (e.g., = draft-niemi-simple-im-wireless-reqs-00) they require that "The content = size MUST NOT be limited by the Instant Messaging, or message session = protocols" - SIMPLE must be able to specify how this is done. I believe SIMPLE WG should define at least a 'default' behavior for = these cases, or refer to an external standard, such as MM1. Oded Cnaan=20 -----Original Message-----=20 From: Sean Olson [ mailto:seancolson@yahoo.com]=20 Sent: Tuesday, January 21, 2003 9:46 AM=20 To: 'Cnaan Oded'; simple@ietf.org=20 Subject: RE: [Simple] Content indirection - Uploading large messages=20 The draft intentionally does not address the how the content is placed=20 on the content server to begin with.=20 That is a separate problem that has many disparate solutions and does=20 not necessarily need to be standardized.=20 The interesting thing about standardizing the content-indirection=20 mechanism is that it involves two SIP entities=20 and directly impacts the SIP signaling. The transfer of content, either=20 from the UA to the server, or between UAs=20 is best handled outside of SIP ... the very point of the draft.=20 Some important things to note:=20 1) The "server" does not have to be distinct from the UA. They can be=20 one in the same.=20 2) The URL does not have to be an HTTP URL, though this will be probably = be one of the more common schemes used.=20 For example, an LDAP URL might very be appropriate for certain types=20 of content=20 3) HTTP is ideal for conveying meta-data about the content it carries,=20 but that argument is best handled outside of SIMPLE=20 4) It was never envisoned that MESSAGE would be used to send these large = payloads -- the entire point of content=20 indirection is to offload this to a non-SIP carrier.=20 5) There is nothing mutually exclusive of content-indirection and MMS.=20 Nor is there anything that compels one to use=20 MMS for this task in the draft. It's simply outside the scope of this = draft.=20 6) Is there something particularly non-concrete about the draft? ;-)=20 7) This mechanism is not tied to any particular architecture, though=20 some architectures may have more pressing need for=20 it than others.=20 cheers,=20 sean=20 -----Original Message-----=20 From: simple-admin@ietf.org [ mailto:simple-admin@ietf.org] On Behalf Of = Cnaan Oded=20 Sent: Monday, January 20, 2003 11:05 PM=20 To: 'simple@ietf.org'=20 Subject: [Simple] Content indirection - Uploading large messages=20 The content-indirection draft (the latest I could find was=20 draft-ietf-sipping-content-indirect-02.txt) describes how messages or=20 notifications carry a URL in order to allow the UA to retrieve the=20 (usually large) content over other transports (e.g., HTTP). The draft=20 however does not specify how large content is uploaded from the UA to=20 the server.=20 Using HTTP per se is not sufficient for uploading messages over HTTP as=20 there is some meta-data that needs to be attached to the document such=20 as sender, recipient(s), message type etc. The MMS standard have already = solved these details in their MM1 protocol (over HTTP as well).=20 Note also that using the MESSAGE method is not a good practice as well=20 as it would generate huge load on the CSCFs (in mobile networks that=20 deploy IMS/MMD infrastructure), denying them from performing call=20 control tasks.=20 1. How should large messages be sent from the UA to the server? any=20 specific draft?=20 2. Does the SIMPLE WG intend to reuse the MM1 specifications or invent a = new one?=20 3. What's the status of this work within the SIMPLE WG? Are there any=20 concrete contributions?=20 Thanks,=20 Oded Cnaan=20 Comverse=20 ------_=_NextPart_001_01C2C133.B211AF68 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Content indirection - Uploading large = messages

Please take a look at

http://www.ietf.org/internet-drafts/draft-khartabil-sip-congestionsafe= -ci-01.txt

I'm planning to update this to include a UA posting (eg: contents for = PUBLISH=20 or MESSAGE).

Regards,

Hisham

-----Original Message-----
From: ext Cnaan Oded=20 [mailto:Oded.Cnaan@comverse.com]
Sent: Tuesday, January 21, = 2003=20 11:51 AM
To: simple@ietf.org
Cc: Rapaport=20 Orly
Subject: RE: [Simple] Content indirection - Uploading = large=20 messages

Sean,

Thanks for the prompt reply.

You may be right that the details of how large = payloads are=20 sent from the UA to the server (in case these are not the same = entities and=20 that there is a network based server) are outside SIMPLE scope but it = seems to=20 me that the first hurdle SIMPLE will face would be -interoperability. = If you=20 leave this question open for proprietary solutions, applications from=20 different vendors will not be able to co-exist on the same network. If = you=20 look at the WG charter, you will find that "The IETF has committed to=20 producing an interoperable standard for these services ".

The charter also refers to RFC 2778 and CPIM which = require=20 defining how messages are sent from UAs to servers, regardless of = their=20 size.

Moreover, if you look at 3GPP requirements from = SIMPLE (e.g.,=20 draft-niemi-simple-im-wireless-reqs-00)  they require that "The = content=20 size MUST NOT be limited by the Instant Messaging, or message session=20 protocols" - SIMPLE must be able to specify how this is = done.

I believe SIMPLE WG should define at least a = 'default'=20 behavior for these cases, or refer to an external standard, such as=20 MM1.

Oded Cnaan


-----Original Message-----
From: Sean=20 Olson [mailto:seancolson@yahoo.com]=20
Sent: Tuesday, January 21, 2003 9:46 AM =
To: 'Cnaan Oded'; simple@ietf.org
Subject: RE:=20 [Simple] Content indirection - Uploading large messages =


The draft intentionally does not address the how the = content=20 is placed
on the content server to begin = with.=20
That is a separate problem that has many disparate = solutions=20 and does
not necessarily need to be=20 standardized.
The interesting thing about=20 standardizing the content-indirection
mechanism is=20 that it involves two SIP entities
and = directly impacts=20 the SIP signaling. The transfer of content, either
from the UA to the server, or between UAs
is=20 best handled outside of SIP ... the very point of the draft. =

Some important things to note:

1) The "server" does not have to be distinct from = the UA. They=20 can be
one in the same.
2) The=20 URL does not have to be an HTTP URL, though this will be = probably=20
be one of the more common schemes used. =
   For example, an LDAP URL might very be = appropriate for=20 certain types
of content
3)=20 HTTP is ideal for conveying meta-data about the content it = carries,=20
but that argument is best handled outside of = SIMPLE=20
4) It was never envisoned that MESSAGE would be = used to send=20 these large
payloads -- the entire point of = content=20
   indirection is to offload this = to a=20 non-SIP carrier.
5) There is nothing = mutually=20 exclusive of content-indirection and MMS.
Nor is there=20 anything that compels one to use
   MMS for=20 this task in the draft. It's simply outside the scope of this =
draft.
6) Is there something = particularly=20 non-concrete about the draft? ;-)
7) This = mechanism is=20 not tied to any particular architecture, though
some=20 architectures may have more pressing need for
   it than others.

cheers,
sean

-----Original Message-----
From:=20 simple-admin@ietf.org [mailto:simple-admin@ietf.org] = On=20 Behalf Of
Cnaan Oded
Sent:=20 Monday, January 20, 2003 11:05 PM
To:=20 'simple@ietf.org'
Subject: [Simple] Content=20 indirection - Uploading large messages

The content-indirection draft (the latest I could = find=20 was
draft-ietf-sipping-content-indirect-02.txt)=20 describes how messages or
notifications = carry a URL in=20 order to allow the UA to retrieve the
(usually large)=20 content over other transports (e.g., HTTP). The draft
however does not specify how large content is uploaded from = the UA=20 to
the server.

Using HTTP per se is not sufficient for uploading = messages=20 over HTTP as
there is some meta-data that = needs to be=20 attached to the document such
as sender, = recipient(s),=20 message type etc. The MMS standard have already
solved=20 these details in their MM1 protocol (over HTTP as well).

Note also that using the MESSAGE method is not a = good practice=20 as well
as it would generate huge load on = the CSCFs=20 (in mobile networks that
deploy IMS/MMD=20 infrastructure), denying them from performing call
control tasks.

1. How should large messages be sent from the UA to = the=20 server? any
specific draft?
2.=20 Does the SIMPLE WG intend to reuse the MM1 specifications or invent = a=20
new one?
3. What's the = status of this=20 work within the SIMPLE WG? Are there any
concrete=20 contributions?

Thanks,
Oded Cnaan =
Comverse

------_=_NextPart_001_01C2C133.B211AF68-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 21 11:32:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04315 for ; Tue, 21 Jan 2003 11:32:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LGnp530494 for simple-archive@odin.ietf.org; Tue, 21 Jan 2003 11:49:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LGnpJ30491 for ; Tue, 21 Jan 2003 11:49:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04304 for ; Tue, 21 Jan 2003 11:31:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LGnXJ30459; Tue, 21 Jan 2003 11:49:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LGmLJ30406 for ; Tue, 21 Jan 2003 11:48:21 -0500 Received: from auemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04266 for ; Tue, 21 Jan 2003 11:30:13 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0LGXa424425; Tue, 21 Jan 2003 11:33:36 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA29789; Tue, 21 Jan 2003 10:33:36 -0600 (CST) Message-ID: <3E2D765E.6030403@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Extending for presence References: <2038BCC78B1AD641891A0D1AE133DBB7FE7162@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Jan 2003 10:33:34 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > I guess the real question is: Can the device be controlled by presence > state? or it like just like Paul's example; you hang a do-not-disturb > sign on the door and hope for the best? I believe that a person should have the option of controlling *their* own device through *their* presence state. That is, if I actively set my presence/availability state to DND, I would like the following sequence of events to happen: 1) My status is set to DND and all watchers are informed. The presentities associated with the watchers see a big "DND" status next to my icon on their UA. 2) My presence document is updated so that all my interactive devices are CLOSED. 3) Either a message is sent to all my interactive devices to stop accepting sessions (currently not possible), or a script is uploaded to my proxy server redirecting all communication sessions to a recorder (definitely possible). Arguably, the reason we cannot do (3) currently is that we cannot control each device we own -- we cannot stop the PSTN phone from ringing (short of plugging it out of the wall), nor can we stop the cell phone from paging me (again, short of powering it down). I believe it is this behavior that is leading us down the path of equating DND with "hanging DND on the door and hoping for the best". In a network where all the devices we own are far more controllable, we can do better. I think the power of the simple WG is the use of SIP as a unifying protocol -- SIP drives all communication aspects. Other IM/P systems like Yahoo! or Jabber do not aim to tie all communication aspects under one protocol. Thus IM is done using native protocols, while phone calls are completed using (probably non-SIP) gateways to the PSTN. This leads to cases where the status of the presentity itself is at odds with the status of its devices (i.e. status of presentity is DND but it still answers the PSTN phone). DND has received a lot of air-time, and Jonathan wrote: > ON DND > > DND has received a bit of discussion on this thread. To be honest, I am > at a loss as to why it is not really a combination of two things: (1) > basic status of CLOSED for each device, and (2) a "task" of "do not > disturb". Paul has defined these tasks as things that describe what the > presentity is doing, such as "out-to-lunch". "do not disturb" seems like > another example. > > It is the usage of the basic status of CLOSED that really captures the > essence of DND - that attempts to contact with that user across their > devices will fail. I don't think the representation of DND is what we are arguing; it is the semantics. DND implies to me that all *my* devices should honor my will and not even alert me. But of course, there maybe cases where the department secretary or the CEO should be able to get to me. Given today's disparate networks, I cannot impose my will on my devices. But should we preclude us from doing so for tomorrow's networks where it maybe more possible to control the device in a far more discrete manner? Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 21 11:45:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04735 for ; Tue, 21 Jan 2003 11:45:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LH3Bc31121 for simple-archive@odin.ietf.org; Tue, 21 Jan 2003 12:03:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LH3BJ31118 for ; Tue, 21 Jan 2003 12:03:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04731 for ; Tue, 21 Jan 2003 11:45:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LH33J31072; Tue, 21 Jan 2003 12:03:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LH2tJ31041 for ; Tue, 21 Jan 2003 12:02:55 -0500 Received: from auemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04711 for ; Tue, 21 Jan 2003 11:44:47 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0LGmA401624; Tue, 21 Jan 2003 11:48:10 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA07477; Tue, 21 Jan 2003 10:48:09 -0600 (CST) Message-ID: <3E2D79C8.7090309@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E231E4B.5090606@lucent.com> <3E253030.5060409@dynamicsoft.com> <3E258ADB.70204@cisco.com> <3E25956B.5050006@lucent.com> <00e701c2bccd$73a5f9d0$40071e0a@myopwv.com> <3E25D681.2050507@cisco.com> <3E2693D1.4030404@dynamicsoft.com> <3E27253F.5060802@cisco.com> <3E273658.60504@lucent.com> <3E2741F8.70405@cisco.com> <3E283F85.8060903@lucent.com> <3E285BA7.7080102@cisco.com> <3E2C688C.2030907@dynamicsoft.com> <3E2C796B.3000104@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Jan 2003 10:48:08 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: [...] > I guess my personal preference is to go ahead and define hierarchies. I'll second that. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 21 12:48:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06648 for ; Tue, 21 Jan 2003 12:48:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LI6Vr03622 for simple-archive@odin.ietf.org; Tue, 21 Jan 2003 13:06:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LI6VJ03619 for ; Tue, 21 Jan 2003 13:06:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06629 for ; Tue, 21 Jan 2003 12:48:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LI6QJ03610; Tue, 21 Jan 2003 13:06:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LI5AJ03560 for ; Tue, 21 Jan 2003 13:05:10 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06615 for ; Tue, 21 Jan 2003 12:47:00 -0500 (EST) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0LHoSYH005015; Tue, 21 Jan 2003 12:50:28 -0500 (EST) Message-ID: <3E2D87CE.5030808@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Steven M. Bellovin" CC: mankin@psg.com, simple@ietf.org, =?ISO-8859-1?Q?Patrik_F=C3=A4lts?= =?ISO-8859-1?Q?tr=C3=B6m?= References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Discuss on SIMPLE doc Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Jan 2003 12:47:58 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This note is in response to comments raised by Steve Bellovin during the IESG review of the simple specs. Steve, thanks for the comments. Responses inline. > ------- Forwarded Message > > From: "Steven M. Bellovin" > To: IESG Secretary > Cc: Internet Engineering Steering Group > Subject: Re: Evaluation: draft-ietf-simple-winfo-package - A Session Initiation Protocol (SIP)Event Template-Package for Watcher Information to Proposed Standard > > draft-ietf-simple-presence-09.txt: > 6.3 should say "some other document will define > a filter language". The current language is too vague. (This > can be fixed with an RFC editor's note.) It looks like I need to rev these for other comments too. So, I changed to text to be more specific. Here is how that paragraph reads: One type of body that can be included in a SUBSCRIBE request is a filter document. These filters request that only certain presence events generate notifications, or would ask for a restriction on the set of data returned in {\NOTIFY} requests. For example, a presence filter might specify that the notifications should only be generated when the status of the user's instant inbox \citenonnorm{rfc2778} changes. It might also say that the content of these notifications should only contain the status of the instant inbox. Filter documents are not specified in this document, and at the time of writing, are expected to be the subject of future standardization activity. > > 6.6.1 -- which authentication methods are mandatory to > implement? Ditto 9.2 and 9.4. Also see 6.2 in > draft-ietf-simple-winfo-package-04.txt RFC 3261 mandates digest for authentication purposes. I've added a sentence to 6.6.1 which states: Note that digest is mandatory to implement, as specified in RFC 3261. Regarding 9.2 (which discusses autehntication and message integrity) and 9.4 (which discusses replay), digest can address the authentication and replay issues (its not perfect of course). Do you feel it needs to state baseline mechanisms beyond those specified in RFC 3261? It was always my assumption that it did not, which is why there are no normative statements about security mechanisms. > > It appears to be possible to probe the name space to see what > user names are valid. Is this a concern? It doesn't seem any more of an issue than it would be in any other application protocol. I don't recall it being raised as a concern specifically. Note that its not specific to presence. The presence behavior directly inherits from baseline sip. In baseline SIP you'd get a 404 response if the user is not valid in that domain. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 21 15:18:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10946 for ; Tue, 21 Jan 2003 15:18:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LKZlx13990 for simple-archive@odin.ietf.org; Tue, 21 Jan 2003 15:35:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LKZkJ13987 for ; Tue, 21 Jan 2003 15:35:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10935 for ; Tue, 21 Jan 2003 15:17:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LKZWJ13967; Tue, 21 Jan 2003 15:35:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LKYgJ13913 for ; Tue, 21 Jan 2003 15:34:42 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10915 for ; Tue, 21 Jan 2003 15:16:29 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA18780; Tue, 21 Jan 2003 15:19:54 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA17298; Tue, 21 Jan 2003 15:19:54 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 15:19:54 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D33@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Vijay K. Gurbani'" , hisham.khartabil@nokia.com Cc: jdrosen@dynamicsoft.com, simple@ietf.org Subject: RE: [Simple] Extending for presence MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Jan 2003 15:19:51 -0500 I have a problem with attaching too much significance to DND. DND is one point on a spectrum from Available to On Vacation. (Hmmm, maybe we could have "deceased" or "No longer employed here") The difference between DND and Out to Lunch is pretty small - if you try communicating with me, you are not likely to get me. All of these states are how unavailable I am. We've struggled a bit here with that, because we find people often don't manually change their presence state to maintain validity. We had particular problems with "Back in 5 minutes" or variations on that. Once you are past "Available", the differences reduce to: how your system will respond, which for us depends on who you are. This is not a standardization issue. what time expectation callers (IM'ers?) have for when you will be available. This is also not a standardization issue, except that we are going to agree on a reasonable set of tags I worry about making everything past "Available" some version of "Closed". It's that step that gets us into the dilemma of "closed for voice, open for IM". It also precludes my local system from saving an IM sent for later review, or forwarding a call to voicemail. To me, presence is guidance to the caller, and state for my local devices to use when requests for calls arrive. I don't want it to be state for remote devices, or at least, I want to encourage a lot of user interaction at the caller. If my spouse sees I'm in DND, and calls anyway, I want that call to go through. My stock broker may not get that behavior. I don't want my wife's IM client to prevent her from sending me a message if I'm in DND. > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > Sent: Tuesday, January 21, 2003 11:34 AM > To: hisham.khartabil@nokia.com > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: Re: [Simple] Extending for presence > > > hisham.khartabil@nokia.com wrote: > > I guess the real question is: Can the device be controlled > by presence > > state? or it like just like Paul's example; you hang a > do-not-disturb > > sign on the door and hope for the best? > > I believe that a person should have the option of controlling *their* > own device through *their* presence state. That is, if I actively set > my presence/availability state to DND, I would like the following > sequence of events to happen: > > 1) My status is set to DND and all watchers are informed. The > presentities associated with the watchers see a big "DND" > status next to my icon on their UA. > 2) My presence document is updated so that all my > interactive devices > are CLOSED. > 3) Either a message is sent to all my interactive devices to stop > accepting sessions (currently not possible), or a script is > uploaded to my proxy server redirecting all > communication sessions > to a recorder (definitely possible). > > Arguably, the reason we cannot do (3) currently is that we cannot > control each device we own -- we cannot stop the PSTN phone from > ringing (short of plugging it out of the wall), nor can we stop the > cell phone from paging me (again, short of powering it down). I > believe it is this behavior that is leading us down the path of > equating DND with "hanging DND on the door and hoping for the best". > > In a network where all the devices we own are far more > controllable, we > can do better. I think the power of the simple WG is the use of SIP > as a unifying protocol -- SIP drives all communication aspects. Other > IM/P systems like Yahoo! or Jabber do not aim to tie all communication > aspects under one protocol. Thus IM is done using native protocols, > while phone calls are completed using (probably non-SIP) > gateways to the > PSTN. This leads to cases where the status of the presentity itself > is at odds with the status of its devices (i.e. status of > presentity is > DND but it still answers the PSTN phone). > > DND has received a lot of air-time, and Jonathan wrote: > > ON DND > > > > DND has received a bit of discussion on this thread. To be > honest, I am > > at a loss as to why it is not really a combination of two > things: (1) > > basic status of CLOSED for each device, and (2) a "task" of "do not > > disturb". Paul has defined these tasks as things that > describe what the > > presentity is doing, such as "out-to-lunch". "do not > disturb" seems like > > another example. > > > > It is the usage of the basic status of CLOSED that really > captures the > > essence of DND - that attempts to contact with that user > across their > > devices will fail. > > I don't think the representation of DND is what we are arguing; it is > the semantics. DND implies to me that all *my* devices should honor > my will and not even alert me. But of course, there maybe cases where > the department secretary or the CEO should be able to get to > me. Given > today's disparate networks, I cannot impose my will on my > devices. But > should we preclude us from doing so for tomorrow's networks where it > maybe more possible to control the device in a far more > discrete manner? > > Thanks, > > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Wireless Networks Group/Internet Software and Services > Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 0216 > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 21 15:47:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11600 for ; Tue, 21 Jan 2003 15:47:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LL5EQ15702 for simple-archive@odin.ietf.org; Tue, 21 Jan 2003 16:05:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LL5EJ15699 for ; Tue, 21 Jan 2003 16:05:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11592 for ; Tue, 21 Jan 2003 15:47:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LL56J15683; Tue, 21 Jan 2003 16:05:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LL4AJ15620 for ; Tue, 21 Jan 2003 16:04:10 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11574 for ; Tue, 21 Jan 2003 15:45:56 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0LKo1dW014748; Tue, 21 Jan 2003 15:50:02 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY28014; Tue, 21 Jan 2003 15:54:16 -0500 (EST) Message-ID: <3E2DB249.60909@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Vijay K. Gurbani'" , hisham.khartabil@nokia.com, jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D33@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Jan 2003 15:49:13 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Brian, You haven't spoken for awhile. Good to hear from somebody else again. I think there may still be some different expectations implied in your response than what my expectations are. Lets try to clarify. inline... Paul Rosen, Brian wrote: > I have a problem with attaching too much significance to DND. > DND is one point on a spectrum from Available to On Vacation. > (Hmmm, maybe we could have "deceased" or "No longer employed here") > The difference between DND and Out to Lunch is pretty small - > if you try communicating with me, you are not likely to get me. > All of these states are how unavailable I am. I agree with you on this. At least as far as *presence status* is concerned these are pretty similar to me. I think the difference is expectations about the behavior of the receiving device when DND status has been set. I think many people believe the act of setting state to DND not only affects the presence state, but also changes the device behavior so it responds with an error rather than alerting. I am inclined to agree that UAs might do this, but consider it out of scope when defining PIDF extensions. > > We've struggled a bit here with that, because we find people > often don't manually change their presence state to maintain > validity. We had particular problems with "Back in 5 minutes" > or variations on that. Yeah. "Back in 5 minutes" is really bad. "Back at " is better, because at least clients know when the status is bogus. A smart UA would manage this. When the expected return time passes, it would change the status to "Expected back momentarily" or simply "unavailable". > > Once you are past "Available", the differences reduce to: > how your system will respond, which for us depends on > who you are. This is not a standardization issue. > what time expectation callers (IM'ers?) have for when > you will be available. This is also not > a standardization issue, except that we are > going to agree on a reasonable set of tags > > I worry about making everything past "Available" some version of > "Closed". It's that step that gets us into the dilemma of > "closed for voice, open for IM". It also precludes my local > system from saving an IM sent for later review, or forwarding > a call to voicemail. Yes, we need more than CLOSED for "not Available". That is why I have explicitly tried to find ways to encode things like: available for IM now, available for voice & IM eventually. This is also why I have tried to provide for operational status like active/inactive vs declarative status like available/unavailable/... > > To me, presence is guidance to the caller, and state for my > local devices to use when requests for calls arrive. Here we differ. I don't see presence as a guide for my devices. Rather I see my local devices as responsible for setting my presence status. > I don't > want it to be state for remote devices, or at least, I want > to encourage a lot of user interaction at the caller. I want user interaction if that is what the user wants. But I also think automated decisions about when to call, or what device to call, are an important feature of presence. It should be possible to build a proxy that directs calls to devices based on presence, rather than based on a registry and location service. > If my spouse sees I'm in DND, and calls anyway, I want that > call to go through. My stock broker may not get that behavior. > I don't want my wife's IM client to prevent her from sending me > a message if I'm in DND. I think I agree with you on this. I don't think your wife's IM client should prohibit her from sending, but it might try to discourage it, and make her go through some override action. Obviously the details are application issues. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 21 16:06:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11996 for ; Tue, 21 Jan 2003 16:06:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LLOAX17155 for simple-archive@odin.ietf.org; Tue, 21 Jan 2003 16:24:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLO9J17152 for ; Tue, 21 Jan 2003 16:24:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11988 for ; Tue, 21 Jan 2003 16:05:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLO2J17143; Tue, 21 Jan 2003 16:24:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLNmJ17124 for ; Tue, 21 Jan 2003 16:23:48 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11985 for ; Tue, 21 Jan 2003 16:05:34 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA21231; Tue, 21 Jan 2003 16:08:59 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA24528; Tue, 21 Jan 2003 16:08:59 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 16:09:00 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D36@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Paul Kyzivat'" Cc: "'Vijay K. Gurbani'" , hisham.khartabil@nokia.com, jdrosen@dynamicsoft.com, simple@ietf.org Subject: RE: [Simple] Extending for presence MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Jan 2003 16:08:59 -0500 > Yes, we need more than CLOSED for "not Available". > > That is why I have explicitly tried to find ways to encode > things like: > available for IM now, available for voice & IM eventually. > > This is also why I have tried to provide for operational status like > active/inactive vs declarative status like available/unavailable/... Okay, but I think we need to standardize tags so that both ends have the same implications. We need to agree that we have a state for "On the phone" vs "Busy". The latter may imply the former, but not necessarily the other way around. > > > > > To me, presence is guidance to the caller, and state for my > > local devices to use when requests for calls arrive. > > Here we differ. I don't see presence as a guide for my > devices. Rather I > see my local devices as responsible for setting my presence status. Well, I agree that if you have an activity detector, that your local presentity client can set your status to Active. What I meant was that my incoming sip proxy can use my presence to guide forwarding decisions. This lets calls from my wife come through if I'm in DND. If my presence system and my phone system are one and the same, that could be internally implemented. If they are not, then my sip proxy subscribes as a watcher to my presence system. Either way, presence becomes state to the incoming proxy server. Brian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 21 16:28:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12479 for ; Tue, 21 Jan 2003 16:28:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LLjhP18695 for simple-archive@odin.ietf.org; Tue, 21 Jan 2003 16:45:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLjhJ18692 for ; Tue, 21 Jan 2003 16:45:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12471 for ; Tue, 21 Jan 2003 16:27:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLjXJ18678; Tue, 21 Jan 2003 16:45:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLi1J18611 for ; Tue, 21 Jan 2003 16:44:01 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12425 for ; Tue, 21 Jan 2003 16:25:48 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h0LLSv824640; Tue, 21 Jan 2003 21:28:57 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 16:31:39 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214D28@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Paul Kyzivat'" , Jonathan Rosenberg Cc: simple@ietf.org Subject: hierarchies (was RE: [Simple] Extending for presence) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Jan 2003 16:31:38 -0500 I am wary of explicitly defining hierarchies by having an extension to PIDF that allows, essentially, tuples within tuples. I am less averse to the concept that tuples representing a group might each contain a contact address with a pres: URI where the presence of that group member might be learned. Indirection rather than hierarchy. Either way, there will be a significant burden on the watcher to figure out whether or not the group as a whole should be considered OPEN (considered as an absolute or through some quantification of partial OPENness). Using indirection allows the presence composition function to be more easily distributed, I think. If several members of a group use, say, different presence services (and I see no reason to rule that out), hierarchies would seem to imply a publication interface between their various presence services and some sort of group aggregator. Various sorts of policy management from the presentity perspective look more complex to me in that architecture. In very large groups, I would imagine it is also better for a watcher's client to decide how many members of the group it would like evaluate, rather than receiving a single massive PIDF document from the presentity. Jon Peterson NeuStar, Inc. [snip] > This could perhaps be represented by specifying three tuples, each > containing a pres: url. But that is a bit of a stretch. This is the case > that seems to cry out for hierarchical tuples. > > I guess my personal preference is to go ahead and define hierarchies. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 21 16:48:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13088 for ; Tue, 21 Jan 2003 16:48:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LM6EM20037 for simple-archive@odin.ietf.org; Tue, 21 Jan 2003 17:06:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LM6EJ20034 for ; Tue, 21 Jan 2003 17:06:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13082 for ; Tue, 21 Jan 2003 16:48:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LM65J20023; Tue, 21 Jan 2003 17:06:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LM56J19992 for ; Tue, 21 Jan 2003 17:05:06 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13066 for ; Tue, 21 Jan 2003 16:46:52 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h0LLo0825119; Tue, 21 Jan 2003 21:50:00 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 16:52:42 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214D29@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Vijay K. Gurbani'" , hisham.khartabil@nokia.com Cc: jdrosen@dynamicsoft.com, simple@ietf.org Subject: dnd (was RE: [Simple] Extending for presence) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Jan 2003 16:52:41 -0500 I think in Mr. Gurbani's argument below I see some requirements for our forthcoming presence extensions, and some unrelated requirements for UA/proxy behavior that is integrated with the setting of particular presence states. It is clear that inspecting a PIDF document is not the only way to learn someone's contact information, and that not everyone who has your contact information will subscribe to your presence. People may attempt to initiate telephone sessions with my SIP AoR regardless of whether or not I am publishing a 'DND' presence, or even if my state is just 'CLOSED'. In that sense, publishing 'DND' alone is not enough, and integrating this publication with appropriate proxy server and UA behavior (rejecting calls as needed, etc) seems like a logical next step. However, I don't see how this requirement affects the work at hand - the question of how we structure PIDF documents for SIMPLE. Personally, I have a hard time seeing why I would want to publish 'DND' as a presence instead of 'CLOSED'. I agree with Mr. Khartabil that presence should be customizable for various watchers - the requirements of RFC2779 are very friendly to selectively revealing your 'true' presence. If I want some set of preferred watchers to be able to contact me, I should show them a state of 'OPEN', and show everyone else a state of 'CLOSED'. 'DND' seems to be a form of impolite blocking - I'm here but I don't want to talk to you. Why would I ever want to send that instead of 'CLOSED', which communicates that I am unreachable? I think it is very limiting to assume that a presentity has one and only one true presence state that it reveals to all watchers. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > Sent: Tuesday, January 21, 2003 8:34 AM > To: hisham.khartabil@nokia.com > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: Re: [Simple] Extending for presence > > > hisham.khartabil@nokia.com wrote: > > I guess the real question is: Can the device be controlled > by presence > > state? or it like just like Paul's example; you hang a > do-not-disturb > > sign on the door and hope for the best? > > I believe that a person should have the option of controlling *their* > own device through *their* presence state. That is, if I actively set > my presence/availability state to DND, I would like the following > sequence of events to happen: > > 1) My status is set to DND and all watchers are informed. The > presentities associated with the watchers see a big "DND" > status next to my icon on their UA. > 2) My presence document is updated so that all my > interactive devices > are CLOSED. > 3) Either a message is sent to all my interactive devices to stop > accepting sessions (currently not possible), or a script is > uploaded to my proxy server redirecting all > communication sessions > to a recorder (definitely possible). > > Arguably, the reason we cannot do (3) currently is that we cannot > control each device we own -- we cannot stop the PSTN phone from > ringing (short of plugging it out of the wall), nor can we stop the > cell phone from paging me (again, short of powering it down). I > believe it is this behavior that is leading us down the path of > equating DND with "hanging DND on the door and hoping for the best". > > In a network where all the devices we own are far more > controllable, we > can do better. I think the power of the simple WG is the use of SIP > as a unifying protocol -- SIP drives all communication aspects. Other > IM/P systems like Yahoo! or Jabber do not aim to tie all communication > aspects under one protocol. Thus IM is done using native protocols, > while phone calls are completed using (probably non-SIP) > gateways to the > PSTN. This leads to cases where the status of the presentity itself > is at odds with the status of its devices (i.e. status of > presentity is > DND but it still answers the PSTN phone). > > DND has received a lot of air-time, and Jonathan wrote: > > ON DND > > > > DND has received a bit of discussion on this thread. To be > honest, I am > > at a loss as to why it is not really a combination of two > things: (1) > > basic status of CLOSED for each device, and (2) a "task" of "do not > > disturb". Paul has defined these tasks as things that > describe what the > > presentity is doing, such as "out-to-lunch". "do not > disturb" seems like > > another example. > > > > It is the usage of the basic status of CLOSED that really > captures the > > essence of DND - that attempts to contact with that user > across their > > devices will fail. > > I don't think the representation of DND is what we are arguing; it is > the semantics. DND implies to me that all *my* devices should honor > my will and not even alert me. But of course, there maybe cases where > the department secretary or the CEO should be able to get to > me. Given > today's disparate networks, I cannot impose my will on my > devices. But > should we preclude us from doing so for tomorrow's networks where it > maybe more possible to control the device in a far more > discrete manner? > > Thanks, > > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Wireless Networks Group/Internet Software and Services > Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 0216 > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 21 17:06:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13446 for ; Tue, 21 Jan 2003 17:06:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LMOAD21324 for simple-archive@odin.ietf.org; Tue, 21 Jan 2003 17:24:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LMOAJ21321 for ; Tue, 21 Jan 2003 17:24:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13439 for ; Tue, 21 Jan 2003 17:05:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LMO2J21312; Tue, 21 Jan 2003 17:24:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LMNMJ21295 for ; Tue, 21 Jan 2003 17:23:22 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13419 for ; Tue, 21 Jan 2003 17:05:08 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA24119; Tue, 21 Jan 2003 17:08:31 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA03365; Tue, 21 Jan 2003 17:08:26 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 17:08:27 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D3B@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Peterson, Jon'" , "'Vijay K. Gurbani'" , hisham.khartabil@nokia.com Cc: jdrosen@dynamicsoft.com, simple@ietf.org Subject: RE: dnd (was RE: [Simple] Extending for presence) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Jan 2003 17:08:26 -0500 The reason you want a rich sense of presence is because the watcher needs the same vocabulary as the presentity to determine whether to initiate communication. If you set yourself to DND, and I am your supervisor, I may act differently than if you set your state to "Vacation". It is not necessary for either end to have any automated behavior, but they could. What is necessary is that there is no loss of information when coupling my presentity system to your watcher. Check the prior exchange between Paul and I on why CLOSED is not appropriate. I am not CLOSED if I am in DND. I may defer or forward communications you send to me. It is up to you to decide if you will initiate communications if I am in DND. It is up to me to decide if I will accept a communication from you if I am in DND. It is necessary for me to communicate to you that I am in DND, and not CLOSED. That is why we need agreement on a range of states other than Open/Closed. Brian > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Tuesday, January 21, 2003 4:53 PM > To: 'Vijay K. Gurbani'; hisham.khartabil@nokia.com > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: dnd (was RE: [Simple] Extending for presence) > > > > I think in Mr. Gurbani's argument below I see some > requirements for our > forthcoming presence extensions, and some unrelated requirements for > UA/proxy behavior that is integrated with the setting of > particular presence > states. > > It is clear that inspecting a PIDF document is not the only > way to learn > someone's contact information, and that not everyone who has > your contact > information will subscribe to your presence. People may > attempt to initiate > telephone sessions with my SIP AoR regardless of whether or not I am > publishing a 'DND' presence, or even if my state is just > 'CLOSED'. In that > sense, publishing 'DND' alone is not enough, and integrating this > publication with appropriate proxy server and UA behavior > (rejecting calls > as needed, etc) seems like a logical next step. However, I > don't see how > this requirement affects the work at hand - the question of > how we structure > PIDF documents for SIMPLE. > > Personally, I have a hard time seeing why I would want to > publish 'DND' as a > presence instead of 'CLOSED'. I agree with Mr. Khartabil that presence > should be customizable for various watchers - the > requirements of RFC2779 > are very friendly to selectively revealing your 'true' > presence. If I want > some set of preferred watchers to be able to contact me, I > should show them > a state of 'OPEN', and show everyone else a state of > 'CLOSED'. 'DND' seems > to be a form of impolite blocking - I'm here but I don't want > to talk to > you. Why would I ever want to send that instead of 'CLOSED', which > communicates that I am unreachable? I think it is very > limiting to assume > that a presentity has one and only one true presence state > that it reveals > to all watchers. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > > Sent: Tuesday, January 21, 2003 8:34 AM > > To: hisham.khartabil@nokia.com > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > Subject: Re: [Simple] Extending for presence > > > > > > hisham.khartabil@nokia.com wrote: > > > I guess the real question is: Can the device be controlled > > by presence > > > state? or it like just like Paul's example; you hang a > > do-not-disturb > > > sign on the door and hope for the best? > > > > I believe that a person should have the option of > controlling *their* > > own device through *their* presence state. That is, if I > actively set > > my presence/availability state to DND, I would like the following > > sequence of events to happen: > > > > 1) My status is set to DND and all watchers are informed. The > > presentities associated with the watchers see a big "DND" > > status next to my icon on their UA. > > 2) My presence document is updated so that all my > > interactive devices > > are CLOSED. > > 3) Either a message is sent to all my interactive > devices to stop > > accepting sessions (currently not possible), or a script is > > uploaded to my proxy server redirecting all > > communication sessions > > to a recorder (definitely possible). > > > > Arguably, the reason we cannot do (3) currently is that we cannot > > control each device we own -- we cannot stop the PSTN phone from > > ringing (short of plugging it out of the wall), nor can we stop the > > cell phone from paging me (again, short of powering it down). I > > believe it is this behavior that is leading us down the path of > > equating DND with "hanging DND on the door and hoping for the best". > > > > In a network where all the devices we own are far more > > controllable, we > > can do better. I think the power of the simple WG is the use of SIP > > as a unifying protocol -- SIP drives all communication > aspects. Other > > IM/P systems like Yahoo! or Jabber do not aim to tie all > communication > > aspects under one protocol. Thus IM is done using native protocols, > > while phone calls are completed using (probably non-SIP) > > gateways to the > > PSTN. This leads to cases where the status of the presentity itself > > is at odds with the status of its devices (i.e. status of > > presentity is > > DND but it still answers the PSTN phone). > > > > DND has received a lot of air-time, and Jonathan wrote: > > > ON DND > > > > > > DND has received a bit of discussion on this thread. To be > > honest, I am > > > at a loss as to why it is not really a combination of two > > things: (1) > > > basic status of CLOSED for each device, and (2) a "task" > of "do not > > > disturb". Paul has defined these tasks as things that > > describe what the > > > presentity is doing, such as "out-to-lunch". "do not > > disturb" seems like > > > another example. > > > > > > It is the usage of the basic status of CLOSED that really > > captures the > > > essence of DND - that attempts to contact with that user > > across their > > > devices will fail. > > > > I don't think the representation of DND is what we are > arguing; it is > > the semantics. DND implies to me that all *my* devices should honor > > my will and not even alert me. But of course, there maybe > cases where > > the department secretary or the CEO should be able to get to > > me. Given > > today's disparate networks, I cannot impose my will on my > > devices. But > > should we preclude us from doing so for tomorrow's networks where it > > maybe more possible to control the device in a far more > > discrete manner? > > > > Thanks, > > > > - vijay > > -- > > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > > Wireless Networks Group/Internet Software and Services > > Lucent Technologies/Bell Labs Innovations, 2000 Lucent > Lane, Rm 6G-440 > > Naperville, Illinois 60566 Voice: +1 630 224 0216 > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 21 17:34:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14140 for ; Tue, 21 Jan 2003 17:34:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LMqen22977 for simple-archive@odin.ietf.org; Tue, 21 Jan 2003 17:52:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LMqeJ22974 for ; Tue, 21 Jan 2003 17:52:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14134 for ; Tue, 21 Jan 2003 17:34:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LMqSJ22965; Tue, 21 Jan 2003 17:52:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LMpTJ22940 for ; Tue, 21 Jan 2003 17:51:29 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14122 for ; Tue, 21 Jan 2003 17:33:14 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h0LMaG827047; Tue, 21 Jan 2003 22:36:16 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 17:38:57 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214D2A@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Jonathan Rosenberg'" , Paul Kyzivat Cc: simple@ietf.org Subject: quantifying activity (was RE: [Simple] Extending for pr esence) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Jan 2003 17:38:56 -0500 I do think that abstracting activity from any particular manner of assessment is interesting and valuable, though undoubtably somewhat challenging (it would be tough to come up with a formula for evaluating whether I am more present on my telephone than my PC when the two use different metrics). I am a little hesitant to tackle this in our initial iteration of this work. If we want a bucket for this in the current document, though, I wonder if the relative 'priority' attribute of elements, which is already specified in PIDF, would be a good place for quantified activity information to be recorded. Presumably, one use of activity information would be to discover the best contact in a set; it might be confusing to have a separate parameter for this that conflicts with the existing priority parameter in PIDF. It also already has the connotation that it can be set manually. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, January 20, 2003 1:22 PM > To: Paul Kyzivat > Cc: simple@ietf.org > Subject: Re: [Simple] Extending for presence > [snip] > > ON ACTIVITY > > I'd next like to comment on what you call "activity". I think there is a > need for some type of standardization to support this concept. There are > several different ways in which the concept can be quantified: > > * the amount of TIME since the presentity last interacted > with the device > * the physical DISTANCE of the presentity from the device > * the PROBABILITY that a communications request to the device will be > answered by the presentity > > I think existing IM systems very much rely on the TIME definition. > However, in my experience that definition is heavily tied to the concept > of a PC application. On a cell phone, where the user normally does not > interact with the device continously, this tends to a poor definition. > For cell phones, the DISTANCE is a better measure, but even that is not > neccesarily a good one. The phone may be near me, but its tucked away > into a laptop bag and so I really am idle with respect to it, since I > can't hear it or reach it. > > Arguably, one approach is to separate the means for measuring "activity" > or "idleness" from its representation. Using something like a > probability, for example, would allow the metric to work across devices, > and for it to be measured differently for different devices. > > Another issue to be factored into the decision about how to represent > idleness is how frequently it needs to be reported to the watcher in > order to be useful. A time-based measure has the nice benefit that the > watcher can continously know how long the presentity has been idle, > simply by conveying the time of last activity in the presence > notifications. > > One final point on activity. Some have stated that the defining > characteristic of this status is that it is implicitly computed by the > system. I disagree. I think it may be perfectly valid to set > it explicitly. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 21 18:45:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15369 for ; Tue, 21 Jan 2003 18:45:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0M03Vx26625 for simple-archive@odin.ietf.org; Tue, 21 Jan 2003 19:03:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M03VJ26622 for ; Tue, 21 Jan 2003 19:03:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15317 for ; Tue, 21 Jan 2003 18:45:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M03PJ26551; Tue, 21 Jan 2003 19:03:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LNpBJ26218 for ; Tue, 21 Jan 2003 18:51:11 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15123 for ; Tue, 21 Jan 2003 18:32:55 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0LNau96008850; Tue, 21 Jan 2003 18:36:57 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-79.cisco.com [161.44.241.79]) by cannon.cisco.com (Mirapoint) with ESMTP id AAY29794; Tue, 21 Jan 2003 18:41:11 -0500 (EST) Message-ID: <3E2DD968.9020800@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Vijay K. Gurbani'" , hisham.khartabil@nokia.com, jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D36@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Jan 2003 18:36:08 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: >>Yes, we need more than CLOSED for "not Available". >> >>That is why I have explicitly tried to find ways to encode >>things like: >>available for IM now, available for voice & IM eventually. >> >>This is also why I have tried to provide for operational status like >>active/inactive vs declarative status like available/unavailable/... > > Okay, but I think we need to standardize tags so that both ends have > the same implications. We need to agree that we have a state for > "On the phone" vs "Busy". The latter may imply the former, but not > necessarily the other way around. I don't know if we need a status that means "On the Phone". Maybe we do, or maybe a text string is sufficient for conveying the "what you are doing" part. I think that practically speaking the reason for reporting "On the Phone" is to indicate that you are currently unavailable to take voice calls, perhaps with the connotation that you will be available sooner than if you were "on Vacation". I have proposed separate notation both for indicating that you might be available for something, but not voice, and for indicating that eventually you will indeed be available for voice. Once you have those, "On the Phone" may be replaced by simple "Busy" or "Unavailable". >>>To me, presence is guidance to the caller, and state for my >>>local devices to use when requests for calls arrive. >> >>Here we differ. I don't see presence as a guide for my >>devices. Rather I >>see my local devices as responsible for setting my presence status. > > Well, I agree that if you have an activity detector, that your local > presentity client can set your status to Active. What I meant was that > my incoming sip proxy can use my presence to guide forwarding decisions. > This lets calls from my wife come through if I'm in DND. > > If my presence system and my phone system are one and the same, > that could be internally implemented. If they are not, then my sip > proxy subscribes as a watcher to my presence system. Either way, > presence becomes state to the incoming proxy server. I think there are a couple of significantly different usage choices here: - you can use your presence system to describe your presentity with a separate tuple/contact for each device you have, each with its own address. If you want a proxy to also choose among devices, you need an AOR different than the addresses of your devices. You could construct such a proxy that uses presence data to do the selection. Alternately, your buddies can simply pick contacts on their own based on the presence data. - you can use your presence system to describe your presentity with a single tuple/contact, where this contact is an Address of Record known and managed by a registrar and proxy. There may be multiple devices, but they aren't visible to presence clients. The proxy could still use presence as input to device selection but its not clear how much value it can get out of it. Your buddies only have one choice of where to call, and so must use callerprefs to choose between devices. Hybrids of the two are also possible. You seem to have the 1st in mind. I also have some applications in mind where I want to use something approaching that model. But the other model also has applicability. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 21 19:28:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16302 for ; Tue, 21 Jan 2003 19:28:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0M0kDe29837 for simple-archive@odin.ietf.org; Tue, 21 Jan 2003 19:46:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M0kDJ29834 for ; Tue, 21 Jan 2003 19:46:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16299 for ; Tue, 21 Jan 2003 19:27:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M0k4J29826; Tue, 21 Jan 2003 19:46:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M0jHJ29774 for ; Tue, 21 Jan 2003 19:45:17 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16266 for ; Tue, 21 Jan 2003 19:26:59 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h0M0U9829222; Wed, 22 Jan 2003 00:30:09 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 19:32:50 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214D2B@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Rosen, Brian'" , "'Vijay K. Gurbani'" , hisham.khartabil@nokia.com Cc: jdrosen@dynamicsoft.com, simple@ietf.org Subject: RE: dnd (was RE: [Simple] Extending for presence) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Jan 2003 19:32:48 -0500 I was trying to make a slightly subtler point - I'm not really arguing against the DND state, but against a particular semantic of DND, one that seems essentially equivalent to CLOSED. If we necessarily couple DND with rejection of unauthenticated communication attempts via IM or voice or what have you, then we violate, I think, Mr. Kyzviat's 'fireman principle' - that is, when we put a DND sign on a hotel door, we assume that we would welcome an interruption when the building is burning down; but if it is impossible to be disturbed when we're DND, then actually our state is really just CLOSED. This makes it really hard for me to see how I would use DND. The fireman principle also could be accommodated, however, if hotel emergency staff were simply given a different presence than the people that come to turn down the bed, as it were. From this thread, I have gotten the impression that many of the arguments for DND are founded in the understanding that I have only one presence that I show to every watcher in the world - so therefore I often want a state that meanas "CLOSED with some exceptions". I was merely reinforcing Mr. Khartabil's assertion that IMPP has other ways to attack this problem, and probably better ones. Referring to your previous example, if you don't mind being disturbed by your wife, then don't send her DND - that is a much simpler approach than trying to figure out a semantic for DND that accomodates sending DND to watcher for whom you want to appear reachable. You are in fact OPEN/available/whatever to those select watchers, and the protocol should support a capability to show different presence to different people. So, I don't disagree that we need a more sophisticated range of communications states than OPEN/CLOSED - I think we've already made a lot of progress towards that here. But if you merely want further descriptive powers ("Vacation"), that sounds like a job for . I am very wary of proliferating standardized states like "On the phone" as distinguished from "Busy" in any way other than through the element, as qualifiers for a broader presence state. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, January 21, 2003 2:08 PM > To: 'Peterson, Jon'; 'Vijay K. Gurbani'; hisham.khartabil@nokia.com > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: RE: dnd (was RE: [Simple] Extending for presence) > > > The reason you want a rich sense of presence is because the > watcher needs the same vocabulary as the presentity to determine > whether to initiate communication. If you set yourself to > DND, and I am your supervisor, I may act differently than if you > set your state to "Vacation". > > It is not necessary for either end to have any automated behavior, > but they could. What is necessary is that there is no loss of > information when coupling my presentity system to your watcher. > > Check the prior exchange between Paul and I on why CLOSED is not > appropriate. I am not CLOSED if I am in DND. I may defer or > forward communications you send to me. It is up to you to decide > if you will initiate communications if I am in DND. It is up to > me to decide if I will accept a communication from you if I am in > DND. It is necessary for me to communicate to you that I am in DND, > and not CLOSED. That is why we need agreement on a range of > states other than Open/Closed. > > Brian > > > -----Original Message----- > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > Sent: Tuesday, January 21, 2003 4:53 PM > > To: 'Vijay K. Gurbani'; hisham.khartabil@nokia.com > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > Subject: dnd (was RE: [Simple] Extending for presence) > > > > > > > > I think in Mr. Gurbani's argument below I see some > > requirements for our > > forthcoming presence extensions, and some unrelated requirements for > > UA/proxy behavior that is integrated with the setting of > > particular presence > > states. > > > > It is clear that inspecting a PIDF document is not the only > > way to learn > > someone's contact information, and that not everyone who has > > your contact > > information will subscribe to your presence. People may > > attempt to initiate > > telephone sessions with my SIP AoR regardless of whether or not I am > > publishing a 'DND' presence, or even if my state is just > > 'CLOSED'. In that > > sense, publishing 'DND' alone is not enough, and integrating this > > publication with appropriate proxy server and UA behavior > > (rejecting calls > > as needed, etc) seems like a logical next step. However, I > > don't see how > > this requirement affects the work at hand - the question of > > how we structure > > PIDF documents for SIMPLE. > > > > Personally, I have a hard time seeing why I would want to > > publish 'DND' as a > > presence instead of 'CLOSED'. I agree with Mr. Khartabil > that presence > > should be customizable for various watchers - the > > requirements of RFC2779 > > are very friendly to selectively revealing your 'true' > > presence. If I want > > some set of preferred watchers to be able to contact me, I > > should show them > > a state of 'OPEN', and show everyone else a state of > > 'CLOSED'. 'DND' seems > > to be a form of impolite blocking - I'm here but I don't want > > to talk to > > you. Why would I ever want to send that instead of 'CLOSED', which > > communicates that I am unreachable? I think it is very > > limiting to assume > > that a presentity has one and only one true presence state > > that it reveals > > to all watchers. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > > > Sent: Tuesday, January 21, 2003 8:34 AM > > > To: hisham.khartabil@nokia.com > > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > > Subject: Re: [Simple] Extending for presence > > > > > > > > > hisham.khartabil@nokia.com wrote: > > > > I guess the real question is: Can the device be controlled > > > by presence > > > > state? or it like just like Paul's example; you hang a > > > do-not-disturb > > > > sign on the door and hope for the best? > > > > > > I believe that a person should have the option of > > controlling *their* > > > own device through *their* presence state. That is, if I > > actively set > > > my presence/availability state to DND, I would like the following > > > sequence of events to happen: > > > > > > 1) My status is set to DND and all watchers are informed. The > > > presentities associated with the watchers see a big "DND" > > > status next to my icon on their UA. > > > 2) My presence document is updated so that all my > > > interactive devices > > > are CLOSED. > > > 3) Either a message is sent to all my interactive > > devices to stop > > > accepting sessions (currently not possible), or a script is > > > uploaded to my proxy server redirecting all > > > communication sessions > > > to a recorder (definitely possible). > > > > > > Arguably, the reason we cannot do (3) currently is that we cannot > > > control each device we own -- we cannot stop the PSTN phone from > > > ringing (short of plugging it out of the wall), nor can > we stop the > > > cell phone from paging me (again, short of powering it down). I > > > believe it is this behavior that is leading us down the path of > > > equating DND with "hanging DND on the door and hoping for > the best". > > > > > > In a network where all the devices we own are far more > > > controllable, we > > > can do better. I think the power of the simple WG is the > use of SIP > > > as a unifying protocol -- SIP drives all communication > > aspects. Other > > > IM/P systems like Yahoo! or Jabber do not aim to tie all > > communication > > > aspects under one protocol. Thus IM is done using native > protocols, > > > while phone calls are completed using (probably non-SIP) > > > gateways to the > > > PSTN. This leads to cases where the status of the > presentity itself > > > is at odds with the status of its devices (i.e. status of > > > presentity is > > > DND but it still answers the PSTN phone). > > > > > > DND has received a lot of air-time, and Jonathan wrote: > > > > ON DND > > > > > > > > DND has received a bit of discussion on this thread. To be > > > honest, I am > > > > at a loss as to why it is not really a combination of two > > > things: (1) > > > > basic status of CLOSED for each device, and (2) a "task" > > of "do not > > > > disturb". Paul has defined these tasks as things that > > > describe what the > > > > presentity is doing, such as "out-to-lunch". "do not > > > disturb" seems like > > > > another example. > > > > > > > > It is the usage of the basic status of CLOSED that really > > > captures the > > > > essence of DND - that attempts to contact with that user > > > across their > > > > devices will fail. > > > > > > I don't think the representation of DND is what we are > > arguing; it is > > > the semantics. DND implies to me that all *my* devices > should honor > > > my will and not even alert me. But of course, there maybe > > cases where > > > the department secretary or the CEO should be able to get to > > > me. Given > > > today's disparate networks, I cannot impose my will on my > > > devices. But > > > should we preclude us from doing so for tomorrow's > networks where it > > > maybe more possible to control the device in a far more > > > discrete manner? > > > > > > Thanks, > > > > > > - vijay > > > -- > > > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > > > Wireless Networks Group/Internet Software and Services > > > Lucent Technologies/Bell Labs Innovations, 2000 Lucent > > Lane, Rm 6G-440 > > > Naperville, Illinois 60566 Voice: +1 630 224 0216 > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 21 21:20:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18819 for ; Tue, 21 Jan 2003 21:20:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0M2cZe03816 for simple-archive@odin.ietf.org; Tue, 21 Jan 2003 21:38:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M2cZJ03813 for ; Tue, 21 Jan 2003 21:38:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18816 for ; Tue, 21 Jan 2003 21:20:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M2cSJ03799; Tue, 21 Jan 2003 21:38:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M2Y5J03000 for ; Tue, 21 Jan 2003 21:34:05 -0500 Received: from mtiwmhc13.worldnet.att.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18766 for ; Tue, 21 Jan 2003 21:15:45 -0500 (EST) Received: from cs.columbia.edu ([12.85.2.153]) by mtiwmhc13.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030122021911.CRUH2583.mtiwmhc13.worldnet.att.net@cs.columbia.edu>; Wed, 22 Jan 2003 02:19:11 +0000 Message-ID: <3E2DFF05.7020106@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: simple@ietf.org Subject: Re: dnd (was RE: [Simple] Extending for presence) References: <15A2739B7DAA624D8091C65981D7DA8101214D2B@stntexch2.va.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Jan 2003 21:16:37 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Peterson, Jon wrote: > I was trying to make a slightly subtler point - I'm not really arguing > against the DND state, but against a particular semantic of DND, one that > seems essentially equivalent to CLOSED. If we necessarily couple DND with > rejection of unauthenticated communication attempts via IM or voice or what > have you, then we violate, I think, Mr. Kyzviat's 'fireman principle' - that > is, when we put a DND sign on a hotel door, we assume that we would welcome > an interruption when the building is burning down; but if it is impossible > to be disturbed when we're DND, then actually our state is really just > CLOSED. This makes it really hard for me to see how I would use DND. The > fireman principle also could be accommodated, however, if hotel emergency > staff were simply given a different presence than the people that come to > turn down the bed, as it were. In the draft that I'm finishing up, I use the same principle as in caller preferences: provide a hint what kind of communication is currently welcome (routine, urgent, emergency). I suspect that this works reasonably well in practice with people you know, as most people would be embarrassed to call you with a trivial problem if you have indicated "emergency only". DND is always a hint; it requires judgement since the disturbing party needs to gauge how important the interruption is. Except for truly life-threatening cases, this is not easily encoded in software. (For example, most people would ignore the DND sign on your door even if it was just a fire drill.) > >>From this thread, I have gotten the impression that many of the arguments > for DND are founded in the understanding that I have only one presence that > I show to every watcher in the world - so therefore I often want a state > that meanas "CLOSED with some exceptions". I was merely reinforcing Mr. > Khartabil's assertion that IMPP has other ways to attack this problem, and > probably better ones. Referring to your previous example, if you don't mind > being disturbed by your wife, then don't send her DND - that is a much > simpler approach than trying to figure out a semantic for DND that > accomodates sending DND to watcher for whom you want to appear reachable. > You are in fact OPEN/available/whatever to those select watchers, and the > protocol should support a capability to show different presence to different > people. To amplify: There are at least three uses for presence information: - for publishing, which then turns into all kinds of notifications (the example you gave); - for direct notifications (the common assumption); - and for generating call policy, e.g., a CPL script. > > So, I don't disagree that we need a more sophisticated range of > communications states than OPEN/CLOSED - I think we've already made a lot of > progress towards that here. But if you merely want further descriptive > powers ("Vacation"), that sounds like a job for . I am very wary of > proliferating standardized states like "On the phone" as distinguished from > "Busy" in any way other than through the element, as qualifiers for a > broader presence state. However, the use within calendaring systems (including large commercial ones like Yahoo calendar and the iCal spec) argue that this is indeed useful for reasons which were mentioned before: - allows some automated processing, including I18N (translation) and icons - allows easier translation into call handling logic; it's much easier to have a 'case foo' list than trying to pick this out of a 'note' statement that will, by necessity, have other information, such as "Lunch with clients (Mexican place around the corner)". - simplifies the UI - much easier to have a pull-down menu than typing this each time. This does *not* mean that we have to enumerate all facets of human activity. iCal doesn't, either. > > Jon Peterson > NeuStar, Inc. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 21 22:27:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20018 for ; Tue, 21 Jan 2003 22:27:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0M3jdV07847 for simple-archive@odin.ietf.org; Tue, 21 Jan 2003 22:45:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M3jcJ07844 for ; Tue, 21 Jan 2003 22:45:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20012 for ; Tue, 21 Jan 2003 22:27:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M3jUJ07836; Tue, 21 Jan 2003 22:45:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M3iOJ07802 for ; Tue, 21 Jan 2003 22:44:24 -0500 Received: from mail2.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20002 for ; Tue, 21 Jan 2003 22:26:04 -0500 (EST) Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id h0M3Rmes010755; Tue, 21 Jan 2003 22:27:48 -0500 (EST) Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 21:29:18 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64421@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'Henning Schulzrinne'" , "Peterson, Jon" Cc: simple@ietf.org Subject: RE: dnd (was RE: [Simple] Extending for presence) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 21 Jan 2003 21:29:11 -0600 Henning Schulzrinne [mailto:hgs@cs.columbia.edu] writes: > > Peterson, Jon wrote: > > > > So, I don't disagree that we need a more sophisticated range of > > communications states than OPEN/CLOSED - I think we've > already made a lot of > > progress towards that here. But if you merely want further > descriptive > > powers ("Vacation"), that sounds like a job for . I > am very wary of > > proliferating standardized states like "On the phone" as > distinguished from > > "Busy" in any way other than through the element, as > qualifiers for a > > broader presence state. > > However, the use within calendaring systems (including large > commercial > ones like Yahoo calendar and the iCal spec) argue that this is indeed > useful for reasons which were mentioned before: > > - allows some automated processing, including I18N > (translation) and icons The ability to display translated statuses is admittedly valuable in certain contexts. In fact, I think we need to take this to its logical conclusion: when we're coming up with these enumerated types, we should do a survey of various cultures, to make sure that we don't miss the English "At Tea" and Spanish "Siesta" and whatever variety of other specific varients of "away" might exist in other cultures around the world. Or, we could just attempt to parameterize the sort of things that characterize typical "away" statuses, and allow applications and/or users to set them as appropriate. Then, even if I don't understand what's in the freeform text field (or don't have a good intuitive feel for when siesta starts and ends), at least I can figure out what the nature of the break is even if I don't know what it would be called in English (assuming, that is, that there is even a cultural equivalent). > - allows easier translation into call handling logic; it's > much easier > to have a 'case foo' list than trying to pick this out of a 'note' > statement that will, by necessity, have other information, such as > "Lunch with clients (Mexican place around the corner)". This is precisely why I proposed trying to come up with parameters that make these situations unique. Instead of having a "case out_to_lunch", you can have "if (time_to_return < 7200)" or similar. Otherwise, your call processing logic might need to specifically bundle "case out_to_lunch" with "case on_the_phone" and "case in_a_meeting" and "case in_the_shower" and "case working_out" and "case at_the_doctor" and "case picking_up_the_kids_from_school" and.... > - simplifies the UI - much easier to have a pull-down menu > than typing > this each time. Certainly everyone here realizes that the decision about whether this is an enumerated, machine-interpretable value versus whether it is a plain-text string has *no* bearing on the interface, right? Even if we choose not to enumerate a standard set of presences, applications can still include "On the phone" in a dropdown box, the selection of which would publish presence with appropriate parameters (OPEN, interruptability=0.1, etc) and with a freeform text field of "On the phone". /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 22 01:44:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23122 for ; Wed, 22 Jan 2003 01:44:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0M72iK18469 for simple-archive@odin.ietf.org; Wed, 22 Jan 2003 02:02:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M72iJ18466 for ; Wed, 22 Jan 2003 02:02:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23117 for ; Wed, 22 Jan 2003 01:44:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M72aJ18414; Wed, 22 Jan 2003 02:02:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M71cJ18378 for ; Wed, 22 Jan 2003 02:01:38 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23078 for ; Wed, 22 Jan 2003 01:43:13 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0M6kfYH005658; Wed, 22 Jan 2003 01:46:42 -0500 (EST) Message-ID: <3E2E3E4E.6010403@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cnaan Oded CC: simple@ietf.org, Rapaport Orly Subject: Re: [Simple] Content indirection - Uploading large messages References: <385D702A9C11D511A9E90008C7160AD5043BCB58@ismail1.comverse.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Jan 2003 01:46:38 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Oded, This fits into the tricky area of architecture. SIMPLE is trying to develop a set of component technologies that can be combined in a variety of different ways to build different IM and presecne systems. For some functions (such as the upload of content), there are multiple solutions, and indeed, there exist multiple standards today, any one of which can be used without modification (http POST, webdav [which supports metadata], MMS M1). So, can and should the IETF say that all SIMPLE systems have to use a single baseline mechanism for uploading the content used in indirection? To date, we have not attempted to do that. It is similar to mandating a common baseline codec for VoIP (although not as complicated of an issue as that), which we also have not done. Rather, it seems that other groups (like 3gpp), prefer to do this kind of architecture work and pick specific ietf protocols that are mandated for use in their area of control. However, there is a document on our charter that discusses the architecture of a complete IM/presence application for consumers, which will discuss the various pieces of a complete system and show how they fit together. No doubt this document will talk about how such uploads are done, and will mention a specific protocol as one way to do it. That document is meant as informational, and so would not say that you have to use a particular protocol. We have not, however, discussed whether such a document should instead be made into a BCP, in which case it would be allowed to make such recommendations. Given the diversity of sip endpoints and systems it is not clear what the value of such recommendations would be. -Jonathan R. Cnaan Oded wrote: > Sean, > > Thanks for the prompt reply. > > You may be right that the details of how large payloads are sent from > the UA to the server (in case these are not the same entities and that > there is a network based server) are outside SIMPLE scope but it seems > to me that the first hurdle SIMPLE will face would be -interoperability. > If you leave this question open for proprietary solutions, applications > from different vendors will not be able to co-exist on the same network. > If you look at the WG charter, you will find that "The IETF has > committed to producing an interoperable standard for these services ". > > The charter also refers to RFC 2778 and CPIM which require defining how > messages are sent from UAs to servers, regardless of their size. > > Moreover, if you look at 3GPP requirements from SIMPLE (e.g., > draft-niemi-simple-im-wireless-reqs-00) they require that "The content > size MUST NOT be limited by the Instant Messaging, or message session > protocols" - SIMPLE must be able to specify how this is done. > > I believe SIMPLE WG should define at least a 'default' behavior for > these cases, or refer to an external standard, such as MM1. > > Oded Cnaan > > > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: Tuesday, January 21, 2003 9:46 AM > To: 'Cnaan Oded'; simple@ietf.org > Subject: RE: [Simple] Content indirection - Uploading large messages > > > The draft intentionally does not address the how the content is placed > on the content server to begin with. > That is a separate problem that has many disparate solutions and does > not necessarily need to be standardized. > The interesting thing about standardizing the content-indirection > mechanism is that it involves two SIP entities > and directly impacts the SIP signaling. The transfer of content, either > from the UA to the server, or between UAs > is best handled outside of SIP ... the very point of the draft. > > Some important things to note: > > 1) The "server" does not have to be distinct from the UA. They can be > one in the same. > 2) The URL does not have to be an HTTP URL, though this will be probably > be one of the more common schemes used. > For example, an LDAP URL might very be appropriate for certain types > of content > 3) HTTP is ideal for conveying meta-data about the content it carries, > but that argument is best handled outside of SIMPLE > 4) It was never envisoned that MESSAGE would be used to send these large > payloads -- the entire point of content > indirection is to offload this to a non-SIP carrier. > 5) There is nothing mutually exclusive of content-indirection and MMS. > Nor is there anything that compels one to use > MMS for this task in the draft. It's simply outside the scope of this > draft. > 6) Is there something particularly non-concrete about the draft? ;-) > 7) This mechanism is not tied to any particular architecture, though > some architectures may have more pressing need for > it than others. > > cheers, > sean > > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of > Cnaan Oded > Sent: Monday, January 20, 2003 11:05 PM > To: 'simple@ietf.org' > Subject: [Simple] Content indirection - Uploading large messages > > The content-indirection draft (the latest I could find was > draft-ietf-sipping-content-indirect-02.txt) describes how messages or > notifications carry a URL in order to allow the UA to retrieve the > (usually large) content over other transports (e.g., HTTP). The draft > however does not specify how large content is uploaded from the UA to > the server. > > Using HTTP per se is not sufficient for uploading messages over HTTP as > there is some meta-data that needs to be attached to the document such > as sender, recipient(s), message type etc. The MMS standard have already > solved these details in their MM1 protocol (over HTTP as well). > > Note also that using the MESSAGE method is not a good practice as well > as it would generate huge load on the CSCFs (in mobile networks that > deploy IMS/MMD infrastructure), denying them from performing call > control tasks. > > 1. How should large messages be sent from the UA to the server? any > specific draft? > 2. Does the SIMPLE WG intend to reuse the MM1 specifications or invent a > new one? > 3. What's the status of this work within the SIMPLE WG? Are there any > concrete contributions? > > Thanks, > Oded Cnaan > Comverse > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 22 02:12:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03463 for ; Wed, 22 Jan 2003 02:12:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0M7UED30306 for simple-archive@odin.ietf.org; Wed, 22 Jan 2003 02:30:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M7UDJ30303 for ; Wed, 22 Jan 2003 02:30:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03459 for ; Wed, 22 Jan 2003 02:11:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M7U6J30287; Wed, 22 Jan 2003 02:30:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M7TVJ30237 for ; Wed, 22 Jan 2003 02:29:31 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03449 for ; Wed, 22 Jan 2003 02:11:05 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0M7EYYH005672; Wed, 22 Jan 2003 02:14:35 -0500 (EST) Message-ID: <3E2E44D6.2060600@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: Paul Kyzivat , simple@ietf.org Subject: Re: quantifying activity (was RE: [Simple] Extending for pr esence) References: <15A2739B7DAA624D8091C65981D7DA8101214D2A@stntexch2.va.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Jan 2003 02:14:30 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Peterson, Jon wrote: > I do think that abstracting activity from any particular manner of > assessment is interesting and valuable, though undoubtably somewhat > challenging (it would be tough to come up with a formula for evaluating > whether I am more present on my telephone than my PC when the two use > different metrics). I am a little hesitant to tackle this in our initial > iteration of this work. I would be hesitant to try and boil the ocean with a general purpose metric that spans all devices. We just dont know how to do that now. However, we do understand the metric in common use today - providing an idle indication for PC-based IM applications. I think it would be relatively easy to tackle that one. Really, I see just a small number of solutions: 1. add an activity status type withe values or IDLE and ACTIVE. 2. add a duration parameter to the existing basic status type, which indicates the time at which the user is considered idle if no update is provided. > > If we want a bucket for this in the current document, though, I wonder if > the relative 'priority' attribute of elements, which is already > specified in PIDF, would be a good place for quantified activity information > to be recorded. Presumably, one use of activity information would be to > discover the best contact in a set; it might be confusing to have a separate > parameter for this that conflicts with the existing priority parameter in > PIDF. It also already has the connotation that it can be set manually. I don't see this is conflicting at all. THe priority conveys something quite different - which one of these is preferred by the presentity. Thats not the same as saying "this one hasn't been used by the presentity in a while". Indeed, it may be inactive but still preferred (say, because there is a store and forward app running there). In fact, the active/idle indication makes sense for single device systems, where priority clearly doesnt help. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 22 02:35:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17910 for ; Wed, 22 Jan 2003 02:35:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0M7rFA32023 for simple-archive@odin.ietf.org; Wed, 22 Jan 2003 02:53:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M7rEJ32020 for ; Wed, 22 Jan 2003 02:53:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17884 for ; Wed, 22 Jan 2003 02:34:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M7r5J32007; Wed, 22 Jan 2003 02:53:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M7qKJ31983 for ; Wed, 22 Jan 2003 02:52:20 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17877 for ; Wed, 22 Jan 2003 02:33:53 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0M7bKYH005686; Wed, 22 Jan 2003 02:37:20 -0500 (EST) Message-ID: <3E2E4A2C.3020804@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'Rosen, Brian'" , "'Vijay K. Gurbani'" , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: dnd (was RE: [Simple] Extending for presence) References: <15A2739B7DAA624D8091C65981D7DA8101214D2B@stntexch2.va.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Jan 2003 02:37:16 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Peterson, Jon wrote: >>From this thread, I have gotten the impression that many of the arguments > for DND are founded in the understanding that I have only one presence that > I show to every watcher in the world - so therefore I often want a state > that meanas "CLOSED with some exceptions". I was merely reinforcing Mr. > Khartabil's assertion that IMPP has other ways to attack this problem, and > probably better ones. Referring to your previous example, if you don't mind > being disturbed by your wife, then don't send her DND - that is a much > simpler approach than trying to figure out a semantic for DND that > accomodates sending DND to watcher for whom you want to appear reachable. > You are in fact OPEN/available/whatever to those select watchers, and the > protocol should support a capability to show different presence to different > people. Well, you aren't really OPEN to those select watchers, either. You are telling them that you are really busy, and would prefer not to be contacted, but communciations attempts from those people will succeed if tried. Again, I argue that this is really just a basic status of OPEN, combined with a "what am i doing" status of "do not disturb", which is one of an enumerated set of such things. FOr those folks for whom I am DND and won't accept communications, the combination of CLOSED and "do not disturb" would make sense. Later on, Adam Roach writes: > > The ability to display translated statuses is admittedly > valuable in certain contexts. In fact, I think we need to > take this to its logical conclusion: when we're coming > up with these enumerated types, we should do a survey of > various cultures, to make sure that we don't miss the > English "At Tea" and Spanish "Siesta" and whatever variety > of other specific varients of "away" might exist in other > cultures around the world. > > Or, we could just attempt to parameterize the sort of things > that characterize typical "away" statuses, and allow > applications and/or users to set them as appropriate. Then, > even if I don't understand what's in the freeform text field > (or don't have a good intuitive feel for when siesta starts > and ends), at least I can figure out what the nature of the > break is even if I don't know what it would be called in > English (assuming, that is, that there is even a cultural > equivalent). > I would be willing to consider such a thing, if you could propose a concrete mechanism which is actually useful and usable. A duration parameter hardly seems to cut it, given the issues raised multiple times surrounding i8n, icons, and other things that people want to do. The essence of your argument is that, because we can't enumerate EVERYTHING, we should enumerate NOTHING. I disagree. I think that, if we scope it to a dozen or so statuses seen in existing systems today with a few more for fun, we can have a very useful and interoperable list. Indeed, we might decide to establish an IANA registry for said statuses, to make it easier to add "in a siesta" down the road, if that is what we need to have. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 22 06:53:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22353 for ; Wed, 22 Jan 2003 06:53:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MCBdU16545 for simple-archive@odin.ietf.org; Wed, 22 Jan 2003 07:11:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MCBdJ16542 for ; Wed, 22 Jan 2003 07:11:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22332 for ; Wed, 22 Jan 2003 06:53:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MCBVJ16526; Wed, 22 Jan 2003 07:11:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MCAsJ16502 for ; Wed, 22 Jan 2003 07:10:54 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22302 for ; Wed, 22 Jan 2003 06:52:22 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0MBsm006038 for ; Wed, 22 Jan 2003 13:54:48 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 22 Jan 2003 13:55:47 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 22 Jan 2003 13:55:47 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 22 Jan 2003 13:55:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] 3GPP Messaging requirements Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD1BA@esebe013.ntc.nokia.com> Thread-Topic: [Simple] 3GPP Messaging requirements Thread-Index: AcKlUKs55xd38hg0RuiJ87StN72h+wUIi4Jw To: Cc: X-OriginalArrivalTime: 22 Jan 2003 11:55:46.0140 (UTC) FILETIME=[32BCE9C0:01C2C20D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0MCAtJ16503 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Jan 2003 13:55:45 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Milt, Thanks for the comments. Sorry for this late response. [snip] > First, I suggest changing the word "wireless" in the title > to "3GPP" to more clearly reflect the contents of the ID. OK. > Section 3.2 Message Content Requirements > Regarding the OPEN ISSUE on content sequencing. The > sequencing of media in > 3GPP messaging is currently handled by a subset of the Synchronized > Multimedia Integration Language (SMIL). That was my understanding as well. As far as I understand, SMIL descriptions are carried as normal MIME payload, so there doesn't seem to be any additional requirements to SIMPLE. > As mentioned in Section 2, terminals are simple devices and > there is often a > problem with terminals trying to exchange multimedia messages when the > media support in thesender and recipient don't match up. There is a > requirement that says: > The recipient's network MUST be able to take into account > the recipient's terminal capabilities and translate > message content into a form that can be used on the > recipient's terminal. The media transcoding issues were already directed elsewhere, I believe. > NOTE: Although this isn't a protocol issue, there are a > minimum set of media > formats that MUST be supported in all 3GPP messaging clients, > defined in > 3GPP TS 26.140 and 3GPP TS 26.234. This doesn't seem to be a SIMPLE requirement, but rather up to the 3GPP. > Section 3.4 Message Delivery and Handling Requirements > There is an additional 3GPP requirement that says: > It MUST be possible for the UA be able to store immediate > messages in a > persistent network-based message store and then to > subsequently retrieve, > list, delete and forward immediate messages. > > The statement of requirements for message filtering in section 3.4 is > incomplete. Some filtering criteria from the 3GPP > requirements were left > off of the list. > > The original wording of 3.4 says: > It MUST be possible to divert or block instant messages as > part of a > user configurable option. Such mechanisms MUST support instant > message diversion based on sender address, message size, message > priority, message subject, message class and message content type. > The mechanism MAY support instant message diversion based on other > message properties. > > The missing message filter criteria are message type and recipient's > presence status. I'll add the message type (meaning session or pager mode), but I'm not sure about the presence status of the recipient. It seems different from the other criteria, could you elaborate a bit? I don't see how the recipient's presence status as a criteria adds any requirements to the first, main requirement of "MUST be possible to divert or block". Is it an absolute criteria in fact, like based on "all messages"? > There are also a number of required actions resulting from a filter > match beyond divert and block. These are: > 1) Store the message content and notify recipient. > 2) Store the message content for a specific time or until > the recipient > requests delivery. > 3) Store and push the message content to recipient when available. Right, seems that I originally completely omitted all of these. I'll include them for the next version. > In the Normative References section, in addition to 3GPP TR > 22.940 the ID > should also refer to 3GPP TS 23.340, "IMS Messaging Stage 1". Will change that. Even though most (if not all) of the stuff is now covered in Jonathan's advanced IM I-D, I will update the 3GPP reqs for the sake of completeness. Thanks. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 22 08:14:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24086 for ; Wed, 22 Jan 2003 08:14:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MDW8E21215 for simple-archive@odin.ietf.org; Wed, 22 Jan 2003 08:32:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MDW8J21212 for ; Wed, 22 Jan 2003 08:32:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24038 for ; Wed, 22 Jan 2003 08:13:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MDVUJ21178; Wed, 22 Jan 2003 08:31:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MDUkJ21028 for ; Wed, 22 Jan 2003 08:30:46 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23969 for ; Wed, 22 Jan 2003 08:12:11 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA11121; Wed, 22 Jan 2003 08:15:36 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA27888; Wed, 22 Jan 2003 08:15:31 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jan 2003 08:15:31 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D3D@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Peterson, Jon'" , "'Vijay K. Gurbani'" , hisham.khartabil@nokia.com Cc: jdrosen@dynamicsoft.com, simple@ietf.org Subject: RE: dnd (was RE: [Simple] Extending for presence) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Jan 2003 08:15:30 -0500 I agree that we don't want DND to be equivalent to CLOSED. I clearly agree we need more states besides OPEN and CLOSED Let me motivate a need for "On the Phone" as opposed to "Busy" Don't get too hung up on the tags, or whether there is a simple list of states, or a multidimensioned state. The fundamental difference I want to point out is "On the Phone" is a state that my SIP UA can detect and report, while Busy is a state a human decides. One of the experiences we have, over the past several months living with a multistate presence system, is that humans don't remember to change their state. We have running code with states like "Available", "Busy", "Do Not Disturb", "Out of Office" and "Back in 5 minutes". We have presentity clients to pick a state from a menu. It's prominently displayed on the UI, and we have watchers that display the state on contacts/speed dials. Our experience is that Presence state is almost always wrong. We're just not used to keeping fine grained state current. It's interesting because having the information is, in fact very useful before you make a call. What's even more interesting is that even when you recognize that as a watcher, it's great, it doesn't motivate you as a presentity to keep your presence state accurate enough. As a result, we are moving to automated state changes. We'll clearly have the manual state mechanism retained, but we need to have the system automatically change state for you. Activity detectors are an obvious source of information. "On the Phone" is something we can detect. "Busy" could imply a lot more than "On the phone". It seems obvious to me that we do manage to keep our calendars reasonably up to date. Thus we can, in fact, determine the difference between "Out of Office" and "On Vacation". I would like to be able to represent that. While putting the difference in a Note works for a human watcher, it doesn't work for providing automated forwarding based on presence; forwarding behavior is much different for those two cases. Brian > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Tuesday, January 21, 2003 7:33 PM > To: 'Rosen, Brian'; 'Vijay K. Gurbani'; hisham.khartabil@nokia.com > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: RE: dnd (was RE: [Simple] Extending for presence) > > > > I was trying to make a slightly subtler point - I'm not really arguing > against the DND state, but against a particular semantic of > DND, one that > seems essentially equivalent to CLOSED. If we necessarily > couple DND with > rejection of unauthenticated communication attempts via IM or > voice or what > have you, then we violate, I think, Mr. Kyzviat's 'fireman > principle' - that > is, when we put a DND sign on a hotel door, we assume that we > would welcome > an interruption when the building is burning down; but if it > is impossible > to be disturbed when we're DND, then actually our state is really just > CLOSED. This makes it really hard for me to see how I would > use DND. The > fireman principle also could be accommodated, however, if > hotel emergency > staff were simply given a different presence than the people > that come to > turn down the bed, as it were. > > From this thread, I have gotten the impression that many of > the arguments > for DND are founded in the understanding that I have only one > presence that > I show to every watcher in the world - so therefore I often > want a state > that meanas "CLOSED with some exceptions". I was merely > reinforcing Mr. > Khartabil's assertion that IMPP has other ways to attack this > problem, and > probably better ones. Referring to your previous example, if > you don't mind > being disturbed by your wife, then don't send her DND - that is a much > simpler approach than trying to figure out a semantic for DND that > accomodates sending DND to watcher for whom you want to > appear reachable. > You are in fact OPEN/available/whatever to those select > watchers, and the > protocol should support a capability to show different > presence to different > people. > > So, I don't disagree that we need a more sophisticated range of > communications states than OPEN/CLOSED - I think we've > already made a lot of > progress towards that here. But if you merely want further descriptive > powers ("Vacation"), that sounds like a job for . I am > very wary of > proliferating standardized states like "On the phone" as > distinguished from > "Busy" in any way other than through the element, as > qualifiers for a > broader presence state. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Tuesday, January 21, 2003 2:08 PM > > To: 'Peterson, Jon'; 'Vijay K. Gurbani'; hisham.khartabil@nokia.com > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > Subject: RE: dnd (was RE: [Simple] Extending for presence) > > > > > > The reason you want a rich sense of presence is because the > > watcher needs the same vocabulary as the presentity to determine > > whether to initiate communication. If you set yourself to > > DND, and I am your supervisor, I may act differently than if you > > set your state to "Vacation". > > > > It is not necessary for either end to have any automated behavior, > > but they could. What is necessary is that there is no loss of > > information when coupling my presentity system to your watcher. > > > > Check the prior exchange between Paul and I on why CLOSED is not > > appropriate. I am not CLOSED if I am in DND. I may defer or > > forward communications you send to me. It is up to you to decide > > if you will initiate communications if I am in DND. It is up to > > me to decide if I will accept a communication from you if I am in > > DND. It is necessary for me to communicate to you that I am in DND, > > and not CLOSED. That is why we need agreement on a range of > > states other than Open/Closed. > > > > Brian > > > > > -----Original Message----- > > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > > Sent: Tuesday, January 21, 2003 4:53 PM > > > To: 'Vijay K. Gurbani'; hisham.khartabil@nokia.com > > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > > Subject: dnd (was RE: [Simple] Extending for presence) > > > > > > > > > > > > I think in Mr. Gurbani's argument below I see some > > > requirements for our > > > forthcoming presence extensions, and some unrelated > requirements for > > > UA/proxy behavior that is integrated with the setting of > > > particular presence > > > states. > > > > > > It is clear that inspecting a PIDF document is not the only > > > way to learn > > > someone's contact information, and that not everyone who has > > > your contact > > > information will subscribe to your presence. People may > > > attempt to initiate > > > telephone sessions with my SIP AoR regardless of whether > or not I am > > > publishing a 'DND' presence, or even if my state is just > > > 'CLOSED'. In that > > > sense, publishing 'DND' alone is not enough, and integrating this > > > publication with appropriate proxy server and UA behavior > > > (rejecting calls > > > as needed, etc) seems like a logical next step. However, I > > > don't see how > > > this requirement affects the work at hand - the question of > > > how we structure > > > PIDF documents for SIMPLE. > > > > > > Personally, I have a hard time seeing why I would want to > > > publish 'DND' as a > > > presence instead of 'CLOSED'. I agree with Mr. Khartabil > > that presence > > > should be customizable for various watchers - the > > > requirements of RFC2779 > > > are very friendly to selectively revealing your 'true' > > > presence. If I want > > > some set of preferred watchers to be able to contact me, I > > > should show them > > > a state of 'OPEN', and show everyone else a state of > > > 'CLOSED'. 'DND' seems > > > to be a form of impolite blocking - I'm here but I don't want > > > to talk to > > > you. Why would I ever want to send that instead of 'CLOSED', which > > > communicates that I am unreachable? I think it is very > > > limiting to assume > > > that a presentity has one and only one true presence state > > > that it reveals > > > to all watchers. > > > > > > Jon Peterson > > > NeuStar, Inc. > > > > > > > -----Original Message----- > > > > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > > > > Sent: Tuesday, January 21, 2003 8:34 AM > > > > To: hisham.khartabil@nokia.com > > > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > > > Subject: Re: [Simple] Extending for presence > > > > > > > > > > > > hisham.khartabil@nokia.com wrote: > > > > > I guess the real question is: Can the device be controlled > > > > by presence > > > > > state? or it like just like Paul's example; you hang a > > > > do-not-disturb > > > > > sign on the door and hope for the best? > > > > > > > > I believe that a person should have the option of > > > controlling *their* > > > > own device through *their* presence state. That is, if I > > > actively set > > > > my presence/availability state to DND, I would like the > following > > > > sequence of events to happen: > > > > > > > > 1) My status is set to DND and all watchers are > informed. The > > > > presentities associated with the watchers see a big "DND" > > > > status next to my icon on their UA. > > > > 2) My presence document is updated so that all my > > > > interactive devices > > > > are CLOSED. > > > > 3) Either a message is sent to all my interactive > > > devices to stop > > > > accepting sessions (currently not possible), or > a script is > > > > uploaded to my proxy server redirecting all > > > > communication sessions > > > > to a recorder (definitely possible). > > > > > > > > Arguably, the reason we cannot do (3) currently is that > we cannot > > > > control each device we own -- we cannot stop the PSTN phone from > > > > ringing (short of plugging it out of the wall), nor can > > we stop the > > > > cell phone from paging me (again, short of powering it down). I > > > > believe it is this behavior that is leading us down the path of > > > > equating DND with "hanging DND on the door and hoping for > > the best". > > > > > > > > In a network where all the devices we own are far more > > > > controllable, we > > > > can do better. I think the power of the simple WG is the > > use of SIP > > > > as a unifying protocol -- SIP drives all communication > > > aspects. Other > > > > IM/P systems like Yahoo! or Jabber do not aim to tie all > > > communication > > > > aspects under one protocol. Thus IM is done using native > > protocols, > > > > while phone calls are completed using (probably non-SIP) > > > > gateways to the > > > > PSTN. This leads to cases where the status of the > > presentity itself > > > > is at odds with the status of its devices (i.e. status of > > > > presentity is > > > > DND but it still answers the PSTN phone). > > > > > > > > DND has received a lot of air-time, and Jonathan wrote: > > > > > ON DND > > > > > > > > > > DND has received a bit of discussion on this thread. To be > > > > honest, I am > > > > > at a loss as to why it is not really a combination of two > > > > things: (1) > > > > > basic status of CLOSED for each device, and (2) a "task" > > > of "do not > > > > > disturb". Paul has defined these tasks as things that > > > > describe what the > > > > > presentity is doing, such as "out-to-lunch". "do not > > > > disturb" seems like > > > > > another example. > > > > > > > > > > It is the usage of the basic status of CLOSED that really > > > > captures the > > > > > essence of DND - that attempts to contact with that user > > > > across their > > > > > devices will fail. > > > > > > > > I don't think the representation of DND is what we are > > > arguing; it is > > > > the semantics. DND implies to me that all *my* devices > > should honor > > > > my will and not even alert me. But of course, there maybe > > > cases where > > > > the department secretary or the CEO should be able to get to > > > > me. Given > > > > today's disparate networks, I cannot impose my will on my > > > > devices. But > > > > should we preclude us from doing so for tomorrow's > > networks where it > > > > maybe more possible to control the device in a far more > > > > discrete manner? > > > > > > > > Thanks, > > > > > > > > - vijay > > > > -- > > > > Vijay K. Gurbani > vkg@{lucent.com,research.bell-labs.com,acm.org} > > > > Wireless Networks Group/Internet Software and Services > > > > Lucent Technologies/Bell Labs Innovations, 2000 Lucent > > > Lane, Rm 6G-440 > > > > Naperville, Illinois 60566 Voice: +1 630 224 0216 > > > > > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 22 08:24:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24357 for ; Wed, 22 Jan 2003 08:24:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MDg8W22271 for simple-archive@odin.ietf.org; Wed, 22 Jan 2003 08:42:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MDg8J22268 for ; Wed, 22 Jan 2003 08:42:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24348 for ; Wed, 22 Jan 2003 08:23:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MDg3J22255; Wed, 22 Jan 2003 08:42:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MDfuJ22237 for ; Wed, 22 Jan 2003 08:41:56 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24345 for ; Wed, 22 Jan 2003 08:23:22 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA11512; Wed, 22 Jan 2003 08:26:48 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA28816; Wed, 22 Jan 2003 08:26:48 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jan 2003 08:26:48 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D3E@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , "Peterson, Jon" Cc: simple@ietf.org Subject: RE: dnd (was RE: [Simple] Extending for presence) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Jan 2003 08:26:47 -0500 > In the draft that I'm finishing up, I use the same principle as in > caller preferences: provide a hint what kind of communication is > currently welcome (routine, urgent, emergency). I suspect that this > works reasonably well in practice with people you know, as > most people > would be embarrassed to call you with a trivial problem if you have > indicated "emergency only". DND is always a hint; it requires > judgement > since the disturbing party needs to gauge how important the > interruption > is. Except for truly life-threatening cases, this is not > easily encoded > in software. (For example, most people would ignore the DND > sign on your > door even if it was just a fire drill.) I don't think this will work well enough. It probably works for DND, but it doesn't work for, say, On Vacation. When I'm on vacation, I welcome calls from friends and family, but not from teammates, vendors, or customers. My Boss may be able to get a call through to me, others calling my office get voicemail. It works the other way for "Out of Office". There, my teammates probably get forwarded to my cell, vendors get voicemail, friends probably get voicemail, my wife gets forwarded. ... snip ... > > To amplify: There are at least three uses for presence information: > - for publishing, which then turns into all kinds of > notifications (the > example you gave); > - for direct notifications (the common assumption); > - and for generating call policy, e.g., a CPL script. I'm not sure I appreciate the difference between the first two. If a human interprets state, and makes a decision on what to do given the state, then we are simply discussing whether we give him a description of what state we are in, or what we are willing to do about it (On Vacation, vs Accepting calls from friends). The third is quite different, because we are providing information for an automaton to act on. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 22 09:28:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25592 for ; Wed, 22 Jan 2003 09:28:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MEkTG25899 for simple-archive@odin.ietf.org; Wed, 22 Jan 2003 09:46:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MEkTJ25896 for ; Wed, 22 Jan 2003 09:46:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25582 for ; Wed, 22 Jan 2003 09:27:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MEkNJ25887; Wed, 22 Jan 2003 09:46:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MEeKJ25665 for ; Wed, 22 Jan 2003 09:40:20 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25484 for ; Wed, 22 Jan 2003 09:21:45 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0MEPBNq029471 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 22 Jan 2003 09:25:12 -0500 (EST) Message-ID: <3E2EA9D8.6050405@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "Peterson, Jon" , simple@ietf.org Subject: Re: dnd (was RE: [Simple] Extending for presence) References: <313680C9A886D511A06000204840E1CF030B5D3E@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D3E@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Jan 2003 09:25:28 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I don't think this will work well enough. > It probably works for DND, but it doesn't work for, say, On Vacation. > When I'm on vacation, I welcome calls from friends and family, but > not from teammates, vendors, or customers. My Boss may be able to > get a call through to me, others calling my office get voicemail. > It works the other way for "Out of Office". There, my teammates > probably get forwarded to my cell, vendors get voicemail, friends > probably get voicemail, my wife gets forwarded. Again, 'dnd' and 'on vacation' are used only in two ways by automatons: (1) If your CPL-generator subscribes to your presence, it may translate "on vacation" to a set of filters and rules that implement the behavior you describe. (2) There may be some rule-based mechanism in your presence agent that translates your PUBLISHed 'dnd' to a set of OPEN and CLOSED indications for particular subscribers. Other indications, such as 'open' or 'closed', customized for each recipient of the notification, determine the precise meaning for each means of communication. >>- for direct notifications (the common assumption); >>- and for generating call policy, e.g., a CPL script. > > I'm not sure I appreciate the difference between the first two. > If a human interprets state, and makes a decision on what to do > given the state, then we are simply discussing whether we give > him a description of what state we are in, or what we are > willing to do about it (On Vacation, vs Accepting calls from > friends). The third is quite different, because we are > providing information for an automaton to act on. See above. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 22 09:47:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26113 for ; Wed, 22 Jan 2003 09:47:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MF5Bp26878 for simple-archive@odin.ietf.org; Wed, 22 Jan 2003 10:05:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MF5BJ26875 for ; Wed, 22 Jan 2003 10:05:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26091 for ; Wed, 22 Jan 2003 09:46:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MF52J26851; Wed, 22 Jan 2003 10:05:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MF4ZJ26797 for ; Wed, 22 Jan 2003 10:04:35 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26063 for ; Wed, 22 Jan 2003 09:45:58 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0MEnpKE008315; Wed, 22 Jan 2003 09:50:00 -0500 (EST) Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-74.cisco.com [161.44.87.74]) by cia.cisco.com (Mirapoint) with ESMTP id ABN30677; Wed, 22 Jan 2003 09:39:01 -0500 (EST) Message-Id: <4.3.2.7.2.20030122094404.00b3cda8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Peterson, Jon" From: Michael Hammer Subject: Re: quantifying activity (was RE: [Simple] Extending for pr esence) Cc: "'Jonathan Rosenberg'" , Paul Kyzivat , simple@ietf.org In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214D2A@stntexch2.va.neus tar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Jan 2003 09:49:01 -0500 Jon, I see activity and priority as two independent things, the former being an implicit fact measurable by the device, the latter being an explicit predisposition set by the user. It indicates which form I am more likely to answer rather than what was the last device I responded to. One is future, the other is past. Time answers the question of how long has it been since you originated or responded to communications using that device. But, out of curiosity, what sort of metric other than time were you thinking of? I think time can be applied equally to two different devices. Mike At 05:38 PM 1/21/2003 -0500, Peterson, Jon wrote: >I do think that abstracting activity from any particular manner of >assessment is interesting and valuable, though undoubtably somewhat >challenging (it would be tough to come up with a formula for evaluating >whether I am more present on my telephone than my PC when the two use >different metrics). I am a little hesitant to tackle this in our initial >iteration of this work. > >If we want a bucket for this in the current document, though, I wonder if >the relative 'priority' attribute of elements, which is already >specified in PIDF, would be a good place for quantified activity information >to be recorded. Presumably, one use of activity information would be to >discover the best contact in a set; it might be confusing to have a separate >parameter for this that conflicts with the existing priority parameter in >PIDF. It also already has the connotation that it can be set manually. > >Jon Peterson >NeuStar, Inc. > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Monday, January 20, 2003 1:22 PM > > To: Paul Kyzivat > > Cc: simple@ietf.org > > Subject: Re: [Simple] Extending for presence > > >[snip] > > > > ON ACTIVITY > > > > I'd next like to comment on what you call "activity". I think there is a > > need for some type of standardization to support this concept. There are > > several different ways in which the concept can be quantified: > > > > * the amount of TIME since the presentity last interacted > > with the device > > * the physical DISTANCE of the presentity from the device > > * the PROBABILITY that a communications request to the device will be > > answered by the presentity > > > > I think existing IM systems very much rely on the TIME definition. > > However, in my experience that definition is heavily tied to the concept > > of a PC application. On a cell phone, where the user normally does not > > interact with the device continously, this tends to a poor definition. > > For cell phones, the DISTANCE is a better measure, but even that is not > > neccesarily a good one. The phone may be near me, but its tucked away > > into a laptop bag and so I really am idle with respect to it, since I > > can't hear it or reach it. > > > > Arguably, one approach is to separate the means for measuring "activity" > > or "idleness" from its representation. Using something like a > > probability, for example, would allow the metric to work across devices, > > and for it to be measured differently for different devices. > > > > Another issue to be factored into the decision about how to represent > > idleness is how frequently it needs to be reported to the watcher in > > order to be useful. A time-based measure has the nice benefit that the > > watcher can continously know how long the presentity has been idle, > > simply by conveying the time of last activity in the presence > > notifications. > > > > One final point on activity. Some have stated that the defining > > characteristic of this status is that it is implicitly computed by the > > system. I disagree. I think it may be perfectly valid to set > > it explicitly. > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 22 10:18:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27377 for ; Wed, 22 Jan 2003 10:18:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MFaEF29165 for simple-archive@odin.ietf.org; Wed, 22 Jan 2003 10:36:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MFaEJ29162 for ; Wed, 22 Jan 2003 10:36:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27360 for ; Wed, 22 Jan 2003 10:17:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MFa6J29148; Wed, 22 Jan 2003 10:36:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MFZ5J29092 for ; Wed, 22 Jan 2003 10:35:05 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27303 for ; Wed, 22 Jan 2003 10:16:28 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0MFKUG0013228; Wed, 22 Jan 2003 10:20:31 -0500 (EST) Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-74.cisco.com [161.44.87.74]) by cia.cisco.com (Mirapoint) with ESMTP id ABN31048; Wed, 22 Jan 2003 10:09:40 -0500 (EST) Message-Id: <4.3.2.7.2.20030122100754.00b3ceb0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jonathan Rosenberg From: Michael Hammer Subject: Re: dnd (was RE: [Simple] Extending for presence) Cc: "Peterson, Jon" , "'Rosen, Brian'" , "'Vijay K. Gurbani'" , hisham.khartabil@nokia.com, simple@ietf.org In-Reply-To: <3E2E4A2C.3020804@dynamicsoft.com> References: <15A2739B7DAA624D8091C65981D7DA8101214D2B@stntexch2.va.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Jan 2003 10:19:40 -0500 Jonathan, What do you expect tech support (customer service) to say to the individual that calls in and complains that he set DND on his phone and it still rang and rang during his power lunch with the CEO? I think there are already well defined semantics associated with phones that work today and don't need to be messed with. That is not to say that you can't define other similar type language to describe what you are trying to do. My main question is this: Should the semantics of DND in presence applications be consistent with the DND of the phone application? I really think the semantics of DND should be one, and not mean something different depending on who you talk to. This is supposed to be convergence, not divergence. If you mean that calls will be "screened for emergencies" then say that. If you use CLOSED with DND versus OPEN with DND, then the DND indication is really superfluous and can be omitted. Mike At 02:37 AM 1/22/2003 -0500, Jonathan Rosenberg wrote: >inline. > >Peterson, Jon wrote: >> From this thread, I have gotten the impression that many of the arguments >>for DND are founded in the understanding that I have only one presence that >>I show to every watcher in the world - so therefore I often want a state >>that meanas "CLOSED with some exceptions". I was merely reinforcing Mr. >>Khartabil's assertion that IMPP has other ways to attack this problem, and >>probably better ones. Referring to your previous example, if you don't mind >>being disturbed by your wife, then don't send her DND - that is a much >>simpler approach than trying to figure out a semantic for DND that >>accomodates sending DND to watcher for whom you want to appear reachable. >>You are in fact OPEN/available/whatever to those select watchers, and the >>protocol should support a capability to show different presence to different >>people. > >Well, you aren't really OPEN to those select watchers, either. You are >telling them that you are really busy, and would prefer not to be >contacted, but communciations attempts from those people will succeed if tried. > >Again, I argue that this is really just a basic status of OPEN, combined >with a "what am i doing" status of "do not disturb", which is one of an >enumerated set of such things. > >FOr those folks for whom I am DND and won't accept communications, the >combination of CLOSED and "do not disturb" would make sense. > >Later on, Adam Roach writes: >>The ability to display translated statuses is admittedly >>valuable in certain contexts. In fact, I think we need to >>take this to its logical conclusion: when we're coming >>up with these enumerated types, we should do a survey of >>various cultures, to make sure that we don't miss the >>English "At Tea" and Spanish "Siesta" and whatever variety >>of other specific varients of "away" might exist in other >>cultures around the world. >>Or, we could just attempt to parameterize the sort of things >>that characterize typical "away" statuses, and allow >>applications and/or users to set them as appropriate. Then, >>even if I don't understand what's in the freeform text field >>(or don't have a good intuitive feel for when siesta starts >>and ends), at least I can figure out what the nature of the >>break is even if I don't know what it would be called in >>English (assuming, that is, that there is even a cultural >>equivalent). > >I would be willing to consider such a thing, if you could propose a >concrete mechanism which is actually useful and usable. A duration >parameter hardly seems to cut it, given the issues raised multiple times >surrounding i8n, icons, and other things that people want to do. > >The essence of your argument is that, because we can't enumerate >EVERYTHING, we should enumerate NOTHING. I disagree. I think that, if we >scope it to a dozen or so statuses seen in existing systems today with a >few more for fun, we can have a very useful and interoperable list. >Indeed, we might decide to establish an IANA registry for said statuses, >to make it easier to add "in a siesta" down the road, if that is what we >need to have. > >-Jonathan R. >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 22 10:22:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27534 for ; Wed, 22 Jan 2003 10:22:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MFeEo30112 for simple-archive@odin.ietf.org; Wed, 22 Jan 2003 10:40:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MFeDJ30109 for ; Wed, 22 Jan 2003 10:40:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27531 for ; Wed, 22 Jan 2003 10:21:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MFe2J30071; Wed, 22 Jan 2003 10:40:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MFdJJ30005 for ; Wed, 22 Jan 2003 10:39:19 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27487 for ; Wed, 22 Jan 2003 10:20:42 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0MFO7D16824 for ; Wed, 22 Jan 2003 10:24:08 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jan 2003 15:24:07 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB007403E75@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Peterson, Jon" , "'Rosen, Brian'" , "'Vijay K. Gurbani'" , hisham.khartabil@nokia.com Cc: jdrosen@dynamicsoft.com, simple@ietf.org Subject: RE: dnd (was RE: [Simple] Extending for presence) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Jan 2003 15:24:03 -0000 To a large extent I concur with Jon. I think it is extremely dangerous to identify something called "DND" and then try and fix semantics to it. This is because the term already carries the users expectations which are all substantiallt different. My understanding, which may not be anyone elses, but derives from my enterprise network (PABX) background would be as follows: 1) DND applies to the device. Putting DND on my phone does not stop people barging in the door. Putting a DND label on the office door does not stop the phone ringing. 2) DND is no different to "The device is busy, please try later". The original implementation of the feature on enterprise networks returned exactly the same tone as "busy". The calling user saw no difference between the user actually using the device and the device being in a state of DND. 3) DND is interruptable to anybody with the appropriate privileges. The managing director can be given a Class of Service that enables him to sucessfully ring anybody with a phone in DND. It is likely to be unsafe to say these are the only version of the semantics that people think of with DND, and therefore whatever is defined, I would urge people not to use the term DND. It may well be applicable to try and define something, at either the user or the device level, that indicates that it is worth trying later. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: 22 January 2003 00:33 > To: 'Rosen, Brian'; 'Vijay K. Gurbani'; hisham.khartabil@nokia.com > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: RE: dnd (was RE: [Simple] Extending for presence) > > > > I was trying to make a slightly subtler point - I'm not really arguing > against the DND state, but against a particular semantic of > DND, one that > seems essentially equivalent to CLOSED. If we necessarily > couple DND with > rejection of unauthenticated communication attempts via IM or > voice or what > have you, then we violate, I think, Mr. Kyzviat's 'fireman > principle' - that > is, when we put a DND sign on a hotel door, we assume that we > would welcome > an interruption when the building is burning down; but if it > is impossible > to be disturbed when we're DND, then actually our state is really just > CLOSED. This makes it really hard for me to see how I would > use DND. The > fireman principle also could be accommodated, however, if > hotel emergency > staff were simply given a different presence than the people > that come to > turn down the bed, as it were. > > From this thread, I have gotten the impression that many of > the arguments > for DND are founded in the understanding that I have only one > presence that > I show to every watcher in the world - so therefore I often > want a state > that meanas "CLOSED with some exceptions". I was merely > reinforcing Mr. > Khartabil's assertion that IMPP has other ways to attack this > problem, and > probably better ones. Referring to your previous example, if > you don't mind > being disturbed by your wife, then don't send her DND - that is a much > simpler approach than trying to figure out a semantic for DND that > accomodates sending DND to watcher for whom you want to > appear reachable. > You are in fact OPEN/available/whatever to those select > watchers, and the > protocol should support a capability to show different > presence to different > people. > > So, I don't disagree that we need a more sophisticated range of > communications states than OPEN/CLOSED - I think we've > already made a lot of > progress towards that here. But if you merely want further descriptive > powers ("Vacation"), that sounds like a job for . I am > very wary of > proliferating standardized states like "On the phone" as > distinguished from > "Busy" in any way other than through the element, as > qualifiers for a > broader presence state. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Tuesday, January 21, 2003 2:08 PM > > To: 'Peterson, Jon'; 'Vijay K. Gurbani'; hisham.khartabil@nokia.com > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > Subject: RE: dnd (was RE: [Simple] Extending for presence) > > > > > > The reason you want a rich sense of presence is because the > > watcher needs the same vocabulary as the presentity to determine > > whether to initiate communication. If you set yourself to > > DND, and I am your supervisor, I may act differently than if you > > set your state to "Vacation". > > > > It is not necessary for either end to have any automated behavior, > > but they could. What is necessary is that there is no loss of > > information when coupling my presentity system to your watcher. > > > > Check the prior exchange between Paul and I on why CLOSED is not > > appropriate. I am not CLOSED if I am in DND. I may defer or > > forward communications you send to me. It is up to you to decide > > if you will initiate communications if I am in DND. It is up to > > me to decide if I will accept a communication from you if I am in > > DND. It is necessary for me to communicate to you that I am in DND, > > and not CLOSED. That is why we need agreement on a range of > > states other than Open/Closed. > > > > Brian > > > > > -----Original Message----- > > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > > Sent: Tuesday, January 21, 2003 4:53 PM > > > To: 'Vijay K. Gurbani'; hisham.khartabil@nokia.com > > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > > Subject: dnd (was RE: [Simple] Extending for presence) > > > > > > > > > > > > I think in Mr. Gurbani's argument below I see some > > > requirements for our > > > forthcoming presence extensions, and some unrelated > requirements for > > > UA/proxy behavior that is integrated with the setting of > > > particular presence > > > states. > > > > > > It is clear that inspecting a PIDF document is not the only > > > way to learn > > > someone's contact information, and that not everyone who has > > > your contact > > > information will subscribe to your presence. People may > > > attempt to initiate > > > telephone sessions with my SIP AoR regardless of whether > or not I am > > > publishing a 'DND' presence, or even if my state is just > > > 'CLOSED'. In that > > > sense, publishing 'DND' alone is not enough, and integrating this > > > publication with appropriate proxy server and UA behavior > > > (rejecting calls > > > as needed, etc) seems like a logical next step. However, I > > > don't see how > > > this requirement affects the work at hand - the question of > > > how we structure > > > PIDF documents for SIMPLE. > > > > > > Personally, I have a hard time seeing why I would want to > > > publish 'DND' as a > > > presence instead of 'CLOSED'. I agree with Mr. Khartabil > > that presence > > > should be customizable for various watchers - the > > > requirements of RFC2779 > > > are very friendly to selectively revealing your 'true' > > > presence. If I want > > > some set of preferred watchers to be able to contact me, I > > > should show them > > > a state of 'OPEN', and show everyone else a state of > > > 'CLOSED'. 'DND' seems > > > to be a form of impolite blocking - I'm here but I don't want > > > to talk to > > > you. Why would I ever want to send that instead of 'CLOSED', which > > > communicates that I am unreachable? I think it is very > > > limiting to assume > > > that a presentity has one and only one true presence state > > > that it reveals > > > to all watchers. > > > > > > Jon Peterson > > > NeuStar, Inc. > > > > > > > -----Original Message----- > > > > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > > > > Sent: Tuesday, January 21, 2003 8:34 AM > > > > To: hisham.khartabil@nokia.com > > > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > > > Subject: Re: [Simple] Extending for presence > > > > > > > > > > > > hisham.khartabil@nokia.com wrote: > > > > > I guess the real question is: Can the device be controlled > > > > by presence > > > > > state? or it like just like Paul's example; you hang a > > > > do-not-disturb > > > > > sign on the door and hope for the best? > > > > > > > > I believe that a person should have the option of > > > controlling *their* > > > > own device through *their* presence state. That is, if I > > > actively set > > > > my presence/availability state to DND, I would like the > following > > > > sequence of events to happen: > > > > > > > > 1) My status is set to DND and all watchers are > informed. The > > > > presentities associated with the watchers see a big "DND" > > > > status next to my icon on their UA. > > > > 2) My presence document is updated so that all my > > > > interactive devices > > > > are CLOSED. > > > > 3) Either a message is sent to all my interactive > > > devices to stop > > > > accepting sessions (currently not possible), or > a script is > > > > uploaded to my proxy server redirecting all > > > > communication sessions > > > > to a recorder (definitely possible). > > > > > > > > Arguably, the reason we cannot do (3) currently is that > we cannot > > > > control each device we own -- we cannot stop the PSTN phone from > > > > ringing (short of plugging it out of the wall), nor can > > we stop the > > > > cell phone from paging me (again, short of powering it down). I > > > > believe it is this behavior that is leading us down the path of > > > > equating DND with "hanging DND on the door and hoping for > > the best". > > > > > > > > In a network where all the devices we own are far more > > > > controllable, we > > > > can do better. I think the power of the simple WG is the > > use of SIP > > > > as a unifying protocol -- SIP drives all communication > > > aspects. Other > > > > IM/P systems like Yahoo! or Jabber do not aim to tie all > > > communication > > > > aspects under one protocol. Thus IM is done using native > > protocols, > > > > while phone calls are completed using (probably non-SIP) > > > > gateways to the > > > > PSTN. This leads to cases where the status of the > > presentity itself > > > > is at odds with the status of its devices (i.e. status of > > > > presentity is > > > > DND but it still answers the PSTN phone). > > > > > > > > DND has received a lot of air-time, and Jonathan wrote: > > > > > ON DND > > > > > > > > > > DND has received a bit of discussion on this thread. To be > > > > honest, I am > > > > > at a loss as to why it is not really a combination of two > > > > things: (1) > > > > > basic status of CLOSED for each device, and (2) a "task" > > > of "do not > > > > > disturb". Paul has defined these tasks as things that > > > > describe what the > > > > > presentity is doing, such as "out-to-lunch". "do not > > > > disturb" seems like > > > > > another example. > > > > > > > > > > It is the usage of the basic status of CLOSED that really > > > > captures the > > > > > essence of DND - that attempts to contact with that user > > > > across their > > > > > devices will fail. > > > > > > > > I don't think the representation of DND is what we are > > > arguing; it is > > > > the semantics. DND implies to me that all *my* devices > > should honor > > > > my will and not even alert me. But of course, there maybe > > > cases where > > > > the department secretary or the CEO should be able to get to > > > > me. Given > > > > today's disparate networks, I cannot impose my will on my > > > > devices. But > > > > should we preclude us from doing so for tomorrow's > > networks where it > > > > maybe more possible to control the device in a far more > > > > discrete manner? > > > > > > > > Thanks, > > > > > > > > - vijay > > > > -- > > > > Vijay K. Gurbani > vkg@{lucent.com,research.bell-labs.com,acm.org} > > > > Wireless Networks Group/Internet Software and Services > > > > Lucent Technologies/Bell Labs Innovations, 2000 Lucent > > > Lane, Rm 6G-440 > > > > Naperville, Illinois 60566 Voice: +1 630 224 0216 > > > > > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 22 10:46:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28465 for ; Wed, 22 Jan 2003 10:46:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MG4YH31327 for simple-archive@odin.ietf.org; Wed, 22 Jan 2003 11:04:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MG4YJ31324 for ; Wed, 22 Jan 2003 11:04:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28458 for ; Wed, 22 Jan 2003 10:45:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MG4NJ31314; Wed, 22 Jan 2003 11:04:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MG3kJ31273 for ; Wed, 22 Jan 2003 11:03:46 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28416 for ; Wed, 22 Jan 2003 10:45:07 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0MFnB30018325; Wed, 22 Jan 2003 10:49:11 -0500 (EST) Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-74.cisco.com [161.44.87.74]) by cia.cisco.com (Mirapoint) with ESMTP id ABN31444; Wed, 22 Jan 2003 10:38:21 -0500 (EST) Message-Id: <4.3.2.7.2.20030122104424.00b8be48@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Drage, Keith (Keith)" From: Michael Hammer Subject: RE: dnd (was RE: [Simple] Extending for presence) Cc: "Peterson, Jon" , "'Rosen, Brian'" , "'Vijay K. Gurbani'" , hisham.khartabil@nokia.com, jdrosen@dynamicsoft.com, simple@ietf.org In-Reply-To: <475FF955A05DD411980D00508B6D5FB007403E75@en0033exch001u.uk .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Jan 2003 10:48:20 -0500 Keith, I agree with your comments and conclusion, with the following exception. (My view comes more from a Centrex/Class environment, but I think it is consistent to PBX.) The DND feature by itself would block all calls from ringing. The barge-in that you describe is effectively a "DND Override" feature that cancels out the DND for that caller. That is not the same as saying that DND lets some users through. That is more of a call screening feature. Anyway, I agree that not overloading the term DND with too many meanings is of value. Mike At 03:24 PM 1/22/2003 +0000, Drage, Keith (Keith) wrote: >To a large extent I concur with Jon. > >I think it is extremely dangerous to identify something called "DND" and >then try and fix semantics to it. This is because the term already carries >the users expectations which are all substantiallt different. > >My understanding, which may not be anyone elses, but derives from my >enterprise network (PABX) background would be as follows: > >1) DND applies to the device. Putting DND on my phone does not stop >people barging in the door. Putting a DND label on the office door does >not stop the phone ringing. > >2) DND is no different to "The device is busy, please try later". The >original implementation of the feature on enterprise networks returned >exactly the same tone as "busy". The calling user saw no difference >between the user actually using the device and the device being in a state >of DND. > >3) DND is interruptable to anybody with the appropriate privileges. >The managing director can be given a Class of Service that enables him to >sucessfully ring anybody with a phone in DND. > >It is likely to be unsafe to say these are the only version of the >semantics that people think of with DND, and therefore whatever is >defined, I would urge people not to use the term DND. > >It may well be applicable to try and define something, at either the user >or the device level, that indicates that it is worth trying later. > >Keith > >Keith Drage >Lucent Technologies >Tel: +44 1793 776249 >Email: drage@lucent.com > > > -----Original Message----- > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > Sent: 22 January 2003 00:33 > > To: 'Rosen, Brian'; 'Vijay K. Gurbani'; hisham.khartabil@nokia.com > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > Subject: RE: dnd (was RE: [Simple] Extending for presence) > > > > > > > > I was trying to make a slightly subtler point - I'm not really arguing > > against the DND state, but against a particular semantic of > > DND, one that > > seems essentially equivalent to CLOSED. If we necessarily > > couple DND with > > rejection of unauthenticated communication attempts via IM or > > voice or what > > have you, then we violate, I think, Mr. Kyzviat's 'fireman > > principle' - that > > is, when we put a DND sign on a hotel door, we assume that we > > would welcome > > an interruption when the building is burning down; but if it > > is impossible > > to be disturbed when we're DND, then actually our state is really just > > CLOSED. This makes it really hard for me to see how I would > > use DND. The > > fireman principle also could be accommodated, however, if > > hotel emergency > > staff were simply given a different presence than the people > > that come to > > turn down the bed, as it were. > > > > From this thread, I have gotten the impression that many of > > the arguments > > for DND are founded in the understanding that I have only one > > presence that > > I show to every watcher in the world - so therefore I often > > want a state > > that meanas "CLOSED with some exceptions". I was merely > > reinforcing Mr. > > Khartabil's assertion that IMPP has other ways to attack this > > problem, and > > probably better ones. Referring to your previous example, if > > you don't mind > > being disturbed by your wife, then don't send her DND - that is a much > > simpler approach than trying to figure out a semantic for DND that > > accomodates sending DND to watcher for whom you want to > > appear reachable. > > You are in fact OPEN/available/whatever to those select > > watchers, and the > > protocol should support a capability to show different > > presence to different > > people. > > > > So, I don't disagree that we need a more sophisticated range of > > communications states than OPEN/CLOSED - I think we've > > already made a lot of > > progress towards that here. But if you merely want further descriptive > > powers ("Vacation"), that sounds like a job for . I am > > very wary of > > proliferating standardized states like "On the phone" as > > distinguished from > > "Busy" in any way other than through the element, as > > qualifiers for a > > broader presence state. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Tuesday, January 21, 2003 2:08 PM > > > To: 'Peterson, Jon'; 'Vijay K. Gurbani'; hisham.khartabil@nokia.com > > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > > Subject: RE: dnd (was RE: [Simple] Extending for presence) > > > > > > > > > The reason you want a rich sense of presence is because the > > > watcher needs the same vocabulary as the presentity to determine > > > whether to initiate communication. If you set yourself to > > > DND, and I am your supervisor, I may act differently than if you > > > set your state to "Vacation". > > > > > > It is not necessary for either end to have any automated behavior, > > > but they could. What is necessary is that there is no loss of > > > information when coupling my presentity system to your watcher. > > > > > > Check the prior exchange between Paul and I on why CLOSED is not > > > appropriate. I am not CLOSED if I am in DND. I may defer or > > > forward communications you send to me. It is up to you to decide > > > if you will initiate communications if I am in DND. It is up to > > > me to decide if I will accept a communication from you if I am in > > > DND. It is necessary for me to communicate to you that I am in DND, > > > and not CLOSED. That is why we need agreement on a range of > > > states other than Open/Closed. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > > > Sent: Tuesday, January 21, 2003 4:53 PM > > > > To: 'Vijay K. Gurbani'; hisham.khartabil@nokia.com > > > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > > > Subject: dnd (was RE: [Simple] Extending for presence) > > > > > > > > > > > > > > > > I think in Mr. Gurbani's argument below I see some > > > > requirements for our > > > > forthcoming presence extensions, and some unrelated > > requirements for > > > > UA/proxy behavior that is integrated with the setting of > > > > particular presence > > > > states. > > > > > > > > It is clear that inspecting a PIDF document is not the only > > > > way to learn > > > > someone's contact information, and that not everyone who has > > > > your contact > > > > information will subscribe to your presence. People may > > > > attempt to initiate > > > > telephone sessions with my SIP AoR regardless of whether > > or not I am > > > > publishing a 'DND' presence, or even if my state is just > > > > 'CLOSED'. In that > > > > sense, publishing 'DND' alone is not enough, and integrating this > > > > publication with appropriate proxy server and UA behavior > > > > (rejecting calls > > > > as needed, etc) seems like a logical next step. However, I > > > > don't see how > > > > this requirement affects the work at hand - the question of > > > > how we structure > > > > PIDF documents for SIMPLE. > > > > > > > > Personally, I have a hard time seeing why I would want to > > > > publish 'DND' as a > > > > presence instead of 'CLOSED'. I agree with Mr. Khartabil > > > that presence > > > > should be customizable for various watchers - the > > > > requirements of RFC2779 > > > > are very friendly to selectively revealing your 'true' > > > > presence. If I want > > > > some set of preferred watchers to be able to contact me, I > > > > should show them > > > > a state of 'OPEN', and show everyone else a state of > > > > 'CLOSED'. 'DND' seems > > > > to be a form of impolite blocking - I'm here but I don't want > > > > to talk to > > > > you. Why would I ever want to send that instead of 'CLOSED', which > > > > communicates that I am unreachable? I think it is very > > > > limiting to assume > > > > that a presentity has one and only one true presence state > > > > that it reveals > > > > to all watchers. > > > > > > > > Jon Peterson > > > > NeuStar, Inc. > > > > > > > > > -----Original Message----- > > > > > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > > > > > Sent: Tuesday, January 21, 2003 8:34 AM > > > > > To: hisham.khartabil@nokia.com > > > > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > > > > Subject: Re: [Simple] Extending for presence > > > > > > > > > > > > > > > hisham.khartabil@nokia.com wrote: > > > > > > I guess the real question is: Can the device be controlled > > > > > by presence > > > > > > state? or it like just like Paul's example; you hang a > > > > > do-not-disturb > > > > > > sign on the door and hope for the best? > > > > > > > > > > I believe that a person should have the option of > > > > controlling *their* > > > > > own device through *their* presence state. That is, if I > > > > actively set > > > > > my presence/availability state to DND, I would like the > > following > > > > > sequence of events to happen: > > > > > > > > > > 1) My status is set to DND and all watchers are > > informed. The > > > > > presentities associated with the watchers see a big "DND" > > > > > status next to my icon on their UA. > > > > > 2) My presence document is updated so that all my > > > > > interactive devices > > > > > are CLOSED. > > > > > 3) Either a message is sent to all my interactive > > > > devices to stop > > > > > accepting sessions (currently not possible), or > > a script is > > > > > uploaded to my proxy server redirecting all > > > > > communication sessions > > > > > to a recorder (definitely possible). > > > > > > > > > > Arguably, the reason we cannot do (3) currently is that > > we cannot > > > > > control each device we own -- we cannot stop the PSTN phone from > > > > > ringing (short of plugging it out of the wall), nor can > > > we stop the > > > > > cell phone from paging me (again, short of powering it down). I > > > > > believe it is this behavior that is leading us down the path of > > > > > equating DND with "hanging DND on the door and hoping for > > > the best". > > > > > > > > > > In a network where all the devices we own are far more > > > > > controllable, we > > > > > can do better. I think the power of the simple WG is the > > > use of SIP > > > > > as a unifying protocol -- SIP drives all communication > > > > aspects. Other > > > > > IM/P systems like Yahoo! or Jabber do not aim to tie all > > > > communication > > > > > aspects under one protocol. Thus IM is done using native > > > protocols, > > > > > while phone calls are completed using (probably non-SIP) > > > > > gateways to the > > > > > PSTN. This leads to cases where the status of the > > > presentity itself > > > > > is at odds with the status of its devices (i.e. status of > > > > > presentity is > > > > > DND but it still answers the PSTN phone). > > > > > > > > > > DND has received a lot of air-time, and Jonathan wrote: > > > > > > ON DND > > > > > > > > > > > > DND has received a bit of discussion on this thread. To be > > > > > honest, I am > > > > > > at a loss as to why it is not really a combination of two > > > > > things: (1) > > > > > > basic status of CLOSED for each device, and (2) a "task" > > > > of "do not > > > > > > disturb". Paul has defined these tasks as things that > > > > > describe what the > > > > > > presentity is doing, such as "out-to-lunch". "do not > > > > > disturb" seems like > > > > > > another example. > > > > > > > > > > > > It is the usage of the basic status of CLOSED that really > > > > > captures the > > > > > > essence of DND - that attempts to contact with that user > > > > > across their > > > > > > devices will fail. > > > > > > > > > > I don't think the representation of DND is what we are > > > > arguing; it is > > > > > the semantics. DND implies to me that all *my* devices > > > should honor > > > > > my will and not even alert me. But of course, there maybe > > > > cases where > > > > > the department secretary or the CEO should be able to get to > > > > > me. Given > > > > > today's disparate networks, I cannot impose my will on my > > > > > devices. But > > > > > should we preclude us from doing so for tomorrow's > > > networks where it > > > > > maybe more possible to control the device in a far more > > > > > discrete manner? > > > > > > > > > > Thanks, > > > > > > > > > > - vijay > > > > > -- > > > > > Vijay K. Gurbani > > vkg@{lucent.com,research.bell-labs.com,acm.org} > > > > > Wireless Networks Group/Internet Software and Services > > > > > Lucent Technologies/Bell Labs Innovations, 2000 Lucent > > > > Lane, Rm 6G-440 > > > > > Naperville, Illinois 60566 Voice: +1 630 224 0216 > > > > > > > > > > _______________________________________________ > > > > > Simple mailing list > > > > > Simple@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 22 10:49:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28550 for ; Wed, 22 Jan 2003 10:49:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MG78231665 for simple-archive@odin.ietf.org; Wed, 22 Jan 2003 11:07:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MG78J31654 for ; Wed, 22 Jan 2003 11:07:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28540 for ; Wed, 22 Jan 2003 10:48:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MG72J31476; Wed, 22 Jan 2003 11:07:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MG6bJ31419 for ; Wed, 22 Jan 2003 11:06:37 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28520 for ; Wed, 22 Jan 2003 10:48:00 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20631; Wed, 22 Jan 2003 10:51:25 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA25512; Wed, 22 Jan 2003 10:51:25 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jan 2003 10:51:26 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D3F@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" Cc: "Peterson, Jon" , simple@ietf.org Subject: RE: dnd (was RE: [Simple] Extending for presence) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Jan 2003 10:51:22 -0500 > (2) There may be some rule-based mechanism in your presence > agent that > translates your PUBLISHed 'dnd' to a set of OPEN and CLOSED > indications > for particular subscribers. > > Other indications, such as 'open' or 'closed', customized for each > recipient of the notification, determine the precise meaning for each > means of communication. > So, are you arguing for one set of states that a presentity defines to his presence system, and another set of states that the presence system supplies to watchers? That is possible, but I'm not so sure I think it's the right thing to do. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 22 10:53:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28698 for ; Wed, 22 Jan 2003 10:53:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MGBI532407 for simple-archive@odin.ietf.org; Wed, 22 Jan 2003 11:11:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MGBIJ32404 for ; Wed, 22 Jan 2003 11:11:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28691 for ; Wed, 22 Jan 2003 10:52:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MGB4J32380; Wed, 22 Jan 2003 11:11:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MGB0J32358 for ; Wed, 22 Jan 2003 11:11:00 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28679 for ; Wed, 22 Jan 2003 10:52:23 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20882; Wed, 22 Jan 2003 10:55:47 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA26088; Wed, 22 Jan 2003 10:55:47 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jan 2003 10:55:48 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D40@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Drage, Keith (Keith)'" , "Peterson, Jon" , "'Vijay K. Gurbani'" , hisham.khartabil@nokia.com Cc: jdrosen@dynamicsoft.com, simple@ietf.org Subject: RE: dnd (was RE: [Simple] Extending for presence) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Jan 2003 10:55:46 -0500 I think we need to agree on a set of presence states that are reasonably unambiguous with respect to their definitions of the presentity's state as communicated from presentity to watcher. It is up to a given UA or proxy server that implements forwarding based on information it obtains as a watcher to decide how to control calls when the presence state is, for example DND. That is not subject to standardization. Our system, for example, allows the user to create exactly the definition of DND that you espouse, but does not limit her to that definition. Brian > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Wednesday, January 22, 2003 10:24 AM > To: Peterson, Jon; 'Rosen, Brian'; 'Vijay K. Gurbani'; > hisham.khartabil@nokia.com > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: RE: dnd (was RE: [Simple] Extending for presence) > > > To a large extent I concur with Jon. > > I think it is extremely dangerous to identify something > called "DND" and then try and fix semantics to it. This is > because the term already carries the users expectations which > are all substantiallt different. > > My understanding, which may not be anyone elses, but derives > from my enterprise network (PABX) background would be as follows: > > 1) DND applies to the device. Putting DND on my phone does > not stop people barging in the door. Putting a DND label on > the office door does not stop the phone ringing. > > 2) DND is no different to "The device is busy, please try > later". The original implementation of the feature on > enterprise networks returned exactly the same tone as "busy". > The calling user saw no difference between the user actually > using the device and the device being in a state of DND. > > 3) DND is interruptable to anybody with the appropriate > privileges. The managing director can be given a Class of > Service that enables him to sucessfully ring anybody with a > phone in DND. > > It is likely to be unsafe to say these are the only version > of the semantics that people think of with DND, and therefore > whatever is defined, I would urge people not to use the term DND. > > It may well be applicable to try and define something, at > either the user or the device level, that indicates that it > is worth trying later. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > -----Original Message----- > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > Sent: 22 January 2003 00:33 > > To: 'Rosen, Brian'; 'Vijay K. Gurbani'; hisham.khartabil@nokia.com > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > Subject: RE: dnd (was RE: [Simple] Extending for presence) > > > > > > > > I was trying to make a slightly subtler point - I'm not > really arguing > > against the DND state, but against a particular semantic of > > DND, one that > > seems essentially equivalent to CLOSED. If we necessarily > > couple DND with > > rejection of unauthenticated communication attempts via IM or > > voice or what > > have you, then we violate, I think, Mr. Kyzviat's 'fireman > > principle' - that > > is, when we put a DND sign on a hotel door, we assume that we > > would welcome > > an interruption when the building is burning down; but if it > > is impossible > > to be disturbed when we're DND, then actually our state is > really just > > CLOSED. This makes it really hard for me to see how I would > > use DND. The > > fireman principle also could be accommodated, however, if > > hotel emergency > > staff were simply given a different presence than the people > > that come to > > turn down the bed, as it were. > > > > From this thread, I have gotten the impression that many of > > the arguments > > for DND are founded in the understanding that I have only one > > presence that > > I show to every watcher in the world - so therefore I often > > want a state > > that meanas "CLOSED with some exceptions". I was merely > > reinforcing Mr. > > Khartabil's assertion that IMPP has other ways to attack this > > problem, and > > probably better ones. Referring to your previous example, if > > you don't mind > > being disturbed by your wife, then don't send her DND - > that is a much > > simpler approach than trying to figure out a semantic for DND that > > accomodates sending DND to watcher for whom you want to > > appear reachable. > > You are in fact OPEN/available/whatever to those select > > watchers, and the > > protocol should support a capability to show different > > presence to different > > people. > > > > So, I don't disagree that we need a more sophisticated range of > > communications states than OPEN/CLOSED - I think we've > > already made a lot of > > progress towards that here. But if you merely want further > descriptive > > powers ("Vacation"), that sounds like a job for . I am > > very wary of > > proliferating standardized states like "On the phone" as > > distinguished from > > "Busy" in any way other than through the element, as > > qualifiers for a > > broader presence state. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Tuesday, January 21, 2003 2:08 PM > > > To: 'Peterson, Jon'; 'Vijay K. Gurbani'; > hisham.khartabil@nokia.com > > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > > Subject: RE: dnd (was RE: [Simple] Extending for > presence) > > > > > > > > > The reason you want a rich sense of presence is because the > > > watcher needs the same vocabulary as the presentity to determine > > > whether to initiate communication. If you set yourself to > > > DND, and I am your supervisor, I may act differently than if you > > > set your state to "Vacation". > > > > > > It is not necessary for either end to have any automated behavior, > > > but they could. What is necessary is that there is no loss of > > > information when coupling my presentity system to your watcher. > > > > > > Check the prior exchange between Paul and I on why CLOSED is not > > > appropriate. I am not CLOSED if I am in DND. I may defer or > > > forward communications you send to me. It is up to you to decide > > > if you will initiate communications if I am in DND. It is up to > > > me to decide if I will accept a communication from you if I am in > > > DND. It is necessary for me to communicate to you that I > am in DND, > > > and not CLOSED. That is why we need agreement on a range of > > > states other than Open/Closed. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > > > Sent: Tuesday, January 21, 2003 4:53 PM > > > > To: 'Vijay K. Gurbani'; hisham.khartabil@nokia.com > > > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > > > Subject: dnd (was RE: [Simple] Extending for presence) > > > > > > > > > > > > > > > > I think in Mr. Gurbani's argument below I see some > > > > requirements for our > > > > forthcoming presence extensions, and some unrelated > > requirements for > > > > UA/proxy behavior that is integrated with the setting of > > > > particular presence > > > > states. > > > > > > > > It is clear that inspecting a PIDF document is not the only > > > > way to learn > > > > someone's contact information, and that not everyone who has > > > > your contact > > > > information will subscribe to your presence. People may > > > > attempt to initiate > > > > telephone sessions with my SIP AoR regardless of whether > > or not I am > > > > publishing a 'DND' presence, or even if my state is just > > > > 'CLOSED'. In that > > > > sense, publishing 'DND' alone is not enough, and > integrating this > > > > publication with appropriate proxy server and UA behavior > > > > (rejecting calls > > > > as needed, etc) seems like a logical next step. However, I > > > > don't see how > > > > this requirement affects the work at hand - the question of > > > > how we structure > > > > PIDF documents for SIMPLE. > > > > > > > > Personally, I have a hard time seeing why I would want to > > > > publish 'DND' as a > > > > presence instead of 'CLOSED'. I agree with Mr. Khartabil > > > that presence > > > > should be customizable for various watchers - the > > > > requirements of RFC2779 > > > > are very friendly to selectively revealing your 'true' > > > > presence. If I want > > > > some set of preferred watchers to be able to contact me, I > > > > should show them > > > > a state of 'OPEN', and show everyone else a state of > > > > 'CLOSED'. 'DND' seems > > > > to be a form of impolite blocking - I'm here but I don't want > > > > to talk to > > > > you. Why would I ever want to send that instead of > 'CLOSED', which > > > > communicates that I am unreachable? I think it is very > > > > limiting to assume > > > > that a presentity has one and only one true presence state > > > > that it reveals > > > > to all watchers. > > > > > > > > Jon Peterson > > > > NeuStar, Inc. > > > > > > > > > -----Original Message----- > > > > > From: Vijay K. Gurbani [mailto:vkg@lucent.com] > > > > > Sent: Tuesday, January 21, 2003 8:34 AM > > > > > To: hisham.khartabil@nokia.com > > > > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > > > > Subject: Re: [Simple] Extending for presence > > > > > > > > > > > > > > > hisham.khartabil@nokia.com wrote: > > > > > > I guess the real question is: Can the device be controlled > > > > > by presence > > > > > > state? or it like just like Paul's example; you hang a > > > > > do-not-disturb > > > > > > sign on the door and hope for the best? > > > > > > > > > > I believe that a person should have the option of > > > > controlling *their* > > > > > own device through *their* presence state. That is, if I > > > > actively set > > > > > my presence/availability state to DND, I would like the > > following > > > > > sequence of events to happen: > > > > > > > > > > 1) My status is set to DND and all watchers are > > informed. The > > > > > presentities associated with the watchers see > a big "DND" > > > > > status next to my icon on their UA. > > > > > 2) My presence document is updated so that all my > > > > > interactive devices > > > > > are CLOSED. > > > > > 3) Either a message is sent to all my interactive > > > > devices to stop > > > > > accepting sessions (currently not possible), or > > a script is > > > > > uploaded to my proxy server redirecting all > > > > > communication sessions > > > > > to a recorder (definitely possible). > > > > > > > > > > Arguably, the reason we cannot do (3) currently is that > > we cannot > > > > > control each device we own -- we cannot stop the PSTN > phone from > > > > > ringing (short of plugging it out of the wall), nor can > > > we stop the > > > > > cell phone from paging me (again, short of powering > it down). I > > > > > believe it is this behavior that is leading us down > the path of > > > > > equating DND with "hanging DND on the door and hoping for > > > the best". > > > > > > > > > > In a network where all the devices we own are far more > > > > > controllable, we > > > > > can do better. I think the power of the simple WG is the > > > use of SIP > > > > > as a unifying protocol -- SIP drives all communication > > > > aspects. Other > > > > > IM/P systems like Yahoo! or Jabber do not aim to tie all > > > > communication > > > > > aspects under one protocol. Thus IM is done using native > > > protocols, > > > > > while phone calls are completed using (probably non-SIP) > > > > > gateways to the > > > > > PSTN. This leads to cases where the status of the > > > presentity itself > > > > > is at odds with the status of its devices (i.e. status of > > > > > presentity is > > > > > DND but it still answers the PSTN phone). > > > > > > > > > > DND has received a lot of air-time, and Jonathan wrote: > > > > > > ON DND > > > > > > > > > > > > DND has received a bit of discussion on this thread. To be > > > > > honest, I am > > > > > > at a loss as to why it is not really a combination of two > > > > > things: (1) > > > > > > basic status of CLOSED for each device, and (2) a "task" > > > > of "do not > > > > > > disturb". Paul has defined these tasks as things that > > > > > describe what the > > > > > > presentity is doing, such as "out-to-lunch". "do not > > > > > disturb" seems like > > > > > > another example. > > > > > > > > > > > > It is the usage of the basic status of CLOSED that really > > > > > captures the > > > > > > essence of DND - that attempts to contact with that user > > > > > across their > > > > > > devices will fail. > > > > > > > > > > I don't think the representation of DND is what we are > > > > arguing; it is > > > > > the semantics. DND implies to me that all *my* devices > > > should honor > > > > > my will and not even alert me. But of course, there maybe > > > > cases where > > > > > the department secretary or the CEO should be able to get to > > > > > me. Given > > > > > today's disparate networks, I cannot impose my will on my > > > > > devices. But > > > > > should we preclude us from doing so for tomorrow's > > > networks where it > > > > > maybe more possible to control the device in a far more > > > > > discrete manner? > > > > > > > > > > Thanks, > > > > > > > > > > - vijay > > > > > -- > > > > > Vijay K. Gurbani > > vkg@{lucent.com,research.bell-labs.com,acm.org} > > > > > Wireless Networks Group/Internet Software and Services > > > > > Lucent Technologies/Bell Labs Innovations, 2000 Lucent > > > > Lane, Rm 6G-440 > > > > > Naperville, Illinois 60566 Voice: +1 630 224 0216 > > > > > > > > > > _______________________________________________ > > > > > Simple mailing list > > > > > Simple@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 22 14:41:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04544 for ; Wed, 22 Jan 2003 14:41:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MJxwB14700 for simple-archive@odin.ietf.org; Wed, 22 Jan 2003 14:59:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MJxvJ14697 for ; Wed, 22 Jan 2003 14:59:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04541 for ; Wed, 22 Jan 2003 14:41:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MJxaJ14686; Wed, 22 Jan 2003 14:59:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MJw8J14634 for ; Wed, 22 Jan 2003 14:58:08 -0500 Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04531 for ; Wed, 22 Jan 2003 14:39:27 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0MJgqNq012643 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 22 Jan 2003 14:42:53 -0500 (EST) Message-ID: <3E2EF44C.5080602@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: "Peterson, Jon" , simple@ietf.org Subject: Re: dnd (was RE: [Simple] Extending for presence) References: <313680C9A886D511A06000204840E1CF030B5D3F@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF030B5D3F@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Jan 2003 14:43:08 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > So, are you arguing for one set of states that a presentity > defines to his presence system, and another set of states that the > presence system supplies to watchers? That is possible, but I'm > not so sure I think it's the right thing to do. This is only one architecture, something like: presentity --> [PUBLISH] --> PA (filter) --> [NOTIFY] I suspect that such filtering or customized will be fairly common, particularly as more information is added to presence information, such as location information or detailed start/ending times. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 22 15:26:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06098 for ; Wed, 22 Jan 2003 15:26:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MKiC118063 for simple-archive@odin.ietf.org; Wed, 22 Jan 2003 15:44:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MKiCJ18060 for ; Wed, 22 Jan 2003 15:44:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06066 for ; Wed, 22 Jan 2003 15:25:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MKi2J18042; Wed, 22 Jan 2003 15:44:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MKh7J17966 for ; Wed, 22 Jan 2003 15:43:07 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06053 for ; Wed, 22 Jan 2003 15:24:24 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA04136; Wed, 22 Jan 2003 15:27:49 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA06029; Wed, 22 Jan 2003 15:27:50 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jan 2003 15:27:50 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D46@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" Cc: "Peterson, Jon" , simple@ietf.org Subject: RE: dnd (was RE: [Simple] Extending for presence) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Jan 2003 15:27:50 -0500 I'm agreeing with the flow, and the concept. We do this now. The question is, are the states between the entities the same, or different? Does the possible states across the Presentity to PA transaction the same as the possible states from the PA to the Watcher? At the moment, I think they are the same. I think [filter] is simple state substitution. I can filter "Out on the phone" to "Interruptable" for example. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, January 22, 2003 2:43 PM > To: Rosen, Brian > Cc: Peterson, Jon; simple@ietf.org > Subject: Re: dnd (was RE: [Simple] Extending for presence) > > > > So, are you arguing for one set of states that a presentity > > defines to his presence system, and another set of states that the > > presence system supplies to watchers? That is possible, but I'm > > not so sure I think it's the right thing to do. > > This is only one architecture, something like: > > presentity --> [PUBLISH] --> PA (filter) --> [NOTIFY] > > I suspect that such filtering or customized will be fairly common, > particularly as more information is added to presence > information, such > as location information or detailed start/ending times. > > Henning > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 22 15:40:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06546 for ; Wed, 22 Jan 2003 15:40:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MKwDw18586 for simple-archive@odin.ietf.org; Wed, 22 Jan 2003 15:58:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MKwDJ18583 for ; Wed, 22 Jan 2003 15:58:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06530 for ; Wed, 22 Jan 2003 15:39:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MKw4J18572; Wed, 22 Jan 2003 15:58:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MKvQJ18543 for ; Wed, 22 Jan 2003 15:57:26 -0500 Received: from ihemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06491 for ; Wed, 22 Jan 2003 15:38:43 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0MKg9V11818; Wed, 22 Jan 2003 15:42:09 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA12633; Wed, 22 Jan 2003 14:42:08 -0600 (CST) Message-ID: <3E2F021D.9080703@lucent.com> From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: simple@ietf.org Subject: Re: dnd (was RE: [Simple] Extending for presence) References: <313680C9A886D511A06000204840E1CF030B5D46@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Jan 2003 14:42:05 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > I'm agreeing with the flow, and the concept. presentity --> [PUBLISH] --> PA (filter) --> [NOTIFY] >We do this now. > The question is, are the states between the entities the same, > or different? Does the possible states across the > Presentity to PA transaction the same as the possible states from > the PA to the Watcher? > > At the moment, I think they are the same. I think [filter] is > simple state substitution. I can filter "Out on the phone" to > "Interruptable" for example. Maybe you are already implying this, I am not sure. But just to be concrete, I would think that there is some value to having [filter] be more than simple 1-to-1 state substitutions. The PA can selectively advertise me as "Busy" to all watchers except my spouse who sees "Interruptible", for example. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 22 16:56:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08929 for ; Wed, 22 Jan 2003 16:56:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MMESI24524 for simple-archive@odin.ietf.org; Wed, 22 Jan 2003 17:14:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MMESJ24521 for ; Wed, 22 Jan 2003 17:14:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08924 for ; Wed, 22 Jan 2003 16:55:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MMEOJ24512; Wed, 22 Jan 2003 17:14:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MMDLJ24421 for ; Wed, 22 Jan 2003 17:13:21 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08893 for ; Wed, 22 Jan 2003 16:54:36 -0500 (EST) Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0MLw0YH006240; Wed, 22 Jan 2003 16:58:00 -0500 (EST) Message-ID: <3E2F13E4.8040903@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: "Peterson, Jon" , "'Rosen, Brian'" , "'Vijay K. Gurbani'" , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: dnd (was RE: [Simple] Extending for presence) References: <15A2739B7DAA624D8091C65981D7DA8101214D2B@stntexch2.va.neustar.com> <4.3.2.7.2.20030122100754.00b3ceb0@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Jan 2003 16:57:56 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Michael Hammer wrote: > Jonathan, > > What do you expect tech support (customer service) to say to the > individual that calls in and complains that he set DND on his phone > and it still rang and rang during his power lunch with the CEO? Its not our job at IETF to tell operators how to build useful and intuitive network services. It is our job to develop the protocol mechanisms that make it possible to do so. It is certainly possible for someone to build a call filtering application that looks at DND. It is NOT ietfs job to mandate that an operator do so. > > I think there are already well defined semantics associated with > phones that work today and don't need to be messed with. That is not > to say that you can't define other similar type language to describe > what you are trying to do. > > My main question is this: Should the semantics of DND in presence > applications be consistent with the DND of the phone application? I > really think the semantics of DND should be one, and not mean > something different depending on who you talk to. This is supposed > to be convergence, not divergence. The semantics need to be clear, in terms of the user intent. I do not think we can, or should, standardize the application behaviors that ought to occur when they see that a user is DND or busy or on vacation. There are MANY applications that can be built which look at presence. Shall we specify the full set of applications and how all of them must operate? I should hope not. > > If you mean that calls will be "screened for emergencies" then say > that. If you use CLOSED with DND versus OPEN with DND, then the DND > indication is really superfluous and can be omitted. My point was CLOSED with DND has different semantics from OPEN with DND. Since the two are orthogonal, it seems like a good thing to have both. Henning writes: > Again, 'dnd' and 'on vacation' are used only in two ways by > automatons: > > (1) If your CPL-generator subscribes to your presence, it may > translate "on vacation" to a set of filters and rules that implement > the behavior you describe. > > (2) There may be some rule-based mechanism in your presence agent > that translates your PUBLISHed 'dnd' to a set of OPEN and CLOSED > indications for particular subscribers. Only two ways? I can think of lots of ways that automatons use these things in addition to the two above: 1. rendering of icons in a buddy list application 2. speaking of the presence state in a voice app 3. creation of an appropriate voicemail greeting for callers 4. automated conferencing applications which call everyone when their status is something that indicates now is a good time -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 22 16:57:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09012 for ; Wed, 22 Jan 2003 16:57:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MMG9E24589 for simple-archive@odin.ietf.org; Wed, 22 Jan 2003 17:16:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MMG9J24586 for ; Wed, 22 Jan 2003 17:16:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08988 for ; Wed, 22 Jan 2003 16:57:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MMG2J24572; Wed, 22 Jan 2003 17:16:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MMFVJ24552 for ; Wed, 22 Jan 2003 17:15:31 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08971 for ; Wed, 22 Jan 2003 16:56:47 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h0MM00816709; Wed, 22 Jan 2003 22:00:00 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jan 2003 17:02:43 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214D35@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Jonathan Rosenberg'" Cc: Paul Kyzivat , simple@ietf.org Subject: RE: quantifying activity (was RE: [Simple] Extending fo r pr esence) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Jan 2003 17:02:35 -0500 Priority and activity may be conflicting in so far as they are both used to determine which contact in a set is the best place to reach a user. If a contact has a high priority and low activity, should that be preferred over a contact with a low priority and high activity? I don't see how the two could not need to be considered simultaneously. In some sense, activity contributes to the decision of preference that one makes based on priority. That's why I was speculating on whether or not we could combine the two, or at least to define how they interrelate. I don't have a particularly strong intuition about how to do this, though. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, January 21, 2003 11:15 PM > To: Peterson, Jon > Cc: Paul Kyzivat; simple@ietf.org > Subject: Re: quantifying activity (was RE: [Simple] Extending > for pr esence) > [snip] > > > > > If we want a bucket for this in the current document, > though, I wonder if > > the relative 'priority' attribute of elements, > which is already > > specified in PIDF, would be a good place for quantified > activity information > > to be recorded. Presumably, one use of activity information > would be to > > discover the best contact in a set; it might be confusing > to have a separate > > parameter for this that conflicts with the existing > priority parameter in > > PIDF. It also already has the connotation that it can be > set manually. > > I don't see this is conflicting at all. THe priority conveys something > quite different - which one of these is preferred by the presentity. > Thats not the same as saying "this one hasn't been used by the > presentity in a while". Indeed, it may be inactive but still preferred > (say, because there is a store and forward app running there). > > In fact, the active/idle indication makes sense for single device > systems, where priority clearly doesnt help. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 22 17:20:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09605 for ; Wed, 22 Jan 2003 17:20:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MMcFF25971 for simple-archive@odin.ietf.org; Wed, 22 Jan 2003 17:38:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MMcFJ25968 for ; Wed, 22 Jan 2003 17:38:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09598 for ; Wed, 22 Jan 2003 17:19:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MMc8J25959; Wed, 22 Jan 2003 17:38:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0MMbcJ25931 for ; Wed, 22 Jan 2003 17:37:38 -0500 Received: from mailgate.pit.comms.marconi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09571 for ; Wed, 22 Jan 2003 17:18:54 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA08790; Wed, 22 Jan 2003 17:22:18 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA21320; Wed, 22 Jan 2003 17:22:19 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jan 2003 17:22:19 -0500 Message-ID: <313680C9A886D511A06000204840E1CF030B5D47@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Vijay K. Gurbani'" Cc: simple@ietf.org Subject: RE: dnd (was RE: [Simple] Extending for presence) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Jan 2003 17:22:18 -0500 > > Maybe you are already implying this, I am not sure. But just to be > concrete, I would think that there is some value to having [filter] be > more than simple 1-to-1 state substitutions. The PA can selectively > advertise me as "Busy" to all watchers except my spouse who sees > "Interruptible", for example. > Yes, the filter can be dependent on watcher. That behavior is only dependent on the implementation of the PA, and thus is not a standardization issue. For that matter, saying that [filter] is state for state substitution is really also a single entity implementation issue. The only thing that we standardize is the states expressed across the boundaries. In this case, I'm advocating that the states across the Presentity to PA boundary be the same as the states across the PA to Watcher boundary. Brian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 22 19:43:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12695 for ; Wed, 22 Jan 2003 19:43:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0N11tP01384 for simple-archive@odin.ietf.org; Wed, 22 Jan 2003 20:01:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N11sJ01380 for ; Wed, 22 Jan 2003 20:01:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12670 for ; Wed, 22 Jan 2003 19:43:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N11fJ01370; Wed, 22 Jan 2003 20:01:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N0xWJ01191 for ; Wed, 22 Jan 2003 19:59:32 -0500 Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12632 for ; Wed, 22 Jan 2003 19:40:45 -0500 (EST) Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h0N0hf820528; Thu, 23 Jan 2003 00:43:41 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Jan 2003 19:46:24 -0500 Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214D40@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Jonathan Rosenberg'" Cc: "'Rosen, Brian'" , "'Vijay K. Gurbani'" , hisham.khartabil@nokia.com, simple@ietf.org Subject: RE: dnd (was RE: [Simple] Extending for presence) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 22 Jan 2003 19:46:23 -0500 inline. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, January 21, 2003 11:37 PM > To: Peterson, Jon > Cc: 'Rosen, Brian'; 'Vijay K. Gurbani'; hisham.khartabil@nokia.com; > simple@ietf.org > Subject: Re: dnd (was RE: [Simple] Extending for presence) > [snip] > > Well, you aren't really OPEN to those select watchers, either. You are > telling them that you are really busy, and would prefer not to be > contacted, but communciations attempts from those people will succeed if > tried. > > Again, I argue that this is really just a basic status of OPEN, combined > with a "what am i doing" status of "do not disturb", which is one of an > enumerated set of such things. > > FOr those folks for whom I am DND and won't accept communications, the > combination of CLOSED and "do not disturb" would make sense. > We're on the same page on all of the above. The key thing for me is that the flavor text ("what I am doing") and the basic status are separable. It is a slightly thornier issue how much flavor text needs to be standardized - it is nice to be able to set away messages arbitrarily, and also nice for automata to make decisions based on something other than basic status. I basically agree with your statement below that finding a dozen or so enumerated standardized statuses is probably the best approach. > Later on, Adam Roach writes: > > > > The ability to display translated statuses is admittedly > > valuable in certain contexts. In fact, I think we need to > > take this to its logical conclusion: when we're coming > > up with these enumerated types, we should do a survey of > > various cultures, to make sure that we don't miss the > > English "At Tea" and Spanish "Siesta" and whatever variety > > of other specific varients of "away" might exist in other > > cultures around the world. > > > > Or, we could just attempt to parameterize the sort of things > > that characterize typical "away" statuses, and allow > > applications and/or users to set them as appropriate. Then, > > even if I don't understand what's in the freeform text field > > (or don't have a good intuitive feel for when siesta starts > > and ends), at least I can figure out what the nature of the > > break is even if I don't know what it would be called in > > English (assuming, that is, that there is even a cultural > > equivalent). > > > > I would be willing to consider such a thing, if you could propose a > concrete mechanism which is actually useful and usable. A duration > parameter hardly seems to cut it, given the issues raised multiple times > surrounding i8n, icons, and other things that people want to do. > I think Adam's core concept here is sound, though I agree that it might be difficult to agre on the set of operands we'd want to use. > The essence of your argument is that, because we can't enumerate > EVERYTHING, we should enumerate NOTHING. I disagree. I think that, if we > scope it to a dozen or so statuses seen in existing systems today with a > few more for fun, we can have a very useful and interoperable list. > Indeed, we might decide to establish an IANA registry for said statuses, > to make it easier to add "in a siesta" down the road, if that is what we > need to have. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 23 00:12:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17512 for ; Thu, 23 Jan 2003 00:12:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0N5UbV16154 for simple-archive@odin.ietf.org; Thu, 23 Jan 2003 00:30:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N5UaJ16151 for ; Thu, 23 Jan 2003 00:30:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17506 for ; Thu, 23 Jan 2003 00:11:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N5UTJ16127; Thu, 23 Jan 2003 00:30:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N5T5J16085 for ; Thu, 23 Jan 2003 00:29:05 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17493 for ; Thu, 23 Jan 2003 00:10:13 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.52]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0N5DbYH006503; Thu, 23 Jan 2003 00:13:37 -0500 (EST) Message-ID: <3E2F79FD.1050703@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: Paul Kyzivat , simple@ietf.org Subject: Re: quantifying activity (was RE: [Simple] Extending fo r pr esence) References: <15A2739B7DAA624D8091C65981D7DA8101214D35@stntexch2.va.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 23 Jan 2003 00:13:33 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I would argue that ALL of the status elements ultimately contribute to the decision about which contact is best to reach a user. FOr example, if the presentity publishes that one tuple supports video, and the other audio, but the audio is lower priority, and the video is active, and the watcher wants to make a video call, it would probably select the video tuple. -Jonathan R. Peterson, Jon wrote: > Priority and activity may be conflicting in so far as they are both used to > determine which contact in a set is the best place to reach a user. If a > contact has a high priority and low activity, should that be preferred over > a contact with a low priority and high activity? I don't see how the two > could not need to be considered simultaneously. In some sense, activity > contributes to the decision of preference that one makes based on priority. > That's why I was speculating on whether or not we could combine the two, or > at least to define how they interrelate. I don't have a particularly strong > intuition about how to do this, though. > > Jon Peterson > NeuStar, Inc. > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Sent: Tuesday, January 21, 2003 11:15 PM >>To: Peterson, Jon >>Cc: Paul Kyzivat; simple@ietf.org >>Subject: Re: quantifying activity (was RE: [Simple] Extending >>for pr esence) >> > > [snip] > >>>If we want a bucket for this in the current document, >> >>though, I wonder if >> >>>the relative 'priority' attribute of elements, >> >>which is already >> >>>specified in PIDF, would be a good place for quantified >> >>activity information >> >>>to be recorded. Presumably, one use of activity information >> >>would be to >> >>>discover the best contact in a set; it might be confusing >> >>to have a separate >> >>>parameter for this that conflicts with the existing >> >>priority parameter in >> >>>PIDF. It also already has the connotation that it can be >> >>set manually. >> >>I don't see this is conflicting at all. THe priority conveys something >>quite different - which one of these is preferred by the presentity. >>Thats not the same as saying "this one hasn't been used by the >>presentity in a while". Indeed, it may be inactive but still preferred >>(say, because there is a store and forward app running there). >> >>In fact, the active/idle indication makes sense for single device >>systems, where priority clearly doesnt help. >> >>-Jonathan R. >>-- >>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >>Chief Scientist First Floor >>dynamicsoft East Hanover, NJ 07936 >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 23 00:23:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17693 for ; Thu, 23 Jan 2003 00:23:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0N5fO517162 for simple-archive@odin.ietf.org; Thu, 23 Jan 2003 00:41:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N5fOJ17159 for ; Thu, 23 Jan 2003 00:41:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17670 for ; Thu, 23 Jan 2003 00:22:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N5fJJ17147; Thu, 23 Jan 2003 00:41:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N5ePJ17105 for ; Thu, 23 Jan 2003 00:40:25 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17659 for ; Thu, 23 Jan 2003 00:21:33 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.52]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0N5P3YH006513; Thu, 23 Jan 2003 00:25:03 -0500 (EST) Message-ID: <3E2F7CAB.40805@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: "Peterson, Jon" , Paul Kyzivat , simple@ietf.org Subject: Re: quantifying activity (was RE: [Simple] Extending for pr esence) References: <4.3.2.7.2.20030122094404.00b3cda8@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 23 Jan 2003 00:24:59 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Michael Hammer wrote: > Jon, > Time answers the question of how long has it been since you originated > or responded to communications using that device. But, out of > curiosity, what sort of metric other than time were you thinking of? I > think time can be applied equally to two different devices. In my email (to which Jon responded) I list other metrics, and indeed, argue why time is not a good metric for devices like cell phones. -Jonathan R. >> > -----Original Message----- >> > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >> > Sent: Monday, January 20, 2003 1:22 PM >> > To: Paul Kyzivat >> > Cc: simple@ietf.org >> > Subject: Re: [Simple] Extending for presence >> > >> [snip] >> > >> > ON ACTIVITY >> > >> > I'd next like to comment on what you call "activity". I think there >> is a >> > need for some type of standardization to support this concept. There >> are >> > several different ways in which the concept can be quantified: >> > >> > * the amount of TIME since the presentity last interacted >> > with the device >> > * the physical DISTANCE of the presentity from the device >> > * the PROBABILITY that a communications request to the device >> will be >> > answered by the presentity >> > >> > I think existing IM systems very much rely on the TIME definition. >> > However, in my experience that definition is heavily tied to the >> concept >> > of a PC application. On a cell phone, where the user normally does not >> > interact with the device continously, this tends to a poor definition. >> > For cell phones, the DISTANCE is a better measure, but even that is not >> > neccesarily a good one. The phone may be near me, but its tucked away >> > into a laptop bag and so I really am idle with respect to it, since I >> > can't hear it or reach it. >> > >> > Arguably, one approach is to separate the means for measuring >> "activity" >> > or "idleness" from its representation. Using something like a >> > probability, for example, would allow the metric to work across >> devices, >> > and for it to be measured differently for different devices. >> > >> > Another issue to be factored into the decision about how to represent >> > idleness is how frequently it needs to be reported to the watcher in >> > order to be useful. A time-based measure has the nice benefit that the >> > watcher can continously know how long the presentity has been idle, >> > simply by conveying the time of last activity in the presence >> > notifications. >> > >> > One final point on activity. Some have stated that the defining >> > characteristic of this status is that it is implicitly computed by the >> > system. I disagree. I think it may be perfectly valid to set >> > it explicitly. >> > >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 23 09:01:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07906 for ; Thu, 23 Jan 2003 09:01:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NEK1r28088 for simple-archive@odin.ietf.org; Thu, 23 Jan 2003 09:20:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NEK0J28076 for ; Thu, 23 Jan 2003 09:20:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07869 for ; Thu, 23 Jan 2003 09:00:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NEJYJ28038; Thu, 23 Jan 2003 09:19:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NDwBJ26401 for ; Thu, 23 Jan 2003 08:58:11 -0500 Received: from mail-blue.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07112 for ; Thu, 23 Jan 2003 08:39:07 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 8D4174CF16; Thu, 23 Jan 2003 08:42:34 -0500 (EST) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id IAA28309; Thu, 23 Jan 2003 08:42:32 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 126717B4D; Thu, 23 Jan 2003 08:42:32 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Jonathan Rosenberg Cc: mankin@psg.com, simple@ietf.org, =?ISO-8859-1?Q?Patrik_F=C3=A4lts?= =?ISO-8859-1?Q?tr=C3=B6m?= Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <20030123134232.126717B4D@berkshire.research.att.com> Subject: [Simple] Re: Discuss on SIMPLE doc Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 23 Jan 2003 08:42:32 -0500 In message <3E2D87CE.5030808@dynamicsoft.com>, Jonathan Rosenberg writes: >This note is in response to comments raised by Steve Bellovin during the >IESG review of the simple specs. > >Steve, thanks for the comments. Responses inline. > > > ------- Forwarded Message > > > > From: "Steven M. Bellovin" > > To: IESG Secretary > > Cc: Internet Engineering Steering Group > > Subject: Re: Evaluation: draft-ietf-simple-winfo-package - A Session >Initiation Protocol (SIP)Event Template-Package for Watcher Information >to Proposed Standard > > > > draft-ietf-simple-presence-09.txt: > > 6.3 should say "some other document will define > > a filter language". The current language is too vague. (This > > can be fixed with an RFC editor's note.) > >It looks like I need to rev these for other comments too. So, I changed >to text to be more specific. Here is how that paragraph reads: > >One type of body that can be included in a SUBSCRIBE request is a >filter document. These filters request that only certain presence >events generate notifications, or would ask for a restriction on the >set of data returned in {\NOTIFY} requests. For example, a presence >filter might specify that the notifications should only be generated >when the status of the user's instant inbox \citenonnorm{rfc2778} >changes. It might also say that the content of these notifications >should only contain the status of the instant inbox. Filter documents >are not specified in this document, and at the time of writing, are >expected to be the subject of future standardization activity. Looks good. > > > > > 6.6.1 -- which authentication methods are mandatory to > > implement? Ditto 9.2 and 9.4. Also see 6.2 in > > draft-ietf-simple-winfo-package-04.txt > >RFC 3261 mandates digest for authentication purposes. I've added a >sentence to 6.6.1 which states: > >Note that digest is mandatory to implement, as >specified in RFC 3261. > >Regarding 9.2 (which discusses autehntication and message integrity) and >9.4 (which discusses replay), digest can address the authentication and >replay issues (its not perfect of course). Do you feel it needs to state >baseline mechanisms beyond those specified in RFC 3261? It was always my >assumption that it did not, which is why there are no normative >statements about security mechanisms. I confess that I don't have 3261 memorized... You're referring to HTTP Digest, as described in Section 22 of 3261, as well as 26.3.2.1 as called out in this draft? My problem with 6.6.1 is with the language "any of the mechanisms". HTTP Digest is adequate for authentication, but that's not what this says; it says "3261 defines several; pick one". Your suggested change resolves the problem. For 9.2 and 9.4, the problem is permissive wording. For example, 9.2 says "IPs authentication and message integrity features can be used." It wasn't clear to me that you were mandating those mechanisms. Similarly, 9.4 says "SIP S/MIME can provide" and "HTTP digest authentication MAY be used". What is mandatory to implement here? SIP is a sufficiently rich protocol that it isn't always clear which elements of it apply to which profiles or instantiations -- I'm asking for just a bit more prescriptive language in the spec. > > > > > > It appears to be possible to probe the name space to see what > > user names are valid. Is this a concern? > >It doesn't seem any more of an issue than it would be in any other >application protocol. I don't recall it being raised as a concern >specifically. > >Note that its not specific to presence. The presence behavior directly >inherits from baseline sip. In baseline SIP you'd get a 404 response if >the user is not valid in that domain. > >Thanks, >Jonathan R. > >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > > > > --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 23 10:00:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09555 for ; Thu, 23 Jan 2003 10:00:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NFIau32151 for simple-archive@odin.ietf.org; Thu, 23 Jan 2003 10:18:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NFIaJ32148 for ; Thu, 23 Jan 2003 10:18:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09537 for ; Thu, 23 Jan 2003 09:59:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NFIAJ32127; Thu, 23 Jan 2003 10:18:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NFHJJ32096 for ; Thu, 23 Jan 2003 10:17:19 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09472 for ; Thu, 23 Jan 2003 09:58:14 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NF1tql026486; Thu, 23 Jan 2003 10:01:56 -0500 (EST) Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-76.cisco.com [161.44.87.76]) by cia.cisco.com (Mirapoint) with ESMTP id ABN42091; Thu, 23 Jan 2003 09:50:44 -0500 (EST) Message-Id: <4.3.2.7.2.20030123095919.00b35210@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jonathan Rosenberg From: Michael Hammer Subject: Re: quantifying activity (was RE: [Simple] Extending fo r pr esence) Cc: "Peterson, Jon" , Paul Kyzivat , simple@ietf.org In-Reply-To: <3E2F79FD.1050703@dynamicsoft.com> References: <15A2739B7DAA624D8091C65981D7DA8101214D35@stntexch2.va.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 23 Jan 2003 10:00:45 -0500 Jonathon, I would argue the opposite. Perhaps the presentity can only support one video feed at a time (due to BW constraints), thus while the video is active, he would not want to receive another and is trying to tell any watchers to IM him instead. Mike At 12:13 AM 1/23/2003 -0500, Jonathan Rosenberg wrote: >I would argue that ALL of the status elements ultimately contribute to the >decision about which contact is best to reach a user. FOr example, if the >presentity publishes that one tuple supports video, and the other audio, >but the audio is lower priority, and the video is active, and the watcher >wants to make a video call, it would probably select the video tuple. > >-Jonathan R. > >Peterson, Jon wrote: >>Priority and activity may be conflicting in so far as they are both used to >>determine which contact in a set is the best place to reach a user. If a >>contact has a high priority and low activity, should that be preferred over >>a contact with a low priority and high activity? I don't see how the two >>could not need to be considered simultaneously. In some sense, activity >>contributes to the decision of preference that one makes based on priority. >>That's why I was speculating on whether or not we could combine the two, or >>at least to define how they interrelate. I don't have a particularly strong >>intuition about how to do this, though. >>Jon Peterson >>NeuStar, Inc. >> >>>-----Original Message----- >>>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>>Sent: Tuesday, January 21, 2003 11:15 PM >>>To: Peterson, Jon >>>Cc: Paul Kyzivat; simple@ietf.org >>>Subject: Re: quantifying activity (was RE: [Simple] Extending >>>for pr esence) >>[snip] >> >>>>If we want a bucket for this in the current document, >>> >>>though, I wonder if >>> >>>>the relative 'priority' attribute of elements, >>> >>>which is already >>> >>>>specified in PIDF, would be a good place for quantified >>> >>>activity information >>> >>>>to be recorded. Presumably, one use of activity information >>> >>>would be to >>> >>>>discover the best contact in a set; it might be confusing >>> >>>to have a separate >>> >>>>parameter for this that conflicts with the existing >>> >>>priority parameter in >>> >>>>PIDF. It also already has the connotation that it can be >>> >>>set manually. >>> >>>I don't see this is conflicting at all. THe priority conveys something >>>quite different - which one of these is preferred by the presentity. >>>Thats not the same as saying "this one hasn't been used by the >>>presentity in a while". Indeed, it may be inactive but still preferred >>>(say, because there is a store and forward app running there). >>> >>>In fact, the active/idle indication makes sense for single device >>>systems, where priority clearly doesnt help. >>> >>>-Jonathan R. >>>-- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >>>Chief Scientist First Floor >>>dynamicsoft East Hanover, NJ 07936 >>>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>>http://www.jdrosen.net PHONE: (973) 952-5000 >>>http://www.dynamicsoft.com > >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 23 10:11:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09749 for ; Thu, 23 Jan 2003 10:11:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NFTaQ32558 for simple-archive@odin.ietf.org; Thu, 23 Jan 2003 10:29:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NFTaJ32555 for ; Thu, 23 Jan 2003 10:29:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09742 for ; Thu, 23 Jan 2003 10:10:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NFTRJ32545; Thu, 23 Jan 2003 10:29:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NFSrJ32527 for ; Thu, 23 Jan 2003 10:28:53 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09724 for ; Thu, 23 Jan 2003 10:09:47 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NFDRVE029667; Thu, 23 Jan 2003 10:13:28 -0500 (EST) Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-76.cisco.com [161.44.87.76]) by cia.cisco.com (Mirapoint) with ESMTP id ABN42265; Thu, 23 Jan 2003 10:02:37 -0500 (EST) Message-Id: <4.3.2.7.2.20030123100301.00b4f1c8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jonathan Rosenberg From: Michael Hammer Subject: Re: quantifying activity (was RE: [Simple] Extending for pr esence) Cc: "Peterson, Jon" , Paul Kyzivat , simple@ietf.org In-Reply-To: <3E2F7CAB.40805@dynamicsoft.com> References: <4.3.2.7.2.20030122094404.00b3cda8@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 23 Jan 2003 10:12:37 -0500 Jonathan, In one of my earlier postings, I suggested that there were two types of time-related activity indications, one which is an actual measure of last time the device sent or received a communication, two an explicit indication by the user that he doesn't intend to use the device until some specific time. But, I think that the latter is a indication of predisposition that could also be corrected when the user changes his mind. There may be a difference in time-scale consideration here. I do think it useful, if someone attempts to call me on my cell phone since that is often viewed as personally with me and for many people is often on. But, if you did have an indication that my phone has not sent nor answered a call in the last several hours, that this method is not the best right now. Just because one indicator is not the best method for all devices does not mean that it might not be useful for others. And either way, you are not going to drive the probability of answer down to zero. People may simply not want to talk to the caller. Mike At 12:24 AM 1/23/2003 -0500, Jonathan Rosenberg wrote: >inline. > >Michael Hammer wrote: >>Jon, > >>Time answers the question of how long has it been since you originated or >>responded to communications using that device. But, out of curiosity, >>what sort of metric other than time were you thinking of? I think time >>can be applied equally to two different devices. > >In my email (to which Jon responded) I list other metrics, and indeed, >argue why time is not a good metric for devices like cell phones. > >-Jonathan R. > >>> > -----Original Message----- >>> > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>> > Sent: Monday, January 20, 2003 1:22 PM >>> > To: Paul Kyzivat >>> > Cc: simple@ietf.org >>> > Subject: Re: [Simple] Extending for presence >>> > >>>[snip] >>> > >>> > ON ACTIVITY >>> > >>> > I'd next like to comment on what you call "activity". I think there is a >>> > need for some type of standardization to support this concept. There are >>> > several different ways in which the concept can be quantified: >>> > >>> > * the amount of TIME since the presentity last interacted >>> > with the device >>> > * the physical DISTANCE of the presentity from the device >>> > * the PROBABILITY that a communications request to the device will be >>> > answered by the presentity >>> > >>> > I think existing IM systems very much rely on the TIME definition. >>> > However, in my experience that definition is heavily tied to the concept >>> > of a PC application. On a cell phone, where the user normally does not >>> > interact with the device continously, this tends to a poor definition. >>> > For cell phones, the DISTANCE is a better measure, but even that is not >>> > neccesarily a good one. The phone may be near me, but its tucked away >>> > into a laptop bag and so I really am idle with respect to it, since I >>> > can't hear it or reach it. >>> > >>> > Arguably, one approach is to separate the means for measuring "activity" >>> > or "idleness" from its representation. Using something like a >>> > probability, for example, would allow the metric to work across devices, >>> > and for it to be measured differently for different devices. >>> > >>> > Another issue to be factored into the decision about how to represent >>> > idleness is how frequently it needs to be reported to the watcher in >>> > order to be useful. A time-based measure has the nice benefit that the >>> > watcher can continously know how long the presentity has been idle, >>> > simply by conveying the time of last activity in the presence >>> > notifications. >>> > >>> > One final point on activity. Some have stated that the defining >>> > characteristic of this status is that it is implicitly computed by the >>> > system. I disagree. I think it may be perfectly valid to set >>> > it explicitly. >>> > >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple > >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 23 11:11:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11601 for ; Thu, 23 Jan 2003 11:11:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NGU3704721 for simple-archive@odin.ietf.org; Thu, 23 Jan 2003 11:30:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NGU3J04718 for ; Thu, 23 Jan 2003 11:30:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11583 for ; Thu, 23 Jan 2003 11:10:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NGTUJ04633; Thu, 23 Jan 2003 11:29:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NGSXJ04582 for ; Thu, 23 Jan 2003 11:28:33 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11470 for ; Thu, 23 Jan 2003 11:09:26 -0500 (EST) Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NGDZtm016762; Thu, 23 Jan 2003 11:13:35 -0500 (EST) Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-76.cisco.com [161.44.87.76]) by cia.cisco.com (Mirapoint) with ESMTP id ABN43033; Thu, 23 Jan 2003 11:02:44 -0500 (EST) Message-Id: <4.3.2.7.2.20030123105557.00b35318@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jonathan Rosenberg From: Michael Hammer Subject: Re: dnd (was RE: [Simple] Extending for presence) Cc: "Peterson, Jon" , "'Rosen, Brian'" , "'Vijay K. Gurbani'" , hisham.khartabil@nokia.com, simple@ietf.org In-Reply-To: <3E2F13E4.8040903@dynamicsoft.com> References: <15A2739B7DAA624D8091C65981D7DA8101214D2B@stntexch2.va.neustar.com> <4.3.2.7.2.20030122100754.00b3ceb0@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 23 Jan 2003 11:12:44 -0500 Jonathan, At 04:57 PM 1/22/2003 -0500, Jonathan Rosenberg wrote: >The semantics need to be clear, in terms of the user intent. That is what I am attempting to do. When you add a new meaning to a well-known term you create ambiguity. That does not help clarity. I am not trying to specify implementation, just as you are not by choosing to use such a name. I am only trying to avoid confusing the developers that eventually will have to use this stuff. Mike _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 23 18:19:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23976 for ; Thu, 23 Jan 2003 18:19:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0NNcX203109 for simple-archive@odin.ietf.org; Thu, 23 Jan 2003 18:38:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NNcXJ03106 for ; Thu, 23 Jan 2003 18:38:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23939 for ; Thu, 23 Jan 2003 18:19:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NNcOJ03089; Thu, 23 Jan 2003 18:38:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NNbtJ03051 for ; Thu, 23 Jan 2003 18:37:55 -0500 Received: from nycsmtp1out.rdc-nyc.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23923 for ; Thu, 23 Jan 2003 18:18:40 -0500 (EST) Received: from BOBDEV (66-108-193-77.nyc.rr.com [66.108.193.77]) by nycsmtp1out.rdc-nyc.rr.com (8.12.1/Road Runner SMTP Server 1.0) with ESMTP id h0NNM6wr014394 for ; Thu, 23 Jan 2003 18:22:06 -0500 (EST) Reply-To: From: "Bob Wyman" To: Message-ID: <007701c2c336$3f772b60$6401a8c0@BOBDEV> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0078_01C2C30C.56A12360" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Simple] SIP soon to be useless due to patents... Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 23 Jan 2003 18:22:07 -0500 This is a multi-part message in MIME format. ------=_NextPart_000_0078_01C2C30C.56A12360 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Today, the USPTO published 8 patent applications which explicitly reference the Session Initiation Protocol. This means there are now 372 pending patent applications that make specific reference to the "Session Initation Protocol." New applications seem to be getting filed at the rate of 10 to 20 per week and the trend seems to be picking up... If you're working in the SIP space, you will be hearing alot about patents in the future... The result of all these patent applications may one day be a rash of issued patents that pin down the SIP technology in such detail that exploitation of the system will be virtually impossible. No matter how much people may support SIP today or wish it well, the fact that it is rapidly becoming encumbered by patents is a real problem that may severely limit its real utility. Clearly, what is happening is a "land rush" of patent filings by people who are attempting to exploit the fact that the SIP space is still a new one and trying to pin down what most would consider to be "obvious" ideas that, because the space is new, have little documented prior art to cover them. Few people are aware, I think, that the current law requires that most patent applications be published 18 months after they are filed. Also, that there exists a two month window after the date of publication during which it is possible for third-parties to submit prior art to the patent office for consideration during the examination of the patent. In other words, for the first time, we have the ability now to fight bad patents cheaply -- before they issue. Lawrence Lessig has been asking "What have we done?" to protect ourselves from the tyranny of excessive patents and perpetual copyrights. Well, one thing we *can* do is stop bad patents before they are issued. I recommend that everyone who wants SIP to remain useful should check the USPTO site every Thursday to see what new applications have been published. This situation is getting really bad. See below links to just this week's new "SIP" related patents. Some just mention SIP but others try to get patents on it's use. Note: My favorite recent application was publised on 9 January. This application (20030009463) is an attempt by Worldcom to patent the idea of using XML as the format of transaction log files. How callous can you get? =20 bob wyman =20 SIP Related Patent Applications published today by the US PTO: (i.e. 8 of the 372 now pending...) There remains a two month window to file third party submissions of prior art in these cases: PUB. APP. NO. Title=09 1 20030018717 Extensible = information distribution mechanism for session management =09 2 20030018704 = Network = presence and location agent =09 3 20030018703 Smart = appliance network system and communication protocol =09 4 20030018480 = Method and apparatus for transmitting voice over internet =09 5 20030016679 = Method and apparatus to perform network routing =09 6 20030016664 = System and = method for providing rapid rerouting of real-time multi-media flows =09 7 20030016630 = Method and = system for providing adaptive bandwidth control for real-time communication =09 8 20030016627 = System and = method for determining flow quality statistics for real-time transport protocol data flows =09 =20 =20 ------=_NextPart_000_0078_01C2C30C.56A12360 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
   =20 Today, the USPTO published 8 patent applications which explicitly = reference the=20 Session Initiation Protocol. This means there are now 372 pending patent = applications that make specific reference to the "Session Initation = Protocol."=20 New applications seem to be getting filed at the rate of 10 to 20 per = week and=20 the trend seems to be picking up... If you're working in the SIP space, = you will=20 be hearing alot about patents in the future...
   =20 The result of all these patent applications may one day be a rash of = issued=20 patents that pin down the SIP technology in such detail that = exploitation of the=20 system will be virtually impossible. No matter how much people may = support SIP=20 today or wish it well, the fact that it is rapidly becoming encumbered = by=20 patents is a real problem that may severely limit its real utility. = Clearly,=20 what is happening is a "land rush" of patent filings by people who are=20 attempting to exploit the fact that the SIP space is still a new one and = trying=20 to pin down what most would consider to be "obvious" ideas that, because = the=20 space is new, have little documented prior art to cover=20 them.
   =20 Few people are aware, I think, that the current law requires that most = patent=20 applications be published 18 months after they are filed. Also, = that there=20 exists a two month window after the date of publication during which it = is=20 possible for third-parties to submit prior art to the patent office for=20 consideration during the examination of the patent. In other words, for = the=20 first time, we have the ability now to fight bad patents cheaply -- = before they=20 issue. Lawrence Lessig has been asking "What have we done?" to protect = ourselves=20 from the tyranny of excessive patents and perpetual copyrights. Well, = one thing=20 we *can* do is stop bad patents before they are = issued.
    I=20 recommend that everyone who wants SIP to remain useful should check the = USPTO=20 site every Thursday to see what new applications have been published. = This=20 situation is getting really bad.
    See below links to just this week's new = "SIP" related=20 patents. Some just mention SIP but others try to get patents on it's = use. Note:=20 My favorite recent application was publised on 9 January. This = application=20 (20030009463) is an attempt by Worldcom to patent the idea of using XML = as the=20 format of transaction log files. How callous can you=20 get?
 
        = bob=20 wyman
 
SIP = Related Patent=20 Applications published today by the US PTO: (i.e. 8 of the 372 now = pending...)=20 There remains a two month window to file third party submissions of = prior art in=20 these cases:
PUB. APP. NO. Title
1 20030018717 Extensible=20 information distribution mechanism for session management =
2 20030018704 Network=20 presence and location agent
3 20030018703 Smart=20 appliance network system and communication protocol
4 20030018480 Method=20 and apparatus for transmitting voice over internet
5 20030016679 Method=20 and apparatus to perform network routing
6 20030016664 System=20 and method for providing rapid rerouting of real-time multi-media = flows=20
7 20030016630 Method=20 and system for providing adaptive bandwidth control for real-time=20 communication
8 20030016627 System=20 and method for determining flow quality statistics for real-time = transport=20 protocol data flows =
 
 
------=_NextPart_000_0078_01C2C30C.56A12360-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 24 11:52:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24697 for ; Fri, 24 Jan 2003 11:52:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OHBKE13578 for simple-archive@odin.ietf.org; Fri, 24 Jan 2003 12:11:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OHBKJ13575 for ; Fri, 24 Jan 2003 12:11:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24680 for ; Fri, 24 Jan 2003 11:51:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OHBCJ13565; Fri, 24 Jan 2003 12:11:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OH8mJ13458 for ; Fri, 24 Jan 2003 12:08:48 -0500 Received: from dyn-tx-app-007.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24652 for ; Fri, 24 Jan 2003 11:49:12 -0500 (EST) Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by dyn-tx-app-007.dfw.dynamicsoft.com (8.12.5/8.12.5) with ESMTP id h0OGqC9Z000971; Fri, 24 Jan 2003 10:52:12 -0600 Message-ID: <3E316F35.2080606@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Henning Schulzrinne , Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] Extending for presence References: <313680C9A886D511A06000204840E1CF030B5D08@whq-msgusr-02.pit.comms.marconi.com> <3E1F1087.8050607@dynamicsoft.com> <3E1F308F.5060602@cisco.com> <3E20E40E.4060904@dynamicsoft.com> <3E20E78D.8000203@cs.columbia.edu> <3E2305C3.5090709@cisco.com> <3E230BEA.7020403@cs.columbia.edu> <3E2311F1.7010809@cisco.com> In-Reply-To: <3E2311F1.7010809@cisco.com> X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 24 Jan 2003 10:52:05 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: [...] > Not that one, because I haven't found an "out to lunch". But while I > haven't been able to verify this, I have heard that "offline" users in > Yahoo can still be sent messages that will be displayed later, while > offline users in MSN can't. > [...] I can verify the yahoo case. In fact, some people around my office have gotten so used to Yahoo's store and forward capabilities that they have forgotten how to use email. Furthermore, if people send you messages while you are invisible or even explicitly busy, you still get the messages immediately. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 24 13:44:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28361 for ; Fri, 24 Jan 2003 13:44:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OJ44I20885 for simple-archive@odin.ietf.org; Fri, 24 Jan 2003 14:04:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OJ44J20882 for ; Fri, 24 Jan 2003 14:04:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28331 for ; Fri, 24 Jan 2003 13:44:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OJ3vJ20870; Fri, 24 Jan 2003 14:03:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OJ00J20614 for ; Fri, 24 Jan 2003 14:00:00 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28210 for ; Fri, 24 Jan 2003 13:40:23 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0OIhrYH007897; Fri, 24 Jan 2003 13:43:54 -0500 (EST) Message-ID: <3E318964.7010305@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: "Peterson, Jon" , Paul Kyzivat , simple@ietf.org Subject: Re: quantifying activity (was RE: [Simple] Extending for pr esence) References: <4.3.2.7.2.20030122094404.00b3cda8@cia.cisco.com> <4.3.2.7.2.20030123100301.00b4f1c8@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 24 Jan 2003 13:43:48 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Michael Hammer wrote: > Jonathan, > > In one of my earlier postings, I suggested that there were two types of > time-related activity indications, one which is an actual measure of > last time the device sent or received a communication, two an explicit > indication by the user that he doesn't intend to use the device until > some specific time. But, I think that the latter is a indication of > predisposition that could also be corrected when the user changes his mind. > > There may be a difference in time-scale consideration here. I do think > it useful, if someone attempts to call me on my cell phone since that is > often viewed as personally with me and for many people is often on. > But, if you did have an indication that my phone has not sent nor > answered a call in the last several hours, that this method is not the > best right now. > > Just because one indicator is not the best method for all devices does > not mean that it might not be useful for others. And either way, you > are not going to drive the probability of answer down to zero. People > may simply not want to talk to the caller. I agree that the likelihood of coming up with a generic device independent indication of activity is low to zero. As such, standardizing things we know how to do, even if not ideal for all devices, is the only choice. And so, I do agree that a time based activity measure is something we need. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 24 13:50:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28471 for ; Fri, 24 Jan 2003 13:50:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OJ9CD21731 for simple-archive@odin.ietf.org; Fri, 24 Jan 2003 14:09:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OJ9CJ21728 for ; Fri, 24 Jan 2003 14:09:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28440 for ; Fri, 24 Jan 2003 13:49:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OJ91J21704; Fri, 24 Jan 2003 14:09:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OJ2KJ20828 for ; Fri, 24 Jan 2003 14:02:20 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28303 for ; Fri, 24 Jan 2003 13:42:42 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0OIkDYH007900; Fri, 24 Jan 2003 13:46:13 -0500 (EST) Message-ID: <3E3189EF.3070104@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: "Peterson, Jon" , Paul Kyzivat , simple@ietf.org Subject: Re: quantifying activity (was RE: [Simple] Extending fo r pr esence) References: <15A2739B7DAA624D8091C65981D7DA8101214D35@stntexch2.va.neustar.com> <4.3.2.7.2.20030123095919.00b35210@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 24 Jan 2003 13:46:07 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Really, the notion of which tuple is "best" is a combination of the needs of the caller and of the needs of the called party. There is no one right answer, to be certain. We can think of examples back and forth which show cases where one status or another is really whats important. The only thing we can do is convey sufficient information so that the caller can make an intelligent decision about how to proceed. -Jonathan R. Michael Hammer wrote: > Jonathon, > > I would argue the opposite. Perhaps the presentity can only support one > video feed at a time (due to BW constraints), thus while the video is > active, he would not want to receive another and is trying to tell any > watchers to IM him instead. > > Mike > > > At 12:13 AM 1/23/2003 -0500, Jonathan Rosenberg wrote: > >> I would argue that ALL of the status elements ultimately contribute to >> the decision about which contact is best to reach a user. FOr example, >> if the presentity publishes that one tuple supports video, and the >> other audio, but the audio is lower priority, and the video is active, >> and the watcher wants to make a video call, it would probably select >> the video tuple. >> >> -Jonathan R. >> >> Peterson, Jon wrote: >> >>> Priority and activity may be conflicting in so far as they are both >>> used to >>> determine which contact in a set is the best place to reach a user. If a >>> contact has a high priority and low activity, should that be >>> preferred over >>> a contact with a low priority and high activity? I don't see how the two >>> could not need to be considered simultaneously. In some sense, activity >>> contributes to the decision of preference that one makes based on >>> priority. >>> That's why I was speculating on whether or not we could combine the >>> two, or >>> at least to define how they interrelate. I don't have a particularly >>> strong >>> intuition about how to do this, though. >>> Jon Peterson >>> NeuStar, Inc. >>> >>>> -----Original Message----- >>>> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>>> Sent: Tuesday, January 21, 2003 11:15 PM >>>> To: Peterson, Jon >>>> Cc: Paul Kyzivat; simple@ietf.org >>>> Subject: Re: quantifying activity (was RE: [Simple] Extending >>>> for pr esence) >>> >>> [snip] >>> >>>>> If we want a bucket for this in the current document, >>>> >>>> >>>> though, I wonder if >>>> >>>>> the relative 'priority' attribute of elements, >>>> >>>> >>>> which is already >>>> >>>>> specified in PIDF, would be a good place for quantified >>>> >>>> >>>> activity information >>>> >>>>> to be recorded. Presumably, one use of activity information >>>> >>>> >>>> would be to >>>> >>>>> discover the best contact in a set; it might be confusing >>>> >>>> >>>> to have a separate >>>> >>>>> parameter for this that conflicts with the existing >>>> >>>> >>>> priority parameter in >>>> >>>>> PIDF. It also already has the connotation that it can be >>>> >>>> >>>> set manually. >>>> >>>> I don't see this is conflicting at all. THe priority conveys >>>> something quite different - which one of these is preferred by the >>>> presentity. Thats not the same as saying "this one hasn't been used >>>> by the presentity in a while". Indeed, it may be inactive but still >>>> preferred (say, because there is a store and forward app running >>>> there). >>>> >>>> In fact, the active/idle indication makes sense for single device >>>> systems, where priority clearly doesnt help. >>>> >>>> -Jonathan R. >>>> -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >>>> Chief Scientist First Floor >>>> dynamicsoft East Hanover, NJ 07936 >>>> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>>> http://www.jdrosen.net PHONE: (973) 952-5000 >>>> http://www.dynamicsoft.com >>> >> >> -- >> Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >> Chief Scientist First Floor >> dynamicsoft East Hanover, NJ 07936 >> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.dynamicsoft.com >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 24 15:18:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01292 for ; Fri, 24 Jan 2003 15:18:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OKbSg27356 for simple-archive@odin.ietf.org; Fri, 24 Jan 2003 15:37:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OKbSJ27353 for ; Fri, 24 Jan 2003 15:37:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01284 for ; Fri, 24 Jan 2003 15:17:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OKa4J26711; Fri, 24 Jan 2003 15:36:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OKXAJ26594 for ; Fri, 24 Jan 2003 15:33:10 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01076 for ; Fri, 24 Jan 2003 15:13:30 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0OKH1YH008080; Fri, 24 Jan 2003 15:17:01 -0500 (EST) Message-ID: <3E319F36.5060907@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Steven M. Bellovin" CC: mankin@psg.com, simple@ietf.org, =?ISO-8859-1?Q?Patrik_F=C3=A4lts?= =?ISO-8859-1?Q?tr=C3=B6m?= References: <20030123134232.126717B4D@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Discuss on SIMPLE doc Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 24 Jan 2003 15:16:54 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for the response. Comments inline. Steven M. Bellovin wrote: >>> 6.6.1 -- which authentication methods are mandatory to >>> implement? Ditto 9.2 and 9.4. Also see 6.2 in >>> draft-ietf-simple-winfo-package-04.txt >> >>RFC 3261 mandates digest for authentication purposes. I've added a >>sentence to 6.6.1 which states: >> >>Note that digest is mandatory to implement, as >>specified in RFC 3261. >> >>Regarding 9.2 (which discusses autehntication and message integrity) and >>9.4 (which discusses replay), digest can address the authentication and >>replay issues (its not perfect of course). Do you feel it needs to state >>baseline mechanisms beyond those specified in RFC 3261? It was always my >>assumption that it did not, which is why there are no normative >>statements about security mechanisms. > > > I confess that I don't have 3261 memorized... What? 269 pages and you haven't memorized it?? ;) > You're referring to HTTP > Digest, as described in Section 22 of 3261, as well as 26.3.2.1 as > called out in this draft? Yes. > My problem with 6.6.1 is with the language > "any of the mechanisms". HTTP Digest is adequate for authentication, > but that's not what this says; it says "3261 defines several; pick one". > Your suggested change resolves the problem. OK. > > For 9.2 and 9.4, the problem is permissive wording. For example, 9.2 > says "IPs authentication and message integrity features can be used." > It wasn't clear to me that you were mandating those mechanisms. No. The intent was that RFC3261 provides such mechanisms, and it also states the implementation strength of them. That said, we do introduce a new element here - a presence agent, which is a UA by SIP definitions. However, I think we may need to introduce additional security requirements for implementors of a PA so that presentities and watchers can get security services. I would imagine that all PA MUST implement TLS (and consequently sips), and MUST support digest (already mandated by rfc3261). So, I changed the wording in 9.2 to say: > RFC 3261 provides many mechanisms to provide these features. In order > for the PA to authenticate the watcher, it MAY use HTTP Digest > (Section 22 of RFC 3261). As a result, all watchers MUST support HTTP > Digest. This is a redundant requirement, however, since all SIP user > agents are mandated to support it by RFC 3261. To provide authenticity > and integrity services, a watcher MAY use the SIPS scheme when > subscribing to the presentity. To support this, all PA MUST support > TLS and SIPS as if they were a proxy (see Section 26.3.1 of RFC 3261). > > Furthermore, SMIME MAY be used for integrity and authenticity of > SUBSCRIBE and NOTIFY requests. This is described in Section 23 of RFC > 3261. is this better? > Similarly, 9.4 says "SIP S/MIME can provide" and "HTTP digest > authentication MAY be used". What is mandatory to implement here? Digest, as it is in SIP. S/MIME is a MAY. I've clarified that, so that the text now reads: > SIP S/MIME can provide message integrity and authentication over SIP > request bodies. Watchers and PAs MAY implement S/MIME signatures > to prevent these replay > attacks. When it is used for that purpose, the presence document > carried in the NOTIFY request MUST contain a timestamp. In the case of > PIDF, this is accomplished using the timestamp element, as described > in Section 6 of > \citenorm{draft-ietf-impp-cpim-pidf}. Tuples whose timestamp is older > than the timestamp of the most recently received presence document > SHOULD be considered stale, and discarded. > > Finally, HTTP digest authentication (which MUST be implemented by > watchers and PAs) MAY be used to prevent replay attacks, when there is > a shared secret between the PA and the watcher. In such a case, the > watcher can challenge the NOTIFY requests with the auth-int quality of > protection. Similarly, in 6.2 of the watcherinfo spec, I changed the wording to read: > One way in which this information can be revealed is eavesdropping. An > attacker can observe watcherinfo notifications, and learn this > information. To prevent that, watchers MAY use the SIPS scheme when > subscribing to a watcherinfo resource. Notifiers for watcherinfo MUST > support TLS and SIPS as if they were a proxy (see Section 26.3.1 of > RFC 3261). > > SIP encryption, using S/MIME, MAY be used end-to-end for the > transmission of both SUBSCRIBE and NOTIFY requests. > > Another way in which this information can be revealed is through > spoofed subscriptions. These attacks can be prevented by > authenticating and authorizing all watcherinfo subscriptions. In order > for the notifier to authenticate the subscriber, it MAY use HTTP > Digest (Section 22 of RFC 3261). As a result, all watchers MUST > support HTTP Digest. This is a redundant requirement, however, since > all SIP user agents are mandated to support it by RFC 3261. Are these improved wordings and requirements OK? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 24 16:03:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02397 for ; Fri, 24 Jan 2003 16:03:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OLMNP29488 for simple-archive@odin.ietf.org; Fri, 24 Jan 2003 16:22:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLMNJ29485 for ; Fri, 24 Jan 2003 16:22:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02370 for ; Fri, 24 Jan 2003 16:02:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLMHJ29467; Fri, 24 Jan 2003 16:22:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLLUJ29437 for ; Fri, 24 Jan 2003 16:21:30 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02321 for ; Fri, 24 Jan 2003 16:01:48 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0OL5KYH008152; Fri, 24 Jan 2003 16:05:20 -0500 (EST) Message-ID: <3E31AA89.1000104@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'Paul Kyzivat'" , simple@ietf.org Subject: Re: hierarchies (was RE: [Simple] Extending for presence) References: <15A2739B7DAA624D8091C65981D7DA8101214D28@stntexch2.va.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 24 Jan 2003 16:05:13 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Peterson, Jon wrote: > I am wary of explicitly defining hierarchies by having an extension to PIDF > that allows, essentially, tuples within tuples. I am less averse to the > concept that tuples representing a group might each contain a contact > address with a pres: URI where the presence of that group member might be > learned. Indirection rather than hierarchy. Both modes seem useful and should be possible. I'll note that this concept intersects significantly with the buddy list subscription work (draft-roach-sip-list-template). There are many interpretations that can be made to the act of subscribing to a group: 1. the subscriber wants to receive a PIDF for each group member when their status changes. Each PIDF has a single presentity, but it represents a group member. PIDF itself knows nothing abuot groups. There is a single subscription for the entire group. This is the roach-sip-list-template approach. 2. the subscriber merely wants the state of the group, and doesnt care about the members. THus, it also receives a PIDF that talks about one presentity, but the presentity represents a group. There are no tuples representing members. There is one subscription. 3. the subscriber wants the state of the group and of its members. The subscription to the group indicates that it has a bunch of members, each represented by a tuple with a pres contact URI. THe subscriber then subscribes to each independently. There are N+1 subscriptions for a flat group with N members. 4. the subscriber wants the state of the group and of its members. The subscription to the group indicates that it has a bunch of members, each represented by a tuple, which has sub-tuples with the state of that member. Notificatoins of changes would be partial, so that each notify contains just the sub-tree that has changed. THere is one subscription. Cases 1. and 4. are very similar. What is interesting is that 4. is a PIDF-specific way to accomplish 1. That might argue that 4. is not needed, that its better to do this kind of thing more generally than for presence. I do think we want to allow for cases 2 and 3. However, for them to work, the key missing piece is a status that indicates what the tuple represents. Indeed, the bigger issue is what the presentity represents. As I mentioned in another email, the presentity and tuples could represent: groups users automaton devices logical components of a device So, I would assert that there is a need for another status type, say that can be applied to the tuples or the presentity, and is one of the values above. Another missing piece is, when the subscriber subscribes, how do they indicate which of the above 4 (or three, if we rule out #4) they want? That might require some presence filters to be defined. > > Either way, there will be a significant burden on the watcher to figure out > whether or not the group as a whole should be considered OPEN (considered as > an absolute or through some quantification of partial OPENness). I would imagine that the PIDF itself should say what the status of the group overall is. > Using > indirection allows the presence composition function to be more easily > distributed, I think. If several members of a group use, say, different > presence services (and I see no reason to rule that out), hierarchies would > seem to imply a publication interface between their various presence > services and some sort of group aggregator. Group aggregator, yes. We've discussed this extensively as part of the buddy list subscription work above. A key goal was to allow hierarchical aggregation, which I believe the most recent proposal (using a sip-events extension) will allow. > Various sorts of policy > management from the presentity perspective look more complex to me in that > architecture. Yes, authorization is more complicated - its the standard "proxy vs. redirect" issue there in terms of security requirements. But, we need the proxy case (where there is a network aggregator) to avoid a plethora of subscriptions. In very large groups, I would imagine it is also better for a > watcher's client to decide how many members of the group it would like > evaluate, rather than receiving a single massive PIDF document from the > presentity. Agreed you don't want a single massive document. It would be multipart or separate notifies for each, I would think. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 24 16:16:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02678 for ; Fri, 24 Jan 2003 16:16:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0OLZFa29966 for simple-archive@odin.ietf.org; Fri, 24 Jan 2003 16:35:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLZFJ29963 for ; Fri, 24 Jan 2003 16:35:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02672 for ; Fri, 24 Jan 2003 16:15:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLZAJ29955; Fri, 24 Jan 2003 16:35:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OLYhJ29921 for ; Fri, 24 Jan 2003 16:34:43 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02668 for ; Fri, 24 Jan 2003 16:15:01 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0OLIUYH008249; Fri, 24 Jan 2003 16:18:31 -0500 (EST) Message-ID: <3E31AD9F.1050400@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Extending for presence References: <2038BCC78B1AD641891A0D1AE133DBB7FE7162@esebe019.ntc.nokia.com> <3E2D765E.6030403@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 24 Jan 2003 16:18:23 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > DND has received a lot of air-time, and Jonathan wrote: > >> ON DND >> >> DND has received a bit of discussion on this thread. To be honest, I am >> at a loss as to why it is not really a combination of two things: (1) >> basic status of CLOSED for each device, and (2) a "task" of "do not >> disturb". Paul has defined these tasks as things that describe what the >> presentity is doing, such as "out-to-lunch". "do not disturb" seems like >> another example. >> >> It is the usage of the basic status of CLOSED that really captures the >> essence of DND - that attempts to contact with that user across their >> devices will fail. > > > I don't think the representation of DND is what we are arguing; it is > the semantics. DND implies to me that all *my* devices should honor > my will and not even alert me. Here is our fundamental disconnect. I view this as one application's interpretation of DND. DND merely means "I dont want to be disturbed". If you have a proxy app that subscribes to your presence, and it creates a CPL that blocks all calls when your presence is DND, thats great. It can do that. That is how that presence-based application works. Others might do different things. I do not want to mandate the way that applications have to operate under certain presence states. That path is full of perils, not the least of which is that networks differ frome each other in many ways, so that applications will need to be built in different ways. You have already stumbled on this above, in the case of uncontrollable PSTN devices. But of course, there maybe cases where > the department secretary or the CEO should be able to get to me. Given > today's disparate networks, I cannot impose my will on my devices. But > should we preclude us from doing so for tomorrow's networks where it > maybe more possible to control the device in a far more discrete manner? We should ENABLE such applications to be built. We should not mandate HOW they are built. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 27 10:08:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17240 for ; Mon, 27 Jan 2003 10:08:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RFTSs28190 for simple-archive@odin.ietf.org; Mon, 27 Jan 2003 10:29:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RFTSJ28187 for ; Mon, 27 Jan 2003 10:29:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17204 for ; Mon, 27 Jan 2003 10:08:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RFTJJ28168; Mon, 27 Jan 2003 10:29:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RFSPJ28094 for ; Mon, 27 Jan 2003 10:28:25 -0500 Received: from brazilnut.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17163 for ; Mon, 27 Jan 2003 10:07:24 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0RFApuX023595 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 Jan 2003 10:10:52 -0500 (EST) Message-ID: <3E354C17.9010004@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Vijay K. Gurbani" , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Extending for presence References: <2038BCC78B1AD641891A0D1AE133DBB7FE7162@esebe019.ntc.nokia.com> <3E2D765E.6030403@lucent.com> <3E31AD9F.1050400@dynamicsoft.com> In-Reply-To: <3E31AD9F.1050400@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 27 Jan 2003 10:11:19 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Fundamentally, this is a discussion about the role of events and presence. In my view, presence and events indicate what is ("status"), not what should be ("control"). As has been discussed here, some other presentity-controlled entity may close the feedback loop and translate "is" into "does". (No, I don't want to discuss the meaning of the word "is".) Trying to implement such restrictions on the watcher side is also fundamentally pointless since it relies on the cooperation of the watcher software. >>> DND has received a bit of discussion on this thread. To be honest, I am >>> at a loss as to why it is not really a combination of two things: (1) >>> basic status of CLOSED for each device, and (2) a "task" of "do not >>> disturb". Paul has defined these tasks as things that describe what the >>> presentity is doing, such as "out-to-lunch". "do not disturb" seems like >>> another example. >>> >>> It is the usage of the basic status of CLOSED that really captures the >>> essence of DND - that attempts to contact with that user across their >>> devices will fail. >> >> >> >> I don't think the representation of DND is what we are arguing; it is >> the semantics. DND implies to me that all *my* devices should honor >> my will and not even alert me. > > > Here is our fundamental disconnect. > > I view this as one application's interpretation of DND. DND merely means > "I dont want to be disturbed". If you have a proxy app that subscribes > to your presence, and it creates a CPL that blocks all calls when your > presence is DND, thats great. It can do that. That is how that > presence-based application works. Others might do different things. I do > not want to mandate the way that applications have to operate under > certain presence states. That path is full of perils, not the least of > which is that networks differ frome each other in many ways, so that > applications will need to be built in different ways. You have already > stumbled on this above, in the case of uncontrollable PSTN devices. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon Jan 27 16:43:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28058 for ; Mon, 27 Jan 2003 16:43:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RM4Af20483 for simple-archive@odin.ietf.org; Mon, 27 Jan 2003 17:04:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RM4AJ20480 for ; Mon, 27 Jan 2003 17:04:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28026 for ; Mon, 27 Jan 2003 16:43:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RM44J20470; Mon, 27 Jan 2003 17:04:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RM3LJ20426 for ; Mon, 27 Jan 2003 17:03:21 -0500 Received: from dewberry.cc.columbia.edu (dewberry.cc.columbia.edu [128.59.59.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27982 for ; Mon, 27 Jan 2003 16:41:40 -0500 (EST) Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h0RLfcSr018624 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 Jan 2003 16:41:39 -0500 (EST) Message-ID: <3E35A7AC.2030805@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Peterson, Jon" , "'Paul Kyzivat'" , simple@ietf.org Subject: Re: hierarchies (was RE: [Simple] Extending for presence) References: <15A2739B7DAA624D8091C65981D7DA8101214D28@stntexch2.va.neustar.com> <3E31AA89.1000104@dynamicsoft.com> In-Reply-To: <3E31AA89.1000104@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 27 Jan 2003 16:42:04 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I'll note that this concept intersects significantly with the buddy list > subscription work (draft-roach-sip-list-template). There are many > interpretations that can be made to the act of subscribing to a group: > > 1. the subscriber wants to receive a PIDF for each group member when > their status changes. Each PIDF has a single presentity, but it > represents a group member. PIDF itself knows nothing abuot groups. There > is a single subscription for the entire group. This is the > roach-sip-list-template approach. Even in that case, the PIDF should probably contain some kind of identifier that tells the watcher why he is getting this PIDF document. This is more than just "this is a group", but rather "you're getting Alice's status since you subscribed to sales@example.com". In SIMPLE, the NOTIFY From will provide this information. Do we need a separate indication in PIDF itself? > 3. the subscriber wants the state of the group and of its members. The > subscription to the group indicates that it has a bunch of members, each > represented by a tuple with a pres contact URI. THe subscriber then > subscribes to each independently. There are N+1 subscriptions for a flat > group with N members. What does OPEN and CLOSED mean in that context? Would it mean that the member temporarily has no presence information available (I think so) or that it is no longer a member of the group (I don't think so). In general, how would a watcher detect that somebody is no longer a member? (The person may still exist, just not as a member of the group.) > > 4. the subscriber wants the state of the group and of its members. The > subscription to the group indicates that it has a bunch of members, each > represented by a tuple, which has sub-tuples with the state of that > member. Notificatoins of changes would be partial, so that each notify > contains just the sub-tree that has changed. THere is one subscription. > > I do think we want to allow for cases 2 and 3. However, for them to > work, the key missing piece is a status that indicates what the tuple > represents. Indeed, the bigger issue is what the presentity represents. > As I mentioned in another email, the presentity and tuples could represent: > > groups > users > automaton > devices > logical components of a device > > So, I would assert that there is a need for another status type, say > that can be applied to the tuples or the presentity, and is > one of the values above. However, I don't think these are all orthogonal, so I wouldn't want to lump them into one descriptor. Basically, I want to know whether a presentity has a "parent" (which indicates group). > > Another missing piece is, when the subscriber subscribes, how do they > indicate which of the above 4 (or three, if we rule out #4) they want? > That might require some presence filters to be defined. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 28 02:08:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17815 for ; Tue, 28 Jan 2003 02:08:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0S7TYI28916 for simple-archive@odin.ietf.org; Tue, 28 Jan 2003 02:29:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S7TXJ28913 for ; Tue, 28 Jan 2003 02:29:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17812 for ; Tue, 28 Jan 2003 02:08:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S7THJ28903; Tue, 28 Jan 2003 02:29:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S7SwJ28875 for ; Tue, 28 Jan 2003 02:28:58 -0500 Received: from smtp012.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17806 for ; Tue, 28 Jan 2003 02:07:36 -0500 (EST) Received: from 12-235-146-159.client.attbi.com (HELO cranberry) (seancolson@12.235.146.159 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 28 Jan 2003 07:11:07 -0000 Reply-To: From: "Sean Olson" To: , , , Cc: Message-ID: <004701c2c69c$6ea944e0$6501a8c0@cranberry> 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.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [Simple] draft-lonnofors-simple-partial-notify-00 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 27 Jan 2003 23:11:07 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I had a quick comment about the draft. I definitely see the need for a partial notification mechanism. I also think the mechanism proposed in the draft is a fairly straightforward and common approach to solving this problem. My main comment is whether or not we can potentially generalize this approach by moving the version and state variables out of the body and into SUB / NOT specific headers. Potentially even entity headers? I think this is a cleaner approach then necessarily creating two different but related schemas for the full vs. partial notification. Regards, Sean Olson Microsoft _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 28 02:32:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18193 for ; Tue, 28 Jan 2003 02:32:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0S7rdf30735 for simple-archive@odin.ietf.org; Tue, 28 Jan 2003 02:53:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S7rcJ30732 for ; Tue, 28 Jan 2003 02:53:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18190 for ; Tue, 28 Jan 2003 02:32:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S7r5J30715; Tue, 28 Jan 2003 02:53:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S7qmJ30696 for ; Tue, 28 Jan 2003 02:52:49 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18179 for ; Tue, 28 Jan 2003 02:31:26 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0S7Xun09588 for ; Tue, 28 Jan 2003 09:33:56 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 28 Jan 2003 09:34:56 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 28 Jan 2003 09:34:56 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C69F.C0D86C0D" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF1041C9@esebe004.ntc.nokia.com> Thread-Topic: New I-Ds on partial notification Thread-Index: AcLGn8CoDUb8BiJvQIq5PznRH81HLw== To: X-OriginalArrivalTime: 28 Jan 2003 07:34:56.0199 (UTC) FILETIME=[C11FED70:01C2C69F] Subject: [Simple] New I-Ds on partial notification Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 28 Jan 2003 09:34:55 +0200 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2C69F.C0D86C0D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Here are links to two new drafts which deal with partial presence notifications. Requirements are discussed here: http://www.ietf.org/internet-drafts/draft-lonnfors-simple-presinfo-deliv -reqs-00.txt A Presence service implemented using SIMPLE has some constraints for=20 delivering presence information to devices with low data processing=20 capabilities, small display, and limited battery power. Other=20 limitations can be caused by the interface between the terminal and=20 the network, i.e. over radio links with high latency and low=20 bandwidth. This memo presents requirements for a solution that aids=20 in reducing the impacts of those constrains and increasing=20 efficiency. And the actual solution is described here: http://www.ietf.org/internet-drafts/draft-lonnofors-simple-partial-notif y-00.txt A Presence service implemented using SIMPLE has some constraints for=20 delivering presence information to devices with low data processing=20 capabilities, small display, and limited battery power. Other=20 limitations can be caused by the interface between the terminal and=20 the network, i.e. over radio links with high latency and low=20 bandwidth. This memo presents a solution that aids in reducing the=20 impact of those constrains and increasing efficiency, by introducing=20 a new MIME-type partial notifications and a Require header=20 extension partial-notification. All comments are most welcome. Regards - Mikko=20 ------_=_NextPart_001_01C2C69F.C0D86C0D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New I-Ds on partial notification

Hi,

Here are links to two new drafts = which deal with partial presence notifications.
Requirements are discussed = here:
http://www.ietf.org/internet-drafts/draft-lonnfors-simple-presinfo-d= eliv-reqs-00.txt
A Presence service implemented = using SIMPLE has some constraints for
delivering presence information = to devices with low data processing
capabilities, small display, and = limited battery power. Other
limitations can be caused by the = interface between the terminal and
the network, i.e. over radio = links with high latency and low
bandwidth. This memo presents = requirements for a solution that aids
in reducing the impacts of those = constrains and increasing
efficiency.

And the actual solution is = described here:
http://www.ietf.org/internet-drafts/draft-lonnofors-simple-partial-n= otify-00.txt
A Presence service implemented = using SIMPLE has some constraints for
delivering presence information = to devices with low data processing
capabilities, small display, and = limited battery power. Other
limitations can be caused by the = interface between the terminal and
the network, i.e. over radio = links with high latency and low
bandwidth. This memo presents a = solution that aids in reducing the
impact of those constrains and = increasing efficiency, by introducing
a new MIME-type partial = notifications and a Require header
extension = partial-notification.

All comments are most = welcome.

Regards
- Mikko

------_=_NextPart_001_01C2C69F.C0D86C0D-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 28 09:50:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26952 for ; Tue, 28 Jan 2003 09:50:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SFBUH25429 for simple-archive@odin.ietf.org; Tue, 28 Jan 2003 10:11:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFBTJ25426 for ; Tue, 28 Jan 2003 10:11:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26921 for ; Tue, 28 Jan 2003 09:50:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFBNJ25400; Tue, 28 Jan 2003 10:11:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QMXpJ27812 for ; Sun, 26 Jan 2003 17:33:51 -0500 Received: from mail-green.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22873 for ; Sun, 26 Jan 2003 17:13:10 -0500 (EST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id DAEDC1E0B3; Sun, 26 Jan 2003 17:16:39 -0500 (EST) Received: from berkshire.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id RAA04193; Sun, 26 Jan 2003 17:16:37 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 2AFC77B71; Sun, 26 Jan 2003 16:42:25 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Jonathan Rosenberg Cc: mankin@psg.com, simple@ietf.org, =?ISO-8859-1?Q?Patrik_F=C3=A4lts?= =?ISO-8859-1?Q?tr=C3=B6m?= Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <20030126214225.2AFC77B71@berkshire.research.att.com> Subject: [Simple] Re: Discuss on SIMPLE doc Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 26 Jan 2003 16:42:25 -0500 In message <3E319F36.5060907@dynamicsoft.com>, Jonathan Rosenberg writes: >Thanks for the response. Comments inline. That looks fine; thanks. > >Steven M. Bellovin wrote: > >>>> 6.6.1 -- which authentication methods are mandatory to >>>> implement? Ditto 9.2 and 9.4. Also see 6.2 in >>>> draft-ietf-simple-winfo-package-04.txt >>> >>>RFC 3261 mandates digest for authentication purposes. I've added a >>>sentence to 6.6.1 which states: >>> >>>Note that digest is mandatory to implement, as >>>specified in RFC 3261. >>> >>>Regarding 9.2 (which discusses autehntication and message integrity) and >>>9.4 (which discusses replay), digest can address the authentication and >>>replay issues (its not perfect of course). Do you feel it needs to state >>>baseline mechanisms beyond those specified in RFC 3261? It was always my >>>assumption that it did not, which is why there are no normative >>>statements about security mechanisms. >> >> >> I confess that I don't have 3261 memorized... > >What? 269 pages and you haven't memorized it?? ;) > >> You're referring to HTTP >> Digest, as described in Section 22 of 3261, as well as 26.3.2.1 as >> called out in this draft? > >Yes. > >> My problem with 6.6.1 is with the language >> "any of the mechanisms". HTTP Digest is adequate for authentication, >> but that's not what this says; it says "3261 defines several; pick one". >> Your suggested change resolves the problem. > >OK. > >> >> For 9.2 and 9.4, the problem is permissive wording. For example, 9.2 >> says "IPs authentication and message integrity features can be used." >> It wasn't clear to me that you were mandating those mechanisms. > >No. The intent was that RFC3261 provides such mechanisms, and it also >states the implementation strength of them. > >That said, we do introduce a new element here - a presence agent, which >is a UA by SIP definitions. However, I think we may need to introduce >additional security requirements for implementors of a PA so that >presentities and watchers can get security services. I would imagine >that all PA MUST implement TLS (and consequently sips), and MUST support >digest (already mandated by rfc3261). > >So, I changed the wording in 9.2 to say: > >> RFC 3261 provides many mechanisms to provide these features. In order >> for the PA to authenticate the watcher, it MAY use HTTP Digest >> (Section 22 of RFC 3261). As a result, all watchers MUST support HTTP >> Digest. This is a redundant requirement, however, since all SIP user >> agents are mandated to support it by RFC 3261. To provide authenticity >> and integrity services, a watcher MAY use the SIPS scheme when >> subscribing to the presentity. To support this, all PA MUST support >> TLS and SIPS as if they were a proxy (see Section 26.3.1 of RFC 3261). >> >> Furthermore, SMIME MAY be used for integrity and authenticity of >> SUBSCRIBE and NOTIFY requests. This is described in Section 23 of RFC >> 3261. > >is this better? > > >> Similarly, 9.4 says "SIP S/MIME can provide" and "HTTP digest >> authentication MAY be used". What is mandatory to implement here? > >Digest, as it is in SIP. S/MIME is a MAY. I've clarified that, so that >the text now reads: > >> SIP S/MIME can provide message integrity and authentication over SIP >> request bodies. Watchers and PAs MAY implement S/MIME signatures >> to prevent these replay >> attacks. When it is used for that purpose, the presence document >> carried in the NOTIFY request MUST contain a timestamp. In the case of >> PIDF, this is accomplished using the timestamp element, as described >> in Section 6 of >> \citenorm{draft-ietf-impp-cpim-pidf}. Tuples whose timestamp is older >> than the timestamp of the most recently received presence document >> SHOULD be considered stale, and discarded. >> >> Finally, HTTP digest authentication (which MUST be implemented by >> watchers and PAs) MAY be used to prevent replay attacks, when there is >> a shared secret between the PA and the watcher. In such a case, the >> watcher can challenge the NOTIFY requests with the auth-int quality of >> protection. > > > >Similarly, in 6.2 of the watcherinfo spec, I changed the wording to read: > >> One way in which this information can be revealed is eavesdropping. An >> attacker can observe watcherinfo notifications, and learn this >> information. To prevent that, watchers MAY use the SIPS scheme when >> subscribing to a watcherinfo resource. Notifiers for watcherinfo MUST >> support TLS and SIPS as if they were a proxy (see Section 26.3.1 of >> RFC 3261). >> >> SIP encryption, using S/MIME, MAY be used end-to-end for the >> transmission of both SUBSCRIBE and NOTIFY requests. >> >> Another way in which this information can be revealed is through >> spoofed subscriptions. These attacks can be prevented by >> authenticating and authorizing all watcherinfo subscriptions. In order >> for the notifier to authenticate the subscriber, it MAY use HTTP >> Digest (Section 22 of RFC 3261). As a result, all watchers MUST >> support HTTP Digest. This is a redundant requirement, however, since >> all SIP user agents are mandated to support it by RFC 3261. > > >Are these improved wordings and requirements OK? > >-Jonathan R. > >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.dynamicsoft.com > > --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 28 09:50:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26973 for ; Tue, 28 Jan 2003 09:50:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SFBX625445 for simple-archive@odin.ietf.org; Tue, 28 Jan 2003 10:11:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFBXJ25442 for ; Tue, 28 Jan 2003 10:11:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26925 for ; Tue, 28 Jan 2003 09:50:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFBTJ25416; Tue, 28 Jan 2003 10:11:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0R8pLJ03083 for ; Mon, 27 Jan 2003 03:51:21 -0500 Received: from mx1.kapsch.net (mx1.kapsch.net [193.154.217.114]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09686 for ; Mon, 27 Jan 2003 03:30:28 -0500 (EST) Received: from dumbo.kapsch.co.at (dumbo.kapsch.co.at) by mx1.kapsch.net (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Mon, 27 Jan 2003 09:33:00 +0100 Received: from atnews1.atc.co.at ([193.80.84.5]) by dumbo.kapsch.co.at with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Jan 2003 09:32:59 +0100 Received: from aviepexs (aviepex3.atc.co.at [193.80.69.24]) Received: by aviepexs with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Jan 2003 09:13:45 +0100 Message-ID: From: Traussnig Robert To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 27 Jan 2003 08:32:59.0735 (UTC) FILETIME=[B30F9670:01C2C5DE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0R8pLJ03084 Subject: [Simple] Presence Authorization Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 27 Jan 2003 09:13:36 +0100 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I have a question regarding Presence Authorization. A UA knows about the Subscriptions made to him by subscribing to his WatcherInfo, but in the draft it is not explained how he can authorize the pending Subscriptions? Is there any draft which defines this? I think this is needed because of interoperability between different Presence Servers and Presence Clients. Thanks, Robert T. -- Ing. Robert Traussnig | SIP Protocol & Applications Kapsch CarrierCom AG | Triester Straße 70 | A-1100 Vienna | Austria Phone +43 1 60501 3188 | Fax +43 1 60501 3103 mailto:robert.traussnig@atc.co.at | http://www.kapsch.net _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 28 09:50:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26992 for ; Tue, 28 Jan 2003 09:50:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SFBe625497 for simple-archive@odin.ietf.org; Tue, 28 Jan 2003 10:11:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFBeJ25492 for ; Tue, 28 Jan 2003 10:11:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26932 for ; Tue, 28 Jan 2003 09:50:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFBYJ25464; Tue, 28 Jan 2003 10:11:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RC5LJ15229 for ; Mon, 27 Jan 2003 07:05:21 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12499; Mon, 27 Jan 2003 06:44:24 -0500 (EST) Message-Id: <200301271144.GAA12499@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-khartabil-simple-presence-filter-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 27 Jan 2003 06:44:23 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Event Notification Filtering for Presence Author(s) : H. Khartabil et al. Filename : draft-khartabil-simple-presence-filter-00.txt Pages : 19 Date : 2003-1-24 The Presence event package for the SIP events framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of user presence. The document details how watchers can subscribe for notifications of all authorised and available presence information about the presentity. The document does not describe a mechanism of how filtering of presence information can be achieved. This document defines a presence filter package for the Event Notification Filtering Architecture. The package provides the mechanism whereby a watcher can specify the presence event filtering rules, using XML, for the presence agent (PA) and how that PA is to behave when receiving such filter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-khartabil-simple-presence-filter-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-khartabil-simple-presence-filter-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-khartabil-simple-presence-filter-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: <2003-1-24113202.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-khartabil-simple-presence-filter-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-khartabil-simple-presence-filter-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-24113202.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 28 09:50:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27005 for ; Tue, 28 Jan 2003 09:50:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SFBgq25512 for simple-archive@odin.ietf.org; Tue, 28 Jan 2003 10:11:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFBaJ25474 for ; Tue, 28 Jan 2003 10:11:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26929 for ; Tue, 28 Jan 2003 09:50:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFBGJ25352; Tue, 28 Jan 2003 10:11:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NNYwJ02258 for ; Thu, 23 Jan 2003 18:34:58 -0500 Received: from nycsmtp1out.rdc-nyc.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23848 for ; Thu, 23 Jan 2003 18:15:43 -0500 (EST) Received: from BOBDEV (66-108-193-77.nyc.rr.com [66.108.193.77]) by nycsmtp1out.rdc-nyc.rr.com (8.12.1/Road Runner SMTP Server 1.0) with ESMTP id h0NNJ9wr011222 for ; Thu, 23 Jan 2003 18:19:09 -0500 (EST) Reply-To: From: "Bob Wyman" To: Message-ID: <007201c2c335$d61ad180$6401a8c0@BOBDEV> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0073_01C2C30B.ED44C980" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Simple] SIP soon to be useless due to patents... Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 23 Jan 2003 18:19:10 -0500 This is a multi-part message in MIME format. ------=_NextPart_000_0073_01C2C30B.ED44C980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Today, the USPTO published 8 patent applications which explicitly reference the Session Initiation Protocol. This means there are now 372 pending patent applications that make specific reference to the "Session Initation Protocol." New applications seem to be getting filed at the rate of 10 to 20 per week and the trend seems to be picking up... If you're working in the SIP space, you will be hearing alot about patents in the future... The result of all these patent applications may one day be a rash of issued patents that pin down the SIP technology in such detail that exploitation of the system will be virtually impossible. No matter how much people may support SIP today or wish it well, the fact that it is rapidly becoming encumbered by patents is a real problem that may severely limit its real utility. Clearly, what is happening is a "land rush" of patent filings by people who are attempting to exploit the fact that the SIP space is still a new one and trying to pin down what most would consider to be "obvious" ideas that, because the space is new, have little documented prior art to cover them. Few people are aware, I think, that the current law requires that most patent applications be published 18 months after they are filed. Also, that there exists a two month window after the date of publication during which it is possible for third-parties to submit prior art to the patent office for consideration during the examination of the patent. In other words, for the first time, we have the ability now to fight bad patents cheaply -- before they issue. Lawrence Lessig has been asking "What have we done?" to protect ourselves from the tyranny of excessive patents and perpetual copyrights. Well, one thing we *can* do is stop bad patents before they are issued. I recommend that everyone who wants SIP to remain useful should check the USPTO site every Thursday to see what new applications have been published. This situation is getting really bad. See below links to just this week's new "SIP" related patents. Some just mention SIP but others try to get patents on it's use. Note: My favorite recent application was publised on 9 January. This application (20030009463) is an attempt by Worldcom to patent the idea of using XML as the format of transaction log files. How callous can you get? =20 bob wyman =20 SIP Related Patent Applications published today by the US PTO: (i.e. 8 of the 372 now pending...) There remains a two month window to file third party submissions of prior art in these cases: PUB. APP. NO. Title=09 1 20030018717 Extensible = information distribution mechanism for session management =09 2 20030018704 = Network = presence and location agent =09 3 20030018703 Smart = appliance network system and communication protocol =09 4 20030018480 = Method and apparatus for transmitting voice over internet =09 5 20030016679 = Method and apparatus to perform network routing =09 6 20030016664 = System and = method for providing rapid rerouting of real-time multi-media flows =09 7 20030016630 = Method and = system for providing adaptive bandwidth control for real-time communication =09 8 20030016627 = System and = method for determining flow quality statistics for real-time transport protocol data flows =09 =20 =20 ------=_NextPart_000_0073_01C2C30B.ED44C980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
   =20 Today, the USPTO published 8 patent applications which explicitly = reference the=20 Session Initiation Protocol. This means there are now 372 pending patent = applications that make specific reference to the "Session Initation = Protocol."=20 New applications seem to be getting filed at the rate of 10 to 20 per = week and=20 the trend seems to be picking up... If you're working in the SIP space, = you will=20 be hearing alot about patents in the future...
   =20 The result of all these patent applications may one day be a rash of = issued=20 patents that pin down the SIP technology in such detail that = exploitation of the=20 system will be virtually impossible. No matter how much people may = support SIP=20 today or wish it well, the fact that it is rapidly becoming encumbered = by=20 patents is a real problem that may severely limit its real utility. = Clearly,=20 what is happening is a "land rush" of patent filings by people who are=20 attempting to exploit the fact that the SIP space is still a new one and = trying=20 to pin down what most would consider to be "obvious" ideas that, because = the=20 space is new, have little documented prior art to cover=20 them.
   =20 Few people are aware, I think, that the current law requires that most = patent=20 applications be published 18 months after they are filed. Also, = that there=20 exists a two month window after the date of publication during which it = is=20 possible for third-parties to submit prior art to the patent office for=20 consideration during the examination of the patent. In other words, for = the=20 first time, we have the ability now to fight bad patents cheaply -- = before they=20 issue. Lawrence Lessig has been asking "What have we done?" to protect = ourselves=20 from the tyranny of excessive patents and perpetual copyrights. Well, = one thing=20 we *can* do is stop bad patents before they are = issued.
    I=20 recommend that everyone who wants SIP to remain useful should check the = USPTO=20 site every Thursday to see what new applications have been published. = This=20 situation is getting really bad.
    See below links to just this week's new = "SIP" related=20 patents. Some just mention SIP but others try to get patents on it's = use. Note:=20 My favorite recent application was publised on 9 January. This = application=20 (20030009463) is an attempt by Worldcom to patent the idea of using XML = as the=20 format of transaction log files. How callous can you=20 get?
 
        = bob=20 wyman
 
SIP = Related Patent=20 Applications published today by the US PTO: (i.e. 8 of the 372 now = pending...)=20 There remains a two month window to file third party submissions of = prior art in=20 these cases:
PUB. APP. NO. Title
1 20030018717 Extensible=20 information distribution mechanism for session management =
2 20030018704 Network=20 presence and location agent
3 20030018703 Smart=20 appliance network system and communication protocol
4 20030018480 Method=20 and apparatus for transmitting voice over internet
5 20030016679 Method=20 and apparatus to perform network routing
6 20030016664 System=20 and method for providing rapid rerouting of real-time multi-media = flows=20
7 20030016630 Method=20 and system for providing adaptive bandwidth control for real-time=20 communication
8 20030016627 System=20 and method for determining flow quality statistics for real-time = transport=20 protocol data flows =
 
 
------=_NextPart_000_0073_01C2C30B.ED44C980-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 28 09:50:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27018 for ; Tue, 28 Jan 2003 09:50:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SFBkU25532 for simple-archive@odin.ietf.org; Tue, 28 Jan 2003 10:11:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFBkJ25529 for ; Tue, 28 Jan 2003 10:11:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26939 for ; Tue, 28 Jan 2003 09:50:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFBeJ25484; Tue, 28 Jan 2003 10:11:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RC5PJ15233 for ; Mon, 27 Jan 2003 07:05:26 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12516; Mon, 27 Jan 2003 06:44:28 -0500 (EST) Message-Id: <200301271144.GAA12516@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-lonnofors-simple-partial-notify-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 27 Jan 2003 06:44:28 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Partial Notification of Presence Information Author(s) : J. Costa-Requena et al. Filename : draft-lonnofors-simple-partial-notify-00.txt Pages : 22 Date : 2003-1-24 A Presence service implemented using SIMPLE has some constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Other limitations can be caused by the interface between the terminal and the network, i.e. over radio links with high latency and low bandwidth. This memo presents a solution that aids in reducing the impact of those constrains and increasing efficiency, by introducing a new MIME-type æpartial notificationsÆ and a Require header extension æpartial-notificationÆ. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lonnofors-simple-partial-notify-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-lonnofors-simple-partial-notify-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-lonnofors-simple-partial-notify-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: <2003-1-24113212.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lonnofors-simple-partial-notify-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-lonnofors-simple-partial-notify-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-24113212.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 28 09:50:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27032 for ; Tue, 28 Jan 2003 09:50:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SFBqh25570 for simple-archive@odin.ietf.org; Tue, 28 Jan 2003 10:11:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFBqJ25563 for ; Tue, 28 Jan 2003 10:11:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26944 for ; Tue, 28 Jan 2003 09:50:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFBkJ25547; Tue, 28 Jan 2003 10:11:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0RC5VJ15237 for ; Mon, 27 Jan 2003 07:05:31 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12533; Mon, 27 Jan 2003 06:44:33 -0500 (EST) Message-Id: <200301271144.GAA12533@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-lonnfors-simple-presinfo-deliv-reqs-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 27 Jan 2003 06:44:33 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Efficient Delivery of Presence Information Author(s) : J. Costa-Requena et al. Filename : draft-lonnfors-simple-presinfo-deliv-reqs-00.txt Pages : 6 Date : 2003-1-24 A Presence service implemented using SIMPLE has some constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Other limitations can be caused by the interface between the terminal and the network, i.e. over radio links with high latency and low bandwidth. This memo presents requirements for a solution that aids in reducing the impacts of those constrains and increasing efficiency. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lonnfors-simple-presinfo-deliv-reqs-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lonnfors-simple-presinfo-deliv-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lonnfors-simple-presinfo-deliv-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-24113223.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lonnfors-simple-presinfo-deliv-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-lonnfors-simple-presinfo-deliv-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-24113223.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 28 09:50:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27045 for ; Tue, 28 Jan 2003 09:50:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SFBuV25597 for simple-archive@odin.ietf.org; Tue, 28 Jan 2003 10:11:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFBuJ25594 for ; Tue, 28 Jan 2003 10:11:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26948 for ; Tue, 28 Jan 2003 09:50:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFBqJ25568; Tue, 28 Jan 2003 10:11:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S7MOJ28242 for ; Tue, 28 Jan 2003 02:22:25 -0500 Received: from mx1.kapsch.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09266 for ; Tue, 28 Jan 2003 02:01:03 -0500 (EST) Received: from dumbo.kapsch.co.at (dumbo.kapsch.co.at) by mx1.kapsch.net (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Tue, 28 Jan 2003 08:04:32 +0100 Received: from atnews1.atc.co.at ([193.80.84.5]) by dumbo.kapsch.co.at with Microsoft SMTPSVC(5.0.2195.2966); Tue, 28 Jan 2003 08:04:32 +0100 Received: from aviepexs (aviepex3.atc.co.at [193.80.69.24]) Received: by aviepexs with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Jan 2003 08:04:52 +0100 Message-ID: From: Traussnig Robert To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 28 Jan 2003 07:04:32.0566 (UTC) FILETIME=[82279D60:01C2C69B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0S7MPJ28243 Subject: [Simple] Presence Authorization Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 28 Jan 2003 08:04:42 +0100 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I have a question regarding Presence Authorization. A UA knows about the Subscriptions made to him by subscribing to his WatcherInfo, but in the draft it is not explained how he can authorize the pending Subscriptions? Is there any draft which defines this? I think this is needed because of interoperability between different Presence Servers and Presence Clients. Thanks, Robert T. -- Ing. Robert Traussnig | SIP Protocol & Applications Kapsch CarrierCom AG | Triester Straße 70 | A-1100 Vienna | Austria Phone +43 1 60501 3188 | Fax +43 1 60501 3103 mailto:robert.traussnig@atc.co.at | http://www.kapsch.net _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 28 09:51:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27061 for ; Tue, 28 Jan 2003 09:51:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SFC3u25634 for simple-archive@odin.ietf.org; Tue, 28 Jan 2003 10:12:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFC3J25630 for ; Tue, 28 Jan 2003 10:12:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26968 for ; Tue, 28 Jan 2003 09:50:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFBwJ25616; Tue, 28 Jan 2003 10:11:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0S7vTJ30895 for ; Tue, 28 Jan 2003 02:57:29 -0500 Received: from mx1.kapsch.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18274 for ; Tue, 28 Jan 2003 02:36:07 -0500 (EST) Received: from dumbo.kapsch.co.at (dumbo.kapsch.co.at) by mx1.kapsch.net (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Tue, 28 Jan 2003 08:39:37 +0100 Received: from atnews1.atc.co.at ([193.80.84.5]) by dumbo.kapsch.co.at with Microsoft SMTPSVC(5.0.2195.2966); Tue, 28 Jan 2003 08:39:37 +0100 Received: from aviepexs (aviepex3.atc.co.at [193.80.69.24]) Received: by aviepexs with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Jan 2003 08:39:56 +0100 Message-ID: From: Traussnig Robert To: "'simple@ietf.org'" Subject: [Simple] Presence Authorization MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 28 Jan 2003 07:39:37.0379 (UTC) FILETIME=[68B89730:01C2C6A0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0S7vTJ30896 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 28 Jan 2003 08:39:47 +0100 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I have a question regarding Presence Authorization. A UA knows about the Subscriptions made to him by subscribing to his WatcherInfo, but in the draft it is not explained how he can authorize the pending Subscriptions? Is there any draft which defines this? I think this is needed because of interoperability between different Presence Servers and Presence Clients. Thanks, Robert T. -- Ing. Robert Traussnig | SIP Protocol & Applications Kapsch CarrierCom AG | Triester Straße 70 | A-1100 Vienna | Austria Phone +43 1 60501 3188 | Fax +43 1 60501 3103 mailto:robert.traussnig@atc.co.at | http://www.kapsch.net _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 28 09:51:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27079 for ; Tue, 28 Jan 2003 09:51:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SFC9X25665 for simple-archive@odin.ietf.org; Tue, 28 Jan 2003 10:12:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFC9J25662 for ; Tue, 28 Jan 2003 10:12:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26987 for ; Tue, 28 Jan 2003 09:50:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SFC3J25653; Tue, 28 Jan 2003 10:12:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SAYsJ07458 for ; Tue, 28 Jan 2003 05:34:54 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20230 for ; Tue, 28 Jan 2003 05:13:29 -0500 (EST) From: Jose.Costa-Requena@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0SAFvn07620 for ; Tue, 28 Jan 2003 12:15:57 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 28 Jan 2003 12:16:58 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 28 Jan 2003 12:16:58 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 28 Jan 2003 12:16:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <07A6D72550C5E0459DE676439EE5384601F57C68@esebe012.ntc.nokia.com> Thread-Topic: draft-lonnofors-simple-partial-notify-00 Thread-Index: AcLGnHBCopS/+/jHSwKkK7xc2HvzAAAGRyfQ To: , , Cc: X-OriginalArrivalTime: 28 Jan 2003 10:16:57.0878 (UTC) FILETIME=[63B26B60:01C2C6B6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0SAYsJ07459 Subject: [Simple] RE: draft-lonnofors-simple-partial-notify-00 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 28 Jan 2003 12:16:57 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Sean, Definitely that was one of the approaches we were considering but finally it was decided to aim that functionality by considering another content-type rather than defining a new header. Nevertheless, this should be evaluated in the list since our objective is to have a mechanism that solves this problem in the most optimal and scalable way without altering too much the protocol itself. Regards, Jose > -----Original Message----- > From: ext Sean Olson [mailto:seancolson@yahoo.com] > Sent: 28 January, 2003 09:11 > To: Costa-Requena Jose (NMP/Helsinki); Lonnfors Mikko (NRC/Helsinki); > Lonnfors Mikko (NRC/Helsinki); Khartabil Hisham (NMP/Helsinki) > Cc: simple@ietf.org > Subject: draft-lonnofors-simple-partial-notify-00 > > > Hi, > > I had a quick comment about the draft. I definitely see the need for > a partial notification mechanism. I also think the mechanism > proposed in > the draft > is a fairly straightforward and common approach to solving > this problem. > My main > comment is whether or not we can potentially generalize this > approach by > moving the > version and state variables out of the body and into SUB / > NOT specific > headers. Potentially even entity headers? I think this is a cleaner > approach then > necessarily creating two different but related schemas for > the full vs. > partial > notification. > > Regards, > Sean Olson > Microsoft > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 28 10:48:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28665 for ; Tue, 28 Jan 2003 10:48:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SG9Fq30187 for simple-archive@odin.ietf.org; Tue, 28 Jan 2003 11:09:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SG9FJ30184 for ; Tue, 28 Jan 2003 11:09:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28574 for ; Tue, 28 Jan 2003 10:47:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SG99J30121; Tue, 28 Jan 2003 11:09:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SG8BJ30064 for ; Tue, 28 Jan 2003 11:08:11 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28554 for ; Tue, 28 Jan 2003 10:46:40 -0500 (EST) From: krisztian.kiss@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0SFqbg19388 for ; Tue, 28 Jan 2003 17:52:37 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 28 Jan 2003 17:50:09 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 28 Jan 2003 17:50:08 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 28 Jan 2003 17:50:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Presence Authorization Message-ID: Thread-Topic: [Simple] Presence Authorization Thread-Index: AcLG3TCMJ8JoCfNURhqURwOqiYr3EAAByNBA To: , X-OriginalArrivalTime: 28 Jan 2003 15:50:08.0131 (UTC) FILETIME=[EED0F530:01C2C6E4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0SG8BJ30065 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 28 Jan 2003 17:50:07 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Robert, Please have a look on these I-Ds: http://www.ietf.org/internet-drafts/draft-ietf-simple-data-req-00.txt http://www.ietf.org/internet-drafts/draft-isomaki-simple-list-man-sem-00.txt Regards, Krisztian > -----Original Message----- > From: ext Traussnig Robert [mailto:Robert.Traussnig@atc.co.at] > Sent: Tuesday, January 28, 2003 9:05 AM > To: 'simple@ietf.org' > Subject: [Simple] Presence Authorization > > > I have a question regarding Presence Authorization. > A UA knows about the Subscriptions made to him by subscribing > to his WatcherInfo, but in the draft it is > not explained how he can authorize the pending Subscriptions? > Is there any draft which defines this? > I think this is needed because of interoperability between > different Presence Servers and Presence Clients. > > Thanks, > Robert T. > > > -- > Ing. Robert Traussnig | SIP Protocol & Applications > Kapsch CarrierCom AG | Triester Straße 70 | A-1100 Vienna | Austria > Phone +43 1 60501 3188 | Fax +43 1 60501 3103 > mailto:robert.traussnig@atc.co.at | http://www.kapsch.net > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 28 14:25:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04426 for ; Tue, 28 Jan 2003 14:25:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SJkmn12995 for simple-archive@odin.ietf.org; Tue, 28 Jan 2003 14:46:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJklJ12992 for ; Tue, 28 Jan 2003 14:46:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04418 for ; Tue, 28 Jan 2003 14:25:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJkAJ12958; Tue, 28 Jan 2003 14:46:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJjVJ12927 for ; Tue, 28 Jan 2003 14:45:31 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04408 for ; Tue, 28 Jan 2003 14:23:54 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0SJR5YH010251; Tue, 28 Jan 2003 14:27:05 -0500 (EST) Message-ID: <3E36D97F.30400@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: "Peterson, Jon" , "'Paul Kyzivat'" , simple@ietf.org Subject: Re: hierarchies (was RE: [Simple] Extending for presence) References: <15A2739B7DAA624D8091C65981D7DA8101214D28@stntexch2.va.neustar.com> <3E31AA89.1000104@dynamicsoft.com> <3E35A7AC.2030805@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 28 Jan 2003 14:26:55 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: >> 1. the subscriber wants to receive a PIDF for each group member when >> their status changes. Each PIDF has a single presentity, but it >> represents a group member. PIDF itself knows nothing abuot groups. >> There is a single subscription for the entire group. This is the >> roach-sip-list-template approach. > > > Even in that case, the PIDF should probably contain some kind of > identifier that tells the watcher why he is getting this PIDF document. > This is more than just "this is a group", but rather "you're getting > Alice's status since you subscribed to sales@example.com". > > In SIMPLE, the NOTIFY From will provide this information. Exactly. > Do we need a > separate indication in PIDF itself? Thats a good question. I think the model we've had to date was that the information about why you were receiving this notification (i.e., this user is in the list you subscribed to) was going to be provided via a separate header or document in the notify. Indeed, in addition to this presence information, there is other ancillary information that is needed, such as the status of the subscription from the list server to the actual presentity. This way, if one of the buddies on my buddy list denies my subscription, I have a way to see it. This is not PRESENCE state, its SUBSCRIPTION state. Now, perhaps we can split this ancillary information into presence related information (structure of the buddy list, presence in PIDF) and subscription information, presence in the ancillary body or headers. Not sure what the benefit is of this split. > > >> 3. the subscriber wants the state of the group and of its members. The >> subscription to the group indicates that it has a bunch of members, >> each represented by a tuple with a pres contact URI. THe subscriber >> then subscribes to each independently. There are N+1 subscriptions for >> a flat group with N members. > > > What does OPEN and CLOSED mean in that context? OPEN and CLOSED for a member, you mean? > Would it mean that the > member temporarily has no presence information available (I think so) or > that it is no longer a member of the group (I don't think so). Hmm. It comes down to what does OPEN/CLOSED mean. I think it means "attempts to connect to the URI in the contact will succeed (OPEN) or fail (CLOSED)". If that contact is a pres URI, or even better, the tuple indicates that it represents a presentity, the meaning of OPEN is that you will be able to succesfully subscribe to it. I would expect, as a result, that OPEN is really the only useful status. > In > general, how would a watcher detect that somebody is no longer a member? > (The person may still exist, just not as a member of the group.) The next notification would omit that user from the list. >> represents. As I mentioned in another email, the presentity and tuples >> could represent: >> >> groups >> users >> automaton >> devices >> logical components of a device >> >> So, I would assert that there is a need for another status type, say >> that can be applied to the tuples or the presentity, and >> is one of the values above. > > > However, I don't think these are all orthogonal, so I wouldn't want to > lump them into one descriptor. Basically, I want to know whether a > presentity has a "parent" (which indicates group). Thats true, but I do not think its sufficient. I think you really do want to know what a tuple and a presentity represent. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 28 14:27:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04452 for ; Tue, 28 Jan 2003 14:27:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SJm8r13072 for simple-archive@odin.ietf.org; Tue, 28 Jan 2003 14:48:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJm7J13069 for ; Tue, 28 Jan 2003 14:48:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04446 for ; Tue, 28 Jan 2003 14:26:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJm1J13059; Tue, 28 Jan 2003 14:48:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJlEJ13022 for ; Tue, 28 Jan 2003 14:47:14 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04424 for ; Tue, 28 Jan 2003 14:25:36 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0SJT5YH010254; Tue, 28 Jan 2003 14:29:08 -0500 (EST) Message-ID: <3E36D9F8.7050901@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: krisztian.kiss@nokia.com CC: Robert.Traussnig@atc.co.at, simple@ietf.org Subject: Re: [Simple] Presence Authorization References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 28 Jan 2003 14:28:56 -0500 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Some protocol drafts are also forthcoming based on these requirements. I will also add that the web is a perfectly good way to set such authorization, and that requires no standardization work. -Jonathan R. krisztian.kiss@nokia.com wrote: > Robert, > > Please have a look on these I-Ds: > http://www.ietf.org/internet-drafts/draft-ietf-simple-data-req-00.txt > http://www.ietf.org/internet-drafts/draft-isomaki-simple-list-man-sem-00.txt > > Regards, > Krisztian > >>-----Original Message----- >>From: ext Traussnig Robert [mailto:Robert.Traussnig@atc.co.at] >>Sent: Tuesday, January 28, 2003 9:05 AM >>To: 'simple@ietf.org' >>Subject: [Simple] Presence Authorization >> >> >>I have a question regarding Presence Authorization. >>A UA knows about the Subscriptions made to him by subscribing >>to his WatcherInfo, but in the draft it is >>not explained how he can authorize the pending Subscriptions? >>Is there any draft which defines this? >>I think this is needed because of interoperability between >>different Presence Servers and Presence Clients. >> >>Thanks, >>Robert T. >> >> >>-- >>Ing. Robert Traussnig | SIP Protocol & Applications >>Kapsch CarrierCom AG | Triester Straße 70 | A-1100 Vienna | Austria >>Phone +43 1 60501 3188 | Fax +43 1 60501 3103 >>mailto:robert.traussnig@atc.co.at | http://www.kapsch.net >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 28 14:58:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05466 for ; Tue, 28 Jan 2003 14:58:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SKJEZ15372 for simple-archive@odin.ietf.org; Tue, 28 Jan 2003 15:19:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SKJEJ15369 for ; Tue, 28 Jan 2003 15:19:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05440 for ; Tue, 28 Jan 2003 14:57:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SKJ8J15336; Tue, 28 Jan 2003 15:19:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SKIaJ15309 for ; Tue, 28 Jan 2003 15:18:36 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05391 for ; Tue, 28 Jan 2003 14:56:58 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0SK0WYH010343; Tue, 28 Jan 2003 15:00:33 -0500 (EST) Message-ID: <3E36E155.9000802@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jose.Costa-Requena@nokia.com CC: seancolson@yahoo.com, mikko.lonnfors@nokia.com, hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] RE: draft-lonnofors-simple-partial-notify-00 References: <07A6D72550C5E0459DE676439EE5384601F57C68@esebe012.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 28 Jan 2003 15:00:21 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think the version and state information belong in the XML document because they are document meta-data that is essential for the processing of the document itself. If the document was delivered by some other means, that same information would need to be present in order to process it (for example, if it was fetched from content indirection). -Jonathan R. Jose.Costa-Requena@nokia.com wrote: > Hi Sean, > > Definitely that was one of the approaches we were considering but finally it was decided to aim that functionality by considering another content-type rather than defining a new header. > Nevertheless, this should be evaluated in the list since our objective is to have a mechanism that solves this problem in the most optimal and scalable way without altering too much the protocol itself. > Regards, > Jose > > >>-----Original Message----- >>From: ext Sean Olson [mailto:seancolson@yahoo.com] >>Sent: 28 January, 2003 09:11 >>To: Costa-Requena Jose (NMP/Helsinki); Lonnfors Mikko (NRC/Helsinki); >>Lonnfors Mikko (NRC/Helsinki); Khartabil Hisham (NMP/Helsinki) >>Cc: simple@ietf.org >>Subject: draft-lonnofors-simple-partial-notify-00 >> >> >>Hi, >> >>I had a quick comment about the draft. I definitely see the need for >>a partial notification mechanism. I also think the mechanism >>proposed in >>the draft >>is a fairly straightforward and common approach to solving >>this problem. >>My main >>comment is whether or not we can potentially generalize this >>approach by >>moving the >>version and state variables out of the body and into SUB / >>NOT specific >>headers. Potentially even entity headers? I think this is a cleaner >>approach then >>necessarily creating two different but related schemas for >>the full vs. >>partial >>notification. >> >>Regards, >>Sean Olson >>Microsoft >> >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue Jan 28 15:09:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05731 for ; Tue, 28 Jan 2003 15:09:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SKUCQ15882 for simple-archive@odin.ietf.org; Tue, 28 Jan 2003 15:30:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SKUCJ15879 for ; Tue, 28 Jan 2003 15:30:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05713 for ; Tue, 28 Jan 2003 15:08:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SKU7J15869; Tue, 28 Jan 2003 15:30:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SKTdJ15829 for ; Tue, 28 Jan 2003 15:29:39 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05703 for ; Tue, 28 Jan 2003 15:08:01 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0SKBYYH010362; Tue, 28 Jan 2003 15:11:35 -0500 (EST) Message-ID: <3E36E3EA.7050003@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com CC: simple@ietf.org Subject: Re: [Simple] New I-Ds on partial notification References: <0C1353ABB1DEB74DB067ADFF749C4EEF1041C9@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 28 Jan 2003 15:11:22 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit While I really don't have any objection in principal to partial notification (winfo uses it, as you indicate), I am trying to understand better the underlying motivations that are driving it. In particular, pushing of large content (such as videos or images), IMHO, is still better handled by conten indirection that partial notifications. The reason is that the subscribing client may not want to pay for receipt of the content. Partial notification avoids the need to send it when it doesn't change, but when it does change, the susbcriber still needs to pay for this. Thus, content indirection to me seems the ideal solution to the charging concerns you raise. Your drafts point out some kind of problem with content indirection, in terms of charging, which I still don't really understand. Can you please clarify exactly what the problem is? On the mechanism itself, it seems that a better solution for the case where a tuple is deleted, is to define an XML element that explicitly indicates a deletion, carried in a partial update. For example: -Jonathan R. mikko.lonnfors@nokia.com wrote: > Hi, > > Here are links to two new drafts which deal with partial presence > notifications. > Requirements are discussed here: > _http://www.ietf.org/internet-drafts/draft-lonnfors-simple-presinfo-deliv-reqs-00.txt_ > > A Presence service implemented using SIMPLE has some constraints for > delivering presence information to devices with low data processing > capabilities, small display, and limited battery power. Other > limitations can be caused by the interface between the terminal and > the network, i.e. over radio links with high latency and low > bandwidth. This memo presents requirements for a solution that aids > in reducing the impacts of those constrains and increasing > efficiency. > > And the actual solution is described here: > _http://www.ietf.org/internet-drafts/draft-lonnofors-simple-partial-notify-00.txt_ > > A Presence service implemented using SIMPLE has some constraints for > delivering presence information to devices with low data processing > capabilities, small display, and limited battery power. Other > limitations can be caused by the interface between the terminal and > the network, i.e. over radio links with high latency and low > bandwidth. This memo presents a solution that aids in reducing the > impact of those constrains and increasing efficiency, by introducing > a new MIME-type partial notifications and a Require header > extension partial-notification. > > All comments are most welcome. > > Regards > - Mikko > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed Jan 29 09:19:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20091 for ; Wed, 29 Jan 2003 09:19:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0TEfKa29830 for simple-archive@odin.ietf.org; Wed, 29 Jan 2003 09:41:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TEfKJ29827 for ; Wed, 29 Jan 2003 09:41:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20083 for ; Wed, 29 Jan 2003 09:19:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TEfDJ29816; Wed, 29 Jan 2003 09:41:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0TEeXJ29786 for ; Wed, 29 Jan 2003 09:40:33 -0500 Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20077 for ; Wed, 29 Jan 2003 09:18:33 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0TEOTe12447 for ; Wed, 29 Jan 2003 16:24:29 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 29 Jan 2003 16:22:01 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 29 Jan 2003 16:22:01 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] New I-Ds on partial notification X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1D7F2@esebe004.ntc.nokia.com> Thread-Topic: [Simple] New I-Ds on partial notification Thread-Index: AcLHCXh2/x7tNN9CRg2lFwCThEur6AAW6esQ To: Cc: X-OriginalArrivalTime: 29 Jan 2003 14:22:01.0473 (UTC) FILETIME=[CA22B710:01C2C7A1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0TEeYJ29787 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 29 Jan 2003 16:22:00 +0200 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Jonathan, As you say CI works pretty well but there are some complications. Charging issue is at least partly 3GPP specific. Charging would be especially difficult in 3GPP type solution where all SIP carried stuff goes via one PDP context (e.g. signaling PDP context). All other traffic is going through other PDP contexts. From these the SIP carried stuff can be free on the bearer level and service based charging is applied in the application server. Other PDP contexts typically cause bill based on the data amount transferred. Now if the operator wants to allow large content as part of the presence and apply a service based changing the system becomes unnecessarily complex due to CI. CI requires some storage where content should be places until its fetched or it expires. This box then needs to maintained and connected to existing network elements like PS. This may be unnecessary overhead for some systems. Security is other issue. System should be able to associate HTTP requests to specific subscription or to specific user. Also if CI is done in some other domain than subscriber's own this issue gets more complicated. One issue relates to usability. If you really want to utilize CI user should always be prompted to make decision whether content should be downloaded or not. If these changes happen often user may be prompted quite frequently (for example every 5 minutes) to make decision about content downloading. This is not very usable ad for example for flat rate charging it does not make much sense. If you want to limit the amount of content delivered via notifications I think filtering might be right solution for that. Also partial notifications allow PS not to send even small amounts of data. In wireless environment this very useful. Personally I think CI is a fine mechanism but some systems might like to use some other mechanism like partial notification. > We also though about adding this kind of mechanism. Our thinking was that we could live without it but if others see that it should be added I don't have anything agents it. This would basically allow PS to send partial notifications about removed tuples and not enforcing it to send full presence document. Regards - Mikko > > While I really don't have any objection in principal to partial > notification (winfo uses it, as you indicate), I am trying to > understand better the underlying motivations that are driving it. > > In particular, pushing of large content (such as videos or images), > IMHO, is still better handled by conten indirection that partial > notifications. The reason is that the subscribing client may not want > to pay for receipt of the content. Partial notification avoids > the need to > send it when it doesn't change, but when it does change, the > susbcriber > still needs to pay for this. > Thus, content indirection to me seems the ideal solution to > the charging > concerns you raise. Your drafts point out some kind of problem with > content indirection, in terms of charging, which I still don't really > understand. Can you please clarify exactly what the problem is? > > > On the mechanism itself, it seems that a better solution for the case > where a tuple is deleted, is to define an XML element that explicitly > indicates a deletion, carried in a partial update. For example: > > > > -Jonathan R. > >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 30 06:07:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24254 for ; Thu, 30 Jan 2003 06:07:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UBTNn23286 for simple-archive@odin.ietf.org; Thu, 30 Jan 2003 06:29:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UBTNJ23283 for ; Thu, 30 Jan 2003 06:29:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24225 for ; Thu, 30 Jan 2003 06:07:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UBTIJ23274; Thu, 30 Jan 2003 06:29:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UBSJJ23213 for ; Thu, 30 Jan 2003 06:28:19 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24190 for ; Thu, 30 Jan 2003 06:05:55 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0UB9QKV003345 for ; Thu, 30 Jan 2003 12:09:26 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 30 Jan 2003 12:09:26 +0100 Message-ID: From: "Vesa Torvinen (LMF)" To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Simple] Presence and a potential DDos attack? Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Jan 2003 12:09:24 +0100 I have a question related to Presence and a potential DDos attack. I am thinking the following scenario: 1) We have anonymous watcher (the attacker) subscribing to the presence information of a presentity. The victims IP-address is defined in the Contact header. 2) The subscription policy of the presentity allows anonymous subscriptions. 3) The presence server has a local policy of challenging all anonymous watchers with HTTP Digest. 4) The watcher replies to the HTTP challenge with 'anonymous' username and empty password as described in RFC 3261. 5) The presence server accepts the subscription and the victim receives the notifications. Is this attack possible? Or maybe you have already discussed the issue... Vesa _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu Jan 30 07:55:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26137 for ; Thu, 30 Jan 2003 07:55:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0UDHJn30132 for simple-archive@odin.ietf.org; Thu, 30 Jan 2003 08:17:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDHJJ30129 for ; Thu, 30 Jan 2003 08:17:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26132 for ; Thu, 30 Jan 2003 07:54:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDH9J30116; Thu, 30 Jan 2003 08:17:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0UDGDJ30068 for ; Thu, 30 Jan 2003 08:16:13 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25856; Thu, 30 Jan 2003 07:53:47 -0500 (EST) Message-Id: <200301301253.HAA25856@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-moran-simple-pres-filter-reqs-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 30 Jan 2003 07:53:47 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Presence specific Event Notification Filters Author(s) : T. Moran, S. Addagatla Filename : draft-moran-simple-pres-filter-reqs-00.txt Pages : 7 Date : 2003-1-29 This document defines a set of structured requirements whereby an event subscriber (client) may specify when notifications are sent to it and what the contents should be. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-moran-simple-pres-filter-reqs-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-moran-simple-pres-filter-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-moran-simple-pres-filter-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-29154728.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-moran-simple-pres-filter-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-moran-simple-pres-filter-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-29154728.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 31 09:08:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07061 for ; Fri, 31 Jan 2003 09:08:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VEBWC28378 for simple-archive@odin.ietf.org; Fri, 31 Jan 2003 09:11:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VEBWJ28375 for ; Fri, 31 Jan 2003 09:11:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07054 for ; Fri, 31 Jan 2003 09:07:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VEBMJ28366; Fri, 31 Jan 2003 09:11:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VEAuJ28345 for ; Fri, 31 Jan 2003 09:10:56 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07050 for ; Fri, 31 Jan 2003 09:06:53 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0VEARYH012948; Fri, 31 Jan 2003 09:10:28 -0500 (EST) Message-ID: <3E3A83CE.7070808@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vesa Torvinen (LMF)" CC: "'simple@ietf.org'" Subject: Re: [Simple] Presence and a potential DDos attack? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 31 Jan 2003 09:10:22 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This attack is addressed in rfc3265 itself, since its possible to launch against any event system. The remedy for it is that the notifier cancels a subscription if it receives a 481 or a transaction timeout (both of which would signify lack of interest from the attacked-watcher). Also, anonymous watchers are not such a great idea. -Jonathan R. Vesa Torvinen (LMF) wrote: > I have a question related to Presence and a potential DDos > attack. I am thinking the following scenario: > > 1) We have anonymous watcher (the attacker) subscribing to > the presence information of a presentity. The victims > IP-address is defined in the Contact header. > > 2) The subscription policy of the presentity allows anonymous > subscriptions. > > 3) The presence server has a local policy of challenging all > anonymous watchers with HTTP Digest. > > 4) The watcher replies to the HTTP challenge with 'anonymous' > username and empty password as described in RFC 3261. > > 5) The presence server accepts the subscription and the victim > receives the notifications. > > Is this attack possible? > > Or maybe you have already discussed the issue... > > Vesa > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 31 10:43:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10163 for ; Fri, 31 Jan 2003 10:43:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VFlCf01535 for simple-archive@odin.ietf.org; Fri, 31 Jan 2003 10:47:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VFlCJ01532 for ; Fri, 31 Jan 2003 10:47:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10141 for ; Fri, 31 Jan 2003 10:43:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VFl6J01523; Fri, 31 Jan 2003 10:47:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VFkvJ01492 for ; Fri, 31 Jan 2003 10:46:57 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10129 for ; Fri, 31 Jan 2003 10:42:53 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0VFkTYH012978; Fri, 31 Jan 2003 10:46:29 -0500 (EST) Message-ID: <3E3A9A4F.9030805@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com CC: simple@ietf.org Subject: Re: [Simple] New I-Ds on partial notification References: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1D7F2@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 31 Jan 2003 10:46:23 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. mikko.lonnfors@nokia.com wrote: > Hi Jonathan, > > As you say CI works pretty well but there are some complications. > Charging issue is at least partly 3GPP specific. Charging would be > especially difficult in 3GPP type solution where all SIP carried stuff > goes via one PDP context (e.g. signaling PDP context). All other traffic > is going through other PDP contexts. From these the SIP carried stuff > can be free on the bearer level and service based charging is applied in > the application server. Other PDP contexts typically cause bill based on > the data amount transferred. Now if the operator wants to allow large > content as part of the presence and apply a service based changing the > system becomes unnecessarily complex due to CI. Such a differentiated charging model for content opens the door for fraud. If sending content through presence is free, but costs money other ways, won't users just always send content through presence? > CI requires some storage where content should be places until its > fetched or it expires. This box then needs to maintained and connected > to existing network elements like PS. This may be unnecessary overhead > for some systems. No doubt this is extra infrastructure to maintain. However, such things will frequently exist anyway (i.e., MMSC provides a similar function). > > Security is other issue. System should be able to associate HTTP > requests to specific subscription or to specific user. Also if CI is > done in some other domain than subscriber's own this issue gets more > complicated. I would propose that security for indirection needs to be equivalently good (or bad) to without indirection. With indirection, if I can eavesdrop, I can get the content, unless its e2e encrypted or goes over encrypted links. Now, if the CI URI is cryptographically random, it turns out the same holds true. You won't be able to guess the URI. To find it out, you'd have to be able to eavesdrop. Of course, if you could eavesdrop, you could obtain the content even if there were no indirection. If the URI is protected e2e with encryption, or goes over secure links, you will get good security. So, AFAICT, security of indirection can be the same for inline content so long as the URI are intelligently chosen. > > One issue relates to usability. If you really want to utilize CI user > should always be prompted to make decision whether content should be > downloaded or not. If these changes happen often user may be prompted > quite frequently (for example every 5 minutes) to make decision about > content downloading. This is not very usable ad for example for flat > rate charging it does not make much sense. One feature of indirection is that it indicates when its changed. So, you would know only to download the content in those cases. > If you want to limit the amount of content delivered via notifications I > think filtering might be right solution for that. Also partial > notifications allow PS not to send even small amounts of data. In > wireless environment this very useful. > > Personally I think CI is a fine mechanism but some systems might like to > use some other mechanism like partial notification. Well, let me be clear on my position. I have problem with partial notifications. I dont mind developing a spec for them either. However, I think their need is greatly overestimated, and it will buy you far less than you think for the complexity it introduces. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri Jan 31 12:38:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13233 for ; Fri, 31 Jan 2003 12:38:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VHgDq08574 for simple-archive@odin.ietf.org; Fri, 31 Jan 2003 12:42:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VHgCJ08571 for ; Fri, 31 Jan 2003 12:42:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13225 for ; Fri, 31 Jan 2003 12:38:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VHg7J08560; Fri, 31 Jan 2003 12:42:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0VHf3J08511 for ; Fri, 31 Jan 2003 12:41:03 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13211 for ; Fri, 31 Jan 2003 12:36:55 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.40]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id h0VHeWYH013217 for ; Fri, 31 Jan 2003 12:40:32 -0500 (EST) Message-ID: <3E3AB50C.90802@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Updated presence specs Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 31 Jan 2003 12:40:28 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, I just submitted an update to all three core presence specs based on the comments received by IESG during their review. All of these have been discussed on the list. Until they appear in the archives, you can pick them up at: http://www.jdrosen.net/papers/draft-ietf-simple-winfo-format-04.txt http://www.jdrosen.net/papers/draft-ietf-simple-winfo-package-05.txt http://www.jdrosen.net/papers/draft-ietf-simple-presence-10.txt Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple