From simple-bounces@ietf.org Fri Oct 1 00:24:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03989; Fri, 1 Oct 2004 00:24:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDF70-0004Dq-73; Fri, 01 Oct 2004 00:33:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDEuk-0004UD-7K; Fri, 01 Oct 2004 00:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDEf3-0008LB-TM for simple@megatron.ietf.org; Fri, 01 Oct 2004 00:04:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02208 for ; Fri, 1 Oct 2004 00:04:46 -0400 (EDT) Received: from s-utl01-slpop.stsn.com ([12.168.96.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CDEnR-0003na-7V for simple@ietf.org; Fri, 01 Oct 2004 00:13:29 -0400 Received: from slpop.smtp.stsn.com ([127.0.0.1]) by s-utl01-slpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004093022041722814 for ; Thu, 30 Sep 2004 22:04:17 -0600 Received: from dynamicsoft.com ([10.2.175.167]) by slpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 30 Sep 2004 22:04:17 -0600 Message-ID: <415CA78D.6070003@dynamicsoft.com> Date: Thu, 30 Sep 2004 20:40:45 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] Scope of XCAP PIDF manipulation wrt. Presence Data Model References: <415A393F.3050900@dynamicsoft.com> <415ACD9A.5000004@cisco.com> In-Reply-To: <415ACD9A.5000004@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Oct 2004 04:04:17.0881 (UTC) FILETIME=[B8E8A490:01C4A76B] X-Spam-Score: 0.7 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, Markus.Isomaki@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit I'm not sure about that. I'm really worried that we'll have interop problems because folks will look at the pidf-manipulation draft, look at publish, and decide to just do one of them, whereas the provider chose the other. Generally, having more than one way to do the same thing is bad. -Jonathan R. Paul Kyzivat wrote: > Jonathan, > > I agree with you and Markus on the validity of Markus's suggested usage. > And I agree the kind of clarification you suggest would be helpful. But > I don't think this is normative behavior, so lets make sure the language > isn't too strong. (All of these attributes should be possible to > manipulate *either* via XCAP or PUBLISH. > > Paul > > Jonathan Rosenberg wrote: > >> Markus, >> >> You make a good point about another use case for the pidf manipulation. >> >> Based on this, I think the pidf-manipulation draft needs to more >> carefully outline the use cases. I think it would be good to point out >> that it is ideal for: >> >> (1) manipulating person information, >> (2) manipulating services that operate in the absence of agents that >> actively run on behalf of the user (email, for example) >> >> In essence, then, the distinction is that PUBLISH is used when there >> is a software agent of some sort representing a device or service, and >> the ability to use that service or that device is predicated on the >> existence and correct operation of that agent. For the above two >> cases, there need not be a software agent that runs in order for the >> data to be meaningful, and thus xcap-pidf. >> >> Probably it needs to be expressed better, but hopefully the idea makes >> sense. >> >> Thanks, >> Jonathan R. >> >> Markus.Isomaki@nokia.com wrote: >> >>> Hi all, >>> >>> The approach presented in Data Model for Presence >>> (http://www.ietf.org/internet-drafts/draft-rosenberg-simple-presence-data-model-00.txt) >>> has been in principle approved in SIMPLE WG, but there are still some >>> open issues on details. One of them concerns the scope of XCAP >>> application usage for PIDF manipulation >>> (http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-pidf-manipulation-usage-01.txt). >>> The Data Model draft has the following text in Chapter 10: >>> One of the source of confusion around the XCAP manipulation of >>> PIDF [17] is that it was unclear as to why one would use it as >>> opposed to PUBLISH. The presence data model presented here sheds >>> some light on that. PUBLISH is appropriate for communicating >>> information about services and devices. PUBLISH is designed for >>> the model where there can be more than one such source (as there >>> is for devices and servcies), and where such state is soft-state >>> (as it should be for devices and services). However, presentity >>> state is not clearly soft-state, and the model here clearly >>> indicates that each presence document can have a single presentity >>> element. Thus, it might make sense to change the >>> pidf-manipulation spec to only allow setting of presentity tuples. >>> Now, that doesnt forbid a source from trying to PUBLISH presentity >>> information, but there is clearly a need for a hard-state approach >>> for setting presentity information. >>> >>> The concrete issue here is whether XCAP PIDF manipulation should be >>> restricted to setting only presentity tuple, i.e. not allow the >>> setting of service tuples or device information. >>> >>> My opinion is that we should not make this kind of restriction. >>> There is at least one use case where "hard state" service tuples make >>> a lot of sense, and that is service tuples for "persistent" services >>> such as e-mail, SMS, MMS or voicemail. These communication means are >>> available for the sender even if the recipient is not on-line wrt. >>> that service, since there is a network-based "inbox" taking care of >>> them. XCAP PIDF manipulation is a better way to describe this kind >>> "off-line" state for such services rather than SIP PUBLISH. (BTW, I >>> believe we should define some new status attribute to this kind of >>> services to clearly indicate the difference between "MMS available >>> but no device on-line" vs. "MMS available with a device on-line" etc. >>> Or probably the standardization fora responsible for e.g. MMS can do >>> that.) >>> >>> What might be a useful specification is to say that in a typical >>> scenario information derived from SIP PUBLISH takes presedence over >>> the information derived from XCAP. But that is already in the >>> territory of specifying the composer policy, which I think is a >>> separate effort from the data model of XCAP PIDF manipulation drafts. >>> >>> So my proposal is basically to keep the XCAP PIDF manipulation draft >>> as it is at the moment, and not make any restricting statements about >>> its use in the Data Model either. Are there other opinions on this >>> topic? >>> >>> Regards, >>> Markus >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 simple-bounces@ietf.org Fri Oct 1 01:14:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07103; Fri, 1 Oct 2004 01:14:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDFsS-0005Rk-EF; Fri, 01 Oct 2004 01:22:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDFYZ-000792-9L; Fri, 01 Oct 2004 01:02:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDFNP-00041J-9v for simple@megatron.ietf.org; Fri, 01 Oct 2004 00:50:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05854 for ; Fri, 1 Oct 2004 00:50:35 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDFVk-0004mE-23 for simple@ietf.org; Fri, 01 Oct 2004 00:59:19 -0400 Received: from dynamicsoft.com ([63.113.46.23]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i914oFpl024365; Fri, 1 Oct 2004 00:50:16 -0400 (EDT) Message-ID: <415CE1ED.6070900@dynamicsoft.com> Date: Fri, 01 Oct 2004 00:49:49 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] Pres Data Model Open Issue #1: in-person communications References: <4159D228.5040905@dynamicsoft.com> <4159FB36.9090502@cs.columbia.edu> In-Reply-To: <4159FB36.9090502@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > I agree, although the two examples you give are rather different in > their usefulness. > > In practice, status information for the postal elements is not > particularly useful as it doesn't tend to change a lot. Your postal > availability is not exactly something subject to OPEN/CLOSED. Plus, the > CIPID vcard element already allows to express this. I don't see why my postal information isn't subject to open or closed, like anything else. Admittedly it won't change often. HOwever, if I go on vacation for two weeks, might I not want to change it to closed? This is the example Mike gave. I don't see how email or SMS or MMS, or any form of store and forward messaging, would be different than postal in this regard. I do think we have agreed that sms, mms and email are useful services to list in the presence docuemnt. I agree that the cipid vcard can be used to convey my postal address. Perhaps then the postal "url" is nothing more than the reference to this vcard, perhaps in the same presence document even. However, that doesnt mean that postal is not a communications service as defined in the model. > > The in-person indication is definitely more useful for coordination. I'd > argue you'd actually want a "protocol" indication, not a URN indication, > since you've already identified the person. OK, so you are saying its a url, and not a URN. I can buy that... > > As you said, this can easily be solved by a convention, maybe suitably > defined in an April 1 RFC, along with the carrier pigeon URL. Well, except that I dont think its a joke at all. I think it would be quite valuable to have this capability in PIDF. Its a real, valid, and absolutely useful form of a communications service to list in a presence document. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 simple-bounces@ietf.org Fri Oct 1 01:19:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07606; Fri, 1 Oct 2004 01:19:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDFxp-0005ZH-Cg; Fri, 01 Oct 2004 01:28:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDFYa-00079C-6q; Fri, 01 Oct 2004 01:02:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDFS1-0004r3-0M for simple@megatron.ietf.org; Fri, 01 Oct 2004 00:55:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06050 for ; Fri, 1 Oct 2004 00:55:21 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDFaO-0004tg-Kq for simple@ietf.org; Fri, 01 Oct 2004 01:04:05 -0400 Received: from dynamicsoft.com ([63.113.46.23]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i914sxpl024383; Fri, 1 Oct 2004 00:54:59 -0400 (EDT) Message-ID: <415CE30A.5050008@dynamicsoft.com> Date: Fri, 01 Oct 2004 00:54:34 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Hammer Subject: Re: [Simple] Pres Data Model Open Issue #1: in-person communications References: <4.3.2.7.2.20040929110138.00b15708@cia.cisco.com> <4159D228.5040905@dynamicsoft.com> <4159D228.5040905@dynamicsoft.com> <4.3.2.7.2.20040929110138.00b15708@cia.cisco.com> <4.3.2.7.2.20040929121646.00b30118@cia.cisco.com> In-Reply-To: <4.3.2.7.2.20040929121646.00b30118@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: Simple WG , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit inline. Mike Hammer wrote: > On the other hand, not all folks carry GPS devices, so the ability > somewhere to convert a Lat/Long to a street address is useful. > > But, to clarify my early point, if the person location information is > available via presence, then the need to define an in-person > communications means is probably moot. I strongly disagree. In-person communications is a service as defined in our model. It has all of the properties of a service. Its a modality. It has characteristics (audio and video content, low latency), and most importantly, it has status (I'm available for folks to come to my office now). Indeed, this status is different from person status. For example, I as a person (using the term person as defined in the model) can be "on the phone", but my availability for in-person communications might still be open if I'm willing to answer a knock at the door while on the phone. It also makes sense to me to be able to prioritize in-person communications over other services, like telephony or IM. Indeed, I might prioritize them differently for different watchers. None of this would be conveyable in the model if in-person is not identified as a service; person doesn't convey availability for communcations, priority, or other characteristics. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 simple-bounces@ietf.org Fri Oct 1 01:34:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08792; Fri, 1 Oct 2004 01:34:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDGC3-0005qi-HC; Fri, 01 Oct 2004 01:43:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDFtF-0004Fx-7W; Fri, 01 Oct 2004 01:23:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDFYm-0007AC-VG for simple@megatron.ietf.org; Fri, 01 Oct 2004 01:02:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06598 for ; Fri, 1 Oct 2004 01:02:23 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDFh8-00056U-0B for simple@ietf.org; Fri, 01 Oct 2004 01:11:05 -0400 Received: from dynamicsoft.com ([63.113.46.23]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i91523pl024417; Fri, 1 Oct 2004 01:02:03 -0400 (EDT) Message-ID: <415CE4B2.80008@dynamicsoft.com> Date: Fri, 01 Oct 2004 01:01:38 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] Pres Data Model Open Issue #3, UUID URN or something else References: <4159D54F.5060700@dynamicsoft.com> <4159E364.8030204@cisco.com> In-Reply-To: <4159E364.8030204@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: >> I would propose approach (3). In particular, I think the data model >> should revert to being agnostic on the URN scheme, reference the >> UUID URN as one possibility, document its problems. We should >> develop a separate specification that defines guidelines for >> choosing the URN for various devices in order to get the >> correlation properties we want. I also think we should take a stab >> at defining a few URN schemes that would be useful - MAC and ESN in >> particular. > > > I think it does make sense to leave the particular choice out of this > document. > > I do think the problem with UUID can be dealt with in a couple of > ways: > > - for some kinds of "devices", like softphones and IM clients, it is > probably fine as-is. They can typically have multiple instances per > device, so they must construct and instance id and save it > persistently as part of the instance configuration. I think softphones are PC-based devices are a candidate where we want to be able to correlate service information with device information learned from network elements like an 802.11 AP. Thus, I do think this problem applies to things besides phones. > > - for a dedicated device, like a phone, that can't or doesn't want to > use the above technique, a cannonical mac-based uuid can be > constructed by using a fixed time (e.g. zero) along with the mac. I thought about that, but wasn't able to convince myself that it was allowed in the UUID URN spec. Do you find words that allow you to set the time to zero? Henning wrote: > As discussed previously, a device may not even have a MAC or may have > several (if it is a composite or a multi-homed device). Thus, this > seems inherently difficult. We went through this whole discussion > before, I believe. Right. We talked more about it during the design team meeting in San Diego. We did in fact reach conclusion on a few things: a. there isn't a universal URN that is going to solve this problem, due to the fact that different devices will be identified in different ways b. using an interface address or an esn works ok, but is likely that for devices which have both (like my palm treo 600, which has Internet access and is a phone), an app which tries to djin the device ID may choose the wrong one. Thus, the presence server will think that services on the same device are running on different devices. THe ultimate solution to this is that determination and handing out of a device ID needs to be an OS function. That is now documented in the model draft. c. Ideally, with a bunch of URNs under our belt, if there was a "well known" algorithm for computing a sensible URN for different devices, it would improve the chance of being able to correlate presence information from different sources together. We could at least cover the common case (single homed PC) with the recommendation of a mac address, and cover more complex cases later. Thus the recommendation in the model draft of using UUID URN. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 simple-bounces@ietf.org Fri Oct 1 01:35:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08853; Fri, 1 Oct 2004 01:35:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDGCo-0005rC-5G; Fri, 01 Oct 2004 01:43:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDFtF-0004GD-PV; Fri, 01 Oct 2004 01:23:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDFaY-0007TV-Kl for simple@megatron.ietf.org; Fri, 01 Oct 2004 01:04:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06629 for ; Fri, 1 Oct 2004 01:04:13 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDFiw-00059s-Qt for simple@ietf.org; Fri, 01 Oct 2004 01:12:55 -0400 Received: from dynamicsoft.com ([63.113.46.23]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i9153vpl024432; Fri, 1 Oct 2004 01:03:58 -0400 (EDT) Message-ID: <415CE525.4030201@dynamicsoft.com> Date: Fri, 01 Oct 2004 01:03:33 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] Pres Data Model Issue #4, indicating the source of data References: <4159D600.8010201@dynamicsoft.com> <415AFFE2.1020705@cs.columbia.edu> In-Reply-To: <415AFFE2.1020705@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Similar work will have to be done for geolocation, as this is quite > important for 911 services to debug when things go wrong. I suspect some > of the considerations are similar. (You want to know, for example, > whether the information is native or has been translated and combined in > some way.) The same thing had occurred to me, yes. > > Also, in general, different pieces of information are likely to have > different types of sources. For location information, you want to know > whether this is from GPS or LORAN. Other items will have different > labeling requirements. Right. In that regard, location sources are arguably a subset of the more general "presence data source" problem. > > In short: not only out of scope for a general document for getting-done > reasons, but likely to be highly content-dependent and best handled for > each type of information. Right. Punt was the big theme in my proposed open issue resolutions ;) -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 simple-bounces@ietf.org Fri Oct 1 01:47:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09614; Fri, 1 Oct 2004 01:47:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDGOU-00067C-DL; Fri, 01 Oct 2004 01:55:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDG59-00080W-9I; Fri, 01 Oct 2004 01:35:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDFud-0004Xd-1G for simple@megatron.ietf.org; Fri, 01 Oct 2004 01:24:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08114 for ; Fri, 1 Oct 2004 01:24:57 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDG30-0005eS-7k for simple@ietf.org; Fri, 01 Oct 2004 01:33:39 -0400 Received: from dynamicsoft.com ([63.113.46.23]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i915Oepl024502; Fri, 1 Oct 2004 01:24:40 -0400 (EDT) Message-ID: <415CE9FF.4030205@dynamicsoft.com> Date: Fri, 01 Oct 2004 01:24:15 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Hammer Subject: Re: [Simple] Pres Data Model Open Issue #5: what does idle mean? References: <4.3.2.7.2.20040929103449.00b0e058@cia.cisco.com> In-Reply-To: <4.3.2.7.2.20040929103449.00b0e058@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit responding to Mike, Paul and Henning in one note: Mike Hammer wrote: > Jonathan, > > I'm having a sense of deja vu here. I thought previous discussions > led to the conclusion that idle means exactly that, i.e. no activity > since some time point, which may or may not be provided, depending > on whether the idler felt that this would violate privacy. The question is, what does "no activity" mean. > > The conclusion that one could jump to based on such an indication > would be implicit to the type of service, device, or person. The > likelihood of a no answer is conditional and thus requires some > intelligence to guess that. I thought this would be left to humans > that have such cognitive skills. I agree, I'm merely presenting an alternative formulation which I thought had been proposed by someone at some point. Seems that Henning also agrees that 'you probably won't get an answer' is not what it means. Seems like perhaps some consensus on this part at least. > While lack of user input is the most likely basis, this can be fooled > or not depending on what the thing reporting is. Does a user > include automatons? I would say that is an implementation detail and > just leave it at a "no activity since" definition. I see no reason > to constrain this. My 2 cents from the peanut gallery. Here is where I disagree. If we don't have a reasonably consistent definition of what "no activity" means, I don't see how humans or automata can reasonably combine that information with other presence data and come to a meaningful conclusion. From some of the discussions we had, there were quite a few different interpretations of what "no activity" meant. Henning wrote: >> At this moment, I'm inclined to the concrete definition (lack of >> user input), and have it be associated with the device, not the >> service. I know others have different opinions. Lets sort this out. >> >> > > > I disagree with the 'device, not service'. I can easily detect > non-usage for a service and it seems to be as valuable for that > service as for some piece of plastic. OK, I can live with that. My main beef is that it be well defined. I'd offer up the following initial definitions: device-idle: The device has received no data input on any of its user input devices that require active input (including keyboards, mice, trackballs, but excluding things like microphones and cameras where there is always "input") service-idle: For a service which receives input while it is the "focus" of the user interaction (focus in the user interface sense), there has been no input. For example, if my IM app is running, but I haven't selected it on my PC, its idle even though I may be typing into another app. Fire away. Paul Kyzivat wrote: > I think idle makes sense for devices, services, and maybe people as > well. If we say idle can only be used for devices we will have > problems when there are services that are capable of reporting their > own idleness but are unable to determine device idleness. I can buy device and service. Person is something different. Sure, an individual can be idle in the sense that they are bored or have nothing to do. But this would seem to be one value of something like a element, as opposed to a separate standalone attribute. Or did you have something else in mind? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 mailman-bounces@ietf.org Fri Oct 1 07:54:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21243 for ; Fri, 1 Oct 2004 07:54:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDM7r-0005SI-O3 for simple-archive@ietf.org; Fri, 01 Oct 2004 08:03:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJt9-0003nL-MJ for simple-archive@ietf.org; Fri, 01 Oct 2004 05:39:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: simple-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:16:40 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org 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, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for simple-archive@ietf.org: List Password // URL ---- -------- simple@ietf.org onahda https://www1.ietf.org/mailman/options/simple/simple-archive%40ietf.org From simple-bounces@ietf.org Fri Oct 1 11:55:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15772; Fri, 1 Oct 2004 11:55:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDPtW-0001lj-1q; Fri, 01 Oct 2004 12:04:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDMls-00032Q-Tf; Fri, 01 Oct 2004 08:44:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDK0v-0000IK-Kg for simple@megatron.ietf.org; Fri, 01 Oct 2004 05:47:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11559 for ; Fri, 1 Oct 2004 05:47:43 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDK94-00030B-1N for simple@ietf.org; Fri, 01 Oct 2004 05:56:28 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i919l7116792; Fri, 1 Oct 2004 12:47:07 +0300 (EET DST) X-Scanned: Fri, 1 Oct 2004 12:46:49 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i919knoR011411; Fri, 1 Oct 2004 12:46:49 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00LCGm5x; Fri, 01 Oct 2004 12:46:36 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i919kZY19390; Fri, 1 Oct 2004 12:46:35 +0300 (EET DST) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 1 Oct 2004 12:46:35 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 1 Oct 2004 12:46:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Pres Data Model Open Issue #5: what does idle mean? Date: Fri, 1 Oct 2004 12:46:34 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C08B686@esebe056.ntc.nokia.com> Thread-Topic: [Simple] Pres Data Model Open Issue #5: what does idle mean? Thread-Index: AcSnej+5RYns7NAEQAaE05742fb4WwAHCpBQ To: , X-OriginalArrivalTime: 01 Oct 2004 09:46:34.0183 (UTC) FILETIME=[897FA570:01C4A79B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Jonathan Rosenberg > Sent: 01.October.2004 08:24 > To: Mike Hammer > Cc: Simple WG > Subject: Re: [Simple] Pres Data Model Open Issue #5: what does idle > mean? >=20 >=20 >=20 > OK, I can live with that. My main beef is that it be well defined. I'd > offer up the following initial definitions: >=20 > device-idle: The device has received no data input on any of its user > input devices that require active input (including keyboards, mice, > trackballs, but excluding things like microphones and cameras where > there is always "input") Ok. >=20 > service-idle: For a service which receives input while it is=20 > the "focus" > of the user interaction (focus in the user interface sense), there has > been no input. For example, if my IM app is running, but I haven't > selected it on my PC, its idle even though I may be typing=20 > into another app. What if the application does have focus, but no user input for a short = unit of time? I actually would like to question the usefulness of this information: = How useful is service-idleness to the watcher? What can a watcher do = with information like: this service has not been used by the presentity = for 10 mins, especially when it is a service like IM where it is idle = most of the time waiting for user input or network input. Service = idleness is really only useful if it tells the watcher that = communicating with a presentity using this service while it is idle *may = not* result in a response from the presentity. For IM, this criteria is = met only when it is combined with device idleness. Therefore it really could be that service idleness is service specific. = Examples: - An IM service is idle when the device it is running on is idle (has = not received any input for x mins) - A video service is idle if the camera cover has been closed or the = camera has been disabled for more than x mins - An audio service is idle if the speakers or microphone have been = disabled for more than x mins - A game service is idle if the player has placed the game in certain = state for x mins Or we can generalise by saying that service idleness is when a critical = component of the service has been disabled or unused for x minutes. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Oct 1 13:03:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24728; Fri, 1 Oct 2004 13:03:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQwl-0003Yf-G6; Fri, 01 Oct 2004 13:11:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPsW-0006Rd-26; Fri, 01 Oct 2004 12:03:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDNC2-0007is-U0 for simple@megatron.ietf.org; Fri, 01 Oct 2004 09:11:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26870 for ; Fri, 1 Oct 2004 09:11:23 -0400 (EDT) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDNKU-0006tg-32 for simple@ietf.org; Fri, 01 Oct 2004 09:20:11 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i91D3npw028883 for ; Fri, 1 Oct 2004 08:03:49 -0500 (EST) Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i91D3mpw028867 for ; Fri, 1 Oct 2004 08:03:48 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Pres Data Model Open Issue #5: what does idle mean? Date: Fri, 1 Oct 2004 09:11:20 -0400 Message-ID: <8CA1128D59AD27429985B397118CEDDF031B0C27@nj7460avexu1.global.avaya.com> Thread-Topic: [Simple] Pres Data Model Open Issue #5: what does idle mean? Thread-Index: AcSneiZtrS0sVgCmSgWmEkev7efbcAAPSb+w From: "Boyer, David G \(Dave\)" To: "Jonathan Rosenberg" , "Mike Hammer" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Jonathan - > service-idle: For a service which receives input while it is=20 > the "focus" of the user interaction (focus in the user=20 > interface sense), there has been no input. For example, if my=20 > IM app is running, but I haven't selected it on my PC, its=20 > idle even though I may be typing into another app. >=20 If the IM app is idle long enough it might report "unavailable." If the device (PC in this case) detects typing, even though it is in another app, isn't appropriate to treat the IM client as available? For example, if I leave different applications running on my PC when=20 I go home at night, apps capable of reporting their idle state will do so. When I return the next morning and start answering emails, shouldn't that be sufficient information to the Presence server for it to know that the IM application is also now available? Dave _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Oct 1 13:08:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25710; Fri, 1 Oct 2004 13:08:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDR1l-0003so-Iv; Fri, 01 Oct 2004 13:17:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQ3t-0003ai-D2; Fri, 01 Oct 2004 12:15:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDNnY-0007oX-Lz for simple@megatron.ietf.org; Fri, 01 Oct 2004 09:50:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00085 for ; Fri, 1 Oct 2004 09:50:11 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDNw0-0007g4-FY for simple@ietf.org; Fri, 01 Oct 2004 09:58:57 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i91Do8621408 for ; Fri, 1 Oct 2004 16:50:08 +0300 (EET DST) X-Scanned: Fri, 1 Oct 2004 16:50:02 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i91Do21B028460 for ; Fri, 1 Oct 2004 16:50:02 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 008ry6pf; Fri, 01 Oct 2004 16:50:00 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i91DnxY25377 for ; Fri, 1 Oct 2004 16:49:59 +0300 (EET DST) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 1 Oct 2004 16:49:58 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 1 Oct 2004 16:49:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Pres Data Model Open Issue #5: what does idle mean? Date: Fri, 1 Oct 2004 16:49:58 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C08B68C@esebe056.ntc.nokia.com> Thread-Topic: [Simple] Pres Data Model Open Issue #5: what does idle mean? Thread-Index: AcSnej+5RYns7NAEQAaE05742fb4WwAQyd4w To: X-OriginalArrivalTime: 01 Oct 2004 13:49:58.0842 (UTC) FILETIME=[8A8DC1A0:01C4A7BD] X-Spam-Score: 0.3 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Jonathan Rosenberg > Sent: 01.October.2004 08:24 > To: Mike Hammer > Cc: Simple WG > Subject: Re: [Simple] Pres Data Model Open Issue #5: what does idle > mean? >=20 >=20 >=20 > OK, I can live with that. My main beef is that it be well defined. I'd > offer up the following initial definitions: >=20 > device-idle: The device has received no data input on any of its user > input devices that require active input (including keyboards, mice, > trackballs, but excluding things like microphones and cameras where > there is always "input") Ok. >=20 > service-idle: For a service which receives input while it is=20 > the "focus" > of the user interaction (focus in the user interface sense), there has > been no input. For example, if my IM app is running, but I haven't > selected it on my PC, its idle even though I may be typing=20 > into another app. What if the application does have focus, but no user input for a short = unit of time? I actually would like to question the usefulness of this information: = How useful is service-idleness to the watcher? What can a watcher do = with information like: this service has not been used by the presentity = for 10 mins, especially when it is a service like IM where it is idle = most of the time waiting for user input or network input. Service = idleness is really only useful if it tells the watcher that = communicating with a presentity using this service while it is idle *may = not* result in a response from the presentity. For IM, this criteria is = met only when it is combined with device idleness. Therefore it really could be that service idleness is service specific. = Examples: - An IM service is idle when the device it is running on is idle (has = not received any input for x mins) - A video service is idle if the camera cover has been closed or the = camera has been disabled for more than x mins - An audio service is idle if the speakers or microphone have been = disabled for more than x mins - A game service is idle if the player has placed the game in certain = state for x mins Or we can generalise by saying that service idleness is when a critical = component of the service has been disabled or unused for x minutes. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Oct 1 13:10:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26155; Fri, 1 Oct 2004 13:10:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDR46-000410-4T; Fri, 01 Oct 2004 13:19:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQ9z-0007Ne-E3; Fri, 01 Oct 2004 12:21:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDOCb-00018c-Ls for simple@megatron.ietf.org; Fri, 01 Oct 2004 10:16:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03077 for ; Fri, 1 Oct 2004 10:16:04 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDOL2-00089Y-L6 for simple@ietf.org; Fri, 01 Oct 2004 10:24:51 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 01 Oct 2004 10:15:32 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i91EFQr5003795; Fri, 1 Oct 2004 10:15:26 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-208.cisco.com [64.100.229.208]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BCK06989; Fri, 1 Oct 2004 07:15:25 -0700 (PDT) Message-Id: <4.3.2.7.2.20041001100912.00b02288@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Oct 2004 10:15:25 -0400 To: Jonathan Rosenberg From: Mike Hammer Subject: Re: [Simple] Pres Data Model Open Issue #1: in-person communications In-Reply-To: <415CE30A.5050008@dynamicsoft.com> References: <4.3.2.7.2.20040929121646.00b30118@cia.cisco.com> <4.3.2.7.2.20040929110138.00b15708@cia.cisco.com> <4159D228.5040905@dynamicsoft.com> <4159D228.5040905@dynamicsoft.com> <4.3.2.7.2.20040929110138.00b15708@cia.cisco.com> <4.3.2.7.2.20040929121646.00b30118@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Simple WG , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Hmmm... I was never against the inclusion of the in-person service, just thought that once in visual contact that body language would take over. But, I can see that it could save a trip down the hall if one knows someone is in, but not willing to have interruptions, or where that might otherwise be ambiguous. I'm also picturing the teenager with the status set to: "talk to the hand". :) It might also help disambiguate the case where several devices report wildly different locations, but you really want to know where the person is, mod privacy controls. Mike At 12:54 AM 10/1/2004 -0400, Jonathan Rosenberg wrote: >inline. > >Mike Hammer wrote: > >>On the other hand, not all folks carry GPS devices, so the ability >>somewhere to convert a Lat/Long to a street address is useful. >>But, to clarify my early point, if the person location information is >>available via presence, then the need to define an in-person >>communications means is probably moot. > >I strongly disagree. > >In-person communications is a service as defined in our model. It has all >of the properties of a service. Its a modality. It has characteristics >(audio and video content, low latency), and most importantly, it has >status (I'm available for folks to come to my office now). Indeed, this >status is different from person status. For example, I as a person (using >the term person as defined in the model) can be "on the phone", but my >availability for in-person communications might still be open if I'm >willing to answer a knock at the door while on the phone. > >It also makes sense to me to be able to prioritize in-person >communications over other services, like telephony or IM. Indeed, I might >prioritize them differently for different watchers. > >None of this would be conveyable in the model if in-person is not >identified as a service; person doesn't convey availability for >communcations, priority, or other characteristics. > >Thanks, >Jonathan R. > > >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Chief Technology Officer Parsippany, NJ 07054-2711 >dynamicsoft >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 simple-bounces@ietf.org Fri Oct 1 13:17:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27212; Fri, 1 Oct 2004 13:17:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDRAv-0004N8-Kw; Fri, 01 Oct 2004 13:26:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQLd-0005jv-G0; Fri, 01 Oct 2004 12:33:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPFh-0004Kj-M8 for simple@megatron.ietf.org; Fri, 01 Oct 2004 11:23:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10038 for ; Fri, 1 Oct 2004 11:23:19 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDPOA-0000zs-Dx for simple@ietf.org; Fri, 01 Oct 2004 11:32:07 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 01 Oct 2004 11:40:37 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i91FMkED001594; Fri, 1 Oct 2004 11:22:46 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-208.cisco.com [64.100.229.208]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BCK12464; Fri, 1 Oct 2004 08:22:46 -0700 (PDT) Message-Id: <4.3.2.7.2.20041001104505.00b02d68@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Oct 2004 11:22:46 -0400 To: Jonathan Rosenberg From: Mike Hammer Subject: Re: [Simple] Pres Data Model Open Issue #5: what does idle mean? In-Reply-To: <415CE9FF.4030205@dynamicsoft.com> References: <4.3.2.7.2.20040929103449.00b0e058@cia.cisco.com> <4.3.2.7.2.20040929103449.00b0e058@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 At 01:24 AM 10/1/2004 -0400, Jonathan Rosenberg wrote: >device-idle: The device has received no data input on any of its user >input devices that require active input (including keyboards, mice, >trackballs, but excluding things like microphones and cameras where >there is always "input") This seems to assume that a human user is always at the other end. I was thinking that there might be devices (e.g. a large telescope, or say an outdoor web cam at a popular ski resort) that could be on-line (versus off-line for maintenance) and could be actively serving one potential star-gazer or skier, or perhaps idle and available (possibly for a small fee). There is no human user providing input, but I suppose one could redefine the controlling automaton to be the user and the activity of data exchange to be the input. Note that while the camera is always on and capturing input, it may or may not be streaming that input to somewhere else, so "active input" might have meaning for cameras or microphones. Note also that being idle in the human user case is giving a clue that perhaps, the human is not really there (caveat the cellphone example); but for an automaton, that is not the case, instead idle might be a clue that the fee was set too high. So, I am still inclined to be wary about "one meaning fits all device types". So, I guess the definition will work. It just moves the definition problem to defining what is the user, and what is active input for cases where user!=human. Should some "need to define" caution be added for those non-human based cases? Mike _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Oct 1 13:30:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28651; Fri, 1 Oct 2004 13:30:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDRNO-0004uv-Df; Fri, 01 Oct 2004 13:39:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQeM-00088c-SI; Fri, 01 Oct 2004 12:52:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPlm-0003mM-He for simple@megatron.ietf.org; Fri, 01 Oct 2004 11:56:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15893 for ; Fri, 1 Oct 2004 11:56:28 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDPuF-0001mp-PQ for simple@ietf.org; Fri, 01 Oct 2004 12:05:16 -0400 Received: from panther.cs.columbia.edu (IDENT:AwBGEZQrsNe/3ckWULmCWdW5m9Iv+CFe@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i91FuFx6004821 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 1 Oct 2004 11:56:15 -0400 (EDT) Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i91FuDeO022681; Fri, 1 Oct 2004 11:56:14 -0400 Message-ID: <415D7E18.4010700@cs.columbia.edu> Date: Fri, 01 Oct 2004 11:56:08 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Pres Data Model Open Issue #1: in-person communications References: <4159D228.5040905@dynamicsoft.com> <4159FB36.9090502@cs.columbia.edu> <415CE1ED.6070900@dynamicsoft.com> In-Reply-To: <415CE1ED.6070900@dynamicsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.10.1.0 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.8 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit > I don't see why my postal information isn't subject to open or closed, > like anything else. Admittedly it won't change often. HOwever, if I go > on vacation for two weeks, might I not want to change it to closed? This > is the example Mike gave. I don't see how email or SMS or MMS, or any > form of store and forward messaging, would be different than postal in > this regard. I do think we have agreed that sms, mms and email are > useful services to list in the presence docuemnt. > > I agree that the cipid vcard can be used to convey my postal address. > Perhaps then the postal "url" is nothing more than the reference to this > vcard, perhaps in the same presence document even. However, that doesnt > mean that postal is not a communications service as defined in the model. But given its description by a vCard, it probably doesn't need a service URI. The problem is similar for other "generic" means of communications. Imagine some future SOAP-based service. It will have HTTP as a URI, which will not tell you much. > Well, except that I dont think its a joke at all. My concern is not that we don't need it, but that the reaction from others, outside the SIMPLE/IM community, will be less accommodating. Maybe I'm being too pessimistic. > > I think it would be quite valuable to have this capability in PIDF. Its > a real, valid, and absolutely useful form of a communications service to > list in a presence document. Having a service modality identifier (postal, personal, electronic) might be easier. Postal and personal would not need URLs. > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Oct 1 13:43:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29506; Fri, 1 Oct 2004 13:43:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDRZv-0005EQ-LP; Fri, 01 Oct 2004 13:52:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQpX-00046N-4t; Fri, 01 Oct 2004 13:04:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDPxp-00089D-Eh for simple@megatron.ietf.org; Fri, 01 Oct 2004 12:08:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17535 for ; Fri, 1 Oct 2004 12:08:54 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQ6I-00024f-RF for simple@ietf.org; Fri, 01 Oct 2004 12:17:43 -0400 Received: from panther.cs.columbia.edu (IDENT:zkEdopz5WkRsUOhWJcpJbJAkK0jLYFgZ@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i91G8kx6007487 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 1 Oct 2004 12:08:47 -0400 (EDT) Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i91G8keO023980; Fri, 1 Oct 2004 12:08:46 -0400 Message-ID: <415D8109.6060100@cs.columbia.edu> Date: Fri, 01 Oct 2004 12:08:41 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Pres Data Model Open Issue #5: what does idle mean? References: <4.3.2.7.2.20040929103449.00b0e058@cia.cisco.com> <415CE9FF.4030205@dynamicsoft.com> In-Reply-To: <415CE9FF.4030205@dynamicsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.10.1.0 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Simple WG , Mike Hammer X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Would a simple definition "no human interaction with the device or service for x minutes" not be sufficient? For a service, 'human interaction' includes a person answering a call, placing a call or sending a message. Since all communication services are either session- or message-based, this should pretty much capture the possibilities. For a device, it includes any user input, via keyboard, mouse, stylus, voice or other HMI device. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Oct 1 13:44:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29870; Fri, 1 Oct 2004 13:44:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDRb6-0005L0-Lo; Fri, 01 Oct 2004 13:53:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDR1H-0002Tk-QF; Fri, 01 Oct 2004 13:16:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDQGh-0002Fz-Ad for simple@megatron.ietf.org; Fri, 01 Oct 2004 12:28:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21053 for ; Fri, 1 Oct 2004 12:28:24 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDQP1-0002T0-FA for simple@ietf.org; Fri, 01 Oct 2004 12:37:13 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 01 Oct 2004 09:34:29 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i91GRZEE023875; Fri, 1 Oct 2004 09:27:36 -0700 (PDT) Received: from cisco.com (dhcp-64-102-209-23.cisco.com [64.102.209.23]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALZ20649; Fri, 1 Oct 2004 12:27:36 -0400 (EDT) Message-ID: <415D8577.8030907@cisco.com> Date: Fri, 01 Oct 2004 12:27:35 -0400 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 Subject: Re: [Simple] Pres Data Model Open Issue #3, UUID URN or something else References: <4159D54F.5060700@dynamicsoft.com> <4159E364.8030204@cisco.com> <415CE4B2.80008@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > inline. > > Paul Kyzivat wrote: > > >>> I would propose approach (3). In particular, I think the data model >>> should revert to being agnostic on the URN scheme, reference the >>> UUID URN as one possibility, document its problems. We should >>> develop a separate specification that defines guidelines for >>> choosing the URN for various devices in order to get the >>> correlation properties we want. I also think we should take a stab >>> at defining a few URN schemes that would be useful - MAC and ESN in >>> particular. >> >> >> >> I think it does make sense to leave the particular choice out of this >> document. >> >> I do think the problem with UUID can be dealt with in a couple of >> ways: >> >> - for some kinds of "devices", like softphones and IM clients, it is >> probably fine as-is. They can typically have multiple instances per >> device, so they must construct and instance id and save it >> persistently as part of the instance configuration. > > > I think softphones are PC-based devices are a candidate where we want to > be able to correlate service information with device information learned > from network elements like an 802.11 AP. Thus, I do think this problem > applies to things besides phones. Yes, I guess you are right. I was still thinking of "instance id", rather than specifically "device id". >> - for a dedicated device, like a phone, that can't or doesn't want to >> use the above technique, a cannonical mac-based uuid can be >> constructed by using a fixed time (e.g. zero) along with the mac. > > I thought about that, but wasn't able to convince myself that it was > allowed in the UUID URN spec. Do you find words that allow you to set > the time to zero? Well, it probably does require some mental gymnastics to justify it. It is a matter of saying you are using the UUID generated with this mac at "the beginning of time". Would it work? yes. Is it ideal? Probably not. Is it a valid usage? Debatable. Could we recommend it? I don't know. Could we say "you might be able to find a creative way to use this form of uuid"? Why not? Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Oct 1 14:10:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02794; Fri, 1 Oct 2004 14:10:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDS0I-0006Iz-OK; Fri, 01 Oct 2004 14:19:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDRT5-0003Po-0X; Fri, 01 Oct 2004 13:45:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDR3E-0003iI-At for simple@megatron.ietf.org; Fri, 01 Oct 2004 13:18:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27348 for ; Fri, 1 Oct 2004 13:18:33 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDRBh-0004Q6-R3 for simple@ietf.org; Fri, 01 Oct 2004 13:27:23 -0400 Received: from panther.cs.columbia.edu (IDENT:80lqih5QDIMuuPYi0yJDjNZkcG/BnMgp@panther.cs.columbia.edu [128.59.16.122]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i91HIQx6027707 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 1 Oct 2004 13:18:26 -0400 (EDT) Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) by panther.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id i91HIQeO032027; Fri, 1 Oct 2004 13:18:26 -0400 Message-ID: <415D915D.2010908@cs.columbia.edu> Date: Fri, 01 Oct 2004 13:18:21 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] Pres Data Model Open Issue #5: what does idle mean? References: <5816828233DEFA41807A6CFDFDF2343C08B68C@esebe056.ntc.nokia.com> In-Reply-To: <5816828233DEFA41807A6CFDFDF2343C08B68C@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.10.1.0 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Another thought: In many cases, it is probably more informative to say "has been active as recently as ten minutes ago", i.e., the inverse of idle. Even knowing that user Bob sent email or placed a call, both services, a short while ago is quite useful - Bob is probably around and not asleep. (Absence of idle is not as informative as the recipient doesn't know the idle threshold and idle may not be reported at all.) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Oct 1 18:43:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04341; Fri, 1 Oct 2004 18:43:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDWGU-0004ih-9E; Fri, 01 Oct 2004 18:52:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDVq2-0003yB-KY; Fri, 01 Oct 2004 18:25:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDUvK-0002JQ-U2 for simple@megatron.ietf.org; Fri, 01 Oct 2004 17:26:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24248 for ; Fri, 1 Oct 2004 17:26:40 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDV3q-0002j4-VN for simple@ietf.org; Fri, 01 Oct 2004 17:35:32 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i91LQauD039931 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 1 Oct 2004 16:26:37 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <414FFFCF.8020007@nokia.com> References: <414FFFCF.8020007@nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <92748F4C-13F0-11D9-B01C-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Date: Fri, 1 Oct 2004 16:26:35 -0500 To: Miguel Garcia X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, rohan@cisco.com, SIMPLE mailing list Subject: [Simple] Re: MSRP URLs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: 7bit On Sep 21, 2004, at 5:17 AM, Miguel Garcia wrote: > Hi: > > A few comments about section 5 of the MSRP draft: > > http://www.ietf.org/internet-drafts/draft-ietf-simple-message- > sessions-08.txt > > 1) The draft should describe the type of resources that are identified > by an MSRP URL. So I would suggest to add an introductory paragraph at > the beginning of section 5 that says something on the following lines: > > The MSRP and MSRPS URL schemes are used to designate a session of > instant messages at a particular host computer. > > Question: is this definition also applicable to relays? > I think if we say at a particular MSRP device, then it applies to both relays and endpoints. Or more precisely, it describes either an MSRP service, or an MSRP session hosted at a particular service. > 2) RFC 2396 is under revision, nowadays > draft-fielding-uri-rfc2396bis-06.txt. I am not sure if you still want > to refer to RFC 2396 or the revision of it. I guess this depends of > which draft makes it first to the IESG. > > Among other things, in case you want to refer to rfc2396bis, this > draft has removed the definition of "hostport". Now it is just "host > [: port]" Does anyone know the status of 2396bis? I want to avoid all the normative references to works in progress that we can. There are too many hoops to jump as it is. > > 3) The current definition of an MSRP URL includes a "resource" part, > when actually it is a "path" or "session-id", because a "resource" is > the the whole MSRP URL, including the URI scheme and the hostname. > > So I would suggest to replace the current definition: > > MSRP_urls = msrp-scheme "://" [userinfo "@"] hostport ["/" > resource] ";" transport > resource = 1*unreserved > > with this other one: > > MSRP_urls = msrp-scheme "://" [userinfo "@"] hostport ["/" > path] ";" transport > resource = 1*unreserved I am okay with "sessionid" or "session". I don't like path, as I think it implies things we don't mean. On the other hand, does resource conflict with something in the abnf? It's just a variable name, and it does not seem useful to get too bogged down in the semantic meaning of abnf identifier choices. > > 4) According to rfc2396bis, "unrerved" is defined as: > > unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" > > On purpose "unreserved" does not include "sub-delims", which is > defined as: > > sub-delims = "!" / "$" / "&" / "'" / "(" / ")" > / "*" / "+" / "," / ";" / "=" > > I guess it is OK for MSRP that the path is formed of unreserved > characters, not including sub-delims. But I would like to point this > out in case someone feels the path needs to include sub-delims. If I recall correctly, we consciously chose to use unreserved on all of this to avoid escaping. Does anyone see a requirement to use other characters here than cannot be achieved with unreserved characters? > > 5) I find a contradiction that we, on one hand, allow to have a > "userinfo" part in the MSRP URL including a reference to RFC 2396, and > on the other hand we restrict the "userinfo" definition in RFC 23964 > to unreserved characters. > > RFC 2396 (and 2396bis) allow to have escaped characters in the > userinfo. However, MSRP does not, but still refers to 2396 for the > definition of userinfo. > > So, if the "userinfo" defined in the MSRP URL is different from (or a > subset of) the "userinfo" defined in RFC 2396, then I would suggest to > change the name (perhaps "unescaped-userinfo"), and avoid the > reference to RFC 2396. > Again, I don't think we want to bring in unescaped characters unless we find a problem with not allowing them. But I am okay with changing the construction name. > 6) Section 5.1 reads on the second bullet point: > > 2. If the hostpart contains an eplicit IP address, and/or port, > these are compared numerically. Otherwise, hostpart is compared > as a case insensitive character string. > > I was wondering in the how to treat zeros in either IPv4 or IPv6 (IPv6 > uses this quite oftenly). The missleading word is "numerically", since > I am not sure if the "::" should be normalized by adding trailing and > leading zeros or not. > > Is it the intention that the following two URLs are equivalent and > MSRP endpoints should detect it? > > msrp://[1080:0:0:0:8:800:200C:417A]/aodisfa;tcp > msrp://[1080::8:800:200C:417A]/aodisfa;tcp > > A clarification should be written. > I don't know enough about IPv6 to address that. Are the two addresses equivalent? We had a suggestion to try to avoid treating URLS differently if they had the same address with slight encoding differences. But if this becomes a complex issue, I propose we just go back to a text comparison. > > Regards, > > Miguel > > > -- > Miguel A. Garcia tel:+358-50-4804586 > Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Oct 1 18:56:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05710; Fri, 1 Oct 2004 18:56:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDWSi-0006QG-Ec; Fri, 01 Oct 2004 19:05:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDVwf-0003Rw-N1; Fri, 01 Oct 2004 18:32:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDVi0-0006r3-JE for simple@megatron.ietf.org; Fri, 01 Oct 2004 18:17:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00893 for ; Fri, 1 Oct 2004 18:16:58 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDVqX-0000pA-Vu for simple@ietf.org; Fri, 01 Oct 2004 18:25:50 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i91MGrxj043579 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 1 Oct 2004 17:16:53 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <5CF97971-13F7-11D9-B01C-000D93B0AE1A@nostrum.com> References: <41544962.2080509@cisco.com> <5CF97971-13F7-11D9-B01C-000D93B0AE1A@nostrum.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <98E41386-13F7-11D9-B01C-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - Byte Ranges in REPORTs Date: Fri, 1 Oct 2004 17:16:52 -0500 To: Ben Campbell X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Oops, I just realized I missed one of Paul's comments. Paul suggests there is no value saying what part of a message fails, only that the whole message fails. I disagree. If a sender learns that a particular byte-range failed, it may be able to send a new chunk containing that byte range. On Oct 1, 2004, at 5:15 PM, Ben Campbell wrote: > Sorry for the late response. Somehow my mail hid this entire thread > from me until a couple of days ago. Else I just forgot how to use > computers. Comments inline. > > On Sep 24, 2004, at 11:20 AM, Paul Kyzivat wrote: > >> I am really confused about how byte ranges are supposed to work in >> reports, and I suspect we are permitting a bunch of nonsense. >> >> Fundamentally, a message can only be considered a success if all its >> bytes are received successfully. If it is to be positively >> acknowledged >> with success reports, then there must be success reports covering >> every byte. Is there any point in sending a success report for less >> than >> the entire message? It doesn't help the receiver, and actually makes >> more work because it then requires keeping track of what bytes have >> been >> confirmed. And it doesn't ease the job of the sender, who could easily >> just wait until all has been received before sending the success >> report. >> >> The flip side is that a message fails if a single byte fails. At that >> point it does no good to know that other parts succeeded or failed. So >> while it makes sense to send a failure report based on problems with a >> single chunk, there is little value in saying which byte range failed. >> >> Bottom line: unless I have missed something, there is no reason for >> Byte-Range in REPORT or responses. A success report should only be >> sent >> after all the chunks of a message have been received. A failure >> report, >> or an error status, can be sent at the time the failure of a single >> chunk is known, but need not identify the byte range. (In that case, >> maybe the Byte-Range could be optional for debugging purposes only.) >> > > I agree you need reports that cover the entirety of the message for a > success. I further agree that endpoints should not send success > reports until they have the entire message. I wonder, however, if > there are situations where this is not possible. For example, if a > message crosses a gateway, and somehow different gateways send > different chunks. But, since said gateway will need to reconstruct the > entire message to pass on, this probably cannot happen. > > So I am willing to assert that you only send success reports on the > entire message. Do we think there is any need for the sender to be > able to accumulate success reports on subsets of a message? > > Just to make sure we are clear, though, I think _failure_ reports are > sent on a per-chunk basis. If an endpoint decides to send a failure > report because it is missing a data range, it should report on that > specific data range. > >> >> >> >> _______________________________________________ >> 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 simple-bounces@ietf.org Fri Oct 1 18:56:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05768; Fri, 1 Oct 2004 18:56:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDWTA-0006RJ-JX; Fri, 01 Oct 2004 19:05:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDVwg-0003T2-FL; Fri, 01 Oct 2004 18:32:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDViL-0007FV-1X for simple@megatron.ietf.org; Fri, 01 Oct 2004 18:17:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00934 for ; Fri, 1 Oct 2004 18:17:18 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDVqs-0000pP-LI for simple@ietf.org; Fri, 01 Oct 2004 18:26:11 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i91MFCVI043456 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 1 Oct 2004 17:15:13 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <41544962.2080509@cisco.com> References: <41544962.2080509@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5CF97971-13F7-11D9-B01C-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - Byte Ranges in REPORTs Date: Fri, 1 Oct 2004 17:15:12 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Sorry for the late response. Somehow my mail hid this entire thread from me until a couple of days ago. Else I just forgot how to use computers. Comments inline. On Sep 24, 2004, at 11:20 AM, Paul Kyzivat wrote: > I am really confused about how byte ranges are supposed to work in > reports, and I suspect we are permitting a bunch of nonsense. > > Fundamentally, a message can only be considered a success if all its > bytes are received successfully. If it is to be positively acknowledged > with success reports, then there must be success reports covering > every byte. Is there any point in sending a success report for less > than > the entire message? It doesn't help the receiver, and actually makes > more work because it then requires keeping track of what bytes have > been > confirmed. And it doesn't ease the job of the sender, who could easily > just wait until all has been received before sending the success > report. > > The flip side is that a message fails if a single byte fails. At that > point it does no good to know that other parts succeeded or failed. So > while it makes sense to send a failure report based on problems with a > single chunk, there is little value in saying which byte range failed. > > Bottom line: unless I have missed something, there is no reason for > Byte-Range in REPORT or responses. A success report should only be sent > after all the chunks of a message have been received. A failure report, > or an error status, can be sent at the time the failure of a single > chunk is known, but need not identify the byte range. (In that case, > maybe the Byte-Range could be optional for debugging purposes only.) > I agree you need reports that cover the entirety of the message for a success. I further agree that endpoints should not send success reports until they have the entire message. I wonder, however, if there are situations where this is not possible. For example, if a message crosses a gateway, and somehow different gateways send different chunks. But, since said gateway will need to reconstruct the entire message to pass on, this probably cannot happen. So I am willing to assert that you only send success reports on the entire message. Do we think there is any need for the sender to be able to accumulate success reports on subsets of a message? Just to make sure we are clear, though, I think _failure_ reports are sent on a per-chunk basis. If an endpoint decides to send a failure report because it is missing a data range, it should report on that specific data range. > > > > _______________________________________________ > 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 simple-bounces@ietf.org Fri Oct 1 18:57:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05856; Fri, 1 Oct 2004 18:57:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDWTQ-0006SK-KM; Fri, 01 Oct 2004 19:06:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDVwh-0003U3-Ml; Fri, 01 Oct 2004 18:32:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDViy-0007vv-9R for simple@megatron.ietf.org; Fri, 01 Oct 2004 18:18:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00987 for ; Fri, 1 Oct 2004 18:17:58 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDVrV-0000pr-TG for simple@ietf.org; Fri, 01 Oct 2004 18:26:50 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i91MHvAH043640 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 1 Oct 2004 17:17:57 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <5816828233DEFA41807A6CFDFDF2343C08B64E@esebe056.ntc.nokia.com> References: <5816828233DEFA41807A6CFDFDF2343C08B64E@esebe056.ntc.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - Byte Ranges in REPORTs Date: Fri, 1 Oct 2004 17:17:56 -0500 To: hisham.khartabil@nokia.com X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: pkyzivat@cisco.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit On Sep 27, 2004, at 5:57 AM, hisham.khartabil@nokia.com wrote: > I agree. The situation is further complicated when a relay decides to > re-chunk. The relay then has to consume the REPORTs and generate it > own to pass upstream. > I don't see why. There is no requirement that the byte-range in a REPORT match the precise byte-range in any chunk that you sent. > /Hisham > >> -----Original Message----- >> From: simple-bounces@ietf.org >> [mailto:simple-bounces@ietf.org]On Behalf >> Of ext Paul Kyzivat >> Sent: 24.September.2004 19:21 >> To: simple@ietf.org >> Subject: [Simple] Review of >> draft-ietf-simple-message-sessions-08 - Byte >> Ranges in REPORTs >> >> >> I am really confused about how byte ranges are supposed to work in >> reports, and I suspect we are permitting a bunch of nonsense. >> >> Fundamentally, a message can only be considered a success if all its >> bytes are received successfully. If it is to be positively >> acknowledged >> with success reports, then there must be success reports covering >> every byte. Is there any point in sending a success report >> for less than >> the entire message? It doesn't help the receiver, and actually makes >> more work because it then requires keeping track of what >> bytes have been >> confirmed. And it doesn't ease the job of the sender, who could easily >> just wait until all has been received before sending the >> success report. >> >> The flip side is that a message fails if a single byte fails. At that >> point it does no good to know that other parts succeeded or failed. So >> while it makes sense to send a failure report based on problems with a >> single chunk, there is little value in saying which byte range failed. >> >> Bottom line: unless I have missed something, there is no reason for >> Byte-Range in REPORT or responses. A success report should >> only be sent >> after all the chunks of a message have been received. A >> failure report, >> or an error status, can be sent at the time the failure of a single >> chunk is known, but need not identify the byte range. (In that case, >> maybe the Byte-Range could be optional for debugging purposes only.) >> >> >> >> >> _______________________________________________ >> 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 simple-bounces@ietf.org Fri Oct 1 18:57:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05980; Fri, 1 Oct 2004 18:57:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDWUE-0006pz-EU; Fri, 01 Oct 2004 19:06:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDVxD-0003wS-7S; Fri, 01 Oct 2004 18:32:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDVnj-0006gL-Md for simple@megatron.ietf.org; Fri, 01 Oct 2004 18:22:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01438 for ; Fri, 1 Oct 2004 18:22:53 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDVwG-0001YC-Lu for simple@ietf.org; Fri, 01 Oct 2004 18:31:45 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i91MMpx8043992 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 1 Oct 2004 17:22:52 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <41544924.30008@cisco.com> References: <41544924.30008@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6DD77295-13F8-11D9-B01C-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - Chunking Date: Fri, 1 Oct 2004 17:22:49 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Cc: "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit On Sep 24, 2004, at 11:19 AM, Paul Kyzivat wrote: > Out approach to chunking has evolved thru the versions, and the > document > doesn't seem wholely clear and consistent about what we have arrived > at. > In fact, I am not entirely certain I know fully what we have decided, > and I can't figure it out for certain from the document. I would > propose > specific wording changes, but first I want to get clarification about > how we think it should now work. > > Based on scattered information in the doc, and reading between the > lines, and factoring in stuff from conversations along the way, I > *think* the following is intended: > > - only SEND messages are chunkable Agreed. > > - there are two kinds of chunks: interrruptible and uninterrupible. > Agreed. > - a chunk is uninterruptible if it has a Byte-Range header with a > numeric range-end. > Agreed. > - other chunks are interruptible. (No Byte-Range, or a Byte-Range > with a range-end of "*".) > Agreed. > - uninterruptible chunks MUST NOT have a range-end greater than 2048. > Agreed--which implies that range-end can never be >2048. > - chunks other than the last SHOULD (or MUST?) have a body ('data' > in the syntax) of length exactly 2048. If SHOULD, what is a > valid reason to violate? > Disagree. I could have sent considerably more than 2k of an interruptible chunk prior to actually interrupting it. > - responses never have bodies at all. Requests other than SEND > may have a body but are unchunkable. The presence of a Byte-Range > in a request other than SEND says nothing about the body of that > request. (In REPORT it refers to the SEND being reported on. > See separate thread on Byte-Range.) This at best seems irregular > and weird. I would further be willing to say that byte-range MUST NOT exist in anything but SEND and REPORT. And if the overloading in report really bothers people, I am willing to change the name of the header in the context of REPORT. > > Section 6.3.1 says: "it is possible the body is shorter than the > range-end field indicates. This can occur if the sender interrupted a > SEND request unexpectedly." Based on what I have interpretted above, > this is no longer possible. (To be interrupted it must have had a > range-end of "*".) This is a leftover from before we defined the rules for putting "*" in byte-range. We could remove it, although there might be some benefit in doing this for resiliency sake. Perhaps dropping it to a MAY? Since Orit made the same complaint, I guess I am willing to cut it completely. > > > > _______________________________________________ > 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 simple-bounces@ietf.org Fri Oct 1 19:00:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06456; Fri, 1 Oct 2004 19:00:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDWWG-0006xL-9h; Fri, 01 Oct 2004 19:08:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDWBQ-0001Gf-Tm; Fri, 01 Oct 2004 18:47:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDVs4-0007xn-JE for simple@megatron.ietf.org; Fri, 01 Oct 2004 18:27:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02765 for ; Fri, 1 Oct 2004 18:27:22 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDW0b-0002V3-UB for simple@ietf.org; Fri, 01 Oct 2004 18:36:14 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i91MRLm5044437 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 1 Oct 2004 17:27:21 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <41583485.1010209@cisco.com> References: <5816828233DEFA41807A6CFDFDF2343C08B656@esebe056.ntc.nokia.com> <41583485.1010209@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0F5A1B86-13F9-11D9-B01C-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - Chunking Date: Fri, 1 Oct 2004 17:27:20 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit On Sep 27, 2004, at 10:40 AM, Paul Kyzivat wrote: [...] >>> It is abnormal in the sense that it can only arise if there is a >>> violation of the specification. Normally we don't specify corrective >>> action in those cases. >> No, I meant device or user behaviour that causes the sending to be >> immediately aborted. Nothing to do with protocol violation. (eg: >> abnorla termination of the application). > > As best I can tell, we are saying that you must decide, when beginning > to send, whether to use an interruptible chunk, or an uninterruptible > chunk. If you use an uninterruptible chunk you specify the range-end > as a number and include that many bytes of body. If you choose an > interruptible chunk, you use "*" for range-end and then you put as > much body as you like. > > An application that chooses to use an uninterruptible chunk, and then > fails to include the full number of bytes for it has violated the > protocol. > > Effectively, an application should only use an uninterruptible chunk > if it already has all the bytes in hand and ready to send. > I think perhaps Hisham refers to error conditions like having the user close an app in mid send. In this case, either the device will cleanly complete the message, or simply stop sending. In that case, there will never be a closing. This is not the same as a closing with the incorrect payload length. > 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 simple-bounces@ietf.org Fri Oct 1 19:00:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06507; Fri, 1 Oct 2004 19:00:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDWWf-0007Jx-Lx; Fri, 01 Oct 2004 19:09:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDWBb-0001HC-PD; Fri, 01 Oct 2004 18:47:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDVsj-0000Bq-9K for simple@megatron.ietf.org; Fri, 01 Oct 2004 18:28:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03078 for ; Fri, 1 Oct 2004 18:28:03 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDW1H-0002jw-5y for simple@ietf.org; Fri, 01 Oct 2004 18:36:55 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i91MRLm6044437 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 1 Oct 2004 17:28:03 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <41581FAC.3070305@cisco.com> References: <5816828233DEFA41807A6CFDFDF2343C08B64F@esebe056.ntc.nokia.com> <41581FAC.3070305@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <28BF45F0-13F9-11D9-B01C-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - max-size Date: Fri, 1 Oct 2004 17:28:03 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit On Sep 27, 2004, at 9:11 AM, Paul Kyzivat wrote: > > > hisham.khartabil@nokia.com wrote: >> I believe it applies to a message (spread across 1 to n SENDS >> requests, i.e. chunks). > > I am inclined to agree. That means that recipients should be prepared > to receive up to 2k bodies with any other request that is permitted to > contain a body. (In this spec that is only REPORT.) > > I think we just need to make this clear. It wasn't entirely clear to > me from reading the existing text. I will attempt to clarify in the next revision. > > Paul > >> Hisham >>> -----Original Message----- >>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]On >>> Behalf >>> Of ext Paul Kyzivat >>> Sent: 24.September.2004 19:21 >>> To: simple@ietf.org >>> Subject: [Simple] Review of draft-ietf-simple-message-sessions-08 - >>> max-size >>> >>> >>> Section 7.1 says: "An endpoint MAY indicate the maximim size message >>> they wish to receive using the max-size a-line attribute". >>> >>> Does this apply only to a *message* - namely the content of a SEND >>> request? Or does this apply to any and all requests (including future >>> extensions) that have content? >>> >>> >>> >>> >>> _______________________________________________ >>> 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 simple-bounces@ietf.org Fri Oct 1 19:02:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06739; Fri, 1 Oct 2004 19:02:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDWYL-0007Nv-Tx; Fri, 01 Oct 2004 19:11:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDWNA-0000up-AH; Fri, 01 Oct 2004 18:59:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDW25-0006Xt-Iy for simple@megatron.ietf.org; Fri, 01 Oct 2004 18:37:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04080 for ; Fri, 1 Oct 2004 18:37:43 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDWAc-0003yl-QZ for simple@ietf.org; Fri, 01 Oct 2004 18:46:35 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i91Mbgb0045184 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 1 Oct 2004 17:37:42 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <4154491E.5050806@cisco.com> References: <4154491E.5050806@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8148E467-13FA-11D9-B01C-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - nits Date: Fri, 1 Oct 2004 17:37:41 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit On Sep 24, 2004, at 11:19 AM, Paul Kyzivat wrote: > I just did a fairly careful review of > draft-ietf-simple-message-sessions-08. I came up with a bunch of > comments. > > I will include the nits here, but in the interest of discussion I will > break the rest up into a number of separate threads. > > Paul > > Section 3, near the end: "This document specifies MSRP behavior only > peer-to-peer session...". Is awkward wording. Suggest inserting "for a" > in front of "peer-to-peer". Typo. Will fix. > > Section 4.3, last paragraph: "... but some other systems choose to use > a > value of "partial" to reduce the load on the servers caused by 200 OK > responses, but still allow error responses to be sent in many cases." > This will make sense later, but it doesn't make sense at this point in > the document because the linkage between the report and the 200 hasn't > been made. Suggest something like: > > "... but some other systems choose to use a value of "partial" to > reduce > the load on the servers. As will be seen in section 6.2, this will omit > 200 OK responses and the load they cause, but still allow error > responses to be sent in many cases." > OK. > Section 4.4, 4th paragraph from end, there is a sentence fragment that > should be combined with the next sentence: > "If the receiving endpoint receives more than one message with the same > Message-ID. It SHOULD assume that the messages are duplicates." > Should be: > "If the receiving endpoint receives more than one message with the same > Message-ID it SHOULD assume that the messages are duplicates." > OK. > The word "insure" is used twice in this document, and in both cases is > should be "ensure". > Oops. I usually gripe at _other_ people about that one... > Section 6.1.2 says: "An MSRP endpoint MUST be able to generate success > REPORT requests." But nowhere do I find a comparable statement about > failure reports. I think the endpoint MUST be able to do both. > That was not the intent. Endpoints would use transaction responses to indicate an error. I thought we had discussed that only relays would normally send failure reports. > Section 6.1.3, 1st paragraph: there is an instance of "respons" that > should be "response". ok. > > Section 6.3.1: s/If chunks data/If chunk data/ > ok. > Section 7.1 says to use "*" to indicate willingness to accept any > content type. This has always seemed gratuitous to me, since the mime > syntax for types already allows "*/*" to mean that. I think it would > minimize future issues if we just accepted that instead of specifying > "*" as a special case. This would require a small change to the syntax > of 'type' and 'subtype'. > I agree, and will change if no one objects. > Section 7.1 uses both "container types" and "compound types" to mean > the > same thing. Can we just pick one and stick with it? (I don't care which > one.) OK. (Except for every seventh reference, which I will call "complicated types". ;-) ) > > Section 7.1.5 says: "Instead, MSRP now specifies a default connection > direction." Its not a default, since you can't change it. I think what > is meant is: "MSRP now associates connection direction with the > direction the offer travels." it is default, in the sense that we have language (or intended to have language; Orit indicated it may not be there) to the effect that if endpoints have some other agreed upon way to negotiate direction, they can override this. The point was to allow people to use something like comedia in the future. > > Section 10.5: Shows using a REGISTER to query for the contacts. There > really isn't anything wrong here, but it may cause some readers to > conclude that using REGISTER this way is something that should normally > be done. Might be worth a disclaimer that this is only shown for > purposes of clarifying the example. Agreed. I am tempted to drop the register altogether and just say that the "proxy learns from the location service..." > > > > > _______________________________________________ > 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 simple-bounces@ietf.org Fri Oct 1 19:03:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07219; Fri, 1 Oct 2004 19:03:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDWZr-0007i1-PS; Fri, 01 Oct 2004 19:12:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDWNB-0000vE-Fa; Fri, 01 Oct 2004 18:59:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDW4N-00079U-Fl for simple@megatron.ietf.org; Fri, 01 Oct 2004 18:40:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04185 for ; Fri, 1 Oct 2004 18:40:04 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDWCt-0004Kt-VN for simple@ietf.org; Fri, 01 Oct 2004 18:48:57 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i91Me3V6045443 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 1 Oct 2004 17:40:04 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <41544958.1040009@cisco.com> References: <41544958.1040009@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - Overlapping Chunks Date: Fri, 1 Oct 2004 17:40:02 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit On Sep 24, 2004, at 11:20 AM, Paul Kyzivat wrote: > Section 6.3.1 discusses how to handle the receipt of overlapping > chunks, > specifying that the last received copy of any particular byte wins. I > don't think this is good. > > If the overlapping chunks contain consistent data then it doesn't > matter > which takes precedence. If they contain conflicting data then > reordering > of chunks can affect the result unpredictably. This rule also prevents > the recipient from rendering a byte when it and all preceding bytes > have > been received. > > I think it should be permissible for the recipient to check for > inconsistency in the overlapping case, and report an error if so. We > may > want to require this checking. (Since it typically won't happen it > shouldn't have a performance impact.) > I'm not sure on this one. As far as typically not happening, I can imagine situations where a chunk gets an error report, but still got delivered. The sender might send a new chunk with that range. Perhaps it would be better to say that, if a sender does this, it MUST NOT change the data in the range. > > > _______________________________________________ > 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 simple-bounces@ietf.org Fri Oct 1 19:09:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07882; Fri, 1 Oct 2004 19:09:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDWf3-0008CV-Nv; Fri, 01 Oct 2004 19:18:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDWNY-0001gd-Kj; Fri, 01 Oct 2004 18:59:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDW6A-0007Xy-60 for simple@megatron.ietf.org; Fri, 01 Oct 2004 18:41:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04307 for ; Fri, 1 Oct 2004 18:41:55 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDWEh-0004NT-N3 for simple@ietf.org; Fri, 01 Oct 2004 18:50:48 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i91MftNB045612 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 1 Oct 2004 17:41:55 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <4154496A.40502@cisco.com> References: <4154496A.40502@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <182C1A9A-13FB-11D9-B01C-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - Port in m-line Date: Fri, 1 Oct 2004 17:41:54 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit I know I fixed that one! I am starting to suspect we had a version control snafu with this revision. I will fix it again, and beat it with a blunt object until it agrees to stay fixed. On Sep 24, 2004, at 11:20 AM, Paul Kyzivat wrote: > Section 7.1 says: "An offered or accepted MSRP media-line MUST have the > following value exactly ... m=message 9 msrp *" > > We've been thru this before. It can't always be 9 because there could > be > two media sections and they can't both use 9. I think we say it must > be: > > m=message msrp * > > and then say SHOULD be 9, but MAY be something else if 9 has > already been used. > > > > > _______________________________________________ > 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 simple-bounces@ietf.org Fri Oct 1 19:13:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08976; Fri, 1 Oct 2004 19:13:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDWjF-0008RT-Hb; Fri, 01 Oct 2004 19:22:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDWNk-0002DF-My; Fri, 01 Oct 2004 19:00:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDW8n-0008TV-BY for simple@megatron.ietf.org; Fri, 01 Oct 2004 18:44:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04420 for ; Fri, 1 Oct 2004 18:44:38 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDWHK-0004k4-Sr for simple@ietf.org; Fri, 01 Oct 2004 18:53:31 -0400 Received: from [192.168.1.100] (c-67-164-133-175.client.comcast.net [67.164.133.175]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i91Mibfw045779 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 1 Oct 2004 17:44:38 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <4154496F.2010405@cisco.com> References: <4154496F.2010405@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <790D84FF-13FB-11D9-B01C-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - Syntax Date: Fri, 1 Oct 2004 17:44:37 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit On Sep 24, 2004, at 11:21 AM, Paul Kyzivat wrote: > Section 5: MSRP URL syntax: > > There is an undefined reference to "ALPHANUM". RFC2396 defines > "alphanum", but that is only a single byte. Suggest replacing ALPHANUM > with 1*alphanum, and reference 2396 for alphanum. ok. (I thought I fixed that one already, too. Grumble.) > > Rohan wanted "?" syntax added. I don't understand the statement. > > Section 8: Formal Syntax: > > I don't know what resulted in the following: > > dUmMy= "Status:" SP namespace SP short-status [SP text-reason] > > It must have been intentional. But the 'Status' element is undefined, > so I think this needs to be changed to: > > Status = "Status:" SP namespace SP short-status [SP text-reason] > Hmm... OK. > We define pval as: > > pval = token / quoted-string > > We might want to consider making it compatible with generic-param in > 3261, which also permits it to be a 'host'. OK. > > > > _______________________________________________ > 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 simple-bounces@ietf.org Sat Oct 2 01:41:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11518; Sat, 2 Oct 2004 01:41:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDcmN-0000mm-33; Sat, 02 Oct 2004 01:49:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDccF-0006Oq-GM; Sat, 02 Oct 2004 01:39:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDcZr-00055n-3w for simple@megatron.ietf.org; Sat, 02 Oct 2004 01:37:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11401 for ; Sat, 2 Oct 2004 01:37:02 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDciS-0000hp-EE for simple@ietf.org; Sat, 02 Oct 2004 01:45:56 -0400 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i925agpl029412; Sat, 2 Oct 2004 01:36:42 -0400 (EDT) Message-ID: <415E0C34.3000109@dynamicsoft.com> Date: Fri, 01 Oct 2004 22:02:28 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Hammer Subject: Re: [Simple] Pres Data Model Open Issue #1: in-person communications References: <4.3.2.7.2.20040929121646.00b30118@cia.cisco.com> <4.3.2.7.2.20040929110138.00b15708@cia.cisco.com> <4159D228.5040905@dynamicsoft.com> <4159D228.5040905@dynamicsoft.com> <4.3.2.7.2.20040929110138.00b15708@cia.cisco.com> <4.3.2.7.2.20040929121646.00b30118@cia.cisco.com> <4.3.2.7.2.20041001100912.00b02288@cia.cisco.com> In-Reply-To: <4.3.2.7.2.20041001100912.00b02288@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: Simple WG , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Mike Hammer wrote: > Hmmm... > > I was never against the inclusion of the in-person service, just thought > that once in visual contact that body language would take over. But, I > can see that it could save a trip down the hall if one knows someone is > in, but not willing to have interruptions, or where that might otherwise > be ambiguous. > > I'm also picturing the teenager with the status set to: "talk to the > hand". :) Right, exactly. Perhaps we should even add "talk to the hand" as a status element in rpid ;) > > It might also help disambiguate the case where several devices report > wildly different locations, but you really want to know where the person > is, mod privacy controls. Well, that we can already do. This problem exactly is the kind of thing that has motivated the separation of the three components of the data model - person, service, and device, each of which can have its onw attributes. Device location and person location are not the same thing. But the idea with in-person as a *service* is not just a vehicle for carrying the location of the person, its for indicating status and characteristics of that service. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 simple-bounces@ietf.org Sat Oct 2 01:43:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11598; Sat, 2 Oct 2004 01:43:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDcp0-0000qV-6H; Sat, 02 Oct 2004 01:52:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDccI-0006Pz-Rq; Sat, 02 Oct 2004 01:39:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDcZr-00055p-Vw for simple@megatron.ietf.org; Sat, 02 Oct 2004 01:37:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11404 for ; Sat, 2 Oct 2004 01:37:03 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDciT-0000hq-Es for simple@ietf.org; Sat, 02 Oct 2004 01:45:57 -0400 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i925aipl029415; Sat, 2 Oct 2004 01:36:44 -0400 (EDT) Message-ID: <415E0D19.3000101@dynamicsoft.com> Date: Fri, 01 Oct 2004 22:06:17 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] Pres Data Model Open Issue #1: in-person communications References: <4159D228.5040905@dynamicsoft.com> <4159FB36.9090502@cs.columbia.edu> <415CE1ED.6070900@dynamicsoft.com> <415D7E18.4010700@cs.columbia.edu> In-Reply-To: <415D7E18.4010700@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.4 (+) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 1.4 (+) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: >> I don't see why my postal information isn't subject to open or closed, >> like anything else. Admittedly it won't change often. HOwever, if I go >> on vacation for two weeks, might I not want to change it to closed? >> This is the example Mike gave. I don't see how email or SMS or MMS, or >> any form of store and forward messaging, would be different than >> postal in this regard. I do think we have agreed that sms, mms and >> email are useful services to list in the presence docuemnt. >> >> I agree that the cipid vcard can be used to convey my postal address. >> Perhaps then the postal "url" is nothing more than the reference to >> this vcard, perhaps in the same presence document even. However, that >> doesnt mean that postal is not a communications service as defined in >> the model. > > > But given its description by a vCard, it probably doesn't need a service > URI. The problem is similar for other "generic" means of communications. > Imagine some future SOAP-based service. It will have HTTP as a URI, > which will not tell you much. To be clear here, if we agree that in-person is a service, then according to the data model it shows up as a in the presence document. includes a element which contains a URI. Our preferred vehicle for indicating what the service is, is with the URI scheme. Thus, the conundrum. In cases where the URI is not sufficient (SIP, for example, or HTTP for something soap-ish), then you need characteristic information to tell you what the service is. > > >> Well, except that I dont think its a joke at all. > > > My concern is not that we don't need it, but that the reaction from > others, outside the SIMPLE/IM community, will be less accommodating. > Maybe I'm being too pessimistic. Well, there is a real problem here, so I think one might need to explain the motivation first... > >> >> I think it would be quite valuable to have this capability in PIDF. >> Its a real, valid, and absolutely useful form of a communications >> service to list in a presence document. > > > Having a service modality identifier (postal, personal, electronic) > might be easier. Postal and personal would not need URLs. So you are proposing something like as a presence attribute that would simply say to use a postal address? I don't think that fits as well really, since the presence attributes in the service are meant to characterize the service, not to declare it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 simple-bounces@ietf.org Sat Oct 2 01:47:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11714; Sat, 2 Oct 2004 01:47:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDcsK-0000uo-2h; Sat, 02 Oct 2004 01:56:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDccJ-0006Q4-K6; Sat, 02 Oct 2004 01:39:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDcZs-00055r-Tt for simple@megatron.ietf.org; Sat, 02 Oct 2004 01:37:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11407 for ; Sat, 2 Oct 2004 01:37:04 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDciU-0000hr-C9 for simple@ietf.org; Sat, 02 Oct 2004 01:45:58 -0400 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i925atpl029430; Sat, 2 Oct 2004 01:36:55 -0400 (EDT) Message-ID: <415E123A.30002@dynamicsoft.com> Date: Fri, 01 Oct 2004 22:28:10 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Simple] Pres Data Model Open Issue #5: what does idle mean? References: <5816828233DEFA41807A6CFDFDF2343C08B686@esebe056.ntc.nokia.com> In-Reply-To: <5816828233DEFA41807A6CFDFDF2343C08B686@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, mhammer@cisco.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit inline. hisham.khartabil@nokia.com wrote: > >> service-idle: For a service which receives input while it is the >> "focus" of the user interaction (focus in the user interface >> sense), there has been no input. For example, if my IM app is >> running, but I haven't selected it on my PC, its idle even though I >> may be typing into another app. > > > What if the application does have focus, but no user input for a > short unit of time? > > I actually would like to question the usefulness of this information: > How useful is service-idleness to the watcher? What can a watcher do > with information like: this service has not been used by the > presentity for 10 mins, especially when it is a service like IM where > it is idle most of the time waiting for user input or network input. > Service idleness is really only useful if it tells the watcher that > communicating with a presentity using this service while it is idle > *may not* result in a response from the presentity. That was an alternate formulation for the definition of idle, as I indicated in my original post. For IM, this > criteria is met only when it is combined with device idleness. > > Therefore it really could be that service idleness is service > specific. Examples: > > - An IM service is idle when the device it is running on is idle (has > not received any input for x mins) - A video service is idle if the > camera cover has been closed or the camera has been disabled for more > than x mins - An audio service is idle if the speakers or microphone > have been disabled for more than x mins - A game service is idle if > the player has placed the game in certain state for x mins I think you can usefully take one of two routes here. You can define service idle to mean, "there is a high likelihood that attempts to reach this service will result in no-answer", and then leave it as an implementation detail about how a service determines this fact. An alternate formulation (and my preferred one), is to define it concretely, and I have proposed lack of user input as the definition. Another point to make here. One of the reasons I much prefer a concrete definition, such as lack of user input for X seconds, is that over time, presence documents will contain more and more information. Combing that information together and producing more condensed statements about a user (see my response to Dave Boyer on an "available" icon) can only be accurately done if the input data is well defined. The path I do not think we should take is what you are proposing (I think) - to define it concretely, but in a different way for each service. Given our difficulty in clearly enumerating services in a meaningful way, how can we expect to meaningfully define idle for each of those services? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 simple-bounces@ietf.org Sat Oct 2 01:47:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11747; Sat, 2 Oct 2004 01:47:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDcsf-0000vL-QA; Sat, 02 Oct 2004 01:56:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDccK-0006QS-Hc; Sat, 02 Oct 2004 01:39:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDcZv-00056I-VR for simple@megatron.ietf.org; Sat, 02 Oct 2004 01:37:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11410 for ; Sat, 2 Oct 2004 01:37:07 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDciN-0000hn-61 for simple@ietf.org; Sat, 02 Oct 2004 01:46:01 -0400 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i925akpl029418; Sat, 2 Oct 2004 01:36:46 -0400 (EDT) Message-ID: <415E0DAC.9070100@dynamicsoft.com> Date: Fri, 01 Oct 2004 22:08:44 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] Pres Data Model Open Issue #3, UUID URN or something else References: <4159D54F.5060700@dynamicsoft.com> <4159E364.8030204@cisco.com> <415CE4B2.80008@dynamicsoft.com> <415D8577.8030907@cisco.com> In-Reply-To: <415D8577.8030907@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: > > > Jonathan Rosenberg wrote: > >> inline. >> >> Paul Kyzivat wrote: >> >> >>>> I would propose approach (3). In particular, I think the data model >>>> should revert to being agnostic on the URN scheme, reference the >>>> UUID URN as one possibility, document its problems. We should >>>> develop a separate specification that defines guidelines for >>>> choosing the URN for various devices in order to get the >>>> correlation properties we want. I also think we should take a stab >>>> at defining a few URN schemes that would be useful - MAC and ESN in >>>> particular. >>> >>> >>> >>> >>> I think it does make sense to leave the particular choice out of this >>> document. >>> >>> I do think the problem with UUID can be dealt with in a couple of >>> ways: >>> >>> - for some kinds of "devices", like softphones and IM clients, it is >>> probably fine as-is. They can typically have multiple instances per >>> device, so they must construct and instance id and save it >>> persistently as part of the instance configuration. >> >> >> >> I think softphones are PC-based devices are a candidate where we want to >> be able to correlate service information with device information learned >> from network elements like an 802.11 AP. Thus, I do think this problem >> applies to things besides phones. > > > Yes, I guess you are right. I was still thinking of "instance id", > rather than specifically "device id". > >>> - for a dedicated device, like a phone, that can't or doesn't want to >>> use the above technique, a cannonical mac-based uuid can be >>> constructed by using a fixed time (e.g. zero) along with the mac. >> >> >> I thought about that, but wasn't able to convince myself that it was >> allowed in the UUID URN spec. Do you find words that allow you to set >> the time to zero? > > > Well, it probably does require some mental gymnastics to justify it. It > is a matter of saying you are using the UUID generated with this mac at > "the beginning of time". > > Would it work? yes. > > Is it ideal? Probably not. > > Is it a valid usage? Debatable. > > Could we recommend it? I don't know. > > Could we say "you might be able to find a creative way to use this form > of uuid"? Why not? I think at this point the help of one of the authors of the UUID draft is needed. One issue is that, if someone develops a UUID implementation, it may have no way of allowing an app to set the time to zero, since its not really something one would think to do based on that spec alone. I'd hate for folks to be forced to write a UUID URN implementation from scratch just because of this. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 simple-bounces@ietf.org Sat Oct 2 01:48:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11792; Sat, 2 Oct 2004 01:48:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDctC-0000wC-63; Sat, 02 Oct 2004 01:57:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDccL-0006RK-8E; Sat, 02 Oct 2004 01:39:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDcZw-00056K-EW for simple@megatron.ietf.org; Sat, 02 Oct 2004 01:37:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11413 for ; Sat, 2 Oct 2004 01:37:07 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDciX-0000ht-Tt for simple@ietf.org; Sat, 02 Oct 2004 01:46:02 -0400 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i925axpl029436; Sat, 2 Oct 2004 01:36:59 -0400 (EDT) Message-ID: <415E1617.5090200@dynamicsoft.com> Date: Fri, 01 Oct 2004 22:44:39 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Hammer Subject: Re: [Simple] Pres Data Model Open Issue #5: what does idle mean? References: <4.3.2.7.2.20040929103449.00b0e058@cia.cisco.com> <4.3.2.7.2.20040929103449.00b0e058@cia.cisco.com> <4.3.2.7.2.20041001104505.00b02d68@cia.cisco.com> In-Reply-To: <4.3.2.7.2.20041001104505.00b02d68@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit inline. Mike Hammer wrote: > At 01:24 AM 10/1/2004 -0400, Jonathan Rosenberg wrote: > >> device-idle: The device has received no data input on any of its user >> input devices that require active input (including keyboards, mice, >> trackballs, but excluding things like microphones and cameras where >> there is always "input") > > > This seems to assume that a human user is always at the other end. A human user or something like it, yes. > > I was thinking that there might be devices (e.g. a large telescope, or > say an outdoor web cam at a popular ski resort) that could be on-line > (versus off-line for maintenance) and could be actively serving one > potential star-gazer or skier, or perhaps idle and available (possibly > for a small fee). Sure. But these things are not communications services, and are not the types of things we are trying to model with presence documents. > Note also that being idle in the human user case is giving a clue that > perhaps, the human is not really there (caveat the cellphone example); What does "there" refer to in your text above? > So, I guess the definition will work. It just moves the definition > problem to defining what is the user, and what is active input for cases > where user!=human. Should some "need to define" caution be added for > those non-human based cases? I dont think so. Presence is about communications status of people or things that have similar properties to people as they relate to usage of communications systems. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 simple-bounces@ietf.org Sat Oct 2 01:48:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11837; Sat, 2 Oct 2004 01:48:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDcta-0000yk-AY; Sat, 02 Oct 2004 01:57:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDccM-0006SV-7b; Sat, 02 Oct 2004 01:39:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDca6-00056u-4e for simple@megatron.ietf.org; Sat, 02 Oct 2004 01:37:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11416 for ; Sat, 2 Oct 2004 01:37:17 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDcih-0000i0-JE for simple@ietf.org; Sat, 02 Oct 2004 01:46:11 -0400 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i925avpl029433; Sat, 2 Oct 2004 01:36:57 -0400 (EDT) Message-ID: <415E1532.8000102@dynamicsoft.com> Date: Fri, 01 Oct 2004 22:40:50 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] Pres Data Model Open Issue #5: what does idle mean? References: <4.3.2.7.2.20040929103449.00b0e058@cia.cisco.com> <415CE9FF.4030205@dynamicsoft.com> <415D8109.6060100@cs.columbia.edu> In-Reply-To: <415D8109.6060100@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: Simple WG , Mike Hammer X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Would a simple definition "no human interaction with the device or > service for x minutes" not be sufficient? > > For a service, 'human interaction' includes a person answering a > call, placing a call or sending a message. Since all communication > services are either session- or message-based, this should pretty > much capture the possibilities. To be honest, I don't see the difference between this an "no user input for X minutes". Is there one? Henning later wrote: > Another thought: > > In many cases, it is probably more informative to say "has been > active as recently as ten minutes ago", i.e., the inverse of idle. > Even knowing that user Bob sent email or placed a call, both > services, a short while ago is quite useful - Bob is probably around > and not asleep. (Absence of idle is not as informative as the > recipient doesn't know the idle threshold and idle may not be > reported at all.) Interesting. You could solve half of this by just reporting the idle threshold as part of the element. Once you do that, the only issue is differentiating lack of an idle indicatiion with active. Seems like the same argument could be made for almost any indicator that has only a positive indication. As such, another approach would be to change idle to include both, just as can indicate either private or public. Both values are included. That would look something like idle active -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 simple-bounces@ietf.org Sat Oct 2 05:25:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06359; Sat, 2 Oct 2004 05:25:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDgHk-0005pS-W3; Sat, 02 Oct 2004 05:34:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDg4E-0000oN-MA; Sat, 02 Oct 2004 05:20:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDfsO-00014c-A2 for simple@megatron.ietf.org; Sat, 02 Oct 2004 05:08:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05741 for ; Sat, 2 Oct 2004 05:08:22 -0400 (EDT) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDg11-0005TO-EO for simple@ietf.org; Sat, 02 Oct 2004 05:17:19 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i92985T07433; Sat, 2 Oct 2004 12:08:05 +0300 (EET DST) X-Scanned: Sat, 2 Oct 2004 12:07:53 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9297rPM005508; Sat, 2 Oct 2004 12:07:53 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00b1hPOL; Sat, 02 Oct 2004 12:07:51 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9297oY10826; Sat, 2 Oct 2004 12:07:50 +0300 (EET DST) Received: from [10.163.23.234] ([10.163.23.234]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 2 Oct 2004 12:07:46 +0300 Message-ID: <415E6FE2.7000602@nokia.com> Date: Sat, 02 Oct 2004 12:07:46 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Ben Campbell References: <414FFFCF.8020007@nokia.com> <92748F4C-13F0-11D9-B01C-000D93B0AE1A@nostrum.com> In-Reply-To: <92748F4C-13F0-11D9-B01C-000D93B0AE1A@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Oct 2004 09:07:47.0050 (UTC) FILETIME=[48D514A0:01C4A85F] X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: 7bit Cc: fluffy@cisco.com, rohan@cisco.com, SIMPLE mailing list Subject: [Simple] Re: MSRP URLs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: 7bit Ben: Thanks for the reply. Inline comments. Ben Campbell wrote: > > On Sep 21, 2004, at 5:17 AM, Miguel Garcia wrote: > >> Hi: >> >> A few comments about section 5 of the MSRP draft: >> >> http://www.ietf.org/internet-drafts/draft-ietf-simple-message- >> sessions-08.txt >> >> 1) The draft should describe the type of resources that are >> identified by an MSRP URL. So I would suggest to add an introductory >> paragraph at the beginning of section 5 that says something on the >> following lines: >> >> The MSRP and MSRPS URL schemes are used to designate a session of >> instant messages at a particular host computer. >> >> Question: is this definition also applicable to relays? >> > > I think if we say at a particular MSRP device, then it applies to both > relays and endpoints. Or more precisely, it describes either an MSRP > service, or an MSRP session hosted at a particular service. Good definition, I like it. > >> 2) RFC 2396 is under revision, nowadays >> draft-fielding-uri-rfc2396bis-06.txt. I am not sure if you still want >> to refer to RFC 2396 or the revision of it. I guess this depends of >> which draft makes it first to the IESG. >> >> Among other things, in case you want to refer to rfc2396bis, this >> draft has removed the definition of "hostport". Now it is just "host >> [: port]" > > > Does anyone know the status of 2396bis? I want to avoid all the > normative references to works in progress that we can. There are too > many hoops to jump as it is. > The I-D tracker indicates that this draft is currently under IESG evaluation, heading towards standard track RFC. Ted Hardie is the shepherding AD. Maybe you want to ask advice from Ted. >> >> 3) The current definition of an MSRP URL includes a "resource" part, >> when actually it is a "path" or "session-id", because a "resource" is >> the the whole MSRP URL, including the URI scheme and the hostname. >> >> So I would suggest to replace the current definition: >> >> MSRP_urls = msrp-scheme "://" [userinfo "@"] hostport ["/" >> resource] ";" transport >> resource = 1*unreserved >> >> with this other one: >> >> MSRP_urls = msrp-scheme "://" [userinfo "@"] hostport ["/" >> path] ";" transport >> resource = 1*unreserved > > > I am okay with "sessionid" or "session". I don't like path, as I think > it implies things we don't mean. On the other hand, does resource > conflict with something in the abnf? It's just a variable name, and it > does not seem useful to get too bogged down in the semantic meaning of > abnf identifier choices. > I don't think "resource" conflicts with anything in the ABNF, it is just a missleading term, as well as "path" as you suggested. I would be happy to go for "session" or "sessionid". >> >> 4) According to rfc2396bis, "unrerved" is defined as: >> >> unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" >> >> On purpose "unreserved" does not include "sub-delims", which is >> defined as: >> >> sub-delims = "!" / "$" / "&" / "'" / "(" / ")" >> / "*" / "+" / "," / ";" / "=" >> >> I guess it is OK for MSRP that the path is formed of unreserved >> characters, not including sub-delims. But I would like to point this >> out in case someone feels the path needs to include sub-delims. > > > If I recall correctly, we consciously chose to use unreserved on all of > this to avoid escaping. Does anyone see a requirement to use other > characters here than cannot be achieved with unreserved characters? I don't have such requirement. I just wanted to check that was a decision taken on purpose, not an oversight. > >> >> 5) I find a contradiction that we, on one hand, allow to have a >> "userinfo" part in the MSRP URL including a reference to RFC 2396, >> and on the other hand we restrict the "userinfo" definition in RFC >> 23964 to unreserved characters. >> >> RFC 2396 (and 2396bis) allow to have escaped characters in the >> userinfo. However, MSRP does not, but still refers to 2396 for the >> definition of userinfo. >> >> So, if the "userinfo" defined in the MSRP URL is different from (or a >> subset of) the "userinfo" defined in RFC 2396, then I would suggest >> to change the name (perhaps "unescaped-userinfo"), and avoid the >> reference to RFC 2396. >> > > Again, I don't think we want to bring in unescaped characters unless > we find a problem with not allowing them. But I am okay with changing > the construction name. ok > >> 6) Section 5.1 reads on the second bullet point: >> >> 2. If the hostpart contains an eplicit IP address, and/or port, >> these are compared numerically. Otherwise, hostpart is compared >> as a case insensitive character string. >> >> I was wondering in the how to treat zeros in either IPv4 or IPv6 >> (IPv6 uses this quite oftenly). The missleading word is >> "numerically", since I am not sure if the "::" should be normalized >> by adding trailing and leading zeros or not. >> >> Is it the intention that the following two URLs are equivalent and >> MSRP endpoints should detect it? >> >> msrp://[1080:0:0:0:8:800:200C:417A]/aodisfa;tcp >> msrp://[1080::8:800:200C:417A]/aodisfa;tcp >> >> A clarification should be written. >> > > I don't know enough about IPv6 to address that. Are the two addresses > equivalent? We had a suggestion to try to avoid treating URLS > differently if they had the same address with slight encoding > differences. But if this becomes a complex issue, I propose we just go > back to a text comparison. At least in IPv6 the examples above represent the same IPv6 address. RFC 3513 indicates the three forms to represent an IPv6 address. I guess there should be a discussion on the equivalency of this kind of addresses. - Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Oct 4 00:35:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02787; Mon, 4 Oct 2004 00:35:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEKid-00076T-VZ; Mon, 04 Oct 2004 00:45:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEKNb-0004hM-6v; Mon, 04 Oct 2004 00:23:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEKDP-0004ki-U4 for simple@megatron.ietf.org; Mon, 04 Oct 2004 00:12:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25912 for ; Mon, 4 Oct 2004 00:12:43 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CE3Bh-0008Er-57 for simple@ietf.org; Sun, 03 Oct 2004 06:01:54 -0400 Received: from razor.cs.columbia.edu (IDENT:YemKLh2ufBZI3p3QH5Dz9f3lcg1hhDPR@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i939qOx6025031 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 3 Oct 2004 05:52:24 -0400 (EDT) Received: from [127.0.0.1] (IDENT:GweRpj3ts8+NcaZ2a7bNSawkQWpklNmT@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i939qKYa023252; Sun, 3 Oct 2004 05:52:23 -0400 Message-ID: <415FCC30.5040201@cs.columbia.edu> Date: Sun, 03 Oct 2004 11:53:52 +0200 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Pres Data Model Open Issue #5: what does idle mean? References: <4.3.2.7.2.20040929103449.00b0e058@cia.cisco.com> <415CE9FF.4030205@dynamicsoft.com> <415D8109.6060100@cs.columbia.edu> <415E1532.8000102@dynamicsoft.com> In-Reply-To: <415E1532.8000102@dynamicsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.10.2.1 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: Simple WG , Mike Hammer X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit > To be honest, I don't see the difference between this an "no user input > for X minutes". Is there one? No real difference. The definition is just less input-oriented and more service-oriented. Presumably calls placed and messages sent require some form of user input. Consider it more like additional examples for services. >> > Henning later wrote: > >> Another thought: >> >> In many cases, it is probably more informative to say "has been >> active as recently as ten minutes ago", i.e., the inverse of idle. >> Even knowing that user Bob sent email or placed a call, both >> services, a short while ago is quite useful - Bob is probably around >> and not asleep. (Absence of idle is not as informative as the >> recipient doesn't know the idle threshold and idle may not be >> reported at all.) > > > Interesting. You could solve half of this by just reporting the idle > threshold as part of the element. Once you do that, the only > issue is differentiating lack of an idle indicatiion with active. Seems > like the same argument could be made for almost any indicator that has > only a positive indication. > > As such, another approach would be to change idle to include both, just > as can indicate either private or public. Both values are > included. That would look something like > > idle > active I'd choose a different label, e.g., usage, but that's third-order nitpicking. The general problem is that long idle times have very limited predictive ability - the probability of reachability dramatically *in*creases after 15 hours of idle time for most office workers, or, around lunch time, after 30 minutes to one hour of idle time. That would work, but I suspect that without a last-active indication, this is all of limited use. The three examples combined (short idle time is useful, gone home, lunch) illustrate that idle/active is helpful mostly if you know how long this has been active or idle (or you know more about the person and her timezone) and requires relatively short reporting intervals. Knowing that somebody was active an hour ago, at the last NOTIFY, isn't all that helpful. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Oct 4 00:36:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02895; Mon, 4 Oct 2004 00:36:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEKjW-00078c-5y; Mon, 04 Oct 2004 00:46:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEKNe-0004lZ-Vx; Mon, 04 Oct 2004 00:23:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEKDb-0004x5-MF for simple@megatron.ietf.org; Mon, 04 Oct 2004 00:12:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26062 for ; Mon, 4 Oct 2004 00:12:55 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CE2wB-0004Sr-NF for simple@ietf.org; Sun, 03 Oct 2004 05:45:53 -0400 Received: from razor.cs.columbia.edu (IDENT:6k6jBpqwU5q9h6WO31Bl12LCS0g1u7+z@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i939aKx6022234 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 3 Oct 2004 05:36:21 -0400 (EDT) Received: from [127.0.0.1] (IDENT:aQU9IsTEYq1yhc1bUnKn2JwjAv2Da/Vz@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i939aHYa022878; Sun, 3 Oct 2004 05:36:19 -0400 Message-ID: <415FC86D.8080909@cs.columbia.edu> Date: Sun, 03 Oct 2004 11:37:49 +0200 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Pres Data Model Open Issue #1: in-person communications References: <4159D228.5040905@dynamicsoft.com> <4159FB36.9090502@cs.columbia.edu> <415CE1ED.6070900@dynamicsoft.com> <415D7E18.4010700@cs.columbia.edu> <415E0D19.3000101@dynamicsoft.com> In-Reply-To: <415E0D19.3000101@dynamicsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.10.2.1 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit > To be clear here, if we agree that in-person is a service, then > according to the data model it shows up as a in the presence > document. includes a element which contains a URI. Our > preferred vehicle for indicating what the service is, is with the URI > scheme. Thus, the conundrum. > > In cases where the URI is not sufficient (SIP, for example, or HTTP for > something soap-ish), then you need characteristic information to tell > you what the service is. One solution is having no URI and a (mandatory) service characteristic. Here, class of service = (electronic, postal/courier, inperson). A URI implies 'electronic' service. We can then later add other service types, such as "remote-acoustic" (bush drums) or "visual" (smoke signals, semaphores, etc.). I very much doubt we'd want to define URIs for all of these... We agreed that just having "no URI = in-person" is bad, but it seems inappropriate to define a pseudo-URL scheme that doesn't really correspond closely with other URL schemes and contains no real information. With the service label, there is no ambiguity and old PIDF interpreters won't get confused. > So you are proposing something like as a presence attribute > that would simply say to use a postal address? I don't think that fits > as well really, since the presence attributes in the service are meant > to characterize the service, not to declare it. Not quite: postal This is just another characteristic of the service, along with all the other prescaps and similar characterizations that we already have. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Oct 4 00:44:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28769; Mon, 4 Oct 2004 00:16:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEKQ2-0005WL-Ui; Mon, 04 Oct 2004 00:25:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJuU-0003D6-2S; Sun, 03 Oct 2004 23:53:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJsM-00010U-PU for simple@megatron.ietf.org; Sun, 03 Oct 2004 23:51:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20014 for ; Sun, 3 Oct 2004 23:50:58 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CE8a4-0002fO-0O for simple@ietf.org; Sun, 03 Oct 2004 11:47:24 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 03 Oct 2004 08:44:35 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i93FbNEE002294; Sun, 3 Oct 2004 08:37:24 -0700 (PDT) Received: from cisco.com (che-vpn-cluster-2-130.cisco.com [10.86.242.130]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALZ83568; Sun, 3 Oct 2004 11:37:22 -0400 (EDT) Message-ID: <41601CB2.9030005@cisco.com> Date: Sun, 03 Oct 2004 11:37:22 -0400 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: Ben Campbell Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - Chunking References: <41544924.30008@cisco.com> <6DD77295-13F8-11D9-B01C-000D93B0AE1A@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > >> - chunks other than the last SHOULD (or MUST?) have a body ('data' >> in the syntax) of length exactly 2048. If SHOULD, what is a >> valid reason to violate? > > Disagree. I could have sent considerably more than 2k of an > interruptible chunk prior to actually interrupting it. Oops - I didn't say exactly what I meant. Yes I agree an *interruptible* chunk can be larger. My comment was intended to apply only to *uninterruptible* chunks. So the question is whether it is permissible for a noninterruptible, non-final, chunk to be less than 2048 bytes long. (We have already settled that it can't be more than 2048.) >> - responses never have bodies at all. Requests other than SEND >> may have a body but are unchunkable. The presence of a Byte-Range >> in a request other than SEND says nothing about the body of that >> request. (In REPORT it refers to the SEND being reported on. >> See separate thread on Byte-Range.) This at best seems irregular >> and weird. > > I would further be willing to say that byte-range MUST NOT exist in > anything but SEND and REPORT. And if the overloading in report really > bothers people, I am willing to change the name of the header in the > context of REPORT. Either of these would be ok with me. (But doesn't it also have to be in a response?) Another question is whether we think there may ever be additional messages that might need to use Byte-Range to chunk a large body. My general philosophy would be to leave that as a possibility, but I have no particular reason to think that is important. >> Section 6.3.1 says: "it is possible the body is shorter than the >> range-end field indicates. This can occur if the sender interrupted a >> SEND request unexpectedly." Based on what I have interpretted above, >> this is no longer possible. (To be interrupted it must have had a >> range-end of "*".) > > This is a leftover from before we defined the rules for putting "*" in > byte-range. We could remove it, although there might be some benefit in > doing this for resiliency sake. Perhaps dropping it to a MAY? I would prefer to see this ruled an error. (MUST NOT) It just eliminates an unnecessary implementation decision. > Since Orit made the same complaint, I guess I am willing to cut it > completely. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Oct 4 00:45:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29030; Mon, 4 Oct 2004 00:16:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEKQL-0005e3-G1; Mon, 04 Oct 2004 00:26:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJuk-0003HL-0K; Sun, 03 Oct 2004 23:53:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJsa-00018n-RY for simple@megatron.ietf.org; Sun, 03 Oct 2004 23:51:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20170 for ; Sun, 3 Oct 2004 23:51:12 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CE8JU-0003Pv-I9 for simple@ietf.org; Sun, 03 Oct 2004 11:30:17 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 03 Oct 2004 08:34:31 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i93FK4dV021337; Sun, 3 Oct 2004 08:20:04 -0700 (PDT) Received: from cisco.com (che-vpn-cluster-2-130.cisco.com [10.86.242.130]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALZ83391; Sun, 3 Oct 2004 11:20:02 -0400 (EDT) Message-ID: <416018A1.7000700@cisco.com> Date: Sun, 03 Oct 2004 11:20:01 -0400 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: Ben Campbell Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - Byte Ranges in REPORTs References: <41544962.2080509@cisco.com> <5CF97971-13F7-11D9-B01C-000D93B0AE1A@nostrum.com> <98E41386-13F7-11D9-B01C-000D93B0AE1A@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Ben, Learning about failure of a chunk is only of value if there is something that you can and should do about it that you wouldn't do based on knowing about the failure of the whole message. You suggest that you might retransmit the chunk. Question is whether there is any value/point in doing this. At least point to point there seems to be no reason, since the underlying protocol is reliable. Maybe it could make sense in the presence of relays, or in cases when a connection fails and is reestablished. Expecting this kind of recovery will then impose added responsibilities on senders. I guess I could go either way on this. A problem with using Byte-Range with REPORT is that the semantics of Byte-Range is highly variable depending on the message it appears in. In SEND it applies to the body of the SEND. In REPORT, even though REPORT can have its own body, the Byte-Range does not apply to that, but instead applies to the SEND the REPORT references. This is perhaps OK, but then I think we need to clarify the definitions to make this crystal clear. We then also ought to spell out clearly what we expect a sender to do when receiving a failure report with a Byte-Range. Paul Ben Campbell wrote: > Oops, I just realized I missed one of Paul's comments. > > Paul suggests there is no value saying what part of a message fails, > only that the whole message fails. I disagree. If a sender learns that a > particular byte-range failed, it may be able to send a new chunk > containing that byte range. > > On Oct 1, 2004, at 5:15 PM, Ben Campbell wrote: > >> Sorry for the late response. Somehow my mail hid this entire thread >> from me until a couple of days ago. Else I just forgot how to use >> computers. Comments inline. >> >> On Sep 24, 2004, at 11:20 AM, Paul Kyzivat wrote: >> >>> I am really confused about how byte ranges are supposed to work in >>> reports, and I suspect we are permitting a bunch of nonsense. >>> >>> Fundamentally, a message can only be considered a success if all its >>> bytes are received successfully. If it is to be positively acknowledged >>> with success reports, then there must be success reports covering >>> every byte. Is there any point in sending a success report for less than >>> the entire message? It doesn't help the receiver, and actually makes >>> more work because it then requires keeping track of what bytes have been >>> confirmed. And it doesn't ease the job of the sender, who could easily >>> just wait until all has been received before sending the success report. >>> >>> The flip side is that a message fails if a single byte fails. At that >>> point it does no good to know that other parts succeeded or failed. So >>> while it makes sense to send a failure report based on problems with a >>> single chunk, there is little value in saying which byte range failed. >>> >>> Bottom line: unless I have missed something, there is no reason for >>> Byte-Range in REPORT or responses. A success report should only be sent >>> after all the chunks of a message have been received. A failure report, >>> or an error status, can be sent at the time the failure of a single >>> chunk is known, but need not identify the byte range. (In that case, >>> maybe the Byte-Range could be optional for debugging purposes only.) >>> >> >> I agree you need reports that cover the entirety of the message for a >> success. I further agree that endpoints should not send success >> reports until they have the entire message. I wonder, however, if >> there are situations where this is not possible. For example, if a >> message crosses a gateway, and somehow different gateways send >> different chunks. But, since said gateway will need to reconstruct the >> entire message to pass on, this probably cannot happen. >> >> So I am willing to assert that you only send success reports on the >> entire message. Do we think there is any need for the sender to be >> able to accumulate success reports on subsets of a message? >> >> Just to make sure we are clear, though, I think _failure_ reports are >> sent on a per-chunk basis. If an endpoint decides to send a failure >> report because it is missing a data range, it should report on that >> specific data range. >> >>> >>> >>> >>> _______________________________________________ >>> 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 simple-bounces@ietf.org Mon Oct 4 06:01:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18954; Mon, 4 Oct 2004 06:01:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEPoO-0001IQ-JP; Mon, 04 Oct 2004 06:11:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEPYY-0003ci-6P; Mon, 04 Oct 2004 05:54:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEPRG-0002d2-3U for simple@megatron.ietf.org; Mon, 04 Oct 2004 05:47:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17675 for ; Mon, 4 Oct 2004 05:47:23 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEPaJ-0007XU-Do for simple@ietf.org; Mon, 04 Oct 2004 05:56:47 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i949lBW24389; Mon, 4 Oct 2004 12:47:11 +0300 (EET DST) X-Scanned: Mon, 4 Oct 2004 12:46:47 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i949kl21026479; Mon, 4 Oct 2004 12:46:47 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00Cn3YI0; Mon, 04 Oct 2004 12:46:45 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i949kjS26677; Mon, 4 Oct 2004 12:46:45 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Oct 2004 12:46:39 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe023.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Oct 2004 12:46:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Review of draft-ietf-simple-message-sessions-08 - Byte Ranges in REPORTs Date: Mon, 4 Oct 2004 12:46:39 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C08B691@esebe056.ntc.nokia.com> Thread-Topic: [Simple] Review of draft-ietf-simple-message-sessions-08 - Byte Ranges in REPORTs Thread-Index: AcSoBJ4mVnLQ3qEeSXKRY7If0VvIjwB8ldWw To: X-OriginalArrivalTime: 04 Oct 2004 09:46:40.0145 (UTC) FILETIME=[0C4AA010:01C4A9F7] X-Spam-Score: 0.3 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: pkyzivat@cisco.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:ben@nostrum.com] > Sent: 02.October.2004 01:18 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: pkyzivat@cisco.com; simple@ietf.org > Subject: Re: [Simple] Review of=20 > draft-ietf-simple-message-sessions-08 - > Byte Ranges in REPORTs >=20 >=20 >=20 > On Sep 27, 2004, at 5:57 AM, hisham.khartabil@nokia.com wrote: >=20 > > I agree. The situation is further complicated when a relay=20 > decides to=20 > > re-chunk. The relay then has to consume the REPORTs and generate it=20 > > own to pass upstream. > > >=20 > I don't see why. There is no requirement that the byte-range in a=20 > REPORT match the precise byte-range in any chunk that you sent. If that is the case, then please clarify the text in the ID. Thanks, Hisham >=20 > > /Hisham > > > >> -----Original Message----- > >> From: simple-bounces@ietf.org > >> [mailto:simple-bounces@ietf.org]On Behalf > >> Of ext Paul Kyzivat > >> Sent: 24.September.2004 19:21 > >> To: simple@ietf.org > >> Subject: [Simple] Review of > >> draft-ietf-simple-message-sessions-08 - Byte > >> Ranges in REPORTs > >> > >> > >> I am really confused about how byte ranges are supposed to work in > >> reports, and I suspect we are permitting a bunch of nonsense. > >> > >> Fundamentally, a message can only be considered a success=20 > if all its > >> bytes are received successfully. If it is to be positively > >> acknowledged > >> with success reports, then there must be success=20 > reports covering > >> every byte. Is there any point in sending a success report > >> for less than > >> the entire message? It doesn't help the receiver, and=20 > actually makes > >> more work because it then requires keeping track of what > >> bytes have been > >> confirmed. And it doesn't ease the job of the sender, who=20 > could easily > >> just wait until all has been received before sending the > >> success report. > >> > >> The flip side is that a message fails if a single byte=20 > fails. At that > >> point it does no good to know that other parts succeeded=20 > or failed. So > >> while it makes sense to send a failure report based on=20 > problems with a > >> single chunk, there is little value in saying which byte=20 > range failed. > >> > >> Bottom line: unless I have missed something, there is no reason for > >> Byte-Range in REPORT or responses. A success report should > >> only be sent > >> after all the chunks of a message have been received. A > >> failure report, > >> or an error status, can be sent at the time the failure of a single > >> chunk is known, but need not identify the byte range. (In=20 > that case, > >> maybe the Byte-Range could be optional for debugging=20 > purposes only.) > >> > >> > >> > >> > >> _______________________________________________ > >> 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 > > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Oct 4 06:34:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21147; Mon, 4 Oct 2004 06:34:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEQJw-0007Cs-Hu; Mon, 04 Oct 2004 06:43:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEQ1T-0001Pp-3W; Mon, 04 Oct 2004 06:24:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEPzP-00013d-8l for simple@megatron.ietf.org; Mon, 04 Oct 2004 06:22:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20288 for ; Mon, 4 Oct 2004 06:22:40 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEQ8S-000539-SP for simple@ietf.org; Mon, 04 Oct 2004 06:32:05 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i94AMSF07857; Mon, 4 Oct 2004 13:22:28 +0300 (EET DST) X-Scanned: Mon, 4 Oct 2004 13:21:53 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i94ALrH7015882; Mon, 4 Oct 2004 13:21:53 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00cgQUai; Mon, 04 Oct 2004 13:21:52 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i94ALjY00868; Mon, 4 Oct 2004 13:21:45 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Oct 2004 13:21:40 +0300 Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Oct 2004 13:21:39 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe021.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Oct 2004 13:21:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Pres Data Model Open Issue #5: what does idle mean? Date: Mon, 4 Oct 2004 13:21:39 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C08B694@esebe056.ntc.nokia.com> Thread-Topic: [Simple] Pres Data Model Open Issue #5: what does idle mean? Thread-Index: AcSpy+vlaa4QoxPYQ2GM+BYJlSlXDwAL+3Ww To: , X-OriginalArrivalTime: 04 Oct 2004 10:21:39.0832 (UTC) FILETIME=[EFCD6F80:01C4A9FB] X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org, mhammer@cisco.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable >=20 > That would work, but I suspect that without a last-active indication,=20 > this is all of limited use. The three examples combined=20 > (short idle time=20 > is useful, gone home, lunch) illustrate that idle/active is helpful=20 > mostly if you know how long this has been active or idle (or you know=20 > more about the person and her timezone) and requires relatively short=20 > reporting intervals. Knowing that somebody was active an hour ago, at=20 > the last NOTIFY, isn't all that helpful. Yep, yahoo, for example tells you how long a buddy has been idle for. /Hisham >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Oct 4 06:36:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21391; Mon, 4 Oct 2004 06:36:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEQM7-0007lj-Mk; Mon, 04 Oct 2004 06:46:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEQ1W-0001R9-HU; Mon, 04 Oct 2004 06:24:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEQ0F-0001Aj-HM for simple@megatron.ietf.org; Mon, 04 Oct 2004 06:23:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20348 for ; Mon, 4 Oct 2004 06:23:32 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEQ9G-00053g-4b for simple@ietf.org; Mon, 04 Oct 2004 06:32:57 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i94ANQW16602; Mon, 4 Oct 2004 13:23:26 +0300 (EET DST) X-Scanned: Mon, 4 Oct 2004 13:23:10 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i94ANARV019612; Mon, 4 Oct 2004 13:23:10 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00EXgrsX; Mon, 04 Oct 2004 13:23:08 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i94AN2Y02124; Mon, 4 Oct 2004 13:23:02 +0300 (EET DST) Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Oct 2004 13:22:46 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Oct 2004 13:22:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Pres Data Model Open Issue #5: what does idle mean? Date: Mon, 4 Oct 2004 13:22:45 +0300 Message-ID: <5816828233DEFA41807A6CFDFDF2343C08B695@esebe056.ntc.nokia.com> Thread-Topic: [Simple] Pres Data Model Open Issue #5: what does idle mean? Thread-Index: AcSoQg95rKeozjh+Suiyi62jZpWPzQBueMXQ To: X-OriginalArrivalTime: 04 Oct 2004 10:22:46.0215 (UTC) FILETIME=[175EAD70:01C4A9FC] X-Spam-Score: 0.3 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org, mhammer@cisco.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable OK, I'm willing to accept your proposal *for now*. We might have to = re-visit this in a couple of years ;) /Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 02.October.2004 05:28 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: mhammer@cisco.com; simple@ietf.org > Subject: Re: [Simple] Pres Data Model Open Issue #5: what does idle > mean? >=20 >=20 > inline. >=20 > hisham.khartabil@nokia.com wrote: >=20 > >=20 >=20 > >> service-idle: For a service which receives input while it is the > >> "focus" of the user interaction (focus in the user interface > >> sense), there has been no input. For example, if my IM app is > >> running, but I haven't selected it on my PC, its idle even though I > >> may be typing into another app. > >=20 > >=20 > > What if the application does have focus, but no user input for a > > short unit of time? > >=20 > > I actually would like to question the usefulness of this=20 > information: > > How useful is service-idleness to the watcher? What can a watcher do > > with information like: this service has not been used by the > > presentity for 10 mins, especially when it is a service=20 > like IM where > > it is idle most of the time waiting for user input or network input. > > Service idleness is really only useful if it tells the watcher that > > communicating with a presentity using this service while it is idle > > *may not* result in a response from the presentity. >=20 > That was an alternate formulation for the definition of idle, as I=20 > indicated in my original post. >=20 > For IM, this > > criteria is met only when it is combined with device idleness. > >=20 > > Therefore it really could be that service idleness is service > > specific. Examples: > >=20 > > - An IM service is idle when the device it is running on is=20 > idle (has > > not received any input for x mins) - A video service is idle if the > > camera cover has been closed or the camera has been=20 > disabled for more > > than x mins - An audio service is idle if the speakers or microphone > > have been disabled for more than x mins - A game service is idle if > > the player has placed the game in certain state for x mins >=20 > I think you can usefully take one of two routes here. You can define=20 > service idle to mean, "there is a high likelihood that=20 > attempts to reach=20 > this service will result in no-answer", and then leave it as an=20 > implementation detail about how a service determines this fact. An=20 > alternate formulation (and my preferred one), is to define it=20 > concretely, and I have proposed lack of user input as the definition. >=20 > Another point to make here. One of the reasons I much prefer=20 > a concrete=20 > definition, such as lack of user input for X seconds, is that=20 > over time,=20 > presence documents will contain more and more information.=20 > Combing that=20 > information together and producing more condensed statements about a=20 > user (see my response to Dave Boyer on an "available" icon)=20 > can only be=20 > accurately done if the input data is well defined. >=20 > The path I do not think we should take is what you are proposing (I=20 > think) - to define it concretely, but in a different way for each=20 > service. Given our difficulty in clearly enumerating services in a=20 > meaningful way, how can we expect to meaningfully define idle=20 > for each=20 > of those services? >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Oct 4 10:00:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06285; Mon, 4 Oct 2004 10:00:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CETWp-0006V3-1j; Mon, 04 Oct 2004 10:09:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CETMf-0002Kw-6m; Mon, 04 Oct 2004 09:58:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CETJX-0001iU-Mh for simple@megatron.ietf.org; Mon, 04 Oct 2004 09:55:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06097 for ; Mon, 4 Oct 2004 09:55:40 -0400 (EDT) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CETSb-0005Xw-He for simple@ietf.org; Mon, 04 Oct 2004 10:05:07 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i94DtZa00130; Mon, 4 Oct 2004 16:55:35 +0300 (EET DST) X-Scanned: Mon, 4 Oct 2004 16:55:21 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i94DtLRH001158; Mon, 4 Oct 2004 16:55:21 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 002wmPbF; Mon, 04 Oct 2004 16:55:19 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i94DtHY01371; Mon, 4 Oct 2004 16:55:17 +0300 (EET DST) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Oct 2004 16:55:16 +0300 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 4 Oct 2004 16:55:16 +0300 Received: ESEBE054.NOE.Nokia.com 172.21.143.44 from 172.21.39.131 172.21.39.131 via HTTP with MS-WebStorage 6.0.6249 Received: from localhost by ESEBE054.NOE.Nokia.com; 04 Oct 2004 16:55:15 +0300 Subject: Re: [Simple] diffs in presence data model from previous version From: Aki Niemi To: ext Jonathan Rosenberg In-Reply-To: <4159D0E5.6010606@dynamicsoft.com> References: <4159D0E5.6010606@dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1096898115.2684.145.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 04 Oct 2004 16:55:15 +0300 X-OriginalArrivalTime: 04 Oct 2004 13:55:16.0192 (UTC) FILETIME=[C6F2C600:01C4AA19] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit On Wed, 2004-09-29 at 00:00, ext Jonathan Rosenberg wrote: ...snip... > * syntax is now using new and elements, rather than > re-using tuple. It was felt that this was likely to be backwards > compatible with existing PIDF implementations, whereas the previous > approach would not be. It does mean that partial publish and partial > notify specs will need to change, but they are not done yet. That's true, and in fact we've already started a bit of a redesign of the partial format to also address this issue. I'll send another email on the subject later. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Oct 4 13:55:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28526; Mon, 4 Oct 2004 13:55:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEXCZ-0000lm-Rh; Mon, 04 Oct 2004 14:04:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEWv4-0003Ad-FJ; Mon, 04 Oct 2004 13:46:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEWkm-00027H-CJ for simple@megatron.ietf.org; Mon, 04 Oct 2004 13:36:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26752 for ; Mon, 4 Oct 2004 13:36:00 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEWtt-0005JU-7K for simple@ietf.org; Mon, 04 Oct 2004 13:45:30 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i94HZT1i003929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Oct 2004 10:35:30 -0700 (PDT) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i94HZR1I006964; Mon, 4 Oct 2004 10:35:28 -0700 (PDT) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: Date: Mon, 4 Oct 2004 10:35:26 -0700 To: ben@nostrum.com From: Ted Hardie Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: simple@ietf.org Subject: [Simple] Status of 2396bis X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Howdy, There was a question about the status of this draft; basically, 2396bis has passed IETF Last Call and there has been a minor update to it to account for some editorial issues raised; it is on the IESG agenda for October 14th. regards, Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Oct 4 14:14:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29845; Mon, 4 Oct 2004 14:14:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEXVP-0004DA-OB; Mon, 04 Oct 2004 14:24:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEX6G-0006kI-Ev; Mon, 04 Oct 2004 13:58:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEWw4-0003am-FY for simple@megatron.ietf.org; Mon, 04 Oct 2004 13:47:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27791 for ; Mon, 4 Oct 2004 13:47:42 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEX5B-0007SG-1L for simple@ietf.org; Mon, 04 Oct 2004 13:57:10 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 04 Oct 2004 13:47:12 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i94Hl7r5011283; Mon, 4 Oct 2004 13:47:08 -0400 (EDT) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-208.cisco.com [64.100.229.208]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BCL21590; Mon, 4 Oct 2004 10:47:06 -0700 (PDT) Message-Id: <4.3.2.7.2.20041004131952.0353f9f0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 04 Oct 2004 13:45:32 -0400 To: Jonathan Rosenberg From: Mike Hammer Subject: Re: [Simple] Pres Data Model Open Issue #5: what does idle mean? In-Reply-To: <415E1617.5090200@dynamicsoft.com> References: <4.3.2.7.2.20041001104505.00b02d68@cia.cisco.com> <4.3.2.7.2.20040929103449.00b0e058@cia.cisco.com> <4.3.2.7.2.20040929103449.00b0e058@cia.cisco.com> <4.3.2.7.2.20041001104505.00b02d68@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 At 10:44 PM 10/1/2004 -0400, Jonathan Rosenberg wrote: >inline. > >Mike Hammer wrote: > >>At 01:24 AM 10/1/2004 -0400, Jonathan Rosenberg wrote: >> >>>device-idle: The device has received no data input on any of its user >>>input devices that require active input (including keyboards, mice, >>>trackballs, but excluding things like microphones and cameras where >>>there is always "input") >> >>This seems to assume that a human user is always at the other end. > >A human user or something like it, yes. > >>I was thinking that there might be devices (e.g. a large telescope, or >>say an outdoor web cam at a popular ski resort) that could be on-line >>(versus off-line for maintenance) and could be actively serving one >>potential star-gazer or skier, or perhaps idle and available (possibly >>for a small fee). > >Sure. But these things are not communications services, and are not the >types of things we are trying to model with presence documents. I was trying to test out the "or something like it" as an automaton operating some type of service, i.e. streaming of video, versus calling a human and asking what the slopes look like. This is a direct substitution, so I don't know why it wouldn't apply. It is at odds with the human-based examples because automatons are always expected to be present and active and therefore the interpretation of idle may not fit the inferences we apply to humans. >>Note also that being idle in the human user case is giving a clue that >>perhaps, the human is not really there (caveat the cellphone example); > >What does "there" refer to in your text above? The presumption is that if the device is idle for long periods it may be because the user went to lunch, etc.; that is, that he is not *there* by the phone or other communication device (which also presumes he would answer if he was there). I don't think one can make any inference about the likelihood of an answer, short of attempting communication, without including some knowledge outside of what can be indicated in the presence message, such as the personal habits of a particular person. In any case, I agree with the idle since external input to the device approach. Mike >>So, I guess the definition will work. It just moves the definition >>problem to defining what is the user, and what is active input for cases >>where user!=human. Should some "need to define" caution be added for >>those non-human based cases? > >I dont think so. Presence is about communications status of people or >things that have similar properties to people as they relate to usage of >communications systems. > >-Jonathan R. > > >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Chief Technology Officer Parsippany, NJ 07054-2711 >dynamicsoft >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 simple-bounces@ietf.org Mon Oct 4 17:12:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23850; Mon, 4 Oct 2004 17:12:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEaHP-00083O-PQ; Mon, 04 Oct 2004 17:21:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEZ2Z-0007c9-KU; Mon, 04 Oct 2004 16:02:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEYn1-0008Ms-Ah; Mon, 04 Oct 2004 15:46:31 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08830; Mon, 4 Oct 2004 15:46:29 -0400 (EDT) Message-Id: <200410041946.PAA08830@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 04 Oct 2004 15:46:29 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-event-filter-funct-03.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Functional Description of Event Notification Filtering Author(s) : H. Khartabil, et al. Filename : draft-ietf-simple-event-filter-funct-03.txt Pages : 30 Date : 2004-10-4 The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism of how filtering of event notification information can be achieved. This document describes the operations a subscriber performs in order to define filtering rules, how to handle responses to subscriptions carrying filtering rules, and how to handle notifications with filtering rules applied to them. The document also describes how the notifier behaves when receiving such filtering rules and how a notification is constructed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-event-filter-funct-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-event-filter-funct-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-event-filter-funct-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-4152727.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-event-filter-funct-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-event-filter-funct-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-4152727.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Mon Oct 4 17:12:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23912; Mon, 4 Oct 2004 17:12:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEaHk-00084A-AP; Mon, 04 Oct 2004 17:22:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEZ2a-0007cR-9g; Mon, 04 Oct 2004 16:02:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEYmv-0008Kf-Pg; Mon, 04 Oct 2004 15:46:25 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08820; Mon, 4 Oct 2004 15:46:23 -0400 (EDT) Message-Id: <200410041946.PAA08820@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 04 Oct 2004 15:46:23 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-filter-format-03.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : An Extensible Markup Language (XML) Based Format for Event Notification Filtering Author(s) : H. Khartabil, et al. Filename : draft-ietf-simple-filter-format-03.txt Pages : 24 Date : 2004-10-4 The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism of how filtering of event notification information can be achieved. Filtering is a mechanism for defining the preferred notification information to be delivered and for specifying the rules for when that information should be delivered. In order to enable this, a format is needed to enable the subscriber to choose when notifications are to be sent to it and what they are to contain. This document presents a solution in the form of an XML document format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-filter-format-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-filter-format-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-4152719.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-filter-format-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-filter-format-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-4152719.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Tue Oct 5 03:41:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29426; Tue, 5 Oct 2004 03:41:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEk6N-0001Uv-2E; Tue, 05 Oct 2004 03:51:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEjtP-0003kk-O9; Tue, 05 Oct 2004 03:37:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEjst-0003d4-Ab for simple@megatron.ietf.org; Tue, 05 Oct 2004 03:37:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29053 for ; Tue, 5 Oct 2004 03:37:17 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEk1y-0000sb-EQ for simple@ietf.org; Tue, 05 Oct 2004 03:46:52 -0400 Received: from dynamicsoft.com ([63.113.46.15]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i957ampl014233; Tue, 5 Oct 2004 03:36:48 -0400 (EDT) Message-ID: <41624EF9.7050204@dynamicsoft.com> Date: Tue, 05 Oct 2004 03:36:25 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] Pres Data Model Open Issue #1: in-person communications References: <4159D228.5040905@dynamicsoft.com> <4159FB36.9090502@cs.columbia.edu> <415CE1ED.6070900@dynamicsoft.com> <415D7E18.4010700@cs.columbia.edu> <415E0D19.3000101@dynamicsoft.com> <415FC86D.8080909@cs.columbia.edu> In-Reply-To: <415FC86D.8080909@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: >> To be clear here, if we agree that in-person is a service, then >> according to the data model it shows up as a in the presence >> document. includes a element which contains a URI. >> Our preferred vehicle for indicating what the service is, is with the >> URI scheme. Thus, the conundrum. >> >> In cases where the URI is not sufficient (SIP, for example, or HTTP >> for something soap-ish), then you need characteristic information to >> tell you what the service is. > > > One solution is having no URI and a (mandatory) service characteristic. > Here, class of service = (electronic, postal/courier, inperson). A URI > implies 'electronic' service. We can then later add other service types, > such as "remote-acoustic" (bush drums) or "visual" (smoke signals, > semaphores, etc.). I very much doubt we'd want to define URIs for all of > these... Hmm, so I think what you are saying is something like this - the contact URI is absent for services that are not "electronic" in nature and not well represented by a URI. For those, and *only those*, services, we can define a element that enumerates non-electronic forms of communications. > > We agreed that just having "no URI = in-person" is bad, but it seems > inappropriate to define a pseudo-URL scheme that doesn't really > correspond closely with other URL schemes and contains no real > information. With the service label, there is no ambiguity and old PIDF > interpreters won't get confused. > > > >> So you are proposing something like as a presence attribute >> that would simply say to use a postal address? I don't think that fits >> as well really, since the presence attributes in the service are meant >> to characterize the service, not to declare it. > > > Not quite: > > postal > > This is just another characteristic of the service, along with all the > other prescaps and similar characterizations that we already have. I might add that, instead of just a string, the value of could be more structured, and include information on invoking the non-electronic service. In the case of postal, it could contain the reference to the vcard, or the address itself inline: 600 Lanidex Plaza Parsippany NJ 07054 I could live with that. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 simple-bounces@ietf.org Tue Oct 5 03:48:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29904; Tue, 5 Oct 2004 03:48:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEkCZ-0002op-K2; Tue, 05 Oct 2004 03:57:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEk2R-0004yC-Io; Tue, 05 Oct 2004 03:47:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEk0R-0004hL-D5 for simple@megatron.ietf.org; Tue, 05 Oct 2004 03:45:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29695 for ; Tue, 5 Oct 2004 03:45:05 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEk9g-0001t9-MJ for simple@ietf.org; Tue, 05 Oct 2004 03:54:41 -0400 Received: from dynamicsoft.com ([63.113.46.15]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i957ihpl014260; Tue, 5 Oct 2004 03:44:43 -0400 (EDT) Message-ID: <416250D4.1070201@dynamicsoft.com> Date: Tue, 05 Oct 2004 03:44:20 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] Pres Data Model Open Issue #5: what does idle mean? References: <4.3.2.7.2.20040929103449.00b0e058@cia.cisco.com> <415CE9FF.4030205@dynamicsoft.com> <415D8109.6060100@cs.columbia.edu> <415E1532.8000102@dynamicsoft.com> <415FCC30.5040201@cs.columbia.edu> In-Reply-To: <415FCC30.5040201@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: Simple WG , Mike Hammer X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: >> To be honest, I don't see the difference between this an "no user input >> for X minutes". Is there one? > > > No real difference. The definition is just less input-oriented and more > service-oriented. Presumably calls placed and messages sent require some > form of user input. Consider it more like additional examples for services. > >>> >> Henning later wrote: >> >>> Another thought: >>> >>> In many cases, it is probably more informative to say "has been >>> active as recently as ten minutes ago", i.e., the inverse of idle. >>> Even knowing that user Bob sent email or placed a call, both >>> services, a short while ago is quite useful - Bob is probably around >>> and not asleep. (Absence of idle is not as informative as the >>> recipient doesn't know the idle threshold and idle may not be >>> reported at all.) >> >> >> >> Interesting. You could solve half of this by just reporting the idle >> threshold as part of the element. Once you do that, the only >> issue is differentiating lack of an idle indicatiion with active. >> Seems like the same argument could be made for almost any indicator >> that has only a positive indication. >> >> As such, another approach would be to change idle to include both, >> just as can indicate either private or public. Both values >> are included. That would look something like >> >> idle >> active > > > I'd choose a different label, e.g., usage, but that's third-order > nitpicking. > > The general problem is that long idle times have very limited predictive > ability - the probability of reachability dramatically *in*creases after > 15 hours of idle time for most office workers, or, around lunch time, > after 30 minutes to one hour of idle time. > > That would work, but I suspect that without a last-active indication, > this is all of limited use. The three examples combined (short idle time > is useful, gone home, lunch) illustrate that idle/active is helpful > mostly if you know how long this has been active or idle (or you know > more about the person and her timezone) and requires relatively short > reporting intervals. Knowing that somebody was active an hour ago, at > the last NOTIFY, isn't all that helpful. > For the current idle definition, there is a timestamp which includes the time it was last active. I think you are saying that, if you want to include a positive indication of activity, you need a timestamp at which the activity first started as well. That sounds fine to me. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 simple-bounces@ietf.org Tue Oct 5 04:38:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03278; Tue, 5 Oct 2004 04:38:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEkzk-0001yn-FX; Tue, 05 Oct 2004 04:48:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEkov-0007my-UZ; Tue, 05 Oct 2004 04:37:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEkjJ-00076Z-Ss for simple@megatron.ietf.org; Tue, 05 Oct 2004 04:31:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02577 for ; Tue, 5 Oct 2004 04:31:27 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEksY-0000s6-AQ for simple@ietf.org; Tue, 05 Oct 2004 04:41:03 -0400 Received: from razor.cs.columbia.edu (IDENT:GeX7mUHqL4cd/r5ecsPLLudObhnW2qtM@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i958VOx6000112 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 5 Oct 2004 04:31:24 -0400 (EDT) Received: from [127.0.0.1] (IDENT:h4CZeJI/P9bUaLdxZCI1qE6oq5bKfYFX@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i958VLYZ005853; Tue, 5 Oct 2004 04:31:22 -0400 Message-ID: <41625BE0.4010001@cs.columbia.edu> Date: Tue, 05 Oct 2004 04:31:28 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Pres Data Model Open Issue #1: in-person communications References: <4159D228.5040905@dynamicsoft.com> <4159FB36.9090502@cs.columbia.edu> <415CE1ED.6070900@dynamicsoft.com> <415D7E18.4010700@cs.columbia.edu> <415E0D19.3000101@dynamicsoft.com> <415FC86D.8080909@cs.columbia.edu> <41624EF9.7050204@dynamicsoft.com> In-Reply-To: <41624EF9.7050204@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.10.4.6 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit > Hmm, so I think what you are saying is something like this - the contact > URI is absent for services that are not "electronic" in nature and not > well represented by a URI. For those, and *only those*, services, we can > define a element that enumerates non-electronic forms of > communications. Almost. For regularity, the rules would be: - if there is a contact URL, the allowable service class is 'electronic' - if there is a URL but no service-type, service-type 'electronic' is implied - if there is no URL, a service-type element MUST be specified for a conformant document > I might add that, instead of just a string, the value of > could be more structured, and include information on invoking the > non-electronic service. In the case of postal, it could contain the > reference to the vcard, or the address itself inline: > > > > 600 > Lanidex Plaza > Parsippany > NJ > 07054 > > > > > I could live with that. Defining the postal details may well be non-trivial, unless one simply copies some XML-based version of vCard. Thus, expediency suggests referencing the vCard. In practice, the address is pretty constant in time, so a reference seems more efficient as well. This sounds like an RPID addition? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Oct 5 08:15:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20596; Tue, 5 Oct 2004 08:15:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEoN1-000107-Ny; Tue, 05 Oct 2004 08:24:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEoCT-0008DK-Hg; Tue, 05 Oct 2004 08:13:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEo8x-0007f7-FM for simple@megatron.ietf.org; Tue, 05 Oct 2004 08:10:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20357 for ; Tue, 5 Oct 2004 08:10:10 -0400 (EDT) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEoIE-0008Vc-11 for simple@ietf.org; Tue, 05 Oct 2004 08:19:47 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i95C9la02062; Tue, 5 Oct 2004 15:09:47 +0300 (EET DST) X-Scanned: Tue, 5 Oct 2004 15:09:18 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i95C9I5s002031; Tue, 5 Oct 2004 15:09:18 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00TSDnYu; Tue, 05 Oct 2004 15:09:17 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i95C9EY23514; Tue, 5 Oct 2004 15:09:14 +0300 (EET DST) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 5 Oct 2004 15:09:14 +0300 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 5 Oct 2004 15:09:14 +0300 Received: ESEBE054.NOE.Nokia.com 172.21.143.44 from 172.21.39.131 172.21.39.131 via HTTP with MS-WebStorage 6.0.6249 Received: from localhost by ESEBE054.NOE.Nokia.com; 05 Oct 2004 15:09:15 +0300 Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - Byte Ranges in REPORTs From: Aki Niemi To: ext Ben Campbell In-Reply-To: <98E41386-13F7-11D9-B01C-000D93B0AE1A@nostrum.com> References: <41544962.2080509@cisco.com> <5CF97971-13F7-11D9-B01C-000D93B0AE1A@nostrum.com> <98E41386-13F7-11D9-B01C-000D93B0AE1A@nostrum.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1096978154.29657.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 05 Oct 2004 15:09:15 +0300 X-OriginalArrivalTime: 05 Oct 2004 12:09:14.0060 (UTC) FILETIME=[213C38C0:01C4AAD4] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit On Sat, 2004-10-02 at 01:16, ext Ben Campbell wrote: > Oops, I just realized I missed one of Paul's comments. > > Paul suggests there is no value saying what part of a message fails, > only that the whole message fails. I disagree. If a sender learns that > a particular byte-range failed, it may be able to send a new chunk > containing that byte range. I don't get this. We have a protocol that runs on top of a TCP connection, or a chain of TCP connections. The only way a chunk can ever get lost without anyone noticing it hop-by-hop is if someone's input buffer or output buffer is seriously leaking bits. Do we really need to design around that hypothetical condition? Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Oct 5 10:33:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03638; Tue, 5 Oct 2004 10:33:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEqWd-0005io-Eh; Tue, 05 Oct 2004 10:42:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEqJh-0000LO-SV; Tue, 05 Oct 2004 10:29:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEqFf-0008Dd-Ah for simple@megatron.ietf.org; Tue, 05 Oct 2004 10:25:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02878 for ; Tue, 5 Oct 2004 10:25:13 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEqOw-0004Mw-VG for simple@ietf.org; Tue, 05 Oct 2004 10:34:52 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 05 Oct 2004 07:29:29 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i95EOZwp006430; Tue, 5 Oct 2004 07:24:35 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMB15066; Tue, 5 Oct 2004 10:24:39 -0400 (EDT) Message-ID: <4162AEA5.4010704@cisco.com> Date: Tue, 05 Oct 2004 10:24:37 -0400 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: Ben Campbell Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - nits References: <4154491E.5050806@cisco.com> <8148E467-13FA-11D9-B01C-000D93B0AE1A@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > >> The word "insure" is used twice in this document, and in both cases is >> should be "ensure". > > Oops. I usually gripe at _other_ people about that one... I'm just being picky. I'm sure you will return the favor some day. :-) >> Section 6.1.2 says: "An MSRP endpoint MUST be able to generate success >> REPORT requests." But nowhere do I find a comparable statement about >> failure reports. I think the endpoint MUST be able to do both. > > That was not the intent. Endpoints would use transaction responses to > indicate an error. I thought we had discussed that only relays would > normally send failure reports. Oh, I guess that is ok. So and endpoint must be able to send a failure response, but sending failure reports is optional and only needed if it is structured so that it sends a success response and can still later detect an error. >> Section 7.1.5 says: "Instead, MSRP now specifies a default connection >> direction." Its not a default, since you can't change it. I think what >> is meant is: "MSRP now associates connection direction with the >> direction the offer travels." > > it is default, in the sense that we have language (or intended to have > language; Orit indicated it may not be there) to the effect that if > endpoints have some other agreed upon way to negotiate direction, they > can override this. The point was to allow people to use something like > comedia in the future. OK - if there really is the possibility of doing something else. But that does make me a little uncomfortable, because it reeks of private agreements that don't interoperate. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Oct 5 10:54:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05307; Tue, 5 Oct 2004 10:54:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEqrb-0000Wa-GR; Tue, 05 Oct 2004 11:04:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEqbe-0002iA-6z; Tue, 05 Oct 2004 10:47:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEqWR-0001kQ-5d for simple@megatron.ietf.org; Tue, 05 Oct 2004 10:42:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04410 for ; Tue, 5 Oct 2004 10:42:32 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEqfi-0006jF-R7 for simple@ietf.org; Tue, 05 Oct 2004 10:52:12 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 05 Oct 2004 07:46:49 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i95Efuwp016569; Tue, 5 Oct 2004 07:41:57 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMB16659; Tue, 5 Oct 2004 10:41:58 -0400 (EDT) Message-ID: <4162B2B4.6070008@cisco.com> Date: Tue, 05 Oct 2004 10:41:56 -0400 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: Ben Campbell Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - Overlapping Chunks References: <41544958.1040009@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > On Sep 24, 2004, at 11:20 AM, Paul Kyzivat wrote: > >> Section 6.3.1 discusses how to handle the receipt of overlapping chunks, >> specifying that the last received copy of any particular byte wins. I >> don't think this is good. >> >> If the overlapping chunks contain consistent data then it doesn't matter >> which takes precedence. If they contain conflicting data then reordering >> of chunks can affect the result unpredictably. This rule also prevents >> the recipient from rendering a byte when it and all preceding bytes have >> been received. >> >> I think it should be permissible for the recipient to check for >> inconsistency in the overlapping case, and report an error if so. We may >> want to require this checking. (Since it typically won't happen it >> shouldn't have a performance impact.) >> > > I'm not sure on this one. As far as typically not happening, I can > imagine situations where a chunk gets an error report, but still got > delivered. The sender might send a new chunk with that range. I'm having trouble with this scenario, given that we have a reliable transport protocol. The most obvious case that comes to mind for me is loss of the TCP connection. The recovery action in that case is to resignal to establish a replacement connection and then retransmit any chunks that hadn't been confirmed. > Perhaps it would be better to say that, if a sender does this, it MUST > NOT change the data in the range. Yes, I think that would be a good thing to do. And a recipient that recives overlapping data MAY report an error if inconsistent overlapping data is received. (Do we have a suitable error for that?) Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Oct 5 11:05:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05928; Tue, 5 Oct 2004 11:05:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEr1b-0001kS-Gq; Tue, 05 Oct 2004 11:14:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEqrI-0005k1-QN; Tue, 05 Oct 2004 11:04:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEqkd-0004Ro-RX for simple@megatron.ietf.org; Tue, 05 Oct 2004 10:57:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05455 for ; Tue, 5 Oct 2004 10:57:13 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEqtx-0000n4-3E for simple@ietf.org; Tue, 05 Oct 2004 11:06:53 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 05 Oct 2004 08:01:32 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i95Euawr026329; Tue, 5 Oct 2004 07:56:40 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMB18656; Tue, 5 Oct 2004 10:56:38 -0400 (EDT) Message-ID: <4162B624.5080909@cisco.com> Date: Tue, 05 Oct 2004 10:56:36 -0400 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: Ben Campbell Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - Syntax References: <4154496F.2010405@cisco.com> <790D84FF-13FB-11D9-B01C-000D93B0AE1A@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > >> Rohan wanted "?" syntax added. > > I don't understand the statement. We had better check with him, but I believe he wanted the "?" syntax for queries (that http uses) added to the msrp url syntax, so that clients of relays could use that to generate a family of distinct URLs after receiving a single one from the relay. (This is analogous to the use of the grid parameter with GRUUs.) So, I could connect to my friendly neighborhood relay, and get back a url like: msrp://atlanta.example.com:7654/jshA and then establish multiple sessions using things like: msrp://atlanta.example.com:7654/jshA?one msrp://atlanta.example.com:7654/jshA?two Interestingly, I just noticed that section 3 already has an example using: msrp://atlanta.example.com:7654/jshA7we;tcp which isn't legal according to the current syntax. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Oct 5 11:23:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07395; Tue, 5 Oct 2004 11:23:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CErJm-00057Y-3O; Tue, 05 Oct 2004 11:33:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEr7g-00080x-6L; Tue, 05 Oct 2004 11:21:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEr6w-0007sy-BS for simple@megatron.ietf.org; Tue, 05 Oct 2004 11:20:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07070 for ; Tue, 5 Oct 2004 11:20:16 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CErG5-0004E9-9R for simple@ietf.org; Tue, 05 Oct 2004 11:29:56 -0400 Received: from dynamicsoft.com ([63.113.46.15]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i95FJipl015891; Tue, 5 Oct 2004 11:19:45 -0400 (EDT) Message-ID: <4162BB79.8030802@dynamicsoft.com> Date: Tue, 05 Oct 2004 11:19:21 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] Pres Data Model Open Issue #1: in-person communications References: <4159D228.5040905@dynamicsoft.com> <4159FB36.9090502@cs.columbia.edu> <415CE1ED.6070900@dynamicsoft.com> <415D7E18.4010700@cs.columbia.edu> <415E0D19.3000101@dynamicsoft.com> <415FC86D.8080909@cs.columbia.edu> <41624EF9.7050204@dynamicsoft.com> <41625BE0.4010001@cs.columbia.edu> In-Reply-To: <41625BE0.4010001@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: >> Hmm, so I think what you are saying is something like this - the >> contact URI is absent for services that are not "electronic" in nature >> and not well represented by a URI. For those, and *only those*, >> services, we can define a element that enumerates >> non-electronic forms of communications. > > > Almost. For regularity, the rules would be: > > - if there is a contact URL, the allowable service class is 'electronic' > - if there is a URL but no service-type, service-type 'electronic' is > implied > - if there is no URL, a service-type element MUST be specified for a > conformant document I think that this is effectively the same thing. > > >> I might add that, instead of just a string, the value of >> could be more structured, and include information on >> invoking the non-electronic service. In the case of postal, it could >> contain the reference to the vcard, or the address itself inline: >> >> >> >> 600 >> Lanidex Plaza >> Parsippany >> NJ >> 07054 >> >> >> >> >> I could live with that. > > > Defining the postal details may well be non-trivial, unless one simply > copies some XML-based version of vCard. Thus, expediency suggests > referencing the vCard. In practice, the address is pretty constant in > time, so a reference seems more efficient as well. > > This sounds like an RPID addition? Yes and no. The data model would need to be updated to make it clear what the URI means when present, and what it means when its not - look for data in other places to identify the service. RPID should probably define an abstract service-type (we need a different name, though, to make it clear that this is NOT a way to represent that this service is PTT or videophone). Details for in-person and postal could then go anywhere. I would prefer not to increase the scope of the things in rpid; postal is something new, and probably belongs in a separate draft. in-person is debatable since we've sort of had it and sort of not.... I could go either way. Other opinions? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 simple-bounces@ietf.org Tue Oct 5 18:27:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18345; Tue, 5 Oct 2004 18:27:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CExw7-0007KH-M4; Tue, 05 Oct 2004 18:37:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CExk5-0003OZ-CW; Tue, 05 Oct 2004 18:25:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CExfZ-0002L0-4Z for simple@megatron.ietf.org; Tue, 05 Oct 2004 18:20:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17866 for ; Tue, 5 Oct 2004 18:20:25 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CExov-0005zy-F1 for simple@ietf.org; Tue, 05 Oct 2004 18:30:09 -0400 Received: from [192.168.2.11] (64.221.254.66.ptr.us.xo.net [64.221.254.66]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i95MKLww050118 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 5 Oct 2004 17:20:22 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <4162B624.5080909@cisco.com> References: <4154496F.2010405@cisco.com> <790D84FF-13FB-11D9-B01C-000D93B0AE1A@nostrum.com> <4162B624.5080909@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - Syntax Date: Tue, 5 Oct 2004 17:20:18 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit On Oct 5, 2004, at 9:56 AM, Paul Kyzivat wrote: > Ben Campbell wrote: >>> Rohan wanted "?" syntax added. >> I don't understand the statement. > > We had better check with him, but I believe he wanted the "?" syntax > for queries (that http uses) added to the msrp url syntax, so that > clients of relays could use that to generate a family of distinct URLs > after receiving a single one from the relay. (This is analogous to the > use of the grid parameter with GRUUs.) > > So, I could connect to my friendly neighborhood relay, and get back a > url like: > > msrp://atlanta.example.com:7654/jshA > > and then establish multiple sessions using things like: > > msrp://atlanta.example.com:7654/jshA?one > msrp://atlanta.example.com:7654/jshA?two Right. I remember now... > > Interestingly, I just noticed that section 3 already has an example > using: > > msrp://atlanta.example.com:7654/jshA7we;tcp > > which isn't legal according to the current syntax. > I must be missing something--what is illegal about it? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Oct 5 18:42:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19702; Tue, 5 Oct 2004 18:42:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEyAA-0000lP-Nz; Tue, 05 Oct 2004 18:52:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CExql-0004oB-EY; Tue, 05 Oct 2004 18:32:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CExoY-0004KJ-VH for simple@megatron.ietf.org; Tue, 05 Oct 2004 18:29:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18483 for ; Tue, 5 Oct 2004 18:29:43 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CExxv-0007ke-II for simple@ietf.org; Tue, 05 Oct 2004 18:39:28 -0400 Received: from [192.168.2.11] (64.221.254.66.ptr.us.xo.net [64.221.254.66]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i95MSZ8f050657 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 5 Oct 2004 17:28:38 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <4162AEA5.4010704@cisco.com> References: <4154491E.5050806@cisco.com> <8148E467-13FA-11D9-B01C-000D93B0AE1A@nostrum.com> <4162AEA5.4010704@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - nits Date: Tue, 5 Oct 2004 17:28:32 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit On Oct 5, 2004, at 9:24 AM, Paul Kyzivat wrote: [...] >>> Section 7.1.5 says: "Instead, MSRP now specifies a default connection >>> direction." Its not a default, since you can't change it. I think >>> what >>> is meant is: "MSRP now associates connection direction with the >>> direction the offer travels." >> it is default, in the sense that we have language (or intended to >> have language; Orit indicated it may not be there) to the effect that >> if endpoints have some other agreed upon way to negotiate direction, >> they can override this. The point was to allow people to use >> something like comedia in the future. > > OK - if there really is the possibility of doing something else. > > But that does make me a little uncomfortable, because it reeks of > private agreements that don't interoperate. > The intent is to allow us to incorporate some new _standard_ for this, if one appears in the future, not to encourage proprietary agreements. I would be happy to entertain any better language for this. > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Oct 5 18:45:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19870; Tue, 5 Oct 2004 18:45:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEyDU-0001DS-A2; Tue, 05 Oct 2004 18:55:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEy2C-0006eW-OL; Tue, 05 Oct 2004 18:43:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CExqs-0004oM-U2 for simple@megatron.ietf.org; Tue, 05 Oct 2004 18:32:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18743 for ; Tue, 5 Oct 2004 18:32:07 -0400 (EDT) Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEy0F-0007oz-G0 for simple@ietf.org; Tue, 05 Oct 2004 18:41:51 -0400 Received: from [192.168.2.11] (64.221.254.66.ptr.us.xo.net [64.221.254.66]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id i95MW6cG050942 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 5 Oct 2004 17:32:07 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <1096978154.29657.12.camel@localhost.localdomain> References: <41544962.2080509@cisco.com> <5CF97971-13F7-11D9-B01C-000D93B0AE1A@nostrum.com> <98E41386-13F7-11D9-B01C-000D93B0AE1A@nostrum.com> <1096978154.29657.12.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <616F003E-171E-11D9-9DE4-000D93B0AE1A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - Byte Ranges in REPORTs Date: Tue, 5 Oct 2004 17:32:03 -0500 To: Aki Niemi X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit On Oct 5, 2004, at 7:09 AM, Aki Niemi wrote: > On Sat, 2004-10-02 at 01:16, ext Ben Campbell wrote: >> Oops, I just realized I missed one of Paul's comments. >> >> Paul suggests there is no value saying what part of a message fails, >> only that the whole message fails. I disagree. If a sender learns that >> a particular byte-range failed, it may be able to send a new chunk >> containing that byte range. > > I don't get this. We have a protocol that runs on top of a TCP > connection, or a chain of TCP connections. The only way a chunk can > ever > get lost without anyone noticing it hop-by-hop is if someone's input > buffer or output buffer is seriously leaking bits. Do we really need to > design around that hypothetical condition? On reflection, I think I am mostly convinced that you are right. The only case I can think of is when you successfully send a bunch of chunks, the session fails, you signal a new session, and attempt to resend the content. One could be saved the task of sending all the parts that had already been delivered. But I think I agree that this benefit is not worth the additional complexity and statefulness necessary to make it work. > > Cheers, > Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Oct 5 18:49:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20196; Tue, 5 Oct 2004 18:49:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEyHW-000265-0W; Tue, 05 Oct 2004 18:59:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEy2m-0006uf-1c; Tue, 05 Oct 2004 18:44:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CExvT-0005cC-J6 for simple@megatron.ietf.org; Tue, 05 Oct 2004 18:36:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19337 for ; Tue, 5 Oct 2004 18:36:52 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEy4n-0008W2-4d for simple@ietf.org; Tue, 05 Oct 2004 18:46:36 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 05 Oct 2004 18:36:20 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i95MaIED005967; Tue, 5 Oct 2004 18:36:19 -0400 (EDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMB62449; Tue, 5 Oct 2004 18:36:17 -0400 (EDT) Message-ID: <416321E1.3060205@cisco.com> Date: Tue, 05 Oct 2004 18:36:17 -0400 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: Ben Campbell Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - Syntax References: <4154496F.2010405@cisco.com> <790D84FF-13FB-11D9-B01C-000D93B0AE1A@nostrum.com> <4162B624.5080909@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > >> Interestingly, I just noticed that section 3 already has an example >> using: >> >> msrp://atlanta.example.com:7654/jshA7we;tcp >> >> which isn't legal according to the current syntax. >> > > I must be missing something--what is illegal about it? Never mind. I'm just blind today. I guess I had "?" on my mind because I read "jshA7we" as "jshA?we". :-( Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Oct 5 19:10:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22148; Tue, 5 Oct 2004 19:10:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEybL-0005JW-Nd; Tue, 05 Oct 2004 19:20:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEyNV-0002Hc-Kn; Tue, 05 Oct 2004 19:05:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEyH9-0001Xj-AH for simple@megatron.ietf.org; Tue, 05 Oct 2004 18:59:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21155 for ; Tue, 5 Oct 2004 18:59:16 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEyQV-0003Tm-Mh for simple@ietf.org; Tue, 05 Oct 2004 19:09:01 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 05 Oct 2004 16:03:38 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i95MwgEE018600; Tue, 5 Oct 2004 15:58:42 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMB63755; Tue, 5 Oct 2004 18:58:43 -0400 (EDT) Message-ID: <41632723.4040901@cisco.com> Date: Tue, 05 Oct 2004 18:58:43 -0400 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: Ben Campbell Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - Byte Ranges in REPORTs References: <41544962.2080509@cisco.com> <5CF97971-13F7-11D9-B01C-000D93B0AE1A@nostrum.com> <98E41386-13F7-11D9-B01C-000D93B0AE1A@nostrum.com> <1096978154.29657.12.camel@localhost.localdomain> <616F003E-171E-11D9-9DE4-000D93B0AE1A@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: Aki Niemi , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > On Oct 5, 2004, at 7:09 AM, Aki Niemi wrote: > >> On Sat, 2004-10-02 at 01:16, ext Ben Campbell wrote: >> >>> Oops, I just realized I missed one of Paul's comments. >>> >>> Paul suggests there is no value saying what part of a message fails, >>> only that the whole message fails. I disagree. If a sender learns that >>> a particular byte-range failed, it may be able to send a new chunk >>> containing that byte range. >> >> >> I don't get this. We have a protocol that runs on top of a TCP >> connection, or a chain of TCP connections. The only way a chunk can ever >> get lost without anyone noticing it hop-by-hop is if someone's input >> buffer or output buffer is seriously leaking bits. Do we really need to >> design around that hypothetical condition? > > > On reflection, I think I am mostly convinced that you are right. The > only case I can think of is when you successfully send a bunch of > chunks, the session fails, you signal a new session, and attempt to > resend the content. One could be saved the task of sending all the parts > that had already been delivered. But I think I agree that this benefit > is not worth the additional complexity and statefulness necessary to > make it work. The significant case now occurs to me: - we are sending that 7gb Lord of the Rings as one message, and part way through the tcp connection fails somewhere along the way. (Maybe a relay crashed.) - it would be good not to have to retransmit the part that got there. Would prefer to establish a replacement session and just send the part we aren't sure was received. To make this work, the sender needs to have received success reports for fragments. Maybe this is worth supporting them. Of course the recipient is still free to just send a single success report at the end, or it can periodically send reports for arbitrary byte ranges that it has received ok. These wouldn't have to correspond to the actual chunking of the message. One could simple be sent every so often, reflecting what has been received to date. So I think I have talked myself back into liking this for success reports. I'm still not convinced about the value in failure reports, but if the range can be there for one then why not the other? Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Oct 5 19:11:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22306; Tue, 5 Oct 2004 19:11:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEycj-0005js-1e; Tue, 05 Oct 2004 19:21:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEyNX-0002Ja-Jy; Tue, 05 Oct 2004 19:05:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEyI2-0001fw-Io for simple@megatron.ietf.org; Tue, 05 Oct 2004 19:00:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21278 for ; Tue, 5 Oct 2004 19:00:11 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEyRP-0003tb-3j for simple@ietf.org; Tue, 05 Oct 2004 19:09:56 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 05 Oct 2004 16:07:14 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i95MxZEE019336; Tue, 5 Oct 2004 15:59:36 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMB63812; Tue, 5 Oct 2004 18:59:36 -0400 (EDT) Message-ID: <41632759.5070309@cisco.com> Date: Tue, 05 Oct 2004 18:59:37 -0400 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: Ben Campbell Subject: Re: [Simple] Review of draft-ietf-simple-message-sessions-08 - nits References: <4154491E.5050806@cisco.com> <8148E467-13FA-11D9-B01C-000D93B0AE1A@nostrum.com> <4162AEA5.4010704@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > On Oct 5, 2004, at 9:24 AM, Paul Kyzivat wrote: > > [...] > >>>> Section 7.1.5 says: "Instead, MSRP now specifies a default connection >>>> direction." Its not a default, since you can't change it. I think what >>>> is meant is: "MSRP now associates connection direction with the >>>> direction the offer travels." >>> >>> it is default, in the sense that we have language (or intended to >>> have language; Orit indicated it may not be there) to the effect that >>> if endpoints have some other agreed upon way to negotiate direction, >>> they can override this. The point was to allow people to use >>> something like comedia in the future. >> >> >> OK - if there really is the possibility of doing something else. >> >> But that does make me a little uncomfortable, because it reeks of >> private agreements that don't interoperate. >> > > The intent is to allow us to incorporate some new _standard_ for this, > if one appears in the future, not to encourage proprietary agreements. I > would be happy to entertain any better language for this. OK. I'm convinced. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Oct 6 01:34:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21229; Wed, 6 Oct 2004 01:34:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF4aa-0005mK-I6; Wed, 06 Oct 2004 01:43:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF4Nq-0004nD-DJ; Wed, 06 Oct 2004 01:30:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF4MX-0004fu-NV for simple@megatron.ietf.org; Wed, 06 Oct 2004 01:29:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21048 for ; Wed, 6 Oct 2004 01:29:16 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF4Vy-0005cH-Kf for simple@ietf.org; Wed, 06 Oct 2004 01:39:03 -0400 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i965T6pl018793; Wed, 6 Oct 2004 01:29:06 -0400 (EDT) Message-ID: <41636579.6060207@dynamicsoft.com> Date: Tue, 05 Oct 2004 23:24:41 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: meaning of tel URI in presence data model, was: Re: [Simple] Presence Data Model: Identifying services References: <4152EFED.9030206@cisco.com> <1096029424.6605.18.camel@localhost.localdomain> <41542824.1010000@cisco.com> <41543F2A.9070708@dynamicsoft.com> <415474FC.6090809@cisco.com> In-Reply-To: <415474FC.6090809@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: Markus.Isomaki@nokia.com, Aki Niemi , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: > > > Jonathan Rosenberg wrote: > >> >>> Why? There is no particular reason why tel: should mean voice. We >>> don't restrict sip: that way, and http: doesn't say much about what >>> you can do either. (I can use http to exchange html, vxml, xcap, etc.) >>> >>> AFAIK, tel: is an addressing format and namespace. The following is >>> from draft-ietf-iptel-rfc2806bis-09: >>> >>> The "tel" URI telephone number is not restricted in the type of >>> termination point it refers to. The termination point can be in the >>> public telephone network, a private telephone network or the >>> Internet. The termination point can be fixed or wireless and address >>> a fixed wired, mobile or nomadic terminal. The terminal addressed >>> can support any electronic communication service (ECS) including >>> voice, data and fax. >> >> >> >> Sigh... here is another case where the tel URI's confusion about what >> it really is, is getting us into trouble. >> >> If you think about the tel URI as a urn scheme, whereby resolution to >> an actual set of communication resources is done using a resolution >> service (ala DDDS), then it becomes fairly obvious (to me at least) >> that you would simply never even put that URN into the of a >> presence document, since it doesnt represent a communications service >> at all. If anything, it's closer to a presentity identifier. Rather, >> you would put the individual service URIs that result from the DDDS >> lookups. >> >> However, the tel URI is somewhat schizophrenic. Its not a URN, even >> though it can use (but doesnt require) URN-like resolution services >> such as enum. It's like a URN in that it can refer to an abstract name >> and be resolved to a wealth of different URIs of many different >> schemes and services. Its unlike a URN in that it is also used to >> refer to telephone resources, and the implication of the tel URI is >> that "I can dial this from a PSTN phone or enterprise phone and reach >> something". In that aspect, its more like a protocol URI. >> >> What does this mean for presence? To be honest, in the discussion in >> the data model draft, I have assumed the protocol URI meaning. That >> is, it refers to a PSTN (or private network) circuit endpoint, period. >> That, of course, is a BIG assumption, and something we should discuss. >> I would propose that we keep this assumption and merely state it. In >> such a case, it would not make sense for the recipient of a presence >> document to look up such a tel URI in enum. Rather, it knows its a >> telephony resource right away and can "dial it". > > > This feels wrong to me. > > I think it is better viewed as "this CAN be reached via the PSTN, and > MAY also be reachable other ways". At the very least, if I choose to use > this published address, and there are ENUM entries for it, I should be > free to use them (potentially making an e2e sip call). The problem is that it could potentially be ANYTHING, since enum could have a SIP URI, HTTP URI, anything really. Putting the tel URI in the and interpreting it as name is really equivalent to putting the presentity URI into the . The presentity URI is already a layer of indirection - subscribe to it, and it tells you how to reach the user, just like enum does. Why then, add another layer of indirection? Indeed, how could one usefully put attributes into the tuple when the actual service could be anything? > > From a practical perspective, I think this means that if all I have is > a PSTN phone, then I can consider this contact as one to try. If I have > a sip device that supports tel uris and ENUM and has a pstn gateway, > then I can also consider trying this contact. The tuple with this > contact could show support for all sorts of media if it wants, and if my > device supports those media then it might try them as well. I think this ambiguity is going to cause us problems. Unlike other URI, a tel URI based on this definition pretty much tells you NOTHING. What to do with it will be interpreted differently by different watchers. Let me flip it around. I've got a cell phone. Its reachable via the PSTN. What should I put into my presence document to unambigously tell the world that I'm reachable at this service through this particular phone number? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft 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 simple-bounces@ietf.org Wed Oct 6 10:31:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01919; Wed, 6 Oct 2004 10:31:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFCyq-0006UT-W0; Wed, 06 Oct 2004 10:41:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFCkb-0005q8-8f; Wed, 06 Oct 2004 10:26:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFChD-0004tV-EF for simple@megatron.ietf.org; Wed, 06 Oct 2004 10:23:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01047 for ; Wed, 6 Oct 2004 10:23:09 -0400 (EDT) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFCqi-0005vN-8x for simple@ietf.org; Wed, 06 Oct 2004 10:33:01 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i96EFRpw008637 for ; Wed, 6 Oct 2004 09:15:27 -0500 (EST) Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i96EFNpw008529 for ; Wed, 6 Oct 2004 09:15:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: FW: Re: [Simple] Pres Data Model Open Issue #5: what does idle mean? Date: Wed, 6 Oct 2004 10:23:01 -0400 Message-ID: <8CA1128D59AD27429985B397118CEDDF03046336@nj7460avexu1.global.avaya.com> Thread-Topic: Re: [Simple] Pres Data Model Open Issue #5: what does idle mean? Thread-Index: AcSq4dkVzSdeR4YMS26bxif+z6RGnAAzg0Qg From: "Boyer, David G \(Dave\)" To: X-Spam-Score: 0.6 (/) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1015207093==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 This is a multi-part message in MIME format. --===============1015207093== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4ABAF.FC19C661" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4ABAF.FC19C661 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Boyer, David G (Dave)] Johnathan, hmmm. Not sure what the right answer is here - inline > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, October 01, 2004 10:21 PM > To: Boyer, David G (Dave) > Subject: Re: [Simple] Pres Data Model Open Issue #5: what does idle > mean? >=20 >=20 > inline. >=20 > Boyer, David G (Dave) wrote: >=20 > > Jonathan - > >=20 > >=20 > >>service-idle: For a service which receives input while it is=20 > >>the "focus" of the user interaction (focus in the user=20 > >>interface sense), there has been no input. For example, if my=20 > >>IM app is running, but I haven't selected it on my PC, its=20 > >>idle even though I may be typing into another app. > >> > >=20 > > If the IM app is idle long enough it might report "unavailable." >=20 > Are you saying that the IM app would change the =20 > status from open=20 > to close if it detects excessive idle? >=20 Yes. This was actually a customer request we had a few years ago. Some = users are good about updating their availability status ("out to lunch", "in = meeting", etc.), others don't want to be bothered and prefer that the system, after an = appropriate period of idleness, change their status to off-line. >=20 > > If the device (PC in this case) detects typing, even though it is > > in another app, isn't appropriate to treat the IM client as=20 > available? >=20 > Sure. What we're trying to do here is come up with a well-defined=20 > meaning for in the context of devices or services. That doesn't = > imply that any particular definition for service idle MUST have the=20 > property that service idle implies "unavailability". A watcher could=20 > choose to present a single icon to the user indicating=20 > "availability",=20 > and compute that icon locally based on a combination of all of the=20 > information in the presence document. >=20 > That said, in my original post, I had proposed that another=20 > formulation=20 > of idle is that it means that the presentity believes that there is a=20 > high likelihood that attempts to communicate with this service will=20 > result in a no-answer. Perhaps you are arguing that we should define=20 > idle in that fashion? This is tricky. On the one hand, if the user is typing at their = computer=20 (checking their email first thing in the morning) you could argue that all applications that have a status to be closed should have it changed to open. If each application is not checking for keyboard/mouse activity, how is it going to be possible = to do this? The Presence server will only know that the Service basic state is = closed, the user may have set it that way, or it could have been set by the = application when it reaches it's idle threshold. Not sure what the answer is. Seems you need to know what entity set the status to make this decision. dave >=20 >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 =20 ------_=_NextPart_001_01C4ABAF.FC19C661 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: Re: [Simple] Pres Data Model Open Issue #5: what does idle = mean?

[Boyer, David G = (Dave)]  Johnathan,

hmmm.
Not sure what the right answer = is here - inline

> -----Original = Message-----
> From: Jonathan Rosenberg = [mailto:jdrosen@dynamicsoft.com]
> Sent: Friday, October 01, = 2004 10:21 PM
> To: Boyer, David G = (Dave)
> Subject: Re: [Simple] Pres = Data Model Open Issue #5: what does idle
> mean?
>
>
> inline.
>
> Boyer, David G (Dave) = wrote:
>
> > Jonathan -
> >
> >
> >>service-idle: For a = service which receives input while it is
> >>the = "focus" of the user interaction (focus in the user
> >>interface sense), = there has been no input. For example, if my
> >>IM app is running, = but I haven't selected it on my PC, its
> >>idle even though I = may be typing into another app.
> >>
> >
> > If the IM app is idle = long enough it might report "unavailable."
>
> Are you saying that the IM = app would change the <basic>
> status from open
> to close if it detects = excessive idle?
>
Yes.  This was actually a = customer request we had a few years ago.  Some users are
good about updating their = availability status ("out to lunch", "in meeting", = etc.),
others don't want to be bothered = and prefer that the system, after an appropriate
period of idleness, change their = status to off-line.

>
> > If the device (PC in = this case) detects typing, even though it is
> > in another app, isn't = appropriate to treat the IM client as
> available?
>
> Sure. What we're trying to = do here is come up with a well-defined
> meaning for <idle> in = the context of devices or services. That doesn't
> imply that any particular = definition for service idle MUST have the
> property that service idle = implies "unavailability". A watcher could
> choose to present a single = icon to the user indicating
> "availability", =
> and compute that icon = locally based on a combination of all of the
> information in the presence = document.
>
> That said, in my original = post, I had proposed that another
> formulation
> of idle is that it means = that the presentity believes that there is a
> high likelihood that = attempts to communicate with this service will
> result in a no-answer. = Perhaps you are arguing that we should define
> idle in that = fashion?

This is tricky.  On the one = hand, if the user is typing at their computer
(checking their email first = thing in the morning) you
could argue that all = applications that have a <basic> status to be
closed should have it = changed  to open.  If each application is
not checking for keyboard/mouse = activity, how is it going to be possible to do this?
The Presence server will only = know that the Service basic state is closed,
the user may have set it that = way, or it could have been set by the application when
it reaches it's idle = threshold.
Not sure what the answer = is.  Seems you need to know what entity set
the <basic> status to make = this decision.

dave

>
>
> -Jonathan R.
> --
> Jonathan D. Rosenberg, = Ph.D.           &n= bsp;    600 Lanidex Plaza
> Chief Technology = Officer           =          Parsippany, NJ = 07054-2711
> dynamicsoft
> = jdrosen@dynamicsoft.com        &n= bsp;            = FAX:   (973) 952-5050
> http://www.jdrosen.net  &nb= sp;           &nbs= p;       PHONE: (973) 952-5000
> http://www.dynamicsoft.com=
>
>


     

------_=_NextPart_001_01C4ABAF.FC19C661-- --===============1015207093== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1015207093==-- From simple-bounces@ietf.org Wed Oct 6 10:41:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02962; Wed, 6 Oct 2004 10:41:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFD8L-00078O-ND; Wed, 06 Oct 2004 10:51:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFCvU-0000OA-4O; Wed, 06 Oct 2004 10:37:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFCsB-00089n-2y for simple@megatron.ietf.org; Wed, 06 Oct 2004 10:34:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02382 for ; Wed, 6 Oct 2004 10:34:28 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFD1g-0006g8-Kp for simple@ietf.org; Wed, 06 Oct 2004 10:44:21 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 06 Oct 2004 07:38:55 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i96EXrwp016840; Wed, 6 Oct 2004 07:33:54 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMB96637; Wed, 6 Oct 2004 10:33:51 -0400 (EDT) Message-ID: <4164024F.1080808@cisco.com> Date: Wed, 06 Oct 2004 10:33:51 -0400 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 Subject: Re: meaning of tel URI in presence data model, was: Re: [Simple] Presence Data Model: Identifying services References: <4152EFED.9030206@cisco.com> <1096029424.6605.18.camel@localhost.localdomain> <41542824.1010000@cisco.com> <41543F2A.9070708@dynamicsoft.com> <415474FC.6090809@cisco.com> <41636579.6060207@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit Cc: Markus.Isomaki@nokia.com, Aki Niemi , SIMPLE WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > inline. > > Paul Kyzivat wrote: > >> Jonathan Rosenberg wrote: >> >>>> Why? There is no particular reason why tel: should mean voice. We >>>> don't restrict sip: that way, and http: doesn't say much about what >>>> you can do either. (I can use http to exchange html, vxml, xcap, etc.) >>>> >>>> AFAIK, tel: is an addressing format and namespace. The following is >>>> from draft-ietf-iptel-rfc2806bis-09: >>>> >>>> The "tel" URI telephone number is not restricted in the type of >>>> termination point it refers to. The termination point can be in the >>>> public telephone network, a private telephone network or the >>>> Internet. The termination point can be fixed or wireless and address >>>> a fixed wired, mobile or nomadic terminal. The terminal addressed >>>> can support any electronic communication service (ECS) including >>>> voice, data and fax. >>> >>> Sigh... here is another case where the tel URI's confusion about what >>> it really is, is getting us into trouble. >>> >>> If you think about the tel URI as a urn scheme, whereby resolution to >>> an actual set of communication resources is done using a resolution >>> service (ala DDDS), then it becomes fairly obvious (to me at least) >>> that you would simply never even put that URN into the of a >>> presence document, since it doesnt represent a communications service >>> at all. If anything, it's closer to a presentity identifier. Rather, >>> you would put the individual service URIs that result from the DDDS >>> lookups. >>> >>> However, the tel URI is somewhat schizophrenic. Its not a URN, even >>> though it can use (but doesnt require) URN-like resolution services >>> such as enum. It's like a URN in that it can refer to an abstract >>> name and be resolved to a wealth of different URIs of many different >>> schemes and services. Its unlike a URN in that it is also used to >>> refer to telephone resources, and the implication of the tel URI is >>> that "I can dial this from a PSTN phone or enterprise phone and reach >>> something". In that aspect, its more like a protocol URI. >>> >>> What does this mean for presence? To be honest, in the discussion in >>> the data model draft, I have assumed the protocol URI meaning. That >>> is, it refers to a PSTN (or private network) circuit endpoint, >>> period. That, of course, is a BIG assumption, and something we should >>> discuss. I would propose that we keep this assumption and merely >>> state it. In such a case, it would not make sense for the recipient >>> of a presence document to look up such a tel URI in enum. Rather, it >>> knows its a telephony resource right away and can "dial it". >> >> This feels wrong to me. >> >> I think it is better viewed as "this CAN be reached via the PSTN, and >> MAY also be reachable other ways". At the very least, if I choose to >> use this published address, and there are ENUM entries for it, I >> should be free to use them (potentially making an e2e sip call). > > The problem is that it could potentially be ANYTHING, since enum could > have a SIP URI, HTTP URI, anything really. Putting the tel URI in the > and interpreting it as name is really equivalent to putting > the presentity URI into the . The presentity URI is already a > layer of indirection - subscribe to it, and it tells you how to reach > the user, just like enum does. Why then, add another layer of indirection? We *already* allow further layers of indirection - the contact can be a SIP AOR. And I am permitted to register all sorts of URIs to an AOR, including http and mailto. So this isn't new. > Indeed, how could one usefully put attributes into the tuple when the > actual service could be anything? You put the attributes you want to advertise. They should be attributes that are realizable via that address. >> From a practical perspective, I think this means that if all I have >> is a PSTN phone, then I can consider this contact as one to try. If I >> have a sip device that supports tel uris and ENUM and has a pstn >> gateway, then I can also consider trying this contact. The tuple with >> this contact could show support for all sorts of media if it wants, >> and if my device supports those media then it might try them as well. > > I think this ambiguity is going to cause us problems. Unlike other URI, > a tel URI based on this definition pretty much tells you NOTHING. Not too far from what a SIP uri tells you. :-) That is why capabilities are important. > What > to do with it will be interpreted differently by different watchers. Within the bounds of what the capabilities say. I think this is goodness. I certainly don't think there should be any problem because a watcher with a PSTN phone makes a PSTN call, while a watcher with a sip phone uses enum and then makes a sip call. > Let me flip it around. I've got a cell phone. Its reachable via the > PSTN. What should I put into my presence document to unambigously tell > the world that I'm reachable at this service through this particular > phone number? You should put a tel: contact, and also capability descriptions for at least voice and whatever else the phone can do concurrently in a session via the tel address. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Oct 6 12:45:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11517; Wed, 6 Oct 2004 12:45:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFF42-0006ec-MY; Wed, 06 Oct 2004 12:54:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFEqv-00012D-UN; Wed, 06 Oct 2004 12:41:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFElH-0000F6-A5 for simple@megatron.ietf.org; Wed, 06 Oct 2004 12:35:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11081 for ; Wed, 6 Oct 2004 12:35:28 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFEun-00064l-Qc for simple@ietf.org; Wed, 06 Oct 2004 12:45:22 -0400 Received: from razor.cs.columbia.edu (IDENT:wQHZDBYAn2+wyJyYoE8Pou89MCNXvFWI@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i96GWNx6002263 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 6 Oct 2004 12:32:24 -0400 (EDT) Received: from UBAHN (IDENT:9rLca8puoB/mfHObpLXSmfcsdazbIYXp@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.10/8.12.10) with SMTP id i96GWKYZ016776; Wed, 6 Oct 2004 12:32:21 -0400 Message-ID: <013101c4abc2$0e916030$4300a8c0@UBAHN> From: "Henning Schulzrinne" To: "Boyer, David G \(Dave\)" , References: <8CA1128D59AD27429985B397118CEDDF03046336@nj7460avexu1.global.avaya.com> Subject: Re: Re: [Simple] Pres Data Model Open Issue #5: what does idle mean? Date: Wed, 6 Oct 2004 12:32:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.10.5.6 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_MSMAIL_PRI 0, __HAS_X_MAILER 0, __HAS_X_PRIORITY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit FW: Re: [Simple] Pres Data Model Open Issue #5: what does idle mean?On some systems, activity for all applications monitors the equivalent of /dev/kbd, rather than input to a particular application. This may not always be possible. But I suppose one could distinguish between "direct" activity ('user input to this application') and inferred activity ('system/device that hosts the service has shown user input'). ------------ This is tricky. On the one hand, if the user is typing at their computer (checking their email first thing in the morning) you could argue that all applications that have a status to be closed should have it changed to open. If each application is not checking for keyboard/mouse activity, how is it going to be possible to do this? The Presence server will only know that the Service basic state is closed, the user may have set it that way, or it could have been set by the application when it reaches it's idle threshold. Not sure what the answer is. Seems you need to know what entity set the status to make this decision. dave > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Oct 7 04:15:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21763; Thu, 7 Oct 2004 04:15:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFTaL-00023D-Gk; Thu, 07 Oct 2004 04:25:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFTP5-0002WD-JD; Thu, 07 Oct 2004 04:13:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFTI5-00019a-RD for simple@megatron.ietf.org; Thu, 07 Oct 2004 04:06:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21405 for ; Thu, 7 Oct 2004 04:06:19 -0400 (EDT) Received: from [62.119.82.41] (helo=mailserver.hotsip.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFTRk-0001WB-QC for simple@ietf.org; Thu, 07 Oct 2004 04:16:21 -0400 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" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Oct 2004 10:03:51 +0200 Message-ID: Thread-Topic: About tuple ids and namespaces in presence data model Thread-Index: AcSsRC4E3xk1zDd3TLevNU253MG5Aw== From: "Dag Ekengren" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Subject: [Simple] About tuple ids and namespaces in presence data model X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable First of all, I would like to thank Rosenberg for his initiative with, draft-ietf-simple-presence-data-model-00. I think the model is very useful. I have a few questions that I hope you can shed some light on. 1. Please correct me where I have gotten this wrong: About the id attribute of the service tuple. If I remember correctly, when reading about tuple-ids some time ago, the id needs only be unique within the pidf document. It is used to detect if a tuple has been removed or a new tuple has been added when refreshing the pidf document. To uniquely identify a tuple on the presence server, you would need to combine the etag (if PUBLISH was used) with the tuple id. So it is perfectly valid to have tuple-ids like let's say "1", "2" and "3" in a pidf document. The tuple id in the notification generated by the presence server can be something completely different. So a publisher that is also a watcher to its own presentity cannot determine if a tuple in a notification is "his" tuple. This would be difficult anyway with splitting/merging and so on. If service tuple were required to have contact uri:s, I guess the tuple-id would be unnecessary. But that would be incompatible with RFC 3863. 2. The new elements "person" and "device". I would like to put a note on the device, would the note element be from the pidf namespace or do you imagine that this element would be added to the urn:ietf:params:xml:ns:pidf:person namespace? RFC 3863 says that a tuple element can have optional note elements, but the person and device elements aren't tuples, at least they aren't called . Should it be possible to use the RPID attributes within these elements? In the examples there are activity elements, but it isn't clear what namespace they are picked from. My guess is that these are indeed the from the RPID namespace. 3. Small comment on the samples: the prescaps for audio looks like this in draft-ietf-simple-prescaps-ext-01: , but in the presence model samples it is expressed as