From simple-bounces@ietf.org Thu Jun 01 04:47:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fliq9-00016U-6D; Thu, 01 Jun 2006 04:47:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fliq7-00016P-PC for simple@ietf.org; Thu, 01 Jun 2006 04:47:35 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fliq5-00055E-T6 for simple@ietf.org; Thu, 01 Jun 2006 04:47:35 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J06009FFBF8OL@szxga02-in.huawei.com> for simple@ietf.org; Thu, 01 Jun 2006 16:54:45 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J06000N5BF82G@szxga02-in.huawei.com> for simple@ietf.org; Thu, 01 Jun 2006 16:54:44 +0800 (CST) Received: from m24697A ([10.164.120.209]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J060038WB6NIS@szxml04-in.huawei.com> for simple@ietf.org; Thu, 01 Jun 2006 16:49:36 +0800 (CST) Date: Thu, 01 Jun 2006 16:39:28 +0800 From: Lunjian Mu Subject: some confusion//Re: [Simple] I-D ACTION:draft-ietf-simple-imdn-00.txt To: simple@ietf.org Message-id: <002a01c68556$e52c5f90$d178a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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: , Errors-To: simple-bounces@ietf.org Hi Burger & Khartabil, I have some confusion about the draft: 1.in MSRP section, it said: " For SEND requests that are IMDNs, the sender MUST NOT request a delivery report (an MSRP REPORT to a SEND request). I.e. It MUST populate the request with a Failure-Report header field with the value "no" and with a Success-Report header field with value "no" (or alternatively leave out that header field since it defaults to "no").". I do not know what the reason is? By my understanding the SIP MESSAGE can support that both delivery report and IMDN can be requested in a SIP MESSAGE. 2.After the MSRP SEND have request a read report and the response is not come, but the MSRP channel is disconnented, how the receiver can response the read report? can using SIP MESSAGE, or reconnet the MSRP channel? It is common scenario for Store and Forward IM. Best regards, Lunjian Mu ----- Original Message ----- From: To: Cc: Sent: Wednesday, May 31, 2006 6:50 AM Subject: [Simple] I-D ACTION:draft-ietf-simple-imdn-00.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. > > Title : Instant Message Disposition Notification > Author(s) : E. Burger, H. Khartabil > Filename : draft-ietf-simple-imdn-00.txt > Pages : 27 > Date : 2006-5-30 > > Instant Messaging (IM) refers to the transfer of messages between > users in real-time. > > This document extends Message/CPIM message format to enable endpoints > to request, create and send IM Disposition Notifications (IMDN), > including delivery and read notifications, for page-mode as well as > session mode instant messages. This document also describes how SIP > and MSRP entities behave using this extension. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-00.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-imdn-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-simple-imdn-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > 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 Thu Jun 01 17:30:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlukB-0007ok-Bl; Thu, 01 Jun 2006 17:30:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlukA-0007mo-F4 for simple@ietf.org; Thu, 01 Jun 2006 17:30:14 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fluk9-0006As-5s for simple@ietf.org; Thu, 01 Jun 2006 17:30:14 -0400 Received: from [172.20.32.201] ([198.181.231.9]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k51LU7ke009039 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 1 Jun 2006 17:30:07 -0400 (EDT) In-Reply-To: <953beacc0605311601x17c4fdbav88e4e5b40b286da7@mail.gmail.com> References: <4478E5A7.7050604@cs.columbia.edu> <953beacc0605311601x17c4fdbav88e4e5b40b286da7@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4B8E9319-FCD3-42A8-84AB-CC9677790509@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Simple] Question on Presence Data Model draft Date: Thu, 1 Jun 2006 17:30:05 -0400 To: Rohan Mahy X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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: , Errors-To: simple-bounces@ietf.org [Chiming in since Vishal's project is in my lab.] On May 31, 2006, at 7:01 PM, Rohan Mahy wrote: > Hi Vishal, > > I'm assuming that the vehicle is a tuple for a human presentity--that > the car doesn't have its own resource/presentity name. > Indeed; it's used as an adjunct to a person (in our case repair technicians in a truck). The basic question is whether this should be treated as: - person-associated information (under ) - a (although it is not necessarily a communication device) Maybe a combination would be best, depending on the nature of the information. > I don't think ignition is really orthogonal to movement status. I > think you want a rich presence indicator of movement within the tuple > representing the vehicle. The lock status might be relevant here as > well. What you are probably trying to determine is 1) a state of > occupancy, and 2) a state of distraction. Keep in mind that many > hybrids don't require use of an ignition switch. I think these work > for automobiles and trucks, but not for other types of vehicles: > > - parked locked (vehicle off) > - parked unlocked (vehicle off) > - standing (vehicle ready - idling/enabled) > - stopped (vehicle not moving, but in a driving "gear") > - under-way (vehicle in motion) > > You probably don't want fuel status. Projected range is probably more > interesting. 1 liter of fuel in a Prius vs. 1 liter in a Hummer makes > a big difference in range. It's just a lot harder to estimate this. I think at least for published information, having raw information seems more useful, maybe along with information about the vehicle type. (I'm actually not quite sure what this information might be used for, but maybe it is useful for OnStar-style systems if a guy with a gas canister needs to be dispatched.) > > The car stereo is often an interesting contributor to presence. Some > cars even allow you to turn on the stereo with the ignition off. As a > student I used to sit in my car while studying, because the stereo was > better there. Be aware that many car stereos are easily heard (and > listened to) outside the vehicle. There are IM/presence systems that display what song you're currently listening to. > > Finally, if one or more of the seat belts are on this is probably a > pretty reliable indicator of the presence of a human. Unfortunately, > not having seat belts on is not a reliable indicator that there are > *not* humans in the car. Most modern cars have weight sensors at least in their front seats, to tune the behavior of air bags. While absence of passengers in the front seat does not indicate an empty car, it might indicate a situation where the occupants are looking for privacy. It would be interesting to find out what information standard vehicle monitoring systems expose. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 01 18:02:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlvFh-0004bl-IS; Thu, 01 Jun 2006 18:02:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlvFf-0004bg-LZ for simple@ietf.org; Thu, 01 Jun 2006 18:02:47 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlvFd-0001GP-40 for simple@ietf.org; Thu, 01 Jun 2006 18:02:47 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 01 Jun 2006 15:02:38 -0700 X-IronPort-AV: i="4.05,199,1146466800"; d="scan'208"; a="287317792:sNHT10479053172" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k51M2bSJ021227; Thu, 1 Jun 2006 15:02:38 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k51M2bku028440; Thu, 1 Jun 2006 18:02:37 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Jun 2006 18:02:37 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Jun 2006 18:02:37 -0400 Message-ID: <447F63FC.6010908@cisco.com> Date: Thu, 01 Jun 2006 18:02:36 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] Question on Presence Data Model draft References: <4478E5A7.7050604@cs.columbia.edu> <953beacc0605311601x17c4fdbav88e4e5b40b286da7@mail.gmail.com> <4B8E9319-FCD3-42A8-84AB-CC9677790509@cs.columbia.edu> In-Reply-To: <4B8E9319-FCD3-42A8-84AB-CC9677790509@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jun 2006 22:02:37.0167 (UTC) FILETIME=[17D837F0:01C685C7] DKIM-Signature: a=rsa-sha1; q=dns; l=3807; t=1149199358; x=1150063358; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Simple]=20Question=20on=20Presence=20Data=20Model=20draft; X=v=3Dcisco.com=3B=20h=3DOY+L3ECsWmg4xbXSLEYoo6S5mK0=3D; b=qnk0dNPREuubFr1YGEm6PusB+6ufslhLiLiE85TIQ39Nsvj1MP7Oy15UNol24CC7M6CphTFt 831mOAndy1WbRV/VGRDichmRwFjxK93c7KPRs+AXVoAa5SUVbv5Eyhim; Authentication-Results: sj-dkim-4.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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: , Errors-To: simple-bounces@ietf.org I may be missing how this is supposed to be used. - Does the car know who (which presentities) are present within, so that it can report presence status about them? - or does some independent element associated with a known presentity query the attributes of the car and then report that as presence status of the associated presentity? (E.g. when I use the car I dock my cell phone. It then picks up and reports the car status as part of my presence.) - or is there a unique presentity associated with the car, regardless of who is within? (This would seem to be the case with OnStar.) Paul Henning Schulzrinne wrote: > [Chiming in since Vishal's project is in my lab.] > > On May 31, 2006, at 7:01 PM, Rohan Mahy wrote: > >> Hi Vishal, >> >> I'm assuming that the vehicle is a tuple for a human presentity--that >> the car doesn't have its own resource/presentity name. >> > > Indeed; it's used as an adjunct to a person (in our case repair > technicians in a truck). > > The basic question is whether this should be treated as: > > - person-associated information (under ) > - a (although it is not necessarily a communication device) > > Maybe a combination would be best, depending on the nature of the > information. > >> I don't think ignition is really orthogonal to movement status. I >> think you want a rich presence indicator of movement within the tuple >> representing the vehicle. The lock status might be relevant here as >> well. What you are probably trying to determine is 1) a state of >> occupancy, and 2) a state of distraction. Keep in mind that many >> hybrids don't require use of an ignition switch. I think these work >> for automobiles and trucks, but not for other types of vehicles: >> >> - parked locked (vehicle off) >> - parked unlocked (vehicle off) >> - standing (vehicle ready - idling/enabled) >> - stopped (vehicle not moving, but in a driving "gear") >> - under-way (vehicle in motion) >> >> You probably don't want fuel status. Projected range is probably more >> interesting. 1 liter of fuel in a Prius vs. 1 liter in a Hummer makes >> a big difference in range. > > It's just a lot harder to estimate this. I think at least for published > information, having raw information seems more useful, maybe along with > information about the vehicle type. (I'm actually not quite sure what > this information might be used for, but maybe it is useful for > OnStar-style systems if a guy with a gas canister needs to be dispatched.) > >> >> The car stereo is often an interesting contributor to presence. Some >> cars even allow you to turn on the stereo with the ignition off. As a >> student I used to sit in my car while studying, because the stereo was >> better there. Be aware that many car stereos are easily heard (and >> listened to) outside the vehicle. > > There are IM/presence systems that display what song you're currently > listening to. > >> >> Finally, if one or more of the seat belts are on this is probably a >> pretty reliable indicator of the presence of a human. Unfortunately, >> not having seat belts on is not a reliable indicator that there are >> *not* humans in the car. > > Most modern cars have weight sensors at least in their front seats, to > tune the behavior of air bags. While absence of passengers in the front > seat does not indicate an empty car, it might indicate a situation where > the occupants are looking for privacy. > > It would be interesting to find out what information standard vehicle > monitoring systems expose. > > > > _______________________________________________ > 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 Jun 02 01:22:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm27A-00089V-MG; Fri, 02 Jun 2006 01:22:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm278-00089Q-PO for simple@ietf.org; Fri, 02 Jun 2006 01:22:26 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm276-00066n-4E for simple@ietf.org; Fri, 02 Jun 2006 01:22:26 -0400 Received: by ug-out-1314.google.com with SMTP id m3so376066uge for ; Thu, 01 Jun 2006 22:22:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=E1xyRbMmicb/2k8VaYojwiMcTkiVu3gvE2JWLW8Ytko2eJSO2kBQH/F7kS5fWdWhUDeD6G3Vdf0nWVYwpSlA16TivBkFEbWnPluYH2E0UiokfkDajfD+k/MDg+DFZCMfWR3VAaMXcxrqrsp0cjgD5W+LrdyUzxKvj8K0UwytR30= Received: by 10.66.216.6 with SMTP id o6mr421758ugg; Thu, 01 Jun 2006 22:22:22 -0700 (PDT) Received: by 10.66.240.1 with HTTP; Thu, 1 Jun 2006 22:22:22 -0700 (PDT) Message-ID: <60b4a2350606012222v5b3f06e2o3872439ccb260615@mail.gmail.com> Date: Fri, 2 Jun 2006 10:52:22 +0530 From: "Gadigeppa Malagund" To: simple@ietf.org Subject: Re: [Simple] Question on Presence Data Model draft In-Reply-To: <447F63FC.6010908@cisco.com> MIME-Version: 1.0 References: <4478E5A7.7050604@cs.columbia.edu> <953beacc0605311601x17c4fdbav88e4e5b40b286da7@mail.gmail.com> <4B8E9319-FCD3-42A8-84AB-CC9677790509@cs.columbia.edu> <447F63FC.6010908@cisco.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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="===============1223000350==" Errors-To: simple-bounces@ietf.org --===============1223000350== Content-Type: multipart/alternative; boundary="----=_Part_3021_4246857.1149225742714" ------=_Part_3021_4246857.1149225742714 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Here is user of presentity is car, so information can be placed under . This also indicates location of the presence source, a part of the information can also be included in . Regards, Gadi On 6/2/06, Paul Kyzivat wrote: > > I may be missing how this is supposed to be used. > > - Does the car know who (which presentities) are present within, so that > it can report presence status about them? > > - or does some independent element associated with a known presentity > query the attributes of the car and then report that as presence status > of the associated presentity? (E.g. when I use the car I dock my cell > phone. It then picks up and reports the car status as part of my > presence.) > > - or is there a unique presentity associated with the car, regardless of > who is within? (This would seem to be the case with OnStar.) > > Paul > > Henning Schulzrinne wrote: > > [Chiming in since Vishal's project is in my lab.] > > > > On May 31, 2006, at 7:01 PM, Rohan Mahy wrote: > > > >> Hi Vishal, > >> > >> I'm assuming that the vehicle is a tuple for a human presentity--that > >> the car doesn't have its own resource/presentity name. > >> > > > > Indeed; it's used as an adjunct to a person (in our case repair > > technicians in a truck). > > > > The basic question is whether this should be treated as: > > > > - person-associated information (under ) > > - a (although it is not necessarily a communication device) > > > > Maybe a combination would be best, depending on the nature of the > > information. > > > >> I don't think ignition is really orthogonal to movement status. I > >> think you want a rich presence indicator of movement within the tuple > >> representing the vehicle. The lock status might be relevant here as > >> well. What you are probably trying to determine is 1) a state of > >> occupancy, and 2) a state of distraction. Keep in mind that many > >> hybrids don't require use of an ignition switch. I think these work > >> for automobiles and trucks, but not for other types of vehicles: > >> > >> - parked locked (vehicle off) > >> - parked unlocked (vehicle off) > >> - standing (vehicle ready - idling/enabled) > >> - stopped (vehicle not moving, but in a driving "gear") > >> - under-way (vehicle in motion) > >> > >> You probably don't want fuel status. Projected range is probably more > >> interesting. 1 liter of fuel in a Prius vs. 1 liter in a Hummer makes > >> a big difference in range. > > > > It's just a lot harder to estimate this. I think at least for published > > information, having raw information seems more useful, maybe along with > > information about the vehicle type. (I'm actually not quite sure what > > this information might be used for, but maybe it is useful for > > OnStar-style systems if a guy with a gas canister needs to be > dispatched.) > > > >> > >> The car stereo is often an interesting contributor to presence. Some > >> cars even allow you to turn on the stereo with the ignition off. As a > >> student I used to sit in my car while studying, because the stereo was > >> better there. Be aware that many car stereos are easily heard (and > >> listened to) outside the vehicle. > > > > There are IM/presence systems that display what song you're currently > > listening to. > > > >> > >> Finally, if one or more of the seat belts are on this is probably a > >> pretty reliable indicator of the presence of a human. Unfortunately, > >> not having seat belts on is not a reliable indicator that there are > >> *not* humans in the car. > > > > Most modern cars have weight sensors at least in their front seats, to > > tune the behavior of air bags. While absence of passengers in the front > > seat does not indicate an empty car, it might indicate a situation where > > the occupants are looking for privacy. > > > > It would be interesting to find out what information standard vehicle > > monitoring systems expose. > > > > > > > > _______________________________________________ > > 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 > ------=_Part_3021_4246857.1149225742714 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Here is user of presentity is car, so information can be placed under <person>.
This also indicates location of the presence source, a part of the information can also be included in <device>.

Regards,
Gadi

On 6/2/06, Paul Kyzivat <pkyzivat@cisco.com> wrote:
I may be missing how this is supposed to be used.

- Does the car know who (which presentities) are present within, so that
it can report presence status about them?

- or does some independent element associated with a known presentity
query the attributes of the car and then report that as presence status
of the associated presentity? (E.g. when I use the car I dock my cell
phone. It then picks up and reports the car status as part of my presence.)

- or is there a unique presentity associated with the car, regardless of
who is within? (This would seem to be the case with OnStar.)

        Paul

Henning Schulzrinne wrote:
> [Chiming in since Vishal's project is in my lab.]
>
> On May 31, 2006, at 7:01 PM, Rohan Mahy wrote:
>
>> Hi Vishal,
>>
>> I'm assuming that the vehicle is a tuple for a human presentity--that
>> the car doesn't have its own resource/presentity name.
>>
>
> Indeed; it's used as an adjunct to a person (in our case repair
> technicians in a truck).
>
> The basic question is whether this should be treated as:
>
> - person-associated information (under <person>)
> - a <device> (although it is not necessarily a communication device)
>
> Maybe a combination would be best, depending on the nature of the
> information.
>
>> I don't think ignition is really orthogonal to movement status.  I
>> think you want a rich presence indicator of movement within the tuple
>> representing the vehicle.  The lock status might be relevant here as
>> well.  What you are probably trying to determine is 1) a state of
>> occupancy, and 2) a state of distraction. Keep in mind that many
>> hybrids don't require use of an ignition switch.  I think these work
>> for automobiles and trucks, but not for other types of vehicles:
>>
>> - parked locked (vehicle off)
>> - parked unlocked (vehicle off)
>> - standing (vehicle ready - idling/enabled)
>> - stopped (vehicle not moving, but in a driving "gear")
>> - under-way (vehicle in motion)
>>
>> You probably don't want fuel status.  Projected range is probably more
>> interesting.  1 liter of fuel in a Prius vs. 1 liter in a Hummer makes
>> a big difference in range.
>
> It's just a lot harder to estimate this. I think at least for published
> information, having raw information seems more useful, maybe along with
> information about the vehicle type. (I'm actually not quite sure what
> this information might be used for, but maybe it is useful for
> OnStar-style systems if a guy with a gas canister needs to be dispatched.)
>
>>
>> The car stereo is often an interesting contributor to presence.  Some
>> cars even allow you to turn on the stereo with the ignition off. As a
>> student I used to sit in my car while studying, because the stereo was
>> better there.  Be aware that many car stereos are easily heard (and
>> listened to) outside the vehicle.
>
> There are IM/presence systems that display what song you're currently
> listening to.
>
>>
>> Finally, if one or more of the seat belts are on this is probably a
>> pretty reliable indicator of the presence of a human.  Unfortunately,
>> not having seat belts on is not a reliable indicator that there are
>> *not* humans in the car.
>
> Most modern cars have weight sensors at least in their front seats, to
> tune the behavior of air bags. While absence of passengers in the front
> seat does not indicate an empty car, it might indicate a situation where
> the occupants are looking for privacy.
>
> It would be interesting to find out what information standard vehicle
> monitoring systems expose.
>
>
>
> _______________________________________________
> 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


------=_Part_3021_4246857.1149225742714-- --===============1223000350== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1223000350==-- From simple-bounces@ietf.org Fri Jun 02 07:41:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm82K-00081p-Cj; Fri, 02 Jun 2006 07:41:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm82I-00081k-O2 for simple@ietf.org; Fri, 02 Jun 2006 07:41:50 -0400 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm82H-0002bO-Ar for simple@ietf.org; Fri, 02 Jun 2006 07:41:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 2 Jun 2006 13:41:23 +0200 Message-ID: <31721CD4D0090B4BA32CBA5E2C40AE9002539835@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Filtering - including attributes? Thread-Index: AcaGOXlLzy+POpfzT72lQae3IqIykw== From: To: X-OriginalArrivalTime: 02 Jun 2006 11:41:47.0987 (UTC) FILETIME=[88042A30:01C68639] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Simple] Filtering - including attributes? 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="===============2137966562==" Errors-To: simple-bounces@ietf.org --===============2137966562== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgaGF2ZSBvbmUgcXVlc3Rpb24gYWJvdXQgZmlsdGVyaW5nIGFuZCBJIGFtIHVuYWJs ZSB0byBmaW5kIGFuIGFuc3dlciBpbiBzcGVjaWZpY2F0aW9ucyDimLkgLiBDb3VsZCBhbnlvbmUg aGVscCBtZSBwbGVhc2U/DQoNCkkgaGF2ZSB0aGUgZm9sbG93aW5nIGRvY3VtZW50Og0KDQo8cm9v dD4NCiAgPGVsZW1lbnQgYXR0cj0ieCI+DQogICAgPHN1Yi1lbGVtZW50PnZhbHVlPC9zdWItZWxl bWVudD4NCiAgPC9lbGVtZW50Pg0KPC9yb290Pg0KDQpTdXBwb3NlIGFsbCBlbGVtZW50cyBhbmQg YXR0cmlidXRlcyBpbiB0aGF0IGRvY3VtZW50IGFyZSBvcHRpb25hbC4gV2hhdCBpcyB0aGUgY29y cmVjdCByZXN1bHQgb2YgZmlsdGVyaW5nIGJ5IHRoZSBmb2xsb3dpbmcgZmlsdGVyPw0KDQo8Zmls dGVyLXNldCB4bWxucz0iLi4uIj4NCiAgPGZpbHRlcj4NCiAgICA8d2hhdD4NCiAgICAgIDxpbmNs dWRlIHR5cGU9InhwYXRoIj4vcm9vdC9lbGVtZW50PC9pbmNsdWRlPg0KICAgIDwvd2hhdD4NCiAg PC9maWx0ZXI+DQo8L2ZpbHRlci1zZXQ+DQoNCg0KSXMgaXQgdGhlIHdob2xlIHNvdXJjZSBkb2N1 bWVudD8gT3IsIGlzIGl0ICI8cm9vdD48ZWxlbWVudC8+PC9yb290PiIgb25seT8gV2hhdCBhYm91 dCB0aGUgJ2F0dHInIGF0dHJpYnV0ZT8gSXMgaXQgaW5jbHVkZWQgdG9vPw0KDQpUaGFua3MsIGlu IGFkdmFuY2UuDQoNCkJlc3QgcmVnYXJkcywNCg0KTWljaGFsIEJ1cmRhDQo= --===============2137966562== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============2137966562==-- From simple-bounces@ietf.org Fri Jun 02 14:53:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmElg-00034d-2A; Fri, 02 Jun 2006 14:53:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmElf-00034X-3D for simple@ietf.org; Fri, 02 Jun 2006 14:53:07 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmElc-0006Zl-PE for simple@ietf.org; Fri, 02 Jun 2006 14:53:07 -0400 Received: from [172.20.32.144] ([198.181.231.9]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k52Ir1Ox001752 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 2 Jun 2006 14:53:01 -0400 (EDT) In-Reply-To: <447F63FC.6010908@cisco.com> References: <4478E5A7.7050604@cs.columbia.edu> <953beacc0605311601x17c4fdbav88e4e5b40b286da7@mail.gmail.com> <4B8E9319-FCD3-42A8-84AB-CC9677790509@cs.columbia.edu> <447F63FC.6010908@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3E0732DD-699B-4DAB-AD01-ACC9C46E00C3@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Simple] Question on Presence Data Model draft Date: Fri, 2 Jun 2006 14:52:59 -0400 To: Paul Kyzivat X-Mailer: Apple Mail (2.750) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: , Errors-To: simple-bounces@ietf.org On Jun 1, 2006, at 6:02 PM, Paul Kyzivat wrote: > I may be missing how this is supposed to be used. > > - Does the car know who (which presentities) are present within, so > that it can report presence status about them? The transmitter box in the car may not know, but the server that generates the NOTIFYs does, by a sign-in mechanism. (Currently, only the subscription side, not the "black-box-to-server" link, uses SIMPLE.) > > - or does some independent element associated with a known > presentity query the attributes of the car and then report that as > presence status of the associated presentity? (E.g. when I use the > car I dock my cell phone. It then picks up and reports the car > status as part of my presence.) Kind of. The in-vehicle box reports status to a server. > > - or is there a unique presentity associated with the car, > regardless of who is within? (This would seem to be the case with > OnStar.) > I agree that for an OnStar-like system using SIMPLE between the car and the telematics service, the car would be its own presentity. In that case, would we treat the car like a ? Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 02 17:59:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmHg8-0006T4-3z; Fri, 02 Jun 2006 17:59:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmHg5-0006Sv-7l for simple@ietf.org; Fri, 02 Jun 2006 17:59:33 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmHg3-0001qO-Qq for simple@ietf.org; Fri, 02 Jun 2006 17:59:33 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 02 Jun 2006 14:59:31 -0700 X-IronPort-AV: i="4.05,205,1146466800"; d="scan'208"; a="288113712:sNHT32442934" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k52LxV5n028532; Fri, 2 Jun 2006 14:59:31 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k52LxUIs002851; Fri, 2 Jun 2006 17:59:30 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Jun 2006 17:59:30 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Jun 2006 17:59:30 -0400 Message-ID: <4480B4C1.8090306@cisco.com> Date: Fri, 02 Jun 2006 17:59:29 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] Question on Presence Data Model draft References: <4478E5A7.7050604@cs.columbia.edu> <953beacc0605311601x17c4fdbav88e4e5b40b286da7@mail.gmail.com> <4B8E9319-FCD3-42A8-84AB-CC9677790509@cs.columbia.edu> <447F63FC.6010908@cisco.com> <3E0732DD-699B-4DAB-AD01-ACC9C46E00C3@cs.columbia.edu> In-Reply-To: <3E0732DD-699B-4DAB-AD01-ACC9C46E00C3@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jun 2006 21:59:30.0217 (UTC) FILETIME=[D2D3A990:01C6868F] DKIM-Signature: a=rsa-sha1; q=dns; l=1539; t=1149285571; x=1150149571; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Simple]=20Question=20on=20Presence=20Data=20Model=20draft; X=v=3Dcisco.com=3B=20h=3DOY+L3ECsWmg4xbXSLEYoo6S5mK0=3D; b=I1v3HNYwm7Pk9vmBIUCNGUh8EVC4om/37QnTd3Ef/FMKGeIpNupmwg8M/jIcSUlExZlulOtl 0DXeKLDoF844NdSJJ/oWrC5oegdkcUqyHZU0ryRUX6NhZ4Zpd2DZ4rCk; Authentication-Results: sj-dkim-4.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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: , Errors-To: simple-bounces@ietf.org Henning Schulzrinne wrote: > > On Jun 1, 2006, at 6:02 PM, Paul Kyzivat wrote: > >> I may be missing how this is supposed to be used. >> >> - Does the car know who (which presentities) are present within, so >> that it can report presence status about them? > > The transmitter box in the car may not know, but the server that > generates the NOTIFYs does, by a sign-in mechanism. (Currently, only > the subscription side, not the "black-box-to-server" link, uses SIMPLE.) You mean I have to "log in" to my car??? Some keys now contain an RFID (at least so I surmise), that is different for each key, the car can know which key is being used. If keys are 1:1 with people (sometimes true) then that may be sufficient, at least for the driver. Paul >> - or does some independent element associated with a known presentity >> query the attributes of the car and then report that as presence >> status of the associated presentity? (E.g. when I use the car I dock >> my cell phone. It then picks up and reports the car status as part of >> my presence.) > > Kind of. The in-vehicle box reports status to a server. > >> >> - or is there a unique presentity associated with the car, regardless >> of who is within? (This would seem to be the case with OnStar.) >> > > I agree that for an OnStar-like system using SIMPLE between the car and > the telematics service, the car would be its own presentity. In that > case, would we treat the car like a ? > > Henning > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jun 03 18:48:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmev0-0004ux-9N; Sat, 03 Jun 2006 18:48:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmeuz-0004us-0d for simple@ietf.org; Sat, 03 Jun 2006 18:48:29 -0400 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fmeux-00067x-OL for simple@ietf.org; Sat, 03 Jun 2006 18:48:28 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k53MkPWK004780 for ; Sat, 3 Jun 2006 18:46:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 4 Jun 2006 01:48:24 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Returned mail: Data format error Thread-Index: AcaHX9J5p1UJ1l9zS+Kfgzc35iSvqgAAAAFw From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Simple] Out of Office AutoReply: Returned mail: Data format error 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="===============1180474922==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1180474922== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6875F.D27EB6AE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6875F.D27EB6AE Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I am out-of-office on vacation and will be back on June 5, 2006. I will = not read e-mail during this period. If you need to contact me urgently, = please leave a voice mail message at my office number. Regards, Dan ------_=_NextPart_001_01C6875F.D27EB6AE Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Out of Office AutoReply: Returned mail: Data format error

I am out-of-office on vacation and will be back on = June 5, 2006.  I will not read e-mail during this period.  If = you need to contact me urgently, please leave a voice mail message at my = office number.

Regards,

Dan

------_=_NextPart_001_01C6875F.D27EB6AE-- --===============1180474922== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1180474922==-- From simple-bounces@ietf.org Mon Jun 05 12:43:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnIAu-0008D0-Oi; Mon, 05 Jun 2006 12:43:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnIAt-0008Cr-3c for simple@ietf.org; Mon, 05 Jun 2006 12:43:31 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnIAr-0001kq-P0 for simple@ietf.org; Mon, 05 Jun 2006 12:43:31 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FnIAq-0008F7-53; Mon, 05 Jun 2006 12:43:28 -0400 Received: from [127.0.0.1] (col-lab-dhcp33-245-066.bbn.com [128.33.245.66]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id k55GhRw29312; Mon, 5 Jun 2006 12:43:27 -0400 (EDT) Message-ID: <44845F2C.1010301@bbn.com> Date: Mon, 05 Jun 2006 12:43:24 -0400 From: Richard Barnes User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] Question on Presence Data Model draft References: <4478E5A7.7050604@cs.columbia.edu> <953beacc0605311601x17c4fdbav88e4e5b40b286da7@mail.gmail.com> <4B8E9319-FCD3-42A8-84AB-CC9677790509@cs.columbia.edu> <447F63FC.6010908@cisco.com> <3E0732DD-699B-4DAB-AD01-ACC9C46E00C3@cs.columbia.edu> <4480B4C1.8090306@cisco.com> In-Reply-To: <4480B4C1.8090306@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: simple@ietf.org, 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: , Errors-To: simple-bounces@ietf.org Paul Kyzivat wrote: > You mean I have to "log in" to my car??? > > Some keys now contain an RFID (at least so I surmise), that is > different for each key, the car can know which key is being used. If > keys are 1:1 with people (sometimes true) then that may be sufficient, > at least for the driver. I'm not sure what the Columbia folks are up to, but I can imagine a couple of use cases where it wouldn't be such a big deal to create a person-car association: Situation 1, Rental cars: When I rent a car, I provide my identity to the rental car company, and I am the only person authorized to operate that car. So in this case, either I, the rental company, or the car could register an association between me and the car. Situation 2, Bluetooth: Many cars now come with integrated Bluetooth capabilities to enable hand-free calling. It's entirely conceivable that when I hop into a car, my phone could ask for the car's presence information and register an association between itself and the car. The opposite situation also seems possible (where the car recognizes its occupants' phones), but this would seem to pose privacy and authentication issues. Cheers, --Richard _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 05 13:03:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnIUS-00088X-8u; Mon, 05 Jun 2006 13:03:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnIUR-00088S-JV for simple@ietf.org; Mon, 05 Jun 2006 13:03:43 -0400 Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnIUM-0004P3-5x for simple@ietf.org; Mon, 05 Jun 2006 13:03:43 -0400 Received: from cacexg12.americas.cpqcorp.net (cacexg12.americas.cpqcorp.net [16.92.1.72]) by palrel10.hp.com (Postfix) with ESMTP id 8E07F352DA; Mon, 5 Jun 2006 10:03:37 -0700 (PDT) Received: from cacexc08.americas.cpqcorp.net ([16.92.1.35]) by cacexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 10:03:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Question on Presence Data Model draft Date: Mon, 5 Jun 2006 10:03:35 -0700 Message-ID: In-reply-to: <44845F2C.1010301@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Question on Presence Data Model draft Thread-Index: AcaIvzMeOr5JVcgNQ36YP63HDaHl4gAAf6JA From: "Winsor, Gerry" To: "Richard Barnes" X-OriginalArrivalTime: 05 Jun 2006 17:03:37.0404 (UTC) FILETIME=[FC909FC0:01C688C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: simple@ietf.org, 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: , Errors-To: simple-bounces@ietf.org Hi Richard, I agree with your Situation 1 use case, and yes the rental car company will want to see a Driver Id for identity however wouldn't this also play into the Federated Identity space where the Service Provider maintaining Presence would use federated identity to authenticate & identify you with the rental car company ... assuming that they have a relationship in place? Federated Identity obviously complicates things somewhat but could establish and maintain the relationship between you and the car? Just a thought ... Gerry -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com]=20 Sent: Monday, June 05, 2006 9:43 AM To: Paul Kyzivat Cc: simple@ietf.org; Henning Schulzrinne Subject: Re: [Simple] Question on Presence Data Model draft Paul Kyzivat wrote: > You mean I have to "log in" to my car??? > > Some keys now contain an RFID (at least so I surmise), that is=20 > different for each key, the car can know which key is being used. If=20 > keys are 1:1 with people (sometimes true) then that may be sufficient, > at least for the driver. I'm not sure what the Columbia folks are up to, but I can imagine a couple of use cases where it wouldn't be such a big deal to create a person-car association: Situation 1, Rental cars: When I rent a car, I provide my identity to the rental car company, and I am the only person authorized to operate that car. So in this case, either I, the rental company, or the car could register an association between me and the car. Situation 2, Bluetooth: Many cars now come with integrated Bluetooth capabilities to enable hand-free calling. It's entirely conceivable that when I hop into a car, my phone could ask for the car's presence information and register an association between itself and the car. The opposite situation also seems possible (where the car recognizes its occupants' phones), but this would seem to pose privacy and authentication issues. Cheers, --Richard _______________________________________________ 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 Jun 05 14:52:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnKBR-0005tK-RR; Mon, 05 Jun 2006 14:52:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnKBQ-0005tC-Rk for simple@ietf.org; Mon, 05 Jun 2006 14:52:12 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnKBO-0000s9-Hc for simple@ietf.org; Mon, 05 Jun 2006 14:52:12 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FnKBN-0006sw-5d; Mon, 05 Jun 2006 14:52:09 -0400 Received: from [127.0.0.1] (col-lab-dhcp33-245-066.bbn.com [128.33.245.66]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id k55Iq9w25262; Mon, 5 Jun 2006 14:52:09 -0400 (EDT) Message-ID: <44847D57.3040101@bbn.com> Date: Mon, 05 Jun 2006 14:52:07 -0400 From: Richard Barnes User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Winsor, Gerry" Subject: Re: [Simple] Question on Presence Data Model draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: simple@ietf.org, 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: , Errors-To: simple-bounces@ietf.org Hi Gerry, There are two issues here 1. Demonstrating to the Presence Service Provider that the request for a car-person association is authorized by the renter/subscriber. 2. Demonstrating to the Rental Car Company that a request (from a Presence Service Provider) for car information is relevant to an actual rental by the renter/subscriber. What I understand from your email is that using federated identities could help with issue 2, where the identity provided by the Presence Service Provider has to match up with the identity held by the Rental Car Company. I agree that this is true -- federated identity is intended to make identities on different systems comparable. On the other hand, federation doesn't really seem relevant to issue 1, and issue 2 may not even arise: For instance, the renter/subscriber could use a device at the rental counter to (1) instruct his Service Provider to subscribe to his car's presence, and (2) instruct the Rental Company's presence facility to accept a subscription from his Service Provider to that car. In this way, the renter/subscriber would only need to authenticate to the Presence Server and the Rental Company individually. Cheers, --Richard Winsor, Gerry wrote: > Hi Richard, > > I agree with your Situation 1 use case, and yes the rental car company > will want to see a Driver Id for identity however wouldn't this also > play into the Federated Identity space where the Service Provider > maintaining Presence would use federated identity to authenticate & > identify you with the rental car company ... assuming that they have a > relationship in place? Federated Identity obviously complicates things > somewhat but could establish and maintain the relationship between you > and the car? > > Just a thought ... > Gerry > > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Monday, June 05, 2006 9:43 AM > To: Paul Kyzivat > Cc: simple@ietf.org; Henning Schulzrinne > Subject: Re: [Simple] Question on Presence Data Model draft > > Paul Kyzivat wrote: >> You mean I have to "log in" to my car??? >> >> Some keys now contain an RFID (at least so I surmise), that is >> different for each key, the car can know which key is being used. If >> keys are 1:1 with people (sometimes true) then that may be sufficient, > >> at least for the driver. > > I'm not sure what the Columbia folks are up to, but I can imagine a > couple of use cases where it wouldn't be such a big deal to create a > person-car association: > > Situation 1, Rental cars: When I rent a car, I provide my identity to > the rental car company, and I am the only person authorized to operate > that car. So in this case, either I, the rental company, or the car > could register an association between me and the car. > > Situation 2, Bluetooth: Many cars now come with integrated Bluetooth > capabilities to enable hand-free calling. It's entirely conceivable > that when I hop into a car, my phone could ask for the car's presence > information and register an association between itself and the car. The > opposite situation also seems possible (where the car recognizes its > occupants' phones), but this would seem to pose privacy and > authentication issues. > > Cheers, > --Richard > > > _______________________________________________ > 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 Wed Jun 07 10:15:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnyod-0008K4-I2; Wed, 07 Jun 2006 10:15:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnyoc-0008Jw-QR for simple@ietf.org; Wed, 07 Jun 2006 10:15:22 -0400 Received: from seldrel01.sonyericsson.com ([212.209.106.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnyob-0007cn-9z for simple@ietf.org; Wed, 07 Jun 2006 10:15:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Jun 2006 16:15:16 +0200 Message-ID: <1AF90E65795A3D45AA116B9264B4DAAF05F779E0@SELDMSX01.corpusers.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Can the subscription sip URI be the pres URI of the presentity? Thread-Index: AcaDzRJ/KAxCkTDTQk++ulgJNZasggGblrzw From: "Hyttfors, Per" To: X-OriginalArrivalTime: 07 Jun 2006 14:15:17.0522 (UTC) FILETIME=[CD646F20:01C68A3C] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: simple@ietf.org Subject: [Simple] Can the subscription sip URI be the pres URI of the presentity? 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: , Errors-To: simple-bounces@ietf.org It is stated in RFC 3863 =A74.1.1 that the element MUST have = an 'entity' attribute. The value of the 'entity' attribute is the 'pres' = URL of the PRESENTITY publishing this presence document. Examples in "draft-ietf-simple-rpid-10", = "draft-ietf-simple-partial-pidf-format-06" has the 'entity' attribute = set to a pres: URI. The example in section 6 in IETF draft = "draft-ietf-simple-event-list-07" has the 'entity' attribute set to a = sip: URI, the same URI as the one in the resource lists document for = that user. Can the presentity URI be the same as the URI used when subscribing? I.e = can the subscription sip URI be the 'pres' URL of the presentity? Also, don't know if this has been reported, but the example in 7.1 in = draft-ietf-simple-presence-data-model-07 is invalid, the entity = attribute is missing. (The unanswered question below covers the same question as mine) Regards, Per =20 >-----Original Message----- >From: Silvestr.Peknik@tietoenator.com=20 >[mailto:Silvestr.Peknik@tietoenator.com]=20 >Sent: tisdag den 30 maj 2006 11:40 >To: jdrosen@cisco.com >Cc: simple@ietf.org >Subject: [Simple] publishing presence state - sip and pres uris (again) > >Hi, please could you check my questions? > >Thank you, >Silvestr > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>Sent: Monday, May 01, 2006 9:21 PM >>To: Peknik Silvestr >>Cc: simple@ietf.org >>Subject: Re: [Simple] publishing presence state - sip and pres uris >> >>This can happen, yes. The presence data model draft (out shortly as an >>RFC) does say you shouldn't do this - that the URI in the=20 >SUBSCRIBE or=20 >>PUBLISH should match that in the document. > >What is the relation between To header and r-URI? Currently it=20 >seems to me that the client should set both to the same value,=20 >but r-URI can be changed by proxies. If this is the case, why=20 >not to use To header instead of r-URI for identifying the=20 >target of the request? And if the r-URI can not be changed,=20 >what is the purpose of To header? > >> >>That said, the presence server should know that the pres and sip URI >are >>equivalent, and thus even though the R-uri identifies the SIP=20 >URI, the=20 >>document should be applied to the presentity URI sip:alan@example.com >as >>well. Consequently, a SUBSCRIBE request for=20 >sip:alan@example.com would=20 >>return a presence document whose entity attribute is >sip:alan@example.com. > >I guess there is typo - it should say: >...applied to the presentity URI pres:alan@example.com as well... >Am I right? > >Thank you, >Silvestr Peknik > >_______________________________________________ >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 Wed Jun 07 11:07:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnzd4-0001tS-Ub; Wed, 07 Jun 2006 11:07:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnzd3-0001tK-Qz for simple@ietf.org; Wed, 07 Jun 2006 11:07:29 -0400 Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk187.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnzcz-0006UB-WF for simple@ietf.org; Wed, 07 Jun 2006 11:07:29 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by wrk187.corp.jabber.com (Postfix) with ESMTP id 37D054E9AA5; Wed, 7 Jun 2006 09:07:30 -0600 (MDT) Message-ID: <448610BB.5000707@jabber.org> Date: Tue, 06 Jun 2006 17:33:15 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060530 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: simple@ietf.org, xmppwg@jabber.org X-Enigmail-Version: 0.94.0.0 Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: Subject: [Simple] "last call" on SIMPLE-XMPP interworking I-D 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="===============1357776109==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1357776109== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010807000707090403000304" This is a cryptographically signed message in MIME format. --------------ms010807000707090403000304 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (Cross-posted to the SIMPLE and XMPP lists.) Because draft-saintandre-xmpp-simple appears to have reached stability, it seems appropriate to request an unofficial last call on this document (which has perhaps the longest title in IETF history). The I-D is available here: http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-simple-07.txt http://www.xmpp.org/drafts/draft-saintandre-xmpp-simple-07.html Please note that this I-D seeks to define only basic presence and messaging interoperability between SIMPLE and XMPP systems. Use cases such as extended presence, chat and multi-party messaging, and file transfer are not covered by this specification, but may be discussed in future I-Ds. Feedback may be sent directly to me, to all three authors, or to either or both of the lists. Thanks! Peter - -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEhhC6NF1RSzyt3NURAtjJAJ9LW+cttgPCKwK8ViYP5KEagn5qegCdFtR+ cx34mhV520JK9Diwvw3wdaY= =s8TL -----END PGP SIGNATURE----- --------------ms010807000707090403000304 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKdDCC BTYwggMeoAMCAQICAwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEw MjUyMjM4NDhaFw0wNjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFu ZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEW F2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA1IwvV3ywawrPfb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqno mVHDuqp0B+53Dp6Re66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnb RW0qfbZ7l278DATqilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfM UG30nhWZj70qW5NZyPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7N UZWmWdMzvCu9tD3nb+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHS MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsG AQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREE LzAtgRJzdHBldGVyQGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqG SIb3DQEBBAUAA4ICAQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhyl O67VqjAXMCYKsWfI6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJ L6ql6QnS0ubtlWJEcKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQA NvDsUx1VnYORRT3E+y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821c DHc1DLp3B9W4hW4PYdfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd 1NRl1LzVIMVml991Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy 2N5hkHEJdFeNIvg4AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoH FPW7OIjaNyHykBoU3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYn BCZ/QOcPiZ+OwlhkXzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCO GMc3fAsxqV6YffveN18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDCCBTYwggMeoAMCAQIC AwGUqzANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRw Oi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wNTEwMjUyMjM4NDhaFw0w NjEwMjUyMjM4NDhaMGoxHTAbBgNVBAMTFEouIFBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZI hvcNAQkBFhJzdHBldGVyQGphYmJlci5vcmcxJjAkBgkqhkiG9w0BCQEWF2oucGV0ZXJAc2Fp bnQtYW5kcmUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1IwvV3ywawrP fb66pLs0KqIj5QKXYQ45EUlTzKp6iHeCQzd+Kr8AOO21dcs/s0VcQqnomVHDuqp0B+53Dp6R e66yc1x89U3HFFWw/HfLuAzbngoD9PmmSLaJsXGfO0PyXQPB5GVJfVnbRW0qfbZ7l278DATq ilmBqGOvoDaJks/XjRvq7tt/0mPWlmWOplw/Nlniy0o6GlbwMnLLgNfMUG30nhWZj70qW5NZ yPTjDQAeYw6LxFieXIk9+6gCc84d2j3VTBglPFe0JkUmdVDXdcFyvU7NUZWmWdMzvCu9tD3n b+6CipKATjYPQNRxMFGcfnP7HxeFLTBYoy8BHL33wQIDAQABo4HVMIHSMAwGA1UdEwEB/wQC MAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJF RSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMDIGCCsGAQUFBwEBBCYwJDAi BggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzA2BgNVHREELzAtgRJzdHBldGVy QGphYmJlci5vcmeBF2oucGV0ZXJAc2FpbnQtYW5kcmUuY29tMA0GCSqGSIb3DQEBBAUAA4IC AQAV/ddHlibIhbnXGnEs1HUglGX5xCIZRW6g8jpCOKIgguVvjHFdvhylO67VqjAXMCYKsWfI 6Sfu6YyoDtSJpq8yWa/83nEq6aMOWtC6N2I9PINAojZelq97W6tHYrrJL6ql6QnS0ubtlWJE cKZoVglMZ+gmqGeuKGmoT25Lz7pslxN7/HXBiRqFaHh/gBqFSy0AGLQANvDsUx1VnYORRT3E +y1p1L82FgWKXHOLBZyaz2Eoi3CCroIA7JxhfQV+NNtVxhxmUyWj821cDHc1DLp3B9W4hW4P Ydfn8Hdzepwug2dYovjyFYEU2kekC38iD9/VuuLK9Z4C66FD1uqCAFfd1NRl1LzVIMVml991 Ejmeju3h5WvdfFMAteDQjmfGgqB9CFPIM3MPKM/Ir3GeaoQ8OV55U1zy2N5hkHEJdFeNIvg4 AE+up7EKkMTdTuXWlYfAG2Tb8ToBrWFqYCUdxorhWM1q2TXrmCMXmsoHFPW7OIjaNyHykBoU 3ZArm8I61UeGcvbtzf4AbDqXLvBjdup7oJofAWqY/2ZsWwmo8m7XqoYnBCZ/QOcPiZ+Owlhk Xzh+qpk4ZBsy5FEFwt9rQQoyQJpaIwF1CFKuPzH3kl/2EJY0GjOtLGCOGMc3fAsxqV6Yffve N18M4OYhLOkYay1QcgwJ81DSYvHs/2N5NjD4rDGCA4cwggODAgEBMIGAMHkxEDAOBgNVBAoT B1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0Eg Q2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQu b3JnAgMBlKswCQYFKw4DAhoFAKCCAdswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwNjA2MjMzMzE1WjAjBgkqhkiG9w0BCQQxFgQUub2a/FDBw4r4bVyx 4m1PwB/zFpowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZEGCSsGAQQBgjcQBDGB gzCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v cmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW EnN1cHBvcnRAY2FjZXJ0Lm9yZwIDAZSrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYD VQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMT GUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2Fj ZXJ0Lm9yZwIDAZSrMA0GCSqGSIb3DQEBAQUABIIBAL0LiCONSqrSP0OHBClirRgtxPaeAV9g 9COWC4wa9YfJ8brPaiBVveUJZztWX88MQ9U11kpE+wMM2z54uZQjUEpeZOKwN43snxZUcFCy D0cQ0cVcIUgwgASoc1ML02k84aVDsqGEMJo9q6Zzrh3JVUVsX/frAB9Q6BZj/LvDXAqwXQ9k U/4v/AzfJxpi94rOyPr0vD/VLrCVA6RkyMR/FkFXQpTCpWHKsY0jsWtqtYy5efi3kbZWrDoa ZfWIwf6CbD+DKKqNTdM5lJVW5vTNLlE22ByfKQqN7SypwKUp2vz3uSWb1fFAXeBld7QwXF0d nS1qrPObAxn9df+PV+HCP9sAAAAAAAA= --------------ms010807000707090403000304-- --===============1357776109== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1357776109==-- From simple-bounces@ietf.org Wed Jun 07 16:22:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4Xg-0005kX-4C; Wed, 07 Jun 2006 16:22:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo4Xf-0005jr-6x; Wed, 07 Jun 2006 16:22:15 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo4Xf-0004r2-57; Wed, 07 Jun 2006 16:22:15 -0400 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fo4Jc-0006JS-2f; Wed, 07 Jun 2006 16:07:45 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k57K7hHp021271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Jun 2006 20:07:43 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fo4Jb-0004c8-JX; Wed, 07 Jun 2006 16:07:43 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 07 Jun 2006 16:07:43 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: simple@ietf.org Subject: [Simple] Last Call: 'The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)' to Proposed Standard (draft-ietf-simple-xcap) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG to consider the following document: - 'The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) ' as a Proposed Standard On 2005-6-21, the IESG approved draft-ietf-simple-xcap-07.txt. Prior to its being published as an RFC, new issues were raised which required revision. The IESG solicits review of this new version, in particular of Sections 7.10, 7.11 & 8.23 where the major changes were made. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-06-21. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-11.txt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 08 20:37:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV0O-0007RS-9Z; Thu, 08 Jun 2006 20:37:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV0M-0007Qf-Hm for simple@ietf.org; Thu, 08 Jun 2006 20:37:38 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoV0K-0003px-8Z for simple@ietf.org; Thu, 08 Jun 2006 20:37:38 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Jun 2006 17:37:36 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,221,1146466800"; d="scan'208"; a="29093072:sNHT22568616" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k590bZYL024395; Thu, 8 Jun 2006 20:37:35 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 20:37:35 -0400 Received: from [192.168.1.101] ([10.86.241.56]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 20:37:34 -0400 Message-ID: <44888A35.9080903@cisco.com> Date: Thu, 08 Jun 2006 16:36:05 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Silvestr.Peknik@tietoenator.com Subject: Re: [Simple] publishing presence state - sip and pres uris References: <3ACC9A25264A684F82C71840111F9798019F9730@carrera.eu.tieto.com> In-Reply-To: <3ACC9A25264A684F82C71840111F9798019F9730@carrera.eu.tieto.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 00:37:34.0897 (UTC) FILETIME=[E69D7A10:01C68B5C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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: , Errors-To: simple-bounces@ietf.org inline. Silvestr.Peknik@tietoenator.com wrote: >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>Sent: Monday, May 01, 2006 9:21 PM >>To: Peknik Silvestr >>Cc: simple@ietf.org >>Subject: Re: [Simple] publishing presence state - sip and pres uris >> >>This can happen, yes. The presence data model draft (out shortly as an >>RFC) does say you shouldn't do this - that the URI in the SUBSCRIBE or >>PUBLISH should match that in the document. > > > What is the relation between To header and r-URI? Currently it seems to > me that the client should set both to the same value, but r-URI can be > changed by proxies. If this is the case, why not to use To header > instead of r-URI for identifying the target of the request? And if the > r-URI can not be changed, what is the purpose of To header? You are correct that the To header and R-URI are set to be the same by the client. As the request is forwarded, the r-uri gets rewritten. Though forwarding makes less sense for presence than it does for an INVITE, it could happen (for example, I can forward subscriptions for sip:jdrosen@cisco.com to sip:jdrosen@jdrosen.net). As such, when a SUBSCRIBE arrives at a presence server, it looks at the request URI. > > >>That said, the presence server should know that the pres and sip URI > > are > >>equivalent, and thus even though the R-uri identifies the SIP URI, tFrom simple-bounces@ietf.org Thu Jun 08 20:37:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV0O-0007RS-9Z; Thu, 08 Jun 2006 20:37:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV0M-0007Qf-Hm for simple@ietf.org; Thu, 08 Jun 2006 20:37:38 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoV0K-0003px-8Z for simple@ietf.org; Thu, 08 Jun 2006 20:37:38 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Jun 2006 17:37:36 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,221,1146466800"; d="scan'208"; a="29093072:sNHT22568616" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k590bZYL024395; Thu, 8 Jun 2006 20:37:35 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 20:37:35 -0400 Received: from [192.168.1.101] ([10.86.241.56]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 20:37:34 -0400 Message-ID: <44888A35.9080903@cisco.com> Date: Thu, 08 Jun 2006 16:36:05 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Silvestr.Peknik@tietoenator.com Subject: Re: [Simple] publishing presence state - sip and pres uris References: <3ACC9A25264A684F82C71840111F9798019F9730@carrera.eu.tieto.com> In-Reply-To: <3ACC9A25264A684F82C71840111F9798019F9730@carrera.eu.tieto.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 00:37:34.0897 (UTC) FILETIME=[E69D7A10:01C68B5C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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: , Errors-To: simple-bounces@ietf.org inline. Silvestr.Peknik@tietoenator.com wrote: >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>Sent: Monday, May 01, 2006 9:21 PM >>To: Peknik Silvestr >>Cc: simple@ietf.org >>Subject: Re: [Simple] publishing presence state - sip and pres uris >> >>This can happen, yes. The presence data model draft (out shortly as an >>RFC) does say you shouldn't do this - that the URI in the SUBSCRIBE or >>PUBLISH should match that in the document. > > > What is the relation between To header and r-URI? Currently it seems to > me that the client should set both to the same value, but r-URI can be > changed by proxies. If this is the case, why not to use To header > instead of r-URI for identifying the target of the request? And if the > r-URI can not be changed, what is the purpose of To header? You are correct that the To header and R-URI are set to be the same by the client. As the request is forwarded, the r-uri gets rewritten. Though forwarding makes less sense for presence than it does for an INVITE, it could happen (for example, I can forward subscriptions for sip:jdrosen@cisco.com to sip:jdrosen@jdrosen.net). As such, when a SUBSCRIBE arrives at a presence server, it looks at the request URI. > > >>That said, the presence server should know that the pres and sip URI > > are > >>equivalent, and thus even though the R-uri identifies the SIP URI, tFrom simple-bounces@ietf.org Thu Jun 08 20:37:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV0O-0007RS-9Z; Thu, 08 Jun 2006 20:37:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV0M-0007Qf-Hm for simple@ietf.org; Thu, 08 Jun 2006 20:37:38 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoV0K-0003px-8Z for simple@ietf.org; Thu, 08 Jun 2006 20:37:38 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Jun 2006 17:37:36 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,221,1146466800"; d="scan'208"; a="29093072:sNHT22568616" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k590bZYL024395; Thu, 8 Jun 2006 20:37:35 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 20:37:35 -0400 Received: from [192.168.1.101] ([10.86.241.56]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 20:37:34 -0400 Message-ID: <44888A35.9080903@cisco.com> Date: Thu, 08 Jun 2006 16:36:05 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Silvestr.Peknik@tietoenator.com Subject: Re: [Simple] publishing presence state - sip and pres uris References: <3ACC9A25264A684F82C71840111F9798019F9730@carrera.eu.tieto.com> In-Reply-To: <3ACC9A25264A684F82C71840111F9798019F9730@carrera.eu.tieto.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 00:37:34.0897 (UTC) FILETIME=[E69D7A10:01C68B5C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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: , Errors-To: simple-bounces@ietf.org inline. Silvestr.Peknik@tietoenator.com wrote: >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>Sent: Monday, May 01, 2006 9:21 PM >>To: Peknik Silvestr >>Cc: simple@ietf.org >>Subject: Re: [Simple] publishing presence state - sip and pres uris >> >>This can happen, yes. The presence data model draft (out shortly as an >>RFC) does say you shouldn't do this - that the URI in the SUBSCRIBE or >>PUBLISH should match that in the document. > > > What is the relation between To header and r-URI? Currently it seems to > me that the client should set both to the same value, but r-URI can be > changed by proxies. If this is the case, why not to use To header > instead of r-URI for identifying the target of the request? And if the > r-URI can not be changed, what is the purpose of To header? You are correct that the To header and R-URI are set to be the same by the client. As the request is forwarded, the r-uri gets rewritten. Though forwarding makes less sense for presence than it does for an INVITE, it could happen (for example, I can forward subscriptions for sip:jdrosen@cisco.com to sip:jdrosen@jdrosen.net). As such, when a SUBSCRIBE arrives at a presence server, it looks at the request URI. > > >>That said, the presence server should know that the pres and sip URI > > are > >>equivalent, and thus even though the R-uri identifies the SIP URI, the >>document should be applied to the presentity URI sip:alan@example.com > > as > >>well. Consequently, a SUBSCRIBE request for sip:alan@example.com would >>return a presence document whose entity attribute is > > sip:alan@example.com. > > I guess there is typo - it should say: > ...applied to the presentity URI pres:alan@example.com as well... > Am I right? Yes, sorry. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 08 20:37:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV0Q-0007Tp-Oz; Thu, 08 Jun 2006 20:37:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV0P-0007Rq-9M for simple@ietf.org; Thu, 08 Jun 2006 20:37:41 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoV0N-0003qO-TQ for simple@ietf.org; Thu, 08 Jun 2006 20:37:41 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 08 Jun 2006 17:37:39 -0700 X-IronPort-AV: i="4.05,221,1146466800"; d="scan'208"; a="1822475225:sNHT1240897502" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k590bcDL030569; Thu, 8 Jun 2006 17:37:38 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k590bccL014791; Thu, 8 Jun 2006 17:37:38 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 20:37:37 -0400 Received: from [192.168.1.101] ([10.86.241.56]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 20:37:37 -0400 Message-ID: <44888B92.7010106@cisco.com> Date: Thu, 08 Jun 2006 16:41:54 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Simple]How does MSRP support NAT traversal? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 09 Jun 2006 00:37:37.0428 (UTC) FILETIME=[E81FAD40:01C68B5C] DKIM-Signature: a=rsa-sha1; q=dns; l=2989; t=1149813458; x=1150677458; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Simple]How=20does=20MSRP=20support=20NAT=20traversal?; X=v=3Dcisco.com=3B=20h=3DskfshDnGdLWtPv4tCv7caXP+lTo=3D; b=AsI9wIoD2njzqyhUDVu5TNf3mLNbx/WZu0MubgMJblxMtLzrThSimithDL7r7IcrsSdIVmMm wAC9Y3zYaFtVKcezmfBt5myycHGsNdBSDZDtfg2h/VJyJYx+p5FaXMv1; Authentication-Results: sj-dkim-5.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: petithug@acm.org, pkyzivat@cisco.com, rohan@ekabal.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: , >document should be applied to the presentity URI sip:alan@example.com > > as > >>well. Consequently, a SUBSCRIBE request for sip:alan@example.com would >>return a presence document whose entity attribute is > > sip:alan@example.com. > > I guess there is typo - it should say: > ...applied to the presentity URI pres:alan@example.com as well... > Am I right? Yes, sorry. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 08 20:37:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV0Q-0007Tp-Oz; Thu, 08 Jun 2006 20:37:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV0P-0007Rq-9M for simple@ietf.org; Thu, 08 Jun 2006 20:37:41 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoV0N-0003qO-TQ for simple@ietf.org; Thu, 08 Jun 2006 20:37:41 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 08 Jun 2006 17:37:39 -0700 X-IronPort-AV: i="4.05,221,1146466800"; d="scan'208"; a="1822475225:sNHT1240897502" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k590bcDL030569; Thu, 8 Jun 2006 17:37:38 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k590bccL014791; Thu, 8 Jun 2006 17:37:38 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 20:37:37 -0400 Received: from [192.168.1.101] ([10.86.241.56]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 20:37:37 -0400 Message-ID: <44888B92.7010106@cisco.com> Date: Thu, 08 Jun 2006 16:41:54 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Simple]How does MSRP support NAT traversal? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 09 Jun 2006 00:37:37.0428 (UTC) FILETIME=[E81FAD40:01C68B5C] DKIM-Signature: a=rsa-sha1; q=dns; l=2989; t=1149813458; x=1150677458; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Simple]How=20does=20MSRP=20support=20NAT=20traversal?; X=v=3Dcisco.com=3B=20h=3DskfshDnGdLWtPv4tCv7caXP+lTo=3D; b=AsI9wIoD2njzqyhUDVu5TNf3mLNbx/WZu0MubgMJblxMtLzrThSimithDL7r7IcrsSdIVmMm wAC9Y3zYaFtVKcezmfBt5myycHGsNdBSDZDtfg2h/VJyJYx+p5FaXMv1; Authentication-Results: sj-dkim-5.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: petithug@acm.org, pkyzivat@cisco.com, rohan@ekabal.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: , Errors-To: simple-bounces@ietf.org I agree it could work. I recall even proposing this eons ago. With TURN and ICE tcp usage maturing it probably is much more viable these days than when msrp-relays started. That said, there are going to be some differences. First and foremost is that with TURN, if you have two domains each of which deploy TURN servers, and you end up in a trapezoid configuration, you'll end up with a separate tcp connection set up between the two TURN servers for each MSRP session. I believe with MSRP the number of connections between servers would just be two. Also, as Cullen is alluding to, TLS will work differently. With the latest TURN each client can have a TLS connection between itself and its own TURN server. However, inter-server TLS won't happen. Rather, you'd end up with TLS from one client to the other. Whether p2p TLS is a feature or a bug may depend on what you're trying to do, but with TURN relays it'll be p2p. There are probably other differences too, but thats what comes to mind. Thanks, Jonathan R. Cullen Jennings wrote: > > I can imagine that it might be possible to set up a MSRP session over > TURN or over STUNT. I've not checked the details of this being possible > but seems like it might work. Keep in mind TLS won't work very well > with TURN. > > On May 24, 2006, at 11:29 AM, > wrote: > >> Hi, >> >>> -----Original Message----- >>> From: ext Marc Petit-Huguenin [mailto:petithug@acm.org] >>> Sent: 24 May, 2006 21:02 >>> To: Rohan Mahy >>> Cc: Cullen Jennings; Paul Kyzivat; simple >>> Subject: Re: [Simple]How does MSRP support NAT traversal? >>> >>> Rohan Mahy wrote: >>> >>>> Hi Marc, >>>> >>>> It was specifically a non-goal of MSRP to use a TURN server for MSRP >>>> traffic. >>> >>> >>> I understand, but what technically prevent doing NAT traversal >>> for MSRP with a TCP TURN server? >>> >> >> Good question, I have been wondering the same. If TURN relays start >> to be available (I hope they do, although I haven't heard about such >> a thing), it would make sense to run MSRP through TURN instead of >> introducing separate MSRP specific relays. There may be other reasons >> to use MSRP relays, but the pure NAT traversal should be based on >> something more generic. >> >> Regards, >> Markus >> >> ---------------------------- >> Markus Isomäki >> markus.isomaki@nokia.com >> ---------------------------- > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 08 20:37:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV0K-0007QE-SM; Thu, 08 Jun 2006 20:37:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV0I-0007PJ-TS for simple@ietf.org; Thu, 08 Jun 2006 20:37:34 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoV0G-0003px-Et for simple@ietf.org; Thu, 08 Jun 2006 20:37:34 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 08 Jun 2006 17:37:32 -0700 X-BrightmailFiltered: true X-Brisimple-request@ietf.org?subject=unsubscribe> List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I agree it could work. I recall even proposing this eons ago. With TURN and ICE tcp usage maturing it probably is much more viable these days than when msrp-relays started. That said, there are going to be some differences. First and foremost is that with TURN, if you have two domains each of which deploy TURN servers, and you end up in a trapezoid configuration, you'll end up with a separate tcp connection set up between the two TURN servers for each MSRP session. I believe with MSRP the number of connections between servers would just be two. Also, as Cullen is alluding to, TLS will work differently. With the latest TURN each client can have a TLS connection between itself and its own TURN server. However, inter-server TLS won't happen. Rather, you'd end up with TLS from one client to the other. Whether p2p TLS is a feature or a bug may depend on what you're trying to do, but with TURN relays it'll be p2p. There are probably other differences too, but thats what comes to mind. Thanks, Jonathan R. Cullen Jennings wrote: > > I can imagine that it might be possible to set up a MSRP session over > TURN or over STUNT. I've not checked the details of this being possible > but seems like it might work. Keep in mind TLS won't work very well > with TURN. > > On May 24, 2006, at 11:29 AM, > wrote: > >> Hi, >> >>> -----Original Message----- >>> From: ext Marc Petit-Huguenin [mailto:petithug@acm.org] >>> Sent: 24 May, 2006 21:02 >>> To: Rohan Mahy >>> Cc: Cullen Jennings; Paul Kyzivat; simple >>> Subject: Re: [Simple]How does MSRP support NAT traversal? >>> >>> Rohan Mahy wrote: >>> >>>> Hi Marc, >>>> >>>> It was specifically a non-goal of MSRP to use a TURN server for MSRP >>>> traffic. >>> >>> >>> I understand, but what technically prevent doing NAT traversal >>> for MSRP with a TCP TURN server? >>> >> >> Good question, I have been wondering the same. If TURN relays start >> to be available (I hope they do, although I haven't heard about such >> a thing), it would make sense to run MSRP through TURN instead of >> introducing separate MSRP specific relays. There may be other reasons >> to use MSRP relays, but the pure NAT traversal should be based on >> something more generic. >> >> Regards, >> Markus >> >> ---------------------------- >> Markus Isomäki >> markus.isomaki@nokia.com >> ---------------------------- > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 08 20:37:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV0K-0007QE-SM; Thu, 08 Jun 2006 20:37:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV0I-0007PJ-TS for simple@ietf.org; Thu, 08 Jun 2006 20:37:34 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoV0G-0003px-Et for simple@ietf.org; Thu, 08 Jun 2006 20:37:34 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 08 Jun 2006 17:37:32 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,221,1146466800"; d="scan'208"; a="29093070:sNHT25428872" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k590bVno019626; Thu, 8 Jun 2006 20:37:31 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 20:37:31 -0400 Received: from [192.168.1.101] ([10.86.241.56]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 20:37:31 -0400 Message-ID: <44888928.20609@cisco.com> Date: Thu, 08 Jun 2006 16:31:36 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] Question on Presence Data Model draft References: <4478E5A7.7050604@cs.columbia.edu> <953beacc0605311601x17c4fdbav88e4e5b40b286da7@mail.gmail.com> <4B8E9319-FCD3-42A8-84AB-CC9677790509@cs.columbia.edu> <447F63FC.6010908@cisco.com> In-Reply-To: <447F63FC.6010908@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 00:37:31.0529 (UTC) FILETIME=[E49B8F90:01C68B5C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: simple@ietf.org, 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: , Errors-To: simple-bounces@ietf.org The model I have in my head from Hennings comments is this: Please view in a fixed-width font such as Courier. +---------+ +---------+ | | | | | |SIMPLE | | |Watcher |-------->|Presence | | | |Server | | | | | +---------+ +---------+ ^ | | i/f A | | +---------+ | | | | | Car | | | | | +---------+ The watcher talks to the presence server with SIMPLE. The presence server is receiving information from the car, such as whether the car is on/off, moving, and so on. The presence server uses this information to generate presence information to the watcher. Consequently, I think you need to consider the two interfaces in the diagram separately. In the interface from the watcher to the presence server, I don't think the documents published from the presence server would say very much at all about the state of the car. Rather, since we're talking about *presence*, which is about human-centric communications, the information from the car would have been used to derive presence states. For example, the element might have an that indicates driving' if the car is moving, and if the car detects that there are no other passengers, might add the element. However, the information from the car to the presence server would be 'raw' - that is, it directly conveys the car states, such as ignition status, fuel status, moghtmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,221,1146466800"; d="scan'208"; a="29093070:sNHT25428872" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k590bVno019626; Thu, 8 Jun 2006 20:37:31 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 20:37:31 -0400 Received: from [192.168.1.101] ([10.86.241.56]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 20:37:31 -0400 Message-ID: <44888928.20609@cisco.com> Date: Thu, 08 Jun 2006 16:31:36 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] Question on Presence Data Model draft References: <4478E5A7.7050604@cs.columbia.edu> <953beacc0605311601x17c4fdbav88e4e5b40b286da7@mail.gmail.com> <4B8E9319-FCD3-42A8-84AB-CC9677790509@cs.columbia.edu> <447F63FC.6010908@cisco.com> In-Reply-To: <447F63FC.6010908@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 00:37:31.0529 (UTC) FILETIME=[E49B8F90:01C68B5C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: simple@ietf.org, 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: , Errors-To: simple-bounces@ietf.org The model I have in my head from Hennings comments is this: Please view in a fixed-width font such as Courier. +---------+ +---------+ | | | | | |SIMPLE | | |Watcher |-------->|Presence | | | |Server | | | | | +---------+ +---------+ ^ | | i/f A | | +---------+ | | | | | Car | | | | | +---------+ The watcher talks to the presence server with SIMPLE. The presence server is receiving information from the car, such as whether the car is on/off, moving, and so on. The presence server uses this information to generate presence information to the watcher. Consequently, I think you need to consider the two interfaces in the diagram separately. In the interface from the watcher to the presence server, I don't think the documents published from the presence server would say very much at all about the state of the car. Rather, since we're talking about *presence*, which is about human-centric communications, the information from the car would have been used to derive presence states. For example, the element might have an that indicates driving' if the car is moving, and if the car detects that there are no other passengers, might add the element. However, the information from the car to the presence server would be 'raw' - that is, it directly conveys the car states, such as ignition status, fuel status, mohe >>document should be applied to the presentity URI sip:alan@example.com > > as > >>well. Consequently, a SUBSCRIBE request for sip:alan@example.com would >>return a presence document whose entity attribute is > > sip:alan@example.com. > > I guess there is typo - it should say: > ...applied to the presentity URI pres:alan@example.com as well... > Am I right? Yes, sorry. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 08 20:37:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV0Q-0007Tp-Oz; Thu, 08 Jun 2006 20:37:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV0P-0007Rq-9M for simple@ietf.org; Thu, 08 Jun 2006 20:37:41 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoV0N-0003qO-TQ for simple@ietf.org; Thu, 08 Jun 2006 20:37:41 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 08 Jun 2006 17:37:39 -0700 X-IronPort-AV: i="4.05,221,1146466800"; d="scan'208"; a="1822475225:sNHT1240897502" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k590bcDL030569; Thu, 8 Jun 2006 17:37:38 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k590bccL014791; Thu, 8 Jun 2006 17:37:38 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 20:37:37 -0400 Received: from [192.168.1.101] ([10.86.241.56]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 20:37:37 -0400 Message-ID: <44888B92.7010106@cisco.com> Date: Thu, 08 Jun 2006 16:41:54 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Simple]How does MSRP support NAT traversal? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 09 Jun 2006 00:37:37.0428 (UTC) FILETIME=[E81FAD40:01C68B5C] DKIM-Signature: a=rsa-sha1; q=dns; l=2989; t=1149813458; x=1150677458; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Simple]How=20does=20MSRP=20support=20NAT=20traversal?; X=v=3Dcisco.com=3B=20h=3DskfshDnGdLWtPv4tCv7caXP+lTo=3D; b=AsI9wIoD2njzqyhUDVu5TNf3mLNbx/WZu0MubgMJblxMtLzrThSimithDL7r7IcrsSdIVmMm wAC9Y3zYaFtVKcezmfBt5myycHGsNdBSDZDtfg2h/VJyJYx+p5FaXMv1; Authentication-Results: sj-dkim-5.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: petithug@acm.org, pkyzivat@cisco.com, rohan@ekabal.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: , I may be missing how this is supposed to be used. > > - Does the car know who (which presentities) are present within, so that > it can report presence status about them? > > - or does some independent element associated with a known presentity > query the attributes of the car and then report that as presence status > of the associated presentity? (E.g. when I use the car I dock my cell > phone. It then picks up and reports the car status as part of my presence.) > > - or is there a unique presentity associated with the car, regardless of > who is within? (This would seem to be the case with OnStar.) > > Paul > > Henning Schulzrinne wrote: > >> [Chiming in since Vishal's project is in my lab.] >> >> On May 31, 2006, at 7:01 PM, Rohan Mahy wrote: >> >>> Hi Vishal, >>> >>> I'm assuming that the vehicle is a tuple for a human presentity--that >>> the car doesn't have its own resource/presentity name. >>> >> >> Indeed; it's used as an adjunct to a person (in our case repair >> technicians in a truck). >> >> The basic question is whether this should be treated as: >> >> - person-associated information (under ) >> - a (although it is not necessarily a communication device) >> >> Maybe a combination would be best, depending on the nature of the >> information. >> >>> I don't think ignition is really orthogonal to movement status. I >>> think you want a rich presence indicator of movement within the tuple >>> representing the vehicle. The lock status might be relevant here as >>> well. What you are probably trying to determine is 1) a state of >>> occupancy, and 2) a state of distraction. Keep in mind that many >>> hybrids don't require use of an ignition switch. I think these work >>> for automobiles and trucks, but not for other types of vehicles: >>> >>> - parked locked (vehicle off) >>> - parked unlocked (vehicle off) >>> - standing (vehicle ready - idling/enabled) >>> - stopped (vehicle not moving, but in a driving "gear") >>> - under-way (vehicle in motion) >>> >>> You probably don't want fuel status. Projected range is probably more >>> interesting. 1 liter of fuel in a Prius vs. 1 liter in a Hummer makes >>> a big difference in range. >> >> >> It's just a lot harder to estimate this. I think at least for >> published information, having raw information seems more useful, maybe >> along with information about the vehicle type. (I'm actually not quite >> sure what this information might be used for, but maybe it is useful >> for OnStar-style systems if a guy with a gas canister needs to be >> dispatched.) >> >>> >>> The car stereo is often an interesting contributor to presence. Some >>> cars even allow you to turn on the stereo with the ignition off. As a >>> student I used to sit in my car while studying, because the stereo was >>> better there. Be aware that many car stereos are easily heard (and >>> listened to) outside the vehicle. >> >> >> There are IM/presence systems that display what song you're currently >> listening to. >> >>> >>> Finally, if one or more of the seat belts are on this is probably a >>> pretty reliable indicator of the presence of a human. Unfortunately, >>> not having seat belts on is not a reliable indicator that there are >>> *not* humans in the car. >> >> >> Most modern cars have weight sensors at least in their front seats, to >> tune the behavior of air bags. While absence of passengers in the >> front seat does not indicate an empty car, it might indicate a >> situation where the occupants are looking for privacy. >> >> It would be interestingvement status, and so on. I would assert that this is not presence at all, but rather is other type of state that is useful for composing presence. Consequently, I'd suggest defining a new event package to appropriately represent this information. This concept - of using data from other event packages (or non-SIP sources as the case may be) to derive presence states - is one of the things that needs to be described in presence-processing-model IMHO. Thanks, Jonathan R. Paul Kyzivat wrote: > I may be missing how this is supposed to be used. > > - Does the car know who (which presentities) are present within, so that > it can report presence status about them? > > - or does some independent element associated with a known presentity > query the attributes of the car and then report that as presence status > of the associated presentity? (E.g. when I use the car I dock my cell > phone. It then picks up and reports the car status as part of my presence.) > > - or is there a unique presentity associated with the car, regardless of > who is within? (This would seem to be the case with OnStar.) > > Paul > > Henning Schulzrinne wrote: > >> [Chiming in since Vishal's project is in my lab.] >> >> On May 31, 2006, at 7:01 PM, Rohan Mahy wrote: >> >>> Hi Vishal, >>> >>> I'm assuming that the vehicle is a tuple for a human presentity--that >>> the car doesn't have its own resource/presentity name. >>> >> >> Indeed; it's used as an adjunct to a person (in our case repair >> technicians in a truck). >> >> The basic question is whether this should be treated as: >> >> - person-associated information (under ) >> - a (although it is not necessarily a communication device) >> >> Maybe a combination would be best, depending on the nature of the >> information. >> >>> I don't think ignition is really orthogonal to movement status. I >>> think you want a rich presence indicator of movement within the tuple >>> representing the vehicle. The lock status might be relevant here as >>> well. What you are probably trying to determine is 1) a state of >>> occupancy, and 2) a state of distraction. Keep in mind that many >>> hybrids don't require use of an ignition switch. I think these work >>> for automobiles and trucks, but not for other types of vehicles: >>> >>> - parked locked (vehicle off) >>> - parked unlocked (vehicle off) >>> - standing (vehicle ready - idling/enabled) >>> - stopped (vehicle not moving, but in a driving "gear") >>> - under-way (vehicle in motion) >>> >>> You probably don't want fuel status. Projected range is probably more >>> interesting. 1 liter of fuel in a Prius vs. 1 liter in a Hummer makes >>> a big difference in range. >> >> >> It's just a lot harder to estimate this. I think at least for >> published information, having raw information seems more useful, maybe >> along with information about the vehicle type. (I'm actually not quite >> sure what this information might be used for, but maybe it is useful >> for OnStar-style systems if a guy with a gas canister needs to be >> dispatched.) >> >>> >>> The car stereo is often an interesting contributor to presence. Some >>> cars even allow you to turn on the stereo with the ignition off. As a >>> student I used to sit in my car while studying, because the stereo was >>> better there. Be aware that many car stereos are easily heard (and >>> listened to) outside the vehicle. >> >> >> There are IM/presence systems that display what song you're currently >> listening to. >> >>> >>> Finally, if one or more of the seat belts are on this is probably a >>> pretty reliable indicator of the presence of a human. Unfortunately, >>> not having seat belts on is not a reliable indicator that there are >>> *not* humans in the car. >> >> >> Most modern cars have weight sensors at least in their front seats, to >> tune the behavior of air bags. While absence of passengers in the >> front seat does not indicate an empty car, it might indicate a >> situation where the occupants are looking for privacy. >> >> It would be interestingsimple-request@ietf.org?subject=unsubscribe> List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I agree it could work. I recall even proposing this eons ago. With TURN and ICE tcp usage maturing it probably is much more viable these days than when msrp-relays started. That said, there are going to be some differences. First and foremost is that with TURN, if you have two domains each of which deploy TURN servers, and you end up in a trapezoid configuration, you'll end up with a separate tcp connection set up between the two TURN servers for each MSRP session. I believe with MSRP the number of connections between servers would just be two. Also, as Cullen is alluding to, TLS will work differently. With the latest TURN each client can have a TLS connection between itself and its own TURN server. However, inter-server TLS won't happen. Rather, you'd end up with TLS from one client to the other. Whether p2p TLS is a feature or a bug may depend on what you're trying to do, but with TURN relays it'll be p2p. There are probably other differences too, but thats what comes to mind. Thanks, Jonathan R. Cullen Jennings wrote: > > I can imagine that it might be possible to set up a MSRP session over > TURN or over STUNT. I've not checked the details of this being possible > but seems like it might work. Keep in mind TLS won't work very well > with TURN. > > On May 24, 2006, at 11:29 AM, > wrote: > >> Hi, >> >>> -----Original Message----- >>> From: ext Marc Petit-Huguenin [mailto:petithug@acm.org] >>> Sent: 24 May, 2006 21:02 >>> To: Rohan Mahy >>> Cc: Cullen Jennings; Paul Kyzivat; simple >>> Subject: Re: [Simple]How does MSRP support NAT traversal? >>> >>> Rohan Mahy wrote: >>> >>>> Hi Marc, >>>> >>>> It was specifically a non-goal of MSRP to use a TURN server for MSRP >>>> traffic. >>> >>> >>> I understand, but what technically prevent doing NAT traversal >>> for MSRP with a TCP TURN server? >>> >> >> Good question, I have been wondering the same. If TURN relays start >> to be available (I hope they do, although I haven't heard about such >> a thing), it would make sense to run MSRP through TURN instead of >> introducing separate MSRP specific relays. There may be other reasons >> to use MSRP relays, but the pure NAT traversal should be based on >> something more generic. >> >> Regards, >> Markus >> >> ---------------------------- >> Markus Isomäki >> markus.isomaki@nokia.com >> ---------------------------- > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 08 20:37:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV0K-0007QE-SM; Thu, 08 Jun 2006 20:37:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV0I-0007PJ-TS for simple@ietf.org; Thu, 08 Jun 2006 20:37:34 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoV0G-0003px-Et for simple@ietf.org; Thu, 08 Jun 2006 20:37:34 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 08 Jun 2006 17:37:32 -0700 X-BrightmailFiltered: true X-Bri to find out what information standard vehicle >> monitoring systems expose. >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple to find out what information standard vehicle >> monitoring systems expose. >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple ghtmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,221,1146466800"; d="scan'208"; a="29093070:sNHT25428872" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k590bVno019626; Thu, 8 Jun 2006 20:37:31 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 20:37:31 -0400 Received: from [192.168.1.101] ([10.86.241.56]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 20:37:31 -0400 Message-ID: <44888928.20609@cisco.com> Date: Thu, 08 Jun 2006 16:31:36 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] Question on Presence Data Model draft References: <4478E5A7.7050604@cs.columbia.edu> <953beacc0605311601x17c4fdbav88e4e5b40b286da7@mail.gmail.com> <4B8E9319-FCD3-42A8-84AB-CC9677790509@cs.columbia.edu> <447F63FC.6010908@cisco.com> In-Reply-To: <447F63FC.6010908@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 00:37:31.0529 (UTC) FILETIME=[E49B8F90:01C68B5C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: simple@ietf.org, 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: , Errors-To: simple-bounces@ietf.org The model I have in my head from Hennings comments is this: Please view in a fixed-width font such as Courier. +---------+ +---------+ | | | | | |SIMPLE | | |Watcher |-------->|Presence | | | |Server | | | | | +---------+ +---------+ ^ | | i/f A | | +---------+ | | | | | Car | | | | | +---------+ The watcher talks to the presence server with SIMPLE. The presence server is receiving information from the car, such as whether the car is on/off, moving, and so on. The presence server uses this information to generate presence information to the watcher. Consequently, I think you need to consider the two interfaces in the diagram separately. In the interface from the watcher to the presence server, I don't think the documents published from the presence server would say very much at all about the state of the car. Rather, since we're talking about *presence*, which is about human-centric communications, the information from the car would have been used to derive presence states. For example, the element might have an that indicates driving' if the car is moving, and if the car detects that there are no other passengers, might add the element. However, the information from the car to the presence server would be 'raw' - that is, it directly conveys the car states, such as ignition status, fuel status, movement status, and so on. I would assert that this is not presence at all, but rather is other type of state that is useful for composing presence. Consequently, I'd suggest defining a new event package to appropriately represent this information. This concept - of using data from other event packages (or non-SIP sources as the case may be) to derive presence states - is one of the things that needs to be described in presence-processing-model IMHO. Thanks, Jonathan R. Paul Kyzivat wrote: > I may be missing how this is supposed to be used. > > - Does the car know who (which presentities) are present within, so that > it can report presence status about them? > > - or does some independent element associated with a known presentity > query the attributes of the car and then report that as presence status > of the associated presentity? (E.g. when I use the car I dock my cell > phone. It then picks up and reports the car status as part of my presence.) > > - or is there a unique presentity associated with the car, regardless of > who is within? (This would seem to be the case with OnStar.) > > Paul > > Henning Schulzrinne wrote: > >> [Chiming in since Vishal's project is in my lab.] >> >> On May 31, 2006, at 7:01 PM, Rohan Mahy wrote: >> >>> Hi Vishal, >>> >>> I'm assuming that the vehicle is a tuple for a human presentity--that >>> the car doesn't have its own resource/presentity name. >>> >> >> Indeed; it's used as an adjunct to a person (in our case repair >> technicians in a truck). >> >> The basic question is whether this should be treated as: >> >> - person-associated information (under ) >> - a (although it is not necessarily a communication device) >> >> Maybe a combination would be best, depending on the nature of the >> information. >> >>> I don't think ignition is really orthogonal to movement status. I >>> think you want a rich presence indicator of movement within the tuple >>> representing the vehicle. The lock status might be relevant here as >>> well. What you are probably trying to determine is 1) a state of >>> occupancy, and 2) a state of distraction. Keep in mind that many >>> hybrids don't require use of an ignition switch. I think these work >>> for automobiles and trucks, but not for other types of vehicles: >>> >>> - parked locked (vehicle off) >>> - parked unlocked (vehicle off) >>> - standing (vehicle ready - idling/enabled) >>> - stopped (vehicle not moving, but in a driving "gear") >>> - under-way (vehicle in motion) >>> >>> You probably don't want fuel status. Projected range is probably more >>> interesting. 1 liter of fuel in a Prius vs. 1 liter in a Hummer makes >>> a big difference in range. >> >> >> It's just a lot harder to estimate this. I think at least for >> published information, having raw information seems more useful, maybe >> along with information about the vehicle type. (I'm actually not quite >> sure what this information might be used for, but maybe it is useful >> for OnStar-style systems if a guy with a gas canister needs to be >> dispatched.) >> >>> >>> The car stereo is often an interesting contributor to presence. Some >>> cars even allow you to turn on the stereo with the ignition off. As a >>> student I used to sit in my car while studying, because the stereo was >>> better there. Be aware that many car stereos are easily heard (and >>> listened to) outside the vehicle. >> >> >> There are IM/presence systems that display what song you're currently >> listening to. >> >>> >>> Finally, if one or more of the seat belts are on this is probably a >>> pretty reliable indicator of the presence of a human. Unfortunately, >>> not having seat belts on is not a reliable indicator that there are >>> *not* humans in the car. >> >> >> Most modern cars have weight sensors at least in their front seats, to >> tune the behavior of air bags. While absence of passengers in the >> front seat does not indicate an empty car, it might indicate a >> situation where the occupants are looking for privacy. >> >> It would be interesting to find out what information standard vehicle >> monitoring systems expose. >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 08 20:37:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV0S-0007Yc-9l; Thu, 08 Jun 2006 20:37:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoV0Q-0007U8-Qm for simple@ietf.org; Thu, 08 Jun 2006 20:37:42 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoV0P-0003qO-FY for simple@ietf.org; Thu, 08 Jun 2006 20:37:42 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 08 Jun 2006 17:37:40 -0700 X-IronPort-AV: i="4.05,221,1146466800"; d="scan'208"; a="1822475234:sNHT31289108" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k590bdMR030573 for ; Thu, 8 Jun 2006 17:37:39 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k590bdcL014795 for ; Thu, 8 Jun 2006 17:37:39 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 20:37:39 -0400 Received: from [192.168.1.101] ([10.86.241.56]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 20:37:39 -0400 Message-ID: <44888DBD.5080306@cisco.com> Date: Thu, 08 Jun 2006 16:51:09 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 00:37:39.0107 (UTC) FILETIME=[E91FDF30:01C68B5C] DKIM-Signature: a=rsa-sha1; q=dns; l=1762; t=1149813459; x=1150677459; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Group=20interest=20in=20draft-ietf-simple-common-policy-caps=20and=20dra ft-ietf-simple-pres-policy-caps?; X=v=3Dcisco.com=3B=20h=3DK+hFpxx3zHG2GLa2crh0MjxWMi0=3D; b=b326A5hti22RQSTqlVtB6hK0LT9FAugqIQjASQ7iLjPAs4MF8hkH2rZIoLOuImY0uexWnORQ U/4ZGInfAO/NLaj4mgwgQaxXGdeN4D8GUovsbvkL69pGG81hKzXlsMWu; Authentication-Results: sj-dkim-5.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Simple] Group interest in draft-ietf-simple-common-policy-caps and draft-ietf-simple-pres-policy-caps? 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: , Errors-To: simple-bounces@ietf.org These drafts expired some time ago. You can still retrieve them from my site: http://www.jdrosen.net/papers/draft-ietf-simple-common-policy-caps-00.txt http://www.jdrosen.net/papers/draft-ietf-simple-pres-policy-caps-00.txt These drafts define an xcap usage and corresponding schemas for declaring capabilities for authorization policies. A client application would fetch these at startup, and based on them, know what kind of authorization policies a user can specify. For example, if a service provider defines new permissions, like 'limited', 'full', and 'unfettered', the capabilities document would indicate to the client that these are presence, and the client could place them into a presence-rules document it uploads to the server. These drafts are only really needed if we are worried about deployments where people implement subsets or extensions to presence-rules, and the clients don't otherwise worry about them. The group has agreed in the past that these drafts were important and we agreed to adopt them as WG items. However, there hasn't been a lot of interest recently, and it will take effort for me to go and revive them and get them finished up. So, I'd like to poll for interest - please let me know if you think these are important and would like to move forward with them, and whether you plan on implementing or using these (or already are). Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 08 23:30:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoXhx-0003BD-Md; Thu, 08 Jun 2006 23:30:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoXhv-0003B3-Rk for simple@ietf.org; Thu, 08 Jun 2006 23:30:47 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoXhv-00018f-9j for simple@ietf.org; Thu, 08 Jun 2006 23:30:47 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 08 Jun 2006 20:30:47 -0700 X-IronPort-AV: i="4.05,221,1146466800"; d="scan'208"; a="1822553767:sNHT38860992" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k593Uka1002168; Thu, 8 Jun 2006 20:30:46 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k593UkcL027453; Thu, 8 Jun 2006 20:30:46 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 23:30:45 -0400 Received: from [10.86.240.152] ([10.86.240.152]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Jun 2006 23:30:45 -0400 Message-ID: <4488EB64.9070703@cisco.com> Date: Thu, 08 Jun 2006 23:30:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Question on Presence Data Model draft References: <4478E5A7.7050604@cs.columbia.edu> <953beacc0605311601x17c4fdbav88e4e5b40b286da7@mail.gmail.com> <4B8E9319-FCD3-42A8-84AB-CC9677790509@cs.columbia.edu> <447F63FC.6010908@cisco.com> <44888928.20609@cisco.com> In-Reply-To: <44888928.20609@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 03:30:45.0306 (UTC) FILETIME=[17C811A0:01C68B75] DKIM-Signature: a=rsa-sha1; q=dns; l=6993; t=1149823846; x=1150687846; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Re=3A=20[Simple]=20Question=20on=20Presence=20Data=20Model=20draft; X=v=3Dcisco.com=3B=20h=3DOY+L3ECsWmg4xbXSLEYoo6S5mK0=3D; b=Jz4yNADybfRMYn/MD4L0OqLvvzLIl8l82NWb3oT5sTgwgAa/Hdo6xS6TzLfwAhXt9dn6AmhN muac/oRiu54Mzv0dWrJfKO9KLSp7o1ort0USFzQDZry78DZTCeRiPDnK; Authentication-Results: sj-dkim-7.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: simple@ietf.org, 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: , Errors-To: simple-bounces@ietf.org Jonathan Rosenberg wrote: > The model I have in my head from Hennings comments is this: > > Please view in a fixed-width font such as > Courier. > > +---------+ +---------+ > | | | | > | |SIMPLE | | > |Watcher |-------->|Presence | > | | |Server | > | | | | > +---------+ +---------+ > ^ > | > | i/f A > | > | > +---------+ > | | > | | > | Car | > | | > | | > +---------+ > > The watcher talks to the presence server with SIMPLE. The presence > server is receiving information from the car, such as whether the car is > on/off, moving, and so on. The presence server uses this information to > generate presence information to the watcher. Consequently, I think you > need to consider the two interfaces in the diagram separately. That works for me. I was initially imagining "i/f A" being PUBLISH, and wondering how the car would know who to publish to. Paul > In the interface from the watcher to the presence server, I don't think > the documents published from the presence server would say very much at > all about the state of the car. Rather, since we're talking about > *presence*, which is about human-centric communications, the information > from the car would have been used to derive presence states. For > example, the element might have an that indicates > driving' if the car is moving, and if the car detects that there are no > other passengers, might add the element. > > However, the information from the car to the presence server would be > 'raw' - that is, it directly conveys the car states, such as ignition > status, fuel status, movement status, and so on. I would assert that > this is not presence at all, but rather is other type of state that is > useful for composing presence. Consequently, I'd suggest defining a new > event package to appropriately represent this information. > > This concept - of using data from other event packages (or non-SIP > sources as the case may be) to derive presence states - is one of the > things that needs to be described in presence-processing-model IMHO. > > Thanks, > Jonathan R. > > Paul Kyzivat wrote: > >> I may be missing how this is supposed to be used. >> >> - Does the car know who (which presentities) are present within, so >> that it can report presence status about them? >> >> - or does some independent element associated with a known presentity >> query the attributes of the car and then report that as presence >> status of the associated presentity? (E.g. when I use the car I dock >> my cell phone. It then picks up and reports the car status as part of >> my presence.) >> >> - or is there a unique presentity associated with the car, regardless >> of who is within? (This would seem to be the case with OnStar.) >> >> Paul >> >> Henning Schulzrinne wrote: >> >>> [Chiming in since Vishal's project is in my lab.] >>> >>> On May 31, 2006, at 7:01 PM, Rohan Mahy wrote: >>> >>>> Hi Vishal, >>>> >>>> I'm assuming that the vehicle is a tuple for a human presentity--that >>>> the car doesn't have its own resource/presentity name. >>>> >>> >>> Indeed; it's used as an adjunct to a person (in our case repair >>> technicians in a truck). >>> >>> The basic question is whether this should be treated as: >>> >>> - person-associated information (under ) >>> - a (although it is not necessarily a communication device) >>> >>> Maybe a combination would be best, depending on the nature of the >>> information. >>> >>>> I don't think ignition is really orthogonal to movement status. I >>>> think you want a rich presence indicator of movement within the tuple >>>> representing the vehicle. The lock status might be relevant here as >>>> well. What you are probably trying to determine is 1) a state of >>>> occupancy, and 2) a state of distraction. Keep in mind that many >>>> hybrids don't require use of an ignition switch. I think these work >>>> for automobiles and trucks, but not for other types of vehicles: >>>> >>>> - parked locked (vehicle off) >>>> - parked unlocked (vehicle off) >>>> - standing (vehicle ready - idling/enabled) >>>> - stopped (vehicle not moving, but in a driving "gear") >>>> - under-way (vehicle in motion) >>>> >>>> You probably don't want fuel status. Projected range is probably more >>>> interesting. 1 liter of fuel in a Prius vs. 1 liter in a Hummer makes >>>> a big difference in range. >>> >>> >>> It's just a lot harder to estimate this. I think at least for >>> published information, having raw information seems more useful, >>> maybe along with information about the vehicle type. (I'm actually >>> not quite sure what this information might be used for, but maybe it >>> is useful for OnStar-style systems if a guy with a gas canister needs >>> to be dispatched.) >>> >>>> >>>> The car stereo is often an interesting contributor to presence. Some >>>> cars even allow you to turn on the stereo with the ignition off. As a >>>> student I used to sit in my car while studying, because the stereo was >>>> better there. Be aware that many car stereos are easily heard (and >>>> listened to) outside the vehicle. >>> >>> >>> There are IM/presence systems that display what song you're currently >>> listening to. >>> >>>> >>>> Finally, if one or more of the seat belts are on this is probably a >>>> pretty reliable indicator of the presence of a human. Unfortunately, >>>> not having seat belts on is not a reliable indicator that there are >>>> *not* humans in the car. >>> >>> >>> Most modern cars have weight sensors at least in their front seats, >>> to tune the behavior of air bags. While absence of passengers in the >>> front seat does not indicate an empty car, it might indicate a >>> situation where the occupants are looking for privacy. >>> >>> It would be interesting to find out what information standard vehicle >>> monitoring systems expose. >>> >>> >>> >>> _______________________________________________ >>> 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 Jun 09 04:41:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FocYp-0000bS-NK; Fri, 09 Jun 2006 04:41:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FocYo-0000SC-4y for simple@ietf.org; Fri, 09 Jun 2006 04:41:42 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FocYm-0003ZP-Ou for simple@ietf.org; Fri, 09 Jun 2006 04:41:42 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k598fdGN000409 for ; Fri, 9 Jun 2006 01:41:39 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k598fb2G024671 for ; Fri, 9 Jun 2006 03:41:38 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jun 2006 16:41:32 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.txt Thread-Index: AcaLoIIdOgGkTvCHQcGh1xjihygCjg== From: "Shetti Shrinivas-Q16945" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Kelley Sean-Q12059 Subject: [Simple] clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.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: , Content-Type: multipart/mixed; boundary="===============0172771175==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0172771175== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68BA0.84E85C09" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68BA0.84E85C09 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi, above draft has following statement in section 4.2 ------------------------------------------------------------------------ Including "eventlist" in a "Require" header field in a SUBSCRIBE request serves no purpose except breaking interoperability in certain cases, and is consequently NOT RECOMMENDED. ------------------------------------------------------------------------ Can anyone clarify why do we discourage use of 'Require' header? My perception about this header being used in SUBSCRIBE is that, it is not going to cause any harm or issue. I might be missing something. I have following scenario in mind. All the presence SUBSCRIBE messages land at a proxy. The proxy server decides to route the request to either 'RLS server' or 1-1 presence server. Now, if client can use 'Require: eventlist', this is definite indication for the proxy to route the request to RLS server. Rest of the subscriptions can go to 1-1 presence server. thanks and best regards, Shetti ------_=_NextPart_001_01C68BA0.84E85C09 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
hi,
above draft has following statement in =
section 4.2
----------------------------------------------=
--------------------------
   Including "eventlist" in a =
"Require" header field in a SUBSCRIBE
   request serves no purpose except breaking interoperability in certain
   cases, and is consequently NOT RECOMMENDED.
----------------------------------------------=
--------------------------
Can anyone clarify why do we discourage use =
of 'Require' header?
My perception about this header being used in =
SUBSCRIBE is that, it is not going to cause any harm or issue. I might =
be missing something.
I have following scenario in =
mind.
All the presence =
SUBSCRIBE messages land at a proxy. The proxy server decides to route =
the request to either 'RLS server' or 1-1 presence =
server.
Now, if client =
can use 'Require: eventlist', this is definite indication for the proxy =
to route the request to RLS server. Rest of the subscriptions can go to =
1-1 presence server.
thanks and best =
regards,
Shetti
------_=_NextPart_001_01C68BA0.84E85C09-- --===============0172771175== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0172771175==-- From simple-bounces@ietf.org Fri Jun 09 05:21:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FodB2-0006cm-AG; Fri, 09 Jun 2006 05:21:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FodB1-0006cX-DN for simple@ietf.org; Fri, 09 Jun 2006 05:21:11 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FodB1-0000PC-B6 for simple@ietf.org; Fri, 09 Jun 2006 05:21:11 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FodAb-0005LN-A3 for simple@ietf.org; Fri, 09 Jun 2006 05:20:46 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k599KiS4000175 for ; Fri, 9 Jun 2006 02:20:44 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k599KgH1011734 for ; Fri, 9 Jun 2006 04:20:43 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jun 2006 17:20:39 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.txt Thread-Index: AcaLoIIdOgGkTvCHQcGh1xjihygCjgABQrKQ From: "Shetti Shrinivas-Q16945" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: -2.5 (--) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Kelley Sean-Q12059 Subject: [Simple] FW: clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.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: , Content-Type: multipart/mixed; boundary="===============1164120402==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1164120402== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68BA5.FAEBDB70" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68BA5.FAEBDB70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the scenario I've mentioned, the assumption is that clients do have knowledge about whether they are subscribing to list URI or NOT.=20 So, is there any harm if they use 'Require:eventlist', when they know that the request URI is a list URI? =20 thanks, Shetti ________________________________ From: Shetti Shrinivas-Q16945=20 Sent: Friday, June 09, 2006 2:12 PM To: 'simple@ietf.org' Cc: Kelley Sean-Q12059 Subject: clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.txt hi, above draft has following statement in section 4.2 ------------------------------------------------------------------------ Including "eventlist" in a "Require" header field in a SUBSCRIBE request serves no purpose except breaking interoperability in certain cases, and is consequently NOT RECOMMENDED. ------------------------------------------------------------------------ Can anyone clarify why do we discourage use of 'Require' header? My perception about this header being used in SUBSCRIBE is that, it is not going to cause any harm or issue. I might be missing something. I have following scenario in mind. All the presence SUBSCRIBE messages land at a proxy. The proxy server decides to route the request to either 'RLS server' or 1-1 presence server. Now, if client can use 'Require: eventlist', this is definite indication for the proxy to route the request to RLS server. Rest of the subscriptions can go to 1-1 presence server. thanks and best regards, Shetti ------_=_NextPart_001_01C68BA5.FAEBDB70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In the scenario I've mentioned, the assumption = is that=20 clients do have knowledge about whether they are subscribing to list URI = or NOT.=20
So, is there any harm if they use = 'Require:eventlist', when=20 they know that the request URI is a list URI?
 
thanks,
Shetti

From: Shetti Shrinivas-Q16945 =
Sent:=20 Friday, June 09, 2006 2:12 PM
To: = 'simple@ietf.org'
Cc:=20 Kelley Sean-Q12059
Subject: clarification regarding 'Require' = header=20 usage in draft-ietf-simple-event-list-07.txt

hi,
above draft has following statement in =
section 4.2
----------------------------------------------=
--------------------------
   Including "eventlist" in a =
"Require" header field in a SUBSCRIBE
   request serves no purpose except breaking interoperability in certain
   cases, and is consequently NOT RECOMMENDED.
----------------------------------------------=
--------------------------
Can anyone clarify why do we discourage use =
of 'Require' header?
My perception about this header being used in =
SUBSCRIBE is that, it is not going to cause any harm or issue. I might =
be missing something.
I have following scenario in =
mind.
All the presence =
SUBSCRIBE messages land at a proxy. The proxy server decides to route =
the request to either 'RLS server' or 1-1 presence =
server.
Now, if client =
can use 'Require: eventlist', this is definite indication for the proxy =
to route the request to RLS server. Rest of the subscriptions can go to =
1-1 presence server.
thanks and best =
regards,
Shetti
------_=_NextPart_001_01C68BA5.FAEBDB70-- --===============1164120402== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1164120402==-- From simple-bounces@ietf.org Fri Jun 09 10:49:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoiIh-0005Xt-Pj; Fri, 09 Jun 2006 10:49:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoiIf-0005X8-OJ for simple@ietf.org; Fri, 09 Jun 2006 10:49:25 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Foi9W-000753-11 for simple@ietf.org; Fri, 09 Jun 2006 10:39:59 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 09 Jun 2006 07:39:58 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,224,1146466800"; d="scan'208"; a="29127402:sNHT22888182" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k59EdoYZ002714; Fri, 9 Jun 2006 10:39:57 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Jun 2006 10:39:57 -0400 Received: from [192.168.1.101] ([10.86.241.56]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Jun 2006 10:39:56 -0400 Message-ID: <44898837.2090105@cisco.com> Date: Fri, 09 Jun 2006 10:39:51 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] Question on Presence Data Model draft References: <4478E5A7.7050604@cs.columbia.edu> <953beacc0605311601x17c4fdbav88e4e5b40b286da7@mail.gmail.com> <4B8E9319-FCD3-42A8-84AB-CC9677790509@cs.columbia.edu> <447F63FC.6010908@cisco.com> <44888928.20609@cisco.com> <4488EB64.9070703@cisco.com> In-Reply-To: <4488EB64.9070703@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 14:39:56.0551 (UTC) FILETIME=[93C9D970:01C68BD2] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: simple@ietf.org, 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: , Errors-To: simple-bounces@ietf.org inline. Paul Kyzivat wrote: > > > Jonathan Rosenberg wrote: > >> The model I have in my head from Hennings comments is this: >> >> Please view in a fixed-width font such as >> Courier. >> >> +---------+ +---------+ >> | | | | >> | |SIMPLE | | >> |Watcher |-------->|Presence | >> | | |Server | >> | | | | >> +---------+ +---------+ >> ^ >> | >> | i/f A >> | >> | >> +---------+ >> | | >> | | >> | Car | >> | | >> | | >> +---------+ >> >> The watcher talks to the presence server with SIMPLE. The presence >> server is receiving information from the car, such as whether the car >> is on/off, moving, and so on. The presence server uses this >> information to generate presence information to the watcher. >> Consequently, I think you need to consider the two interfaces in the >> diagram separately. > > > That works for me. I was initially imagining "i/f A" being PUBLISH, and > wondering how the car would know who to publish to. It can still be a PUBLISH (the alternative being a back end subscription from the presence server to the car), but it wouldn't be for the presence event package. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 09 11:25:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoirT-00066H-F3; Fri, 09 Jun 2006 11:25:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoirS-00066C-86 for simple@ietf.org; Fri, 09 Jun 2006 11:25:22 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoirQ-0003ZY-UR for simple@ietf.org; Fri, 09 Jun 2006 11:25:22 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 09 Jun 2006 08:25:20 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,224,1146466800"; d="scan'208"; a="29132640:sNHT23090424" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k59FP6YR014202; Fri, 9 Jun 2006 11:25:20 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Jun 2006 11:25:19 -0400 Received: from [192.168.1.101] ([10.86.241.56]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Jun 2006 11:25:18 -0400 Message-ID: <448992DB.9050603@cisco.com> Date: Fri, 09 Jun 2006 11:25:15 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin.Hynar@tietoenator.com References: <3ACC9A25264A684F82C71840111F9798019A72D4@carrera.eu.tieto.com> In-Reply-To: <3ACC9A25264A684F82C71840111F9798019A72D4@carrera.eu.tieto.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 15:25:19.0020 (UTC) FILETIME=[EA81A6C0:01C68BD8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: simple@ietf.org Subject: [Simple] Re: Few more comments to presence-rules-06 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: , Errors-To: simple-bounces@ietf.org inline. Martin.Hynar@tietoenator.com wrote: > Hi, > > I traversed the presence rules draft 06 once again and I found few > issues there. > > - In section 3.1.1.2 there is last paragraph noticing usage of TEL URI > and SIP URI for one user. There is bug in first combination of URIs > starting "A WR identity .." > SIP with phone to SIP but should be SIP with phone to TEL > in the reverse direction I would prefer to mention SIP URI with the > phone number instead of pure SIP URI fixed. > > - In section 3.3.2.14 third paragraph first sentence. > "Another consequence of this definition is that the interpretation of > the element can change should the > presence server be upgraded with a new schema that defines > authorization rules for elements included in a attribute>." > This sentence makes me really confused and I can't catch the idea. OK, I tried to clarify. The document now says: Another consequence of this definition is that the interpretation of the <provide-unknown-attribute> element can change should the presence server be upgraded. For example, consider a server which, prior to the upgrade, had an authorization document that used <provide-unknown-attribute> for some attribute, say foo. This attribute was from a namespace and schema unknown to the server, and so the attribute was provided to watchers. However, after upgrade, the server is now aware of a new namespace and schema for a permission that grants access to the foo attribute. Now, the <provide-unknown-attribute> permission for the foo attribute will be ignored, resulting in a removal of those elements from presence documents sent to watchers. The system remains privacy safe, but behavior might not be as expected. Developers of systems which allow clients to set policies are advised to check the capabilities of the server, (using mechanisms like those defined in , for example) before uploading a new authorization document, to make sure that the behavior will be as expected. > > Other issues are moreless cosmetic > - First paragraph of 3.1.1.2 contains "can can" sequence fixed > - Last paragraph of 3.2.1 contains "is is" sequence fixed > - In section 3.3.2 there is used element fixed > - Permission definitions are in form: there is permission XXX realized > by element . But provide unknown attribute permission violates this > convention. Similar deviation is in 3.3.2.15. I don't follow; all permissions are of the form for various XXX. > > > In addition, what was the reason to change to > ? It somehow breaks the conventions of provide-xxx > elements. No - because in the data model draft the attribute is so its permission is . Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 09 11:49:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FojEf-0006EP-7k; Fri, 09 Jun 2006 11:49:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FojEd-0006EI-VE for simple@ietf.org; Fri, 09 Jun 2006 11:49:19 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FojEc-0006ki-Je for simple@ietf.org; Fri, 09 Jun 2006 11:49:19 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 09 Jun 2006 11:49:18 -0400 X-IronPort-AV: i="4.05,224,1146456000"; d="scan'208"; a="89671821:sNHT32253612" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k59FnIYL019416; Fri, 9 Jun 2006 11:49:18 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Jun 2006 11:49:17 -0400 Received: from [192.168.1.101] ([10.86.241.56]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Jun 2006 11:49:17 -0400 Message-ID: <4489987D.9090708@cisco.com> Date: Fri, 09 Jun 2006 11:49:17 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-presence-rules-06.txt References: <009901c6792c$e8386610$31713b51@BEMBUSTER> In-Reply-To: <009901c6792c$e8386610$31713b51@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 15:49:17.0613 (UTC) FILETIME=[43F985D0:01C68BDC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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: , Errors-To: simple-bounces@ietf.org OK, this is a good suggestion. I'll make the change. Thanks, Jonathan R. Jeroen van Bemmel wrote: > Jonathan, > > The way in which namespaces are bound to 'provide-unknown-attribute' > could be problematic when multiple XML documents are combined. XML tools > will not be aware of the binding, and could e.g. rename conflicting > namespace prefixes which would cause the rule to become invalid. > > Suggestion: > name="foo">true > this keeps the namespace binding more local to the rule, and works when > multiple rule documents are merged. Also, it avoids confusion, since the > namespace prefix used in target documents (to which the rules are > applied) might well be different from "new". > > Regards, > > jeroen > > PS Minor nit: for the example in 5 could consider to use > 'urn:ietf:params:xml:ns:common-policy' as default namespace > > ----- Original Message ----- From: > To: > Cc: > Sent: Tuesday, May 16, 2006 9:50 PM > Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-rules-06.txt > > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the SIP for Instant Messaging and >> Presence Leveraging Extensions Working Group of the IETF. >> >> Title : Presence Authorization Rules >> Author(s) : J. Rosenberg >> Filename : draft-ietf-simple-presence-rules-06.txt >> Pages : 28 >> Date : 2006-5-16 >> >> Authorization is a key function in presence systems. Authorization >> policies, also known as authorization rules, specify what presence >> information can be given to which watchers, and when. This >> specification defines an Extensible Markup Language (XML) document >> format for expressing presence authorization rules. Such a document >> can be manipulated by clients using the XML Configuration Access >> Protocol (XCAP), although other techniques are permitted. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules-06.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-presence-rules-06.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-simple-presence-rules-06.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> > > > -------------------------------------------------------------------------------- > > > >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 09 14:09:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FolPj-000588-3P; Fri, 09 Jun 2006 14:08:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FolPh-0004yY-4G for simple@ietf.org; Fri, 09 Jun 2006 14:08:53 -0400 Received: from [2001:5c0:8fff:fffe::4c49] (helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FolPf-0000Iz-Dk for simple@ietf.org; Fri, 09 Jun 2006 14:08:53 -0400 Received: from [172.17.2.252] (dsl001-129-070.dfw1.dsl.speakeasy.net [72.1.129.70]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.4) with ESMTP id k59I8mcE077481 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 9 Jun 2006 13:08:49 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <13D321E0-EAFA-4D25-B93D-3675D1C6CD9F@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: simple@ietf.org From: Robert Sparks Date: Fri, 9 Jun 2006 13:08:49 -0500 X-Mailer: Apple Mail (2.750) Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Simple] WG -00s 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: , Errors-To: simple-bounces@ietf.org The only new working group draft (00) that I am expecting to be submitted between now and Montreal is the advanced messaging requirements draft. If I've forgotten something, please let me know immediately. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 09 15:09:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FomMQ-00079H-NV; Fri, 09 Jun 2006 15:09:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FomMP-00078z-1f for simple@ietf.org; Fri, 09 Jun 2006 15:09:33 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FomCf-00060W-3l for simple@ietf.org; Fri, 09 Jun 2006 14:59:30 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 09 Jun 2006 11:59:28 -0700 X-IronPort-AV: i="4.05,224,1146466800"; d="scan'208"; a="292398831:sNHT157605962" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k59IxSGH030046 for ; Fri, 9 Jun 2006 11:59:28 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k59IxSIs000405 for ; Fri, 9 Jun 2006 11:59:28 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Jun 2006 14:59:27 -0400 Received: from [192.168.1.101] ([10.86.240.47]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Jun 2006 14:59:27 -0400 Message-ID: <4489C50E.7060706@cisco.com> Date: Fri, 09 Jun 2006 14:59:26 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 18:59:27.0176 (UTC) FILETIME=[D49AAC80:01C68BF6] DKIM-Signature: a=rsa-sha1; q=dns; l=705; t=1149879568; x=1150743568; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:updated=20presence-rules=20spec; X=v=3Dcisco.com=3B=20h=3DaELuV45neeHKQV+wEMN9yz6fOPQ=3D; b=CTqVEIvsE6rGEe4N/7mn1jZVQKK4xtmiZA/0yhlfHcgqaf+K+ZxvQ90Hq+4h/1Il24BMZQ46 9ZGtY93mUKqUG4u/oIlBNfmvG/faN/DfeXJcOIQls5Y5tcrPEhEDV2VC; Authentication-Results: sj-dkim-8.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Simple] updated presence-rules spec 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: , Errors-To: simple-bounces@ietf.org I've just submitted an updated to the presence-rules spec. Until it appears, you can pick it up here: http://www.jdrosen.net/papers/draft-ietf-simple-presence-rules-07.txt The only major change is the way namespaces are handled for the unknown-presence-attribute permission. The rest are based on minor comments received since the last revision. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 09 16:31:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fondr-0005WI-Vy; Fri, 09 Jun 2006 16:31:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fondq-0005V6-KK; Fri, 09 Jun 2006 16:31:38 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FonF4-0006ke-EQ; Fri, 09 Jun 2006 16:06:02 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fon0Y-0006Cx-8Q; Fri, 09 Jun 2006 15:51:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k59Jo1mU011565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FomzZ-000605-Pk; Fri, 09 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 09 Jun 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-notify-07.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: , Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Session Initiation Protocol (SIP) extension for Partial Notification of Presence Information Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-notify-07.txt Pages : 15 Date : 2006-6-9 By default, presence delivered using the Presence Event Package for the Session Initiation Protocol is represented in the Presence Information Data Format (PIDF). A PIDF document contains a set of elements, each representing a different aspect of the presence being reported. When any subset of the elements change, even just a single element, a new document containing the full set of elements is delivered. This memo defines an extension allowing delivery of presence data that has actually changed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-07.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-partial-notify-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-partial-notify-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-9143310.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-notify-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-notify-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-9143310.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Mon Jun 12 17:20:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fptpo-0005Un-VU; Mon, 12 Jun 2006 17:20:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fptpn-0005Og-Js; Mon, 12 Jun 2006 17:20:31 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpsvU-0002CM-22; Mon, 12 Jun 2006 16:22:20 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FpsRC-0005JV-3l; Mon, 12 Jun 2006 15:51:09 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5CJo1mU019787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FpsQD-0006gD-KZ; Mon, 12 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 12 Jun 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-rules-07.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: , Errors-To: simple-bounces@ietf.org --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 : Presence Authorization Rules Author(s) : J. Rosenberg Filename : draft-ietf-simple-presence-rules-07.txt Pages : 28 Date : 2006-6-12 Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules-07.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-presence-rules-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-presence-rules-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-12102236.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presence-rules-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presence-rules-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-12102236.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Mon Jun 12 20:55:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpxCC-0007ub-Gi; Mon, 12 Jun 2006 20:55:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpxCA-0007iN-FY for simple@ietf.org; Mon, 12 Jun 2006 20:55:50 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpxC8-0006AX-NS for simple@ietf.org; Mon, 12 Jun 2006 20:55:50 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0R00ASJXMK8O@szxga03-in.huawei.com> for simple@ietf.org; Tue, 13 Jun 2006 09:03:56 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0R00AW2XMKKV@szxga03-in.huawei.com> for simple@ietf.org; Tue, 13 Jun 2006 09:03:56 +0800 (CST) Received: from z53160 ([10.164.5.15]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0R00BT5X9H1G@szxml03-in.huawei.com> for simple@ietf.org; Tue, 13 Jun 2006 08:56:08 +0800 (CST) Date: Tue, 13 Jun 2006 08:54:47 +0800 From: Harrison Zhou To: Simple WG Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcaOg/eg3FySkFheSvm8Dv0YAN/StA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Simple] Comments on draft-zhou-simple-hierarchical-presence-00.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: , Errors-To: simple-bounces@ietf.org Hi, draft-zhou-simple-hierarchical-presence-00.txt describe a new method for the Presence Server to process presence in inter-domain scenarios . The new method void duplicated messaging between Presence Servers. I have already submitted the new draft. you can fetch a copy from: http://www.ietf.org/internet-drafts/draft-zhou-simple-hierarchical-pres ence-00.txt Regards, Hong _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jun 13 01:40:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq1dN-0000oJ-BS; Tue, 13 Jun 2006 01:40:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq1dL-0000oE-UM for simple@ietf.org; Tue, 13 Jun 2006 01:40:11 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq1dK-0006ZF-G0 for simple@ietf.org; Tue, 13 Jun 2006 01:40:11 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k5D5e97m028886 for ; Mon, 12 Jun 2006 22:40:09 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k5D5e70J015768 for ; Tue, 13 Jun 2006 00:40:08 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 Jun 2006 13:40:03 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.txt Thread-Index: AcaLoIIdOgGkTvCHQcGh1xjihygCjgABQrKQALplhBA= From: "Shetti Shrinivas-Q16945" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.1 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: Subject: [Simple] FW: clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.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: , Content-Type: multipart/mixed; boundary="===============0818677509==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0818677509== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68EAB.D1974F2F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68EAB.D1974F2F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable can some one please clarify this? ________________________________ From: Shetti Shrinivas-Q16945=20 Sent: Friday, June 09, 2006 2:51 PM To: 'simple@ietf.org' Cc: Kelley Sean-Q12059 Subject: FW: clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.txt In the scenario I've mentioned, the assumption is that UACs do have knowledge about whether they are subscribing to list URI or NOT.=20 So, is there any harm if UAC uses 'Require:eventlist', when it knows that the request URI is a list URI? =20 thanks, Shetti ________________________________ From: Shetti Shrinivas-Q16945=20 Sent: Friday, June 09, 2006 2:12 PM To: 'simple@ietf.org' Cc: Kelley Sean-Q12059 Subject: clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.txt hi, above draft has following statement in section 4.2 ------------------------------------------------------------------------ Including "eventlist" in a "Require" header field in a SUBSCRIBE request serves no purpose except breaking interoperability in certain cases, and is consequently NOT RECOMMENDED. ------------------------------------------------------------------------ Can anyone clarify why do we discourage use of 'Require' header? My perception about this header being used in SUBSCRIBE is that, it is not going to cause any harm or issue. I might be missing something. I have following scenario in mind. All the presence SUBSCRIBE messages land at a proxy. The proxy server decides to route the request to either 'RLS server' or 1-1 presence server. Now, if client can use 'Require: eventlist', this is definite indication for the proxy to route the request to RLS server. Rest of the subscriptions can go to 1-1 presence server. thanks and best regards, Shetti ------_=_NextPart_001_01C68EAB.D1974F2F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
can some one please clarify = this?

From: Shetti Shrinivas-Q16945 =
Sent:=20 Friday, June 09, 2006 2:51 PM
To: = 'simple@ietf.org'
Cc:=20 Kelley Sean-Q12059
Subject: FW: clarification regarding = 'Require'=20 header usage in draft-ietf-simple-event-list-07.txt

In the scenario I've mentioned, the assumption = is=20 that  UACs do = have=20 knowledge about whether they are subscribing to list URI or NOT.=20
So, is there any harm if  UAC uses  'Require:eventlist', = when  it knows that the request URI is a list=20 URI?
 
thanks,
Shetti

From: Shetti Shrinivas-Q16945 =
Sent:=20 Friday, June 09, 2006 2:12 PM
To: = 'simple@ietf.org'
Cc:=20 Kelley Sean-Q12059
Subject: clarification regarding 'Require' = header=20 usage in draft-ietf-simple-event-list-07.txt

hi,
above draft has following statement in =
section 4.2
----------------------------------------------=
--------------------------
   Including "eventlist" in a =
"Require" header field in a SUBSCRIBE
   request serves no purpose except breaking interoperability in certain
   cases, and is consequently NOT RECOMMENDED.
----------------------------------------------=
--------------------------
Can anyone clarify why do we discourage use =
of 'Require' header?
My perception about this header being used in =
SUBSCRIBE is that, it is not going to cause any harm or issue. I might =
be missing something.
I have following scenario in =
mind.
All the presence =
SUBSCRIBE messages land at a proxy. The proxy server decides to route =
the request to either 'RLS server' or 1-1 presence =
server.
Now, if client =
can use 'Require: eventlist', this is definite indication for the proxy =
to route the request to RLS server. Rest of the subscriptions can go to =
1-1 presence server.
thanks and best =
regards,
Shetti
------_=_NextPart_001_01C68EAB.D1974F2F-- --===============0818677509== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0818677509==-- From simple-bounces@ietf.org Tue Jun 13 02:33:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq2Sr-0007XC-NP; Tue, 13 Jun 2006 02:33:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq2Sq-0007X6-Ao for simple@ietf.org; Tue, 13 Jun 2006 02:33:24 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq2So-000386-PT for simple@ietf.org; Tue, 13 Jun 2006 02:33:24 -0400 Received: by ug-out-1314.google.com with SMTP id j40so372524ugd for ; Mon, 12 Jun 2006 23:33:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=MCuYMbRhCfKeoi0BRAPpzpf7orwnVo5KMPKKj4H1CI7OZQLlz01MloNx27FUHw6vVM5gNF3yWFfxIdOI1sODL1+fbEddxRm2XkfvYBVoPklyH+Wg7JbETHGJbYxf41bXQsjzSinDJS52afBQIxIV4EwiNUriX5HpJLtZYXW5Z0w= Received: by 10.67.100.12 with SMTP id c12mr5965042ugm; Mon, 12 Jun 2006 23:33:21 -0700 (PDT) Received: by 10.66.240.1 with HTTP; Mon, 12 Jun 2006 23:33:21 -0700 (PDT) Message-ID: <60b4a2350606122333r256153f9m1d038bf822f889ab@mail.gmail.com> Date: Tue, 13 Jun 2006 12:03:21 +0530 From: "Gadigeppa Malagund" To: "Shetti Shrinivas-Q16945" Subject: Re: [Simple] FW: clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.txt In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.1 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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: , Content-Type: multipart/mixed; boundary="===============1150532647==" Errors-To: simple-bounces@ietf.org --===============1150532647== Content-Type: multipart/alternative; boundary="----=_Part_9014_208768.1150180401492" ------=_Part_9014_208768.1150180401492 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Your suggestion is appropriate and enhances performance of the n/w. When "Supported: eventlist" is included in subscribe, proxy by default forwards request to 1-1 presence server depending on "Event: presence". For this if request URI is Group URI, then proxy gets "404 not found" response from the 1-1 PS. Proxy sees whether there is header "Supported: eventlist" and then forwards to RLS. So if "Require: eventlist" is included then proxy can directly forward this request RLS. So this RECOMMENDTION is not specific to presence group subscribe however more to do with usage of "Require" header by the client. Note that incoming NOTIFYs from RLS have MUST "Require: eventlist" header NOT "Supported" Regards, Gadi On 6/13/06, Shetti Shrinivas-Q16945 wrote: > > can some one please clarify this? > > ------------------------------ > *From:* Shetti Shrinivas-Q16945 > *Sent:* Friday, June 09, 2006 2:51 PM > > *To:* 'simple@ietf.org' > *Cc:* Kelley Sean-Q12059 > *Subject:* FW: clarification regarding 'Require' header usage in > draft-ietf-simple-event-list-07.txt > > In the scenario I've mentioned, the assumption is that UACs do have > knowledge about whether they are subscribing to list URI or NOT. > So, is there any harm if UAC uses 'Require:eventlist', when it knows that > the request URI is a list URI? > > thanks, > Shetti > > ------------------------------ > *From:* Shetti Shrinivas-Q16945 > *Sent:* Friday, June 09, 2006 2:12 PM > *To:* 'simple@ietf.org' > *Cc:* Kelley Sean-Q12059 > *Subject:* clarification regarding 'Require' header usage in > draft-ietf-simple-event-list-07.txt > > hi, > > above draft has following statement in section 4.2 > > ------------------------------------------------------------------------ > > Including "eventlist" in a "Require" header field in a SUBSCRIBE > request serves no purpose except breaking interoperability in certain > cases, and is consequently NOT RECOMMENDED. > > ------------------------------------------------------------------------ > > Can anyone clarify why do we discourage use of 'Require' header? > > My perception about this header being used in SUBSCRIBE is that, it is not going to cause any harm or issue. I might be missing something. > > I have following scenario in mind. > > All the presence SUBSCRIBE messages land at a proxy. The proxy server decides to route the request to either 'RLS server' or 1-1 presence server. > > Now, if client can use 'Require: eventlist', this is definite indication for the proxy to route the request to RLS server. Rest of the subscriptions can go to 1-1 presence server. > > thanks and best regards, > > Shetti > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > > -- ------=_Part_9014_208768.1150180401492 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Your suggestion is appropriate and enhances performance of the n/w.

When "Supported: eventlist" is included in subscribe, proxy by default forwards request to 1-1 presence server depending on "Event: presence".
For this if request URI is Group URI, then proxy gets "404 not found" response from the 1-1 PS.
Proxy sees whether there is header "Supported: eventlist" and then forwards to RLS.

So if "Require: eventlist" is included then proxy can directly forward this request RLS.

So this RECOMMENDTION is not specific to presence group subscribe however more to do with usage of "Require" header by the client.

Note that incoming NOTIFYs from RLS have MUST "Require: eventlist" header NOT "Supported"

Regards,
Gadi

On 6/13/06, Shetti Shrinivas-Q16945 <sshetti@motorola.com> wrote:
can some one please clarify this?

From: Shetti Shrinivas-Q16945
Sent: Friday, June 09, 2006 2:51 PM

To: 'simple@ietf.org '
Cc: Kelley Sean-Q12059
Subject: FW: clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.txt

In the scenario I've mentioned, the assumption is that  UACs do have knowledge about whether they are subscribing to list URI or NOT.
So, is there any harm if  UAC uses  'Require:eventlist', when  it knows that the request URI is a list URI?
 
thanks,
Shetti

From: Shetti Shrinivas-Q16945
Sent: Friday, June 09, 2006 2:12 PM
To: 'simple@ietf.org'
Cc: Kelley Sean-Q12059
Subject: clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.txt

hi,
above draft has following statement in section 4.2
------------------------------------------------------------------------

   Including "eventlist" in a "Require" header field in a SUBSCRIBE
   request serves no purpose except breaking interoperability in certain
   cases, and is consequently NOT RECOMMENDED.
------------------------------------------------------------------------
Can anyone clarify why do we discourage use of 'Require' header?
My perception about this header being used in SUBSCRIBE is that, it is not going to cause any harm or issue. I might be missing something.

I have following scenario in mind.
All the presence SUBSCRIBE messages land at a proxy. The proxy server decides to route the request to either 'RLS server' or 1-1 presence server.

Now, if client can use 'Require: eventlist', this is definite indication for the proxy to route the request to RLS server. Rest of the subscriptions can go to 1-1 presence server.
thanks and best regards,
Shetti

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple





--  ------=_Part_9014_208768.1150180401492-- --===============1150532647== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1150532647==-- From simple-bounces@ietf.org Tue Jun 13 04:01:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq3pY-0004ZP-6m; Tue, 13 Jun 2006 04:00:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq3pX-0004ZK-5x for simple@ietf.org; Tue, 13 Jun 2006 04:00:55 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq3pW-0004qG-H6 for simple@ietf.org; Tue, 13 Jun 2006 04:00:55 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k5D80rHW025497 for ; Tue, 13 Jun 2006 01:00:53 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k5D80pmT018404 for ; Tue, 13 Jun 2006 03:00:52 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Simple] FW: clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.txt Date: Tue, 13 Jun 2006 16:00:45 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] FW: clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.txt Thread-Index: AcaOs0qXb434+J2jRNS9Z5ueqUqXdAAC3KCA From: "Shetti Shrinivas-Q16945" To: "Gadigeppa Malagund" , , , X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.1 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Cc: Kelley Sean-Q12059 , 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: , Content-Type: multipart/mixed; boundary="===============0637988726==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0637988726== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68EBF.7C875BD2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68EBF.7C875BD2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable thanks Gadi, =20 So, I assume that "there is no harm including 'Require: eventlist' in the SUBSCRIBE, when UAC knows the request URI is a list URI." =20 Can we have this spec updated to indicate the above, rather than discouraging 'Require' header usage altogether in SUBSCRIBE request? =20 Request spec authors to kindly comment on this. =20 best regards, Shetti ________________________________ From: Gadigeppa Malagund [mailto:gadigeppa@gmail.com]=20 Sent: Tuesday, June 13, 2006 12:03 PM To: Shetti Shrinivas-Q16945 Cc: simple@ietf.org Subject: Re: [Simple] FW: clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.txt Your suggestion is appropriate and enhances performance of the n/w. When "Supported: eventlist" is included in subscribe, proxy by default forwards request to 1-1 presence server depending on "Event: presence". For this if request URI is Group URI, then proxy gets "404 not found" response from the 1-1 PS. Proxy sees whether there is header "Supported: eventlist" and then forwards to RLS. So if "Require: eventlist" is included then proxy can directly forward this request RLS. So this RECOMMENDTION is not specific to presence group subscribe however more to do with usage of "Require" header by the client. Note that incoming NOTIFYs from RLS have MUST "Require: eventlist" header NOT "Supported" Regards, Gadi On 6/13/06, Shetti Shrinivas-Q16945 wrote:=20 can some one please clarify this? ________________________________ From: Shetti Shrinivas-Q16945=20 Sent: Friday, June 09, 2006 2:51 PM =09 To: 'simple@ietf.org ' Cc: Kelley Sean-Q12059 =09 Subject: FW: clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.txt =09 =09 In the scenario I've mentioned, the assumption is that UACs do have knowledge about whether they are subscribing to list URI or NOT.=20 So, is there any harm if UAC uses 'Require:eventlist', when it knows that the request URI is a list URI? =09 =20 thanks, Shetti ________________________________ From: Shetti Shrinivas-Q16945=20 Sent: Friday, June 09, 2006 2:12 PM To: 'simple@ietf.org' Cc: Kelley Sean-Q12059 Subject: clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.txt =09 =09 hi, above draft has following statement in section 4.2 =09 ------------------------------------------------------------------------ =09 Including "eventlist" in a "Require" header field in a SUBSCRIBE request serves no purpose except breaking interoperability in certain cases, and is consequently NOT RECOMMENDED. =09 ------------------------------------------------------------------------ Can anyone clarify why do we discourage use of 'Require' header? My perception about this header being used in SUBSCRIBE is that, it is not going to cause any harm or issue. I might be missing something. =09 I have following scenario in mind. All the presence SUBSCRIBE messages land at a proxy. The proxy server decides to route the request to either 'RLS server' or 1-1 presence server. =09 Now, if client can use 'Require: eventlist', this is definite indication for the proxy to route the request to RLS server. Rest of the subscriptions can go to 1-1 presence server. thanks and best regards, Shetti _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple =09 =09 =09 -- =20 ------_=_NextPart_001_01C68EBF.7C875BD2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
thanks Gadi,
 
So, I assume that "there is no harm including = 'Require:=20 eventlist' in the SUBSCRIBE, when UAC knows the request URI is a list=20 URI."
 
Can we have this spec updated to indicate the = above, rather=20 than discouraging 'Require' header usage altogether in SUBSCRIBE=20 request?
 
Request spec authors to kindly comment on=20 this.
 
best regards,
Shetti

From: Gadigeppa Malagund=20 [mailto:gadigeppa@gmail.com]
Sent: Tuesday, June 13, 2006 = 12:03=20 PM
To: Shetti Shrinivas-Q16945
Cc:=20 simple@ietf.org
Subject: Re: [Simple] FW: clarification = regarding=20 'Require' header usage in=20 draft-ietf-simple-event-list-07.txt

Your suggestion is appropriate and = enhances=20 performance of the n/w.

When "Supported: eventlist" is included = in=20 subscribe, proxy by default forwards request to 1-1 presence server = depending on=20 "Event: presence".
For this if request URI is Group URI, then proxy = gets "404=20 not found" response from the 1-1 PS.
Proxy sees whether there is = header=20 "Supported: eventlist" and then forwards to RLS.

So if "Require:=20 eventlist" is included then proxy can directly forward this request=20 RLS.

So this RECOMMENDTION is not specific to presence = group=20 subscribe however more to do with usage of "Require" header by the=20 client.

Note that incoming NOTIFYs from RLS have MUST "Require:=20 eventlist" header NOT "Supported"

Regards,
Gadi

On 6/13/06, Shetti=20 Shrinivas-Q16945 <sshetti@motorola.com> = wrote:
can some=20 one please clarify this?

From: Shetti Shrinivas-Q16945 =
Sent:=20 Friday, June 09, 2006 2:51 PM

To: 'simple@ietf.org=20 '
Cc: Kelley Sean-Q12059
Subject: FW: clarification = regarding=20 'Require' header usage in=20 draft-ietf-simple-event-list-07.txt

In the=20 scenario I've mentioned, the assumption is=20 that  UACs do have knowledge about whether = they=20 are subscribing to list URI or NOT.
So, is=20 there any harm = if  UAC uses =20 'Require:eventlist',=20 when  it knows that the = request=20 URI is a list URI?
 
thanks,
Shetti

From: Shetti Shrinivas-Q16945 =
Sent:=20 Friday, June 09, 2006 2:12 PM
To: 'simple@ietf.org'
Cc:=20 Kelley Sean-Q12059
Subject: clarification regarding = 'Require' header=20 usage in draft-ietf-simple-event-list-07.txt

hi,
above draft has following =
statement in section =
4.2
----------------------------------------------=
--------------------------

   Including "eventlist" in a "Require" header field in a SUBSCRIBE
  =
 request serves no purpose except breaking interoperability in =
certain
   cases, and is consequently NOT =
RECOMMENDED.
--------------------------------------------=
----------------------------
Can anyone clarify =
why do we discourage use of 'Require' header?
My =
perception about this header being used in SUBSCRIBE is that, it is not =
going to cause any harm or issue. I might be missing something.

I have following scenario in =
mind.
All the presence SUBSCRIBE messages land at =
a proxy. The proxy server decides to route the request to either 'RLS =
server' or 1-1 presence server.

Now, if client can use 'Require: eventlist', =
this is definite indication for the proxy to route the request to RLS =
server. Rest of the subscriptions can go to 1-1 presence =
server.
thanks and best =
regards,
Shetti
=

_______________________________________________
S= imple=20 mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

=


--  ------_=_NextPart_001_01C68EBF.7C875BD2-- --===============0637988726== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0637988726==-- From simple-bounces@ietf.org Tue Jun 13 16:09:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqFCh-0000Bn-NM; Tue, 13 Jun 2006 16:09:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqFCg-0000Bf-7Q for simple@ietf.org; Tue, 13 Jun 2006 16:09:34 -0400 Received: from [2001:5c0:8fff:fffe::4c3d] (helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqFCe-0001TR-1o for simple@ietf.org; Tue, 13 Jun 2006 16:09:34 -0400 Received: from [172.17.2.251] ([172.17.2.251]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k5DK9Ghp055019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jun 2006 15:09:19 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <448F1B64.6060803@estacado.net> Date: Tue, 13 Jun 2006 15:09:08 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Shetti Shrinivas-Q16945 Subject: Re: [Simple] FW: clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: Kelley Sean-Q12059 , 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: , Errors-To: simple-bounces@ietf.org The intention of the passage that Shetti cites below is very much that client are advised not to sent "Require: eventlist" under any circumstances. Ignoring SIP for a few moments: when you design a network with lists of resources treated as a whole, there are two possible places you can require knowledge that any particular resource is a list: either in the network or in the client. An example of the former is email lists (when you send email to a list alias, your client doesn't know that it is a list alias). When we were designing the event list extension, we felt that the email model -- in which the network knows which resources are lists -- was more flexible for network administrators. Your proposal ends up combining the disadvantages of both schemes, while adding an additional layer of fragility: both the client *and* the network need to know, a priori, whether a resource is a list. This makes provisioning of services brittle (since you need to ensure that both ends agree on whether a URI refers to a scalar or a vector). Any mismatch simply results in a failure to operate. I understand the architecture you describe -- in which the RLS is at a different server than a non-RLS notifier. There are several *far* better ways to perform the de-multiplexing described. The obvious example, following in the spirit of RFC 3087, is to use the Request-URI. Keep in mind that this is all according to site-local convention, and not subject to standardization. One example of such a scheme would be to prefix the user-portion with the five characters "list-" for all list resources. The other would be to use a list-specific authority portion for the lists (e.g. "sip:bob@example.com" for a non-list resource, "sip:friends@lists.example.com" for a list resource -- keeping in mind that the NAPTR records for "example.com" and "lists.example.com" can resolve down to the same IP address if that suits your deployment better). I will reiterate that these conventions are exactly that -- site-local conventions followed by the operator when provisioning resources. I speak with considerable experience when I assert that it is quite easy to design products that handle such site-local conventions for the purposes of de-multiplexing types of requests in an efficient manner. /a Shetti Shrinivas-Q16945 wrote: > thanks Gadi, > > So, I assume that "there is no harm including 'Require: eventlist' in > the SUBSCRIBE, when UAC knows the request URI is a list URI." > > Can we have this spec updated to indicate the above, rather than > discouraging 'Require' header usage altogether in SUBSCRIBE request? > > Request spec authors to kindly comment on this. > > best regards, > Shetti > > ------------------------------------------------------------------------ > *From:* Gadigeppa Malagund [mailto:gadigeppa@gmail.com] > *Sent:* Tuesday, June 13, 2006 12:03 PM > *To:* Shetti Shrinivas-Q16945 > *Cc:* simple@ietf.org > *Subject:* Re: [Simple] FW: clarification regarding 'Require' header > usage in draft-ietf-simple-event-list-07.txt > > Your suggestion is appropriate and enhances performance of the n/w. > > When "Supported: eventlist" is included in subscribe, proxy by default > forwards request to 1-1 presence server depending on "Event: presence". > For this if request URI is Group URI, then proxy gets "404 not found" > response from the 1-1 PS. > Proxy sees whether there is header "Supported: eventlist" and then > forwards to RLS. > > So if "Require: eventlist" is included then proxy can directly forward > this request RLS. > > So this RECOMMENDTION is not specific to presence group subscribe > however more to do with usage of "Require" header by the client. > > Note that incoming NOTIFYs from RLS have MUST "Require: eventlist" > header NOT "Supported" > > Regards, > Gadi > > On 6/13/06, *Shetti Shrinivas-Q16945* > wrote: > > can some one please clarify this? > > ------------------------------------------------------------------------ > *From:* Shetti Shrinivas-Q16945 > *Sent:* Friday, June 09, 2006 2:51 PM > > *To:* 'simple@ietf.org ' > *Cc:* Kelley Sean-Q12059 > *Subject:* FW: clarification regarding 'Require' header usage in > draft-ietf-simple-event-list-07.txt > > In the scenario I've mentioned, the assumption is that UACs do > have knowledge about whether they are subscribing to list URI or NOT. > So, is there any harm if UAC uses 'Require:eventlist', > when it knows that the request URI is a list URI? > > thanks, > Shetti > > ------------------------------------------------------------------------ > *From:* Shetti Shrinivas-Q16945 > *Sent:* Friday, June 09, 2006 2:12 PM > *To:* 'simple@ietf.org ' > *Cc:* Kelley Sean-Q12059 > *Subject:* clarification regarding 'Require' header usage in > draft-ietf-simple-event-list-07.txt > > hi, > > above draft has following statement in section 4.2 > > ------------------------------------------------------------------------ > > > Including "eventlist" in a "Require" header field in a SUBSCRIBE > request serves no purpose except breaking interoperability in certain > cases, and is consequently NOT RECOMMENDED. > > ------------------------------------------------------------------------ > > Can anyone clarify why do we discourage use of 'Require' header? > > My perception about this header being used in SUBSCRIBE is that, it is not going to cause any harm or issue. I might be missing something. > > I have following scenario in mind. > > All the presence SUBSCRIBE messages land at a proxy. The proxy server decides to route the request to either 'RLS server' or 1-1 presence server. > > Now, if client can use 'Require: eventlist', this is definite indication for the proxy to route the request to RLS server. Rest of the subscriptions can go to 1-1 presence server. > > thanks and best regards, > > Shetti > > > _______________________________________________ > 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 Wed Jun 14 01:05:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqNZ1-0000Y1-6s; Wed, 14 Jun 2006 01:05:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqNYz-0000Xw-5k for simple@ietf.org; Wed, 14 Jun 2006 01:05:09 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqNYy-0005B3-Op for simple@ietf.org; Wed, 14 Jun 2006 01:05:09 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5E556se013079 for ; Tue, 13 Jun 2006 22:05:06 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k5E5546r017525 for ; Wed, 14 Jun 2006 00:05:05 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 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] FW: clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.txt Date: Wed, 14 Jun 2006 13:04:55 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] FW: clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.txt Thread-Index: AcaPJVEhupKDm1JvQfiSUMTjU2FBOgAQt41g From: "Shetti Shrinivas-Q16945" To: "Adam Roach" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: Kelley Sean-Q12059 , 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: , Errors-To: simple-bounces@ietf.org Hi Adam, Thanks for detailed response. I understand your view point. The usecase which I have in hand is that the client always knows for sure that the req-uri is 'eventlist' uri or not. Question of mismatch doesn't arise here. I am also looking at the other possibility of indicating it as eventlist uri as per rfc3087. I am OK with the current text in the spec. The statement doesn't 'forbid' usage of 'Require' header altogether. *But, I feel that anyone who reads the spec will not understand the real purpose or reasons for it. Is it possible to put some background in the next version of the draft spec? that would be of very good help.* Coming to request URI convention: is it ok to use uri parameters? Like user=3Dphone type. For ex: sip:friends@example.com;list=3Deventlist OR sip:friends@example.com;eventlist I am not sure if it is inline with 3087 spec. Regards, Shetti -----Original Message----- From: Adam Roach [mailto:adam@estacado.net]=20 Sent: Wednesday, June 14, 2006 1:39 AM To: Shetti Shrinivas-Q16945 Cc: Gadigeppa Malagund; ben@estacado.net; jdrosen@cisco.com; simple@ietf.org; Kelley Sean-Q12059 Subject: Re: [Simple] FW: clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.txt The intention of the passage that Shetti cites below is very much that client are advised not to sent "Require: eventlist" under any circumstances. Ignoring SIP for a few moments: when you design a network with lists of resources treated as a whole, there are two possible places you can require knowledge that any particular resource is a list: either in the network or in the client. An example of the former is email lists (when you send email to a list alias, your client doesn't know that it is a list alias). When we were designing the event list extension, we felt that the email model -- in which the network knows which resources are lists -- was more flexible for network administrators. Your proposal ends up combining the disadvantages of both schemes, while adding an additional layer of fragility: both the client *and* the network need to know, a priori, whether a resource is a list. This makes provisioning of services brittle (since you need to ensure that both ends agree on whether a URI refers to a scalar or a vector). Any mismatch simply results in a failure to operate. I understand the architecture you describe -- in which the RLS is at a different server than a non-RLS notifier. There are several *far* better ways to perform the de-multiplexing described. The obvious example, following in the spirit of RFC 3087, is to use the Request-URI. Keep in mind that this is all according to site-local convention, and not subject to standardization. One example of such a scheme would be to prefix the user-portion with the five characters "list-" for all list resources. The other would be to use a list-specific authority portion for the lists (e.g.=20 "sip:bob@example.com" for a non-list resource, "sip:friends@lists.example.com" for a list resource -- keeping in mind that the NAPTR records for "example.com" and "lists.example.com" can resolve down to the same IP address if that suits your deployment better). I will reiterate that these conventions are exactly that -- site-local conventions followed by the operator when provisioning resources. I speak with considerable experience when I assert that it is quite easy to design products that handle such site-local conventions for the purposes of de-multiplexing types of requests in an efficient manner. /a Shetti Shrinivas-Q16945 wrote: > thanks Gadi, > =20 > So, I assume that "there is no harm including 'Require: eventlist' in=20 > the SUBSCRIBE, when UAC knows the request URI is a list URI." > =20 > Can we have this spec updated to indicate the above, rather than=20 > discouraging 'Require' header usage altogether in SUBSCRIBE request? > =20 > Request spec authors to kindly comment on this. > =20 > best regards, > Shetti > > ---------------------------------------------------------------------- > -- > *From:* Gadigeppa Malagund [mailto:gadigeppa@gmail.com] > *Sent:* Tuesday, June 13, 2006 12:03 PM > *To:* Shetti Shrinivas-Q16945 > *Cc:* simple@ietf.org > *Subject:* Re: [Simple] FW: clarification regarding 'Require' header=20 > usage in draft-ietf-simple-event-list-07.txt > > Your suggestion is appropriate and enhances performance of the n/w. > > When "Supported: eventlist" is included in subscribe, proxy by default > forwards request to 1-1 presence server depending on "Event: presence". > For this if request URI is Group URI, then proxy gets "404 not found"=20 > response from the 1-1 PS. > Proxy sees whether there is header "Supported: eventlist" and then=20 > forwards to RLS. > > So if "Require: eventlist" is included then proxy can directly forward > this request RLS. > > So this RECOMMENDTION is not specific to presence group subscribe=20 > however more to do with usage of "Require" header by the client. > > Note that incoming NOTIFYs from RLS have MUST "Require: eventlist"=20 > header NOT "Supported" > > Regards, > Gadi > > On 6/13/06, *Shetti Shrinivas-Q16945* > wrote: > > can some one please clarify this? > > ------------------------------------------------------------------------ > *From:* Shetti Shrinivas-Q16945 > *Sent:* Friday, June 09, 2006 2:51 PM > > *To:* 'simple@ietf.org ' > *Cc:* Kelley Sean-Q12059 > *Subject:* FW: clarification regarding 'Require' header usage in > draft-ietf-simple-event-list-07.txt > > In the scenario I've mentioned, the assumption is that UACs do > have knowledge about whether they are subscribing to list URI or NOT. > So, is there any harm if UAC uses 'Require:eventlist', > when it knows that the request URI is a list URI? > =20 > thanks, > Shetti > > ------------------------------------------------------------------------ > *From:* Shetti Shrinivas-Q16945 > *Sent:* Friday, June 09, 2006 2:12 PM > *To:* 'simple@ietf.org ' > *Cc:* Kelley Sean-Q12059 > *Subject:* clarification regarding 'Require' header usage in > draft-ietf-simple-event-list-07.txt > > hi, > > above draft has following statement in section 4.2 > > =20 > ---------------------------------------------------------------------- > -- > > > Including "eventlist" in a "Require" header field in a SUBSCRIBE > request serves no purpose except breaking interoperability in certain > cases, and is consequently NOT RECOMMENDED. > > =20 > ---------------------------------------------------------------------- > -- > > Can anyone clarify why do we discourage use of 'Require' header? > > My perception about this header being used in SUBSCRIBE is that, it is not going to cause any harm or issue. I might be missing something. > > I have following scenario in mind. > > All the presence SUBSCRIBE messages land at a proxy. The proxy server decides to route the request to either 'RLS server' or 1-1 presence server. > > Now, if client can use 'Require: eventlist', this is definite indication for the proxy to route the request to RLS server. Rest of the subscriptions can go to 1-1 presence server. > > thanks and best regards, > > Shetti > > > _______________________________________________ > 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 Wed Jun 14 07:42:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqTli-0007G0-TF; Wed, 14 Jun 2006 07:42:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqTli-0007Fv-H5 for simple@ietf.org; Wed, 14 Jun 2006 07:42:42 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqTli-0004rC-Fc for simple@ietf.org; Wed, 14 Jun 2006 07:42:42 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqTXC-0000X3-1Y for simple@ietf.org; Wed, 14 Jun 2006 07:27:43 -0400 Received: from [192.168.0.102] (ppp-70-249-158-92.dsl.rcsntx.swbell.net [70.249.158.92]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k5EBRLrl013356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jun 2006 06:27:26 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <448FF294.20506@estacado.net> Date: Wed, 14 Jun 2006 06:27:16 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shetti Shrinivas-Q16945 Subject: Re: [Simple] FW: clarification regarding 'Require' header usage in draft-ietf-simple-event-list-07.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Kelley Sean-Q12059 , 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: , Errors-To: simple-bounces@ietf.org Shetti Shrinivas-Q16945 wrote: >Is it possible to put some background in the next version of the draft spec? > > Not really. The document is in the RFC Editors' Queue. Substantive changes at this point would slow the process down considerably. >Coming to request URI convention: is it ok to use uri parameters? Like >user=phone type. >For ex: >sip:friends@example.com;list=eventlist >OR >sip:friends@example.com;eventlist > > No. SIP URI parameters are controlled by IANA, and require an RFC. See RFC 3969 and RFC 3427 for details. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 14 09:06:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqV4I-0006Dl-95; Wed, 14 Jun 2006 09:05:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqV4G-0006Bu-F1 for simple@ietf.org; Wed, 14 Jun 2006 09:05:56 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqV4E-0007xF-Oi for simple@ietf.org; Wed, 14 Jun 2006 09:05:56 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id AEB3F1944B8 for ; Wed, 14 Jun 2006 15:05:53 +0200 (CEST) Received: from [192.168.1.33] ([192.168.1.33]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 15:05:22 +0200 Mime-Version: 1.0 (Apple Message framework v624) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7ae2a04a1f6086cb7f1a1439490e9483@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-imdn-00.txt Date: Wed, 14 Jun 2006 15:06:00 +0200 To: 'simple@ietf.org' WG X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 14 Jun 2006 13:05:22.0328 (UTC) FILETIME=[31C0E180:01C68FB3] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: 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: , Errors-To: simple-bounces@ietf.org This version of the Instant Messaging Disposition Notification draft represents consensus from the design team (with very few open issues). The authors would appreciate some review and comments before the next IETF meeting in Montreal in order to allow us to properly discuss any open issues that are raised. Thanks, Hisham On May 31, 2006, at 12:50 AM, Internet-Drafts@ietf.org wrote: > 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 : Instant Message Disposition Notification > Author(s) : E. Burger, H. Khartabil > Filename : draft-ietf-simple-imdn-00.txt > Pages : 27 > Date : 2006-5-30 > > Instant Messaging (IM) refers to the transfer of messages between > users in real-time. > > This document extends Message/CPIM message format to enable endpoints > to request, create and send IM Disposition Notifications (IMDN), > including delivery and read notifications, for page-mode as well as > session mode instant messages. This document also describes how SIP > and MSRP entities behave using this extension. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-00.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-imdn-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-simple-imdn-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2006-5-30162236.I-D@ietf.org> > > _______________________________________________ > 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 Wed Jun 14 10:17:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWAu-0004qr-R1; Wed, 14 Jun 2006 10:16:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWAt-0004qX-B8 for simple@ietf.org; Wed, 14 Jun 2006 10:16:51 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqWAs-0000pV-LA for simple@ietf.org; Wed, 14 Jun 2006 10:16:51 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 337631944A6 for ; Wed, 14 Jun 2006 16:16:49 +0200 (CEST) Received: from [192.168.1.33] ([192.168.1.33]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 16:16:19 +0200 In-Reply-To: <002a01c68556$e52c5f90$d178a40a@china.huawei.com> References: <002a01c68556$e52c5f90$d178a40a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: some confusion//Re: [Simple] I-D ACTION:draft-ietf-simple-imdn-00.txt Date: Wed, 14 Jun 2006 16:16:55 +0200 To: Lunjian Mu X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 14 Jun 2006 14:16:19.0103 (UTC) FILETIME=[1AFD32F0:01C68FBD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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: , Errors-To: simple-bounces@ietf.org On Jun 1, 2006, at 10:39 AM, Lunjian Mu wrote: > Hi Burger & Khartabil, > I have some confusion about the draft: > 1.in MSRP section, it said: " For SEND requests that are IMDNs, the > sender MUST NOT request a > delivery report (an MSRP REPORT to a SEND request). I.e. It MUST > populate the request with a Failure-Report header field with the > value "no" and with a Success-Report header field with value "no" > (or > alternatively leave out that header field since it defaults to > "no").". I do not know what the reason is? > By my understanding the SIP MESSAGE can support that both delivery > report and IMDN can be requested in a SIP MESSAGE. MSRP draft defines delivery report in the draft itself while SIP MESSAGE RFC does not. The IMDN draft indicates that. > > 2.After the MSRP SEND have request a read report and the response is > not come, but the MSRP channel is disconnented, how the receiver can > response the read report? can using SIP MESSAGE, or reconnet the MSRP > channel? It is common scenario for Store and Forward IM. The read report is like any other SEND request. You would follow the procedures defined in MSRP base draft to reconnect and send. I guess the read question is: should the reports still be sent even if the TCP connection was lost? I'm on the fence on that one. Any comments by others? Hisham > > Best regards, > > Lunjian Mu > > ----- Original Message ----- > From: > To: > Cc: > Sent: Wednesday, May 31, 2006 6:50 AM > Subject: [Simple] I-D ACTION:draft-ietf-simple-imdn-00.txt > > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the SIP for Instant Messaging and >> Presence Leveraging Extensions Working Group of the IETF. >> >> Title : Instant Message Disposition Notification >> Author(s) : E. Burger, H. Khartabil >> Filename : draft-ietf-simple-imdn-00.txt >> Pages : 27 >> Date : 2006-5-30 >> >> Instant Messaging (IM) refers to the transfer of messages between >> users in real-time. >> >> This document extends Message/CPIM message format to enable endpoints >> to request, create and send IM Disposition Notifications (IMDN), >> including delivery and read notifications, for page-mode as well as >> session mode instant messages. This document also describes how SIP >> and MSRP entities behave using this extension. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-00.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-imdn-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-simple-imdn-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> > > > ----------------------------------------------------------------------- > --------- > > >> _______________________________________________ >> 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 Wed Jun 14 10:18:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWCV-00061I-HQ; Wed, 14 Jun 2006 10:18:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqWCU-00061D-GJ for simple@ietf.org; Wed, 14 Jun 2006 10:18:30 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqWCU-00027Y-Et for simple@ietf.org; Wed, 14 Jun 2006 10:18:30 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqWCR-0003Rj-AK for simple@ietf.org; Wed, 14 Jun 2006 10:18:30 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id B285B1944A6 for ; Wed, 14 Jun 2006 16:18:25 +0200 (CEST) Received: from [192.168.1.33] ([192.168.1.33]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 16:17:55 +0200 In-Reply-To: <31721CD4D0090B4BA32CBA5E2C40AE9002539835@carrera.eu.tieto.com> References: <31721CD4D0090B4BA32CBA5E2C40AE9002539835@carrera.eu.tieto.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=UTF-8; format=flowed Message-Id: <752c59f95b7be1b7b32df7cdb487cd47@telio.no> Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Subject: Re: [Simple] Filtering - including attributes? Date: Wed, 14 Jun 2006 16:18:32 +0200 To: X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 14 Jun 2006 14:17:55.0713 (UTC) FILETIME=[5492B710:01C68FBD] X-Spam-Score: -2.6 (--) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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: , Errors-To: simple-bounces@ietf.org On Jun 2, 2006, at 1:41 PM, wrote: > Hi, > > I have one question about filtering and I am unable to find an answer=20= > in specifications =E2=98=B9 . Could anyone help me please? > > I have the following document: > > > > value > > > > Suppose all elements and attributes in that document are optional.=20 > What is the correct result of filtering by the following filter? > > > > > /root/element > > > > > > Is it the whole source document? Or, is it ""=20= > only? What about the 'attr' attribute? Is it included too? it is "" only unless the sub-element is a=20 mandatory element. The attribute is only included if the it is=20 mandatory. Hisham > > Thanks, in advance. > > Best regards, > > Michal Burda > _______________________________________________ > 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 Wed Jun 14 20:03:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqfKV-00083Q-EZ; Wed, 14 Jun 2006 20:03:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqfKU-00083L-HT for simple@ietf.org; Wed, 14 Jun 2006 20:03:22 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqfKQ-0006ra-T8 for simple@ietf.org; Wed, 14 Jun 2006 20:03:22 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0V00GFIKUI0X@szxga02-in.huawei.com> for simple@ietf.org; Thu, 15 Jun 2006 08:18:19 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0V008Z3KUITM@szxga02-in.huawei.com> for simple@ietf.org; Thu, 15 Jun 2006 08:18:18 +0800 (CST) Received: from ny3106042310b ([58.191.155.21]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0V00JC1L079T@szxml01-in.huawei.com>; Thu, 15 Jun 2006 08:21:50 +0800 (CST) Date: Thu, 15 Jun 2006 08:02:08 +0800 From: Lunjian Mu Subject: Re: some confusion//Re: [Simple] I-D ACTION:draft-ietf-simple-imdn-00.txt To: Hisham Khartabil Message-id: <002401c6900e$f6fd38d0$c1010a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <002a01c68556$e52c5f90$d178a40a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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: , Errors-To: simple-bounces@ietf.org ----- Original Message ----- From: "Hisham Khartabil" To: "Lunjian Mu" Cc: Sent: Wednesday, June 14, 2006 10:16 PM Subject: Re: some confusion//Re: [Simple] I-D ACTION:draft-ietf-simple-imdn-00.txt > > On Jun 1, 2006, at 10:39 AM, Lunjian Mu wrote: > >> Hi Burger & Khartabil, >> I have some confusion about the draft: >> 1.in MSRP section, it said: " For SEND requests that are IMDNs, the >> sender MUST NOT request a >> delivery report (an MSRP REPORT to a SEND request). I.e. It MUST >> populate the request with a Failure-Report header field with the >> value "no" and with a Success-Report header field with value "no" >> (or >> alternatively leave out that header field since it defaults to >> "no").". I do not know what the reason is? >> By my understanding the SIP MESSAGE can support that both delivery >> report and IMDN can be requested in a SIP MESSAGE. > > MSRP draft defines delivery report in the draft itself while SIP > MESSAGE RFC does not. The IMDN draft indicates that. What my question is: why the MSRP can not support both delivery report and IMDN in one MSRP SEND? >> >> 2.After the MSRP SEND have request a read report and the response is >> not come, but the MSRP channel is disconnented, how the receiver can >> response the read report? can using SIP MESSAGE, or reconnet the MSRP >> channel? It is common scenario for Store and Forward IM. > > The read report is like any other SEND request. You would follow the > procedures defined in MSRP base draft to reconnect and send. I guess > the read question is: should the reports still be sent even if the TCP > connection was lost? I'm on the fence on that one. Any comments by > others? > > Hisham > >> >> Best regards, >> >> Lunjian Mu >> >> ----- Original Message ----- >> From: >> To: >> Cc: >> Sent: Wednesday, May 31, 2006 6:50 AM >> Subject: [Simple] I-D ACTION:draft-ietf-simple-imdn-00.txt >> >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the SIP for Instant Messaging and >>> Presence Leveraging Extensions Working Group of the IETF. >>> >>> Title : Instant Message Disposition Notification >>> Author(s) : E. Burger, H. Khartabil >>> Filename : draft-ietf-simple-imdn-00.txt >>> Pages : 27 >>> Date : 2006-5-30 >>> >>> Instant Messaging (IM) refers to the transfer of messages between >>> users in real-time. >>> >>> This document extends Message/CPIM message format to enable endpoints >>> to request, create and send IM Disposition Notifications (IMDN), >>> including delivery and read notifications, for page-mode as well as >>> session mode instant messages. This document also describes how SIP >>> and MSRP entities behave using this extension. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-00.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-imdn-00.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE /internet-drafts/draft-ietf-simple-imdn-00.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >> >> >> ----------------------------------------------------------------------- >> --------- >> >> >>> _______________________________________________ >>> 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 Jun 16 09:44:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrEby-0007qa-J7; Fri, 16 Jun 2006 09:43:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrEbx-0007qU-Do for simple@ietf.org; Fri, 16 Jun 2006 09:43:45 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrEbw-0004mo-3L for simple@ietf.org; Fri, 16 Jun 2006 09:43:45 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k5GDhhLp021812 for ; Fri, 16 Jun 2006 06:43:43 -0700 (MST) Received: from zuk35exm61.ds.mot.com (zuk35exm61.ea.mot.com [10.178.1.40]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k5GDhgai020686 for ; Fri, 16 Jun 2006 08:43:42 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Jun 2006 14:43:41 +0100 Message-ID: <70213C6261091D4289C9E245E092640B01061BE5@zuk35exm61.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RLMI schema issue in draft-ietf-simple-event-list-07 Thread-Index: AcaOwtcHu/DdFZICSkuD67mI9bnr0Q== From: "Joyeux Nicolas-r58909" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Simple] RLMI schema issue in draft-ietf-simple-event-list-07 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: , Errors-To: simple-bounces@ietf.org Hello, =20 I am working with the internet draft "draft-ietf-simple-event-list-07" and I have an issue with the XML schema of the Resource List Meta-Information document provided page 13 and 14. =20 The fact is that when parsing this schema with a tool (XMLSpy 2006), I have the following error : =20 The schema doesn't appear to be valid by itself . Element is not allowed under element . Reason: The following elements are expected at this location: Error location: xs:schema / xs:element / xs:complexType / xs:attribute / xs:restriction Details cvc-model-group: Element unexpected by type 'xs:attribute' of element . cvc-elt.5.2.1: The element is not valid with respect to the actual type definition 'xs:attribute'. =20 =20 Could you please check that error ?=20 =20 Moreover I have detected a typo error page 15, in the XML example, a double quote is missing :=20 =3D> Regards, =20 Nicolas J. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jun 18 23:27:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsAQ2-0004gy-Li; Sun, 18 Jun 2006 23:27:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsAQ1-0004gt-IX for simple@ietf.org; Sun, 18 Jun 2006 23:27:17 -0400 Received: from smtp3.infineon.com ([203.126.106.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsAPx-0003kF-3R for simple@ietf.org; Sun, 18 Jun 2006 23:27:17 -0400 Received: from unknown (HELO sinse212.ap.infineon.com) ([172.17.65.148]) by smtp3.infineon.com with ESMTP; 19 Jun 2006 11:27:10 +0800 X-SBRS: None Received: from blrse201.ap.infineon.com ([172.20.20.12]) by sinse212.ap.infineon.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Jun 2006 11:27:09 +0800 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 Date: Mon, 19 Jun 2006 08:56:44 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Generating Response Thread-Index: AcaS78xMK0eer9+8TQKt75CK/UNDpw== From: To: X-OriginalArrivalTime: 19 Jun 2006 03:27:09.0469 (UTC) FILETIME=[3F4374D0:01C69350] X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Simple] Generating Response 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: , Errors-To: simple-bounces@ietf.org Hi All, In draft-ietf-simple-message-session-14.txt section 7.2=20 "If an MSRP endpoint receives a request that either contains a Failure-Report header field value of "yes", or does not contain a Failure-Report header field at all, it MUST immediately generate a response. Likewise, if an MSRP endpoint receives a request that contains a Failure-Report header field value of "partial", and the receiver is unable to process the request, it SHOULD immediately generate a response." Is it means that generating response totally depends on the Failure-Report header field value? Consider the below example=20 MSRP 248 a786hjs2 SEND To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp Success-Report: yes Failure-Report: no Message-ID: 87652\r\n Byte-Range: 1-25/25\r\n Content-Type: text/plain\r\n \r\n Hey Bob, are you there?\r\n -------a786hjs2$\r\n =20 Will receiver has to generate the 200 OK transaction response or not? Regards Amit=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 19 01:01:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsBsZ-0007Da-3d; Mon, 19 Jun 2006 01:00:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsBsY-0007DV-0O for simple@ietf.org; Mon, 19 Jun 2006 01:00:50 -0400 Received: from nav2.lgsoftindia.com ([203.200.13.13] helo=NAV2.LGE.NET) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FsBsW-0007EI-Db for simple@ietf.org; Mon, 19 Jun 2006 01:00:49 -0400 Received: (from IT [192.168.1.34]) by NAV2.LGE.NET (SMSSMTP 4.1.2.20) with SMTP id M2006061910243321782 for ; Mon, 19 Jun 2006 10:24:33 +0530 X-SEF-Processed: 5_0_0_910__2006_06_19_10_38_14 Received: from Unknown [172.24.1.101] by IT - SurfControl E-mail Filter (5.0); Mon, 19 Jun 2006 10:38:14 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Simple] Generating Response Date: Mon, 19 Jun 2006 10:29:32 +0530 Message-ID: <607194575BD8CE46BCC8D747996FA7F9012D8A1A@SI-RD10-MS01.LGE.NET> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Generating Response Thread-Index: AcaS78xMK0eer9+8TQKt75CK/UNDpwAbLAqw From: "Giridhar A N" To: X-Spam-Score: 0.4 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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="===============1131089871==" Errors-To: simple-bounces@ietf.org --===============1131089871== Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 SGkgQW1pdCwNCglUaGUgZHJhZnQgY2xlYXJseSBzYXlzIHRoYXQgZ2VuZXJhdGluZyByZXNw b25zZSBkZXBlbmRzIG9uIHRoZQ0KRmFpbHVyZS1yZXBvcnQgaGVhZGVyIGZpZWxkIHZhbHVl LiBQbC4gY2hlY2sgdGhlIGZvbGxvd2luZyBzZWN0aW9uDQooNy4xLjQuICBHZW5lcmF0aW5n IEZhaWx1cmUgUmVwb3J0cykgd2hpY2ggc2F5czoNCg0KIiBJZiB0aGUgZW5kcG9pbnQgcmVj ZWl2ZXMgYSBTRU5EIHJlcXVlc3Qgd2l0aCBhIEZhaWx1cmUtUmVwb3J0IGhlYWRlcg0KICAg ZmllbGQgdmFsdWUgb2YgIm5vIiwgdGhlbiBpdCBNVVNUIE5PVCBzZW5kIGEgZmFpbHVyZSBS RVBPUlQgcmVxdWVzdCwNCiAgIGFuZCBNVVNUIE5PVCBzZW5kIGEgdHJhbnNhY3Rpb24gcmVz cG9uc2UuIg0KDQpSZ2RzDQpHaXJpZGhhcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogQW1pdGt1bWFyLkdvZWxAaW5maW5lb24uY29tIFttYWlsdG86QW1pdGt1bWFy LkdvZWxAaW5maW5lb24uY29tXSANClNlbnQ6IE1vbmRheSwgSnVuZSAxOSwgMjAwNiA4OjU3 IEFNDQpUbzogc2ltcGxlQGlldGYub3JnDQpTdWJqZWN0OiBbU2ltcGxlXSBHZW5lcmF0aW5n IFJlc3BvbnNlDQoNCkhpIEFsbCwNCg0KSW4gZHJhZnQtaWV0Zi1zaW1wbGUtbWVzc2FnZS1z ZXNzaW9uLTE0LnR4dCBzZWN0aW9uIDcuMiANCg0KIklmIGFuIE1TUlAgZW5kcG9pbnQgcmVj ZWl2ZXMgYSByZXF1ZXN0IHRoYXQgZWl0aGVyIGNvbnRhaW5zIGENCkZhaWx1cmUtUmVwb3J0 IGhlYWRlciBmaWVsZCB2YWx1ZSBvZiAieWVzIiwgb3IgZG9lcyBub3QgY29udGFpbiBhDQpG YWlsdXJlLVJlcG9ydCBoZWFkZXIgZmllbGQgYXQgYWxsLCBpdCBNVVNUIGltbWVkaWF0ZWx5 IGdlbmVyYXRlIGENCnJlc3BvbnNlLiAgTGlrZXdpc2UsIGlmIGFuIE1TUlAgZW5kcG9pbnQg cmVjZWl2ZXMgYSByZXF1ZXN0IHRoYXQNCmNvbnRhaW5zIGEgRmFpbHVyZS1SZXBvcnQgaGVh ZGVyIGZpZWxkIHZhbHVlIG9mICJwYXJ0aWFsIiwgYW5kIHRoZQ0KcmVjZWl2ZXIgaXMgdW5h YmxlIHRvIHByb2Nlc3MgdGhlIHJlcXVlc3QsIGl0IFNIT1VMRCBpbW1lZGlhdGVseQ0KZ2Vu ZXJhdGUgYSByZXNwb25zZS4iDQoNCklzIGl0IG1lYW5zIHRoYXQgZ2VuZXJhdGluZyByZXNw b25zZSB0b3RhbGx5IGRlcGVuZHMgb24gdGhlDQpGYWlsdXJlLVJlcG9ydCBoZWFkZXIgZmll bGQgdmFsdWU/DQoNCkNvbnNpZGVyIHRoZSBiZWxvdyBleGFtcGxlIA0KDQpNU1JQIDI0OCBh Nzg2aGpzMiBTRU5EDQpUby1QYXRoOiBtc3JwOi8vYmlsb3hpLmV4YW1wbGUuY29tOjEyNzYz L2tqaGQzN3MyczI7dGNwDQpGcm9tLVBhdGg6IG1zcnA6Ly9hdGxhbnRhLmV4YW1wbGUuY29t Ojc2NTQvanNoQTd3ZTt0Y3ANClN1Y2Nlc3MtUmVwb3J0OiB5ZXMNCkZhaWx1cmUtUmVwb3J0 OiBubw0KTWVzc2FnZS1JRDogODc2NTJcclxuDQpCeXRlLVJhbmdlOiAxLTI1LzI1XHJcbg0K Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluXHJcbg0KXHJcbg0KSGV5IEJvYiwgYXJlIHlvdSB0 aGVyZT9cclxuDQotLS0tLS0tYTc4NmhqczIkXHJcbiAgIA0KDQoNCldpbGwgcmVjZWl2ZXIg aGFzIHRvIGdlbmVyYXRlIHRoZSAyMDAgT0sgdHJhbnNhY3Rpb24gcmVzcG9uc2Ugb3Igbm90 Pw0KDQpSZWdhcmRzDQpBbWl0IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KU2ltcGxlIG1haWxpbmcgbGlzdA0KU2ltcGxlQGlldGYub3Jn DQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaW1wbGUNCg0KDQoN Cg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjDQpUSElTIEVNQUlMIE1FU1NBR0UgSVMgRk9SIFRIRSBTT0xFIFVTRSBPRiBUSEUg SU5URU5ERUQNClJFQ0lQSUVOVChTKSBBTkQgTUFZIENPTlRBSU4gQ09ORklERU5USUFMIEFO RCBQUklWSUxFR0VEDQpJTkZPUk1BVElPTi4gQU5ZIFVOQVVUSE9SSVpFRCBSRVZJRVcsIFVT RSwgRElTQ0xPU1VSRSBPUg0KRElTVFJJQlVUSU9OIElTIFBST0hJQklURUQuQkVGT1JFIE9Q RU5JTkcgQU5ZIEFUVEFDSE1FTlRTDQpQTEVBU0UgQ0hFQ0sgRk9SIFZJUlVTRVMgQU5EIERF RkVDVFMuSUYgWU9VIEFSRSBOT1QgVEhFDQpJTlRFTkRFRCBSRUNJUElFTlQsIFBMRUFTRSBO T1RJRlkgVVMgSU1NRURJQVRFTFkgQlkgUkVQTFkNCkUtTUFJTCBBTkQgREVMRVRFIFRIRSBP UklHSU5BTCBNRVNTQUdFLg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIw== --===============1131089871== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1131089871==-- From simple-bounces@ietf.org Tue Jun 20 09:48:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsgaf-0005su-Cd; Tue, 20 Jun 2006 09:48:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsgad-0005q0-CP for simple@ietf.org; Tue, 20 Jun 2006 09:48:23 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsgac-0001jG-MS for simple@ietf.org; Tue, 20 Jun 2006 09:48:23 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5KDmJ5E015168 for ; Tue, 20 Jun 2006 16:48:22 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 16:47:52 +0300 Received: from [127.0.0.1] ([172.21.35.54]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 20 Jun 2006 16:47:53 +0300 Message-ID: <4497FC88.5090207@nokia.com> Date: Tue, 20 Jun 2006 16:47:52 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "'simple@ietf.org'" Content-Type: multipart/mixed; boundary="------------000600010604070403000908" X-OriginalArrivalTime: 20 Jun 2006 13:47:53.0550 (UTC) FILETIME=[20E0F6E0:01C69470] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Subject: [Simple] [Fwd: I-D ACTION:draft-garcia-simple-presence-dictionary-00.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: , Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --------------000600010604070403000908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi: I have submitted an Internet Draft that proposes to use Sigcomp together with a presence-specific static dictionary as a compression mechanism for presence. This tries to mitigate the problem of lengthy presence XML documents. The I-D should include all the strings that we can get today in presence XML documents, although in this initial version of the draft I just went through the most relevant ones. If you have any comments, please send them to the list and the author. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland --------------000600010604070403000908 Content-Type: message/rfc822; name*0="I-D ACTION:draft-garcia-simple-presence-dictionary-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="I-D ACTION:draft-garcia-simple-presence-dictionary-00.txt" Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebe104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 22:51:19 +0300 Received: from esebh107.NOE.Nokia.com ([172.21.143.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 22:51:19 +0300 Received: from esdks003.ntc.nokia.com ([172.21.138.158]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 22:51:19 +0300 X-Scanned: Mon, 19 Jun 2006 22:50:40 +0300 Nokia Message Protector V1.3.35 2005042208 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id k5JJoeW0027385; Mon, 19 Jun 2006 22:50:40 +0300 Received: from mgw-ext01.nokia.com (131.228.20.93) by esdks003.ntc.nokia.com 00dV63t2; Mon, 19 Jun 2006 22:50:39 EEST Received: from megatron.ietf.org (optimus.ietf.org [156.154.16.145]) by mgw-ext01.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5JJoZeg001526 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 19 Jun 2006 22:50:36 +0300 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsPlH-0006qf-9w; Mon, 19 Jun 2006 15:50:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsPl4-0006j3-KR for i-d-announce@ietf.org; Mon, 19 Jun 2006 15:50:02 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsPl4-0000S9-0y for i-d-announce@ietf.org; Mon, 19 Jun 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5JJo1Rx002255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FsPl3-0007YH-Gt for i-d-announce@ietf.org; Mon, 19 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: From: "ext i-d-announce-bounces@ietf.org" Message-Id: Date: Mon, 19 Jun 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: I-D ACTION:draft-garcia-simple-presence-dictionary-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org Return-Path: i-d-announce-bounces@ietf.org X-OriginalArrivalTime: 19 Jun 2006 19:51:19.0595 (UTC) FILETIME=[BBE19FB0:01C693D9] --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Presence-specific Dictionary for the Signaling Compression (Sigcomp) Framework Author(s) : M. Garcia-Martin Filename : draft-garcia-simple-presence-dictionary-00.txt Pages : 16 Date : 2006-6-19 The Session Initiation Protocol (SIP) [4] is a text-based protocol for initiating and managing communication sessions. The protocol is extended by the SIP-events framework [5] to provide, e.g., subscriptions and notifications to presence information that are carried in presence documents [8]. SIP can be compressed by using Signaling Compression (SigComp) [2], which is enhanced by using the SIP/SDP dictionary [7] to achieve better compression rates. However, the SIP/SDP dictionary [7] is not able to increase the compression factor of (typically lengthy) presence documents. This memo defines the presence-specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-garcia-simple-presence-dictionary-00.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-garcia-simple-presence-dictionary-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-garcia-simple-presence-dictionary-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-19113109.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-garcia-simple-presence-dictionary-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-garcia-simple-presence-dictionary-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-19113109.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --------------000600010604070403000908 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --------------000600010604070403000908-- From simple-bounces@ietf.org Wed Jun 21 03:35:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsxF6-00042e-Fx; Wed, 21 Jun 2006 03:35:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsxF5-00042Q-3A for simple@ietf.org; Wed, 21 Jun 2006 03:35:15 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsxF3-0000Wm-JN for simple@ietf.org; Wed, 21 Jun 2006 03:35:15 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5L7Z1r1019947; Wed, 21 Jun 2006 10:35:03 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 10:35:02 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 10:35:01 +0300 Received: from 172.21.34.145 ([172.21.34.145]) by esebe105.NOE.Nokia.com ([172.21.143.53]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Jun 2006 07:35:00 +0000 Received: from esdhcp034145.research.nokia.com by esebe105.noe.nokia.com; 21 Jun 2006 10:35:01 +0300 Subject: Re: [Simple] RLMI schema issue in draft-ietf-simple-event-list-07 From: Jari Urpalainen To: ext Joyeux Nicolas-r58909 , Adam Roach In-Reply-To: <70213C6261091D4289C9E245E092640B01061BE5@zuk35exm61.ds.mot.com> References: <70213C6261091D4289C9E245E092640B01061BE5@zuk35exm61.ds.mot.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 21 Jun 2006 10:35:01 +0300 Message-Id: <1150875301.28491.27.camel@esdhcp034145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) X-OriginalArrivalTime: 21 Jun 2006 07:35:01.0614 (UTC) FILETIME=[349430E0:01C69505] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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: , Errors-To: simple-bounces@ietf.org On Fri, 2006-06-16 at 14:43 +0100, ext Joyeux Nicolas-r58909 wrote: > Hello, > > I am working with the internet draft "draft-ietf-simple-event-list-07" > and I have an issue with the XML schema of the Resource List > Meta-Information document provided page 13 and 14. > > The fact is that when parsing this schema with a tool (XMLSpy 2006), I > have the following error : > > The schema doesn't appear to be valid by itself . > Element is not allowed under element . > Reason: The following elements are expected at this location: > > Error location: xs:schema / xs:element / xs:complexType / xs:attribute > / xs:restriction > Details > cvc-model-group: Element unexpected by type > 'xs:attribute' of element . > cvc-elt.5.2.1: The element is not valid with respect > to the actual type definition 'xs:attribute'. > > > Could you please check that error ? > right, there's a missing statement for "state" attribute, if inlined schema types are being used, the schema should e.g. be: i.e. simpleType tag is missing (although what other type could an attribute have ;-)). > Moreover I have detected a typo error page 15, in the XML example, a > double quote is missing : > > > > Regards, > > Nicolas J. there's also another additional double quote typo in the schema: While the schema puts some extension points with and the default value for processContents is "strict", i think the intention is to have processContents="lax" instead to allow additional elements without further complications. Also there are some bugs in pidf examples, the "id" attribute of is of type so the "id" value may not start with a number. Also there has been a BCP to register schemas in IANA, which seems to be missing. Although this i-d is in rfc-ed queue, I'll hope these can still be fixed ? btw. although i might sound like a broken record, there's a schema tool available at br,Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 21 03:47:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsxQV-0003b0-6g; Wed, 21 Jun 2006 03:47:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsxQT-0003av-Rf for simple@ietf.org; Wed, 21 Jun 2006 03:47:01 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsxQS-0002RY-Dj for simple@ietf.org; Wed, 21 Jun 2006 03:47:01 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5L7kxI0009449 for ; Wed, 21 Jun 2006 10:46:59 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 10:46:59 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 10:46:58 +0300 Received: from 172.21.34.145 ([172.21.34.145]) by esebe105.NOE.Nokia.com ([172.21.143.53]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Jun 2006 07:46:57 +0000 Received: from esdhcp034145.research.nokia.com by esebe105.noe.nokia.com; 21 Jun 2006 10:46:58 +0300 From: Jari Urpalainen To: simple@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 21 Jun 2006 10:46:58 +0300 Message-Id: <1150876018.29061.7.camel@esdhcp034145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) X-OriginalArrivalTime: 21 Jun 2006 07:46:58.0811 (UTC) FILETIME=[E00FC4B0:01C69506] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Simple] xcap with webdav 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: , Errors-To: simple-bounces@ietf.org Hi all! Once XCAP has virtually been finished, there are still some missing features that WebDAV already provides (locks, properties, collections, acls etc.). I have tried to put some conventions about the co-operation of XCAP with WebDAV in the i-d Any comments ? br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 21 17:44:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtAVJ-0004wo-Ii; Wed, 21 Jun 2006 17:44:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtASX-0003Hc-3p for simple@ietf.org; Wed, 21 Jun 2006 17:42:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtADu-0007TN-N1 for simple@ietf.org; Wed, 21 Jun 2006 17:26:54 -0400 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtA6N-0006Lw-9V for simple@ietf.org; Wed, 21 Jun 2006 17:19:09 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.6/8.13.6) with ESMTP id k5LLJ6ed130790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 21 Jun 2006 21:19:06 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k5LLLRF5084746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 21 Jun 2006 23:21:27 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k5LLJ56h011888 for ; Wed, 21 Jun 2006 23:19:05 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5LLJ55D011885 for ; Wed, 21 Jun 2006 23:19:05 +0200 To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Thu, 22 Jun 2006 00:22:05 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.1HF123 | April 14, 2006) at 22/06/2006 00:21:26, Serialize complete at 22/06/2006 00:21:26 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: -2.4 (--) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Simple] SIMPLE Problem Statement 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: , Errors-To: simple-bounces@ietf.org Tim Rang, Edwin Aoki and me have created the following draft. http://www.ietf.org/internet-drafts/draft-rang-simple-problem-statement-00.txt SIMPLE based presence systems today require a unique dialog to be stablished between every unique presentity-watcher pair. Even hough some optimizations have been suggested to the protocol, in cases where many users within a domain are subscribed to a number of users in another domain, the number of subscriptions between domains quickly becomes an issue. This document examines the scaling issue and concludes that additional optimizations are necessary. It also suggests an initial list of requirements for these optimizations. As I recall at the end of the last SIMPLE meeting a charter item regarding scaling of SIMPLE presence systems was discussed and a problem statement was needed. I hope that the above draft will help. --Avshalom _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 22 21:48:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftaly-000163-9Q; Thu, 22 Jun 2006 21:47:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftalw-0000zb-P3 for simple@ietf.org; Thu, 22 Jun 2006 21:47:48 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftalr-0004Yu-2G for simple@ietf.org; Thu, 22 Jun 2006 21:47:48 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1A006LJID3PR@szxga01-in.huawei.com> for simple@ietf.org; Fri, 23 Jun 2006 09:48:39 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1A0058MID3Z8@szxga01-in.huawei.com> for simple@ietf.org; Fri, 23 Jun 2006 09:48:39 +0800 (CST) Received: from z53160 ([10.164.5.15]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1A00F5KIS4SU@szxml04-in.huawei.com> for simple@ietf.org; Fri, 23 Jun 2006 09:57:44 +0800 (CST) Date: Fri, 23 Jun 2006 09:46:55 +0800 From: Harrison Zhou To: Robert Sparks , hisham.khartabil@telio.no, Jonathan Rosenberg , Spencer Dawkins , Miguel.An.Garcia@nokia.com, noga.tor@gmail.com, x.victoria@gmail.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcaWZufsS0MHbGCfT2mj7dQbvbI72A== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Simple WG Subject: [Simple] Could you review my draft please? 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: , Errors-To: simple-bounces@ietf.org Dear sip experts, I've written a draft and this draft describe a new method for the Presence Server to process presence in inter-domain scenarios . The new method void duplicated messaging between Presence Servers. I am interested in SIMPLE and will work on it. This is my first draft and I hope someone can review my draft and give me some comments. Thanks! you can fetch a copy from: http://www.ietf.org/internet-drafts/draft-zhou-simple-hierarchical-presence- 00.txt Regards, Hong _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 23 06:32:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftixi-0007eB-6y; Fri, 23 Jun 2006 06:32:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftixh-0007YW-0F for Simple@ietf.org; Fri, 23 Jun 2006 06:32:29 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftixf-0000zC-EM for Simple@ietf.org; Fri, 23 Jun 2006 06:32:28 -0400 Received: by ug-out-1314.google.com with SMTP id m3so998308uge for ; Fri, 23 Jun 2006 03:32:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=r0EJMU1ohzNMtyxkYAq+Pia5mR4Vm42HVPgLXGc2/ZL2xJqc7sLU07isHXXskCZKs3kr9hfnkWBDmv+SeO6DSyuOVj6n78cACYZMXTNg+bjYvT2qbDtAvicnNOzgQHD0JU0VAokyWE4YZgAsqSCGpD7nKC4naJOipVVqEyJheP4= Received: by 10.78.151.15 with SMTP id y15mr1214765hud; Fri, 23 Jun 2006 03:32:24 -0700 (PDT) Received: by 10.78.46.13 with HTTP; Fri, 23 Jun 2006 03:32:24 -0700 (PDT) Message-ID: <6405cd720606230332y524fc774ua239cbedea600b54@mail.gmail.com> Date: Fri, 23 Jun 2006 12:32:24 +0200 From: jos4711@googlemail.com To: Simple@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.7 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Subject: [Simple] MSRP-Size of Chunks 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: , Errors-To: simple-bounces@ietf.org Hi! I have q question about the size of the chunks in the MSRP. How come its 2048 Bytes? What is the base for this size? Thank you! _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 23 09:13:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtlT2-0006ub-WF; Fri, 23 Jun 2006 09:13:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtlT0-0006s4-W7 for Simple@ietf.org; Fri, 23 Jun 2006 09:12:59 -0400 Received: from [2001:5c0:8fff:fffe::4c3d] (helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtlSy-0004dx-PJ for Simple@ietf.org; Fri, 23 Jun 2006 09:12:58 -0400 Received: from [192.168.1.102] (c-67-164-146-154.hsd1.tx.comcast.net [67.164.146.154]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k5NDCe4b085679 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 23 Jun 2006 08:12:45 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <6405cd720606230332y524fc774ua239cbedea600b54@mail.gmail.com> References: <6405cd720606230332y524fc774ua239cbedea600b54@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0537E69D-4B0D-4C6A-812A-9755A8F799FC@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP-Size of Chunks Date: Fri, 23 Jun 2006 08:12:34 -0500 To: jos4711@googlemail.com X-Mailer: Apple Mail (2.750) X-Spam-Score: 1.8 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: , Errors-To: simple-bounces@ietf.org It was a size that transfers quickly on most modern communication technologies. But mostly we just picked a number. Keep in mind that it is not a "chunk-size" per se. It is a size above which the sender must make the message interruptible. Actual chunks can be larger or smaller. On Jun 23, 2006, at 5:32 AM, jos4711@googlemail.com wrote: > Hi! > I have q question about the size of the chunks in the MSRP. > How come its 2048 Bytes? What is the base for this size? > > Thank you! > > _______________________________________________ > 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 Jun 23 10:50:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftmz9-00048l-LL; Fri, 23 Jun 2006 10:50:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftmyy-0003FW-8X; Fri, 23 Jun 2006 10:50:04 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftmyw-0007cf-01; Fri, 23 Jun 2006 10:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5NEo1Rx008613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jun 2006 14:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ftmyv-00070h-Ml; Fri, 23 Jun 2006 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 23 Jun 2006 10:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-messaging-requirements-00.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: , Errors-To: simple-bounces@ietf.org --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 : Advanced Instant Messaging Requirements for the Session Initiation Protocol (SIP) Author(s) : M. Isomaki, J. Rosenberg Filename : draft-ietf-simple-messaging-requirements-00.txt Pages : 11 Date : 2006-6-23 Session Initiation Protocol (SIP) supports the basic instant messaging service in both page and session mode. This document defines a set of requirements for instant messaging capabilities that are beyond the scope of the baseline specifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-messaging-requirements-00.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-messaging-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-messaging-requirements-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart 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: <2006-6-23095850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-messaging-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-messaging-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-23095850.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Fri Jun 23 19:39:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtvF7-0002l2-3Q; Fri, 23 Jun 2006 19:39:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtvF5-0002kf-8d for simple@ietf.org; Fri, 23 Jun 2006 19:39:15 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtsNa-0002DG-F0 for simple@ietf.org; Fri, 23 Jun 2006 16:35:50 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fts5O-0008UE-SP for simple@ietf.org; Fri, 23 Jun 2006 16:17:04 -0400 X-IronPort-AV: i="4.06,170,1149480000"; d="scan'208"; a="34556000:sNHT44354592" X-MimeOLE: Produced By Microsoft Exchange V6.5 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] I-D ACTION:draft-ietf-simple-imdn-00.txt Date: Fri, 23 Jun 2006 16:18:25 -0400 Message-ID: <330A23D8336C0346B5C1A5BB196666470317AB1E@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-imdn-00.txt Thread-Index: AcaPs5DcfgnvXg9FSMeOkgQFjc4sIwG21dHQ From: "Burger, Eric" To: X-Spam-Score: -2.5 (--) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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: , Errors-To: simple-bounces@ietf.org Folks - It has been a week, and we've heard boo on the topic. Every time we bring up, "Is IMDN important?" we get a ton of "oh, yes, it is!" However, we need to get SOME feedback. Just for grins, there are a few "oopses" in the draft. Can you find them? Please give us a review! -- - Eric -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: Wednesday, June 14, 2006 9:06 AM To: 'simple@ietf.org' WG Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-imdn-00.txt=20 This version of the Instant Messaging Disposition Notification draft=20 represents consensus from the design team (with very few open issues).=20 The authors would appreciate some review and comments before the next=20 IETF meeting in Montreal in order to allow us to properly discuss any=20 open issues that are raised. Thanks, Hisham On May 31, 2006, at 12:50 AM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the SIP for Instant Messaging and=20 > Presence Leveraging Extensions Working Group of the IETF. > > Title : Instant Message Disposition Notification > Author(s) : E. Burger, H. Khartabil > Filename : draft-ietf-simple-imdn-00.txt > Pages : 27 > Date : 2006-5-30 > =09 > Instant Messaging (IM) refers to the transfer of messages between > users in real-time. > > This document extends Message/CPIM message format to enable endpoints > to request, create and send IM Disposition Notifications (IMDN), > including delivery and read notifications, for page-mode as well as > session mode instant messages. This document also describes how SIP > and MSRP entities behave using this extension. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-simple-imdn-00.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=20 > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-simple-imdn-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-simple-imdn-00.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2006-5-30162236.I-D@ietf.org> > > _______________________________________________ > 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 philipokon062@adinet.com.uy Sat Jun 24 10:13:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu8sk-0006lU-Na for simple-archive@lists.ietf.org; Sat, 24 Jun 2006 10:13:06 -0400 Received: from smtp-s4.antel.net.uy ([200.40.30.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu8sj-0000HD-AY for simple-archive@lists.ietf.org; Sat, 24 Jun 2006 10:13:06 -0400 Received: from fe-ps02 (192.168.2.202) by smtp-s4.antel.net.uy (7.2.072.1) (authenticated as philipokon062@adinet.com.uy) id 4474803E006B1F05; Sat, 24 Jun 2006 10:59:37 -0300 Received: from [203.151.154.20] by www.adinet.com.uy via http; Sat Jun 24 10:59:36 UYT 2006 Message-ID: <3291854.1151157576933.JavaMail.tomcat@fe-ps02> Date: Sat, 24 Jun 2006 10:59:36 -0300 (UYT) From: Philip Okon Reply-To: philip_okooon@yahoo.com Subject: RE: Notification of Bequest MIME-Version: 1.0 Content-Type: text/plain;charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Originating-IP: 203.151.154.20 X-Spam-Score: 2.2 (++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 BARRISTER PHILIP OKON & CHAMBERS solicitors & Advocates (Notary public) of The Supreme Court Of Nigeria Our Ref: TOB/AT LAW/1717/2005 ADDRESS: N0 35 Saint Street Aguda Lagos Nigeria Hello dear RE: Notification of Bequest With gratitude to God to a life well spent and on behalf of my late client Rev. Dr. JOHN OKONKWO, I write to notify you that my late client made you a beneficiary to the bequest sum of One Million Five Hundred Thousand United States Dollars (USD $1,500.000) in the last codicil to his last WILL and testament of the year 2003. Late Rev. Dr. JOHN OKONKWO died of high blood pressure on the 2nd February 2004. Until his death, late Rev. Dr. JOHN OKONKWO was a regional director in Nigeria with United Nations Refugees and humanitarian commission. A renowned PHILANTHROPIST, who has widely travelled and very good Christian of the Christian fellowship of Nigeria. A non denominational society. According to him he is giving you this amount because of your active involvement in the upliftment of Christian activities with its ministries and making better the world?s situation for the acceptance of Christian religion in Christ Jesus as the son of God. We the executors and trustees of this WILL wish to inform you that the WILL was read at the High Court probate Division on the 5th June 2005 as the law provides in section (52) sub-section 3&4 of the Nigeria constitution and is ready for execution.You are therefore required by this notification to confirm your ownership to this legacy by forwarding to us immediately via e-mail, your current telephone, e-mail and fax number (private) for easy communication and prompt payment without delay. Your contact address (private) is also required for verification and authentication of the WILL as the law stipulated. A photocopy of your international passport number or drivers licence if available shall be required from you on the day of your payment. This is to avoid paying to a wrong beneficiary.We shall detail you on the procedure involved in executing this will upon the receipt of your prompt e-mail response. We are sorry for not notifying you by posted mail due to the urgency required in this matter and also your e-mail contact was given to us by the wife of my late client. Thanks and God bless. HON.BARRISTER PHILIP OKON Head of Chamber. From simple-bounces@ietf.org Mon Jun 26 10:57:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FusWz-0002Wc-QE; Mon, 26 Jun 2006 10:57:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FusWy-0002WX-0F for simple@ietf.org; Mon, 26 Jun 2006 10:57:40 -0400 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FusWw-0008Kl-OB for simple@ietf.org; Mon, 26 Jun 2006 10:57:39 -0400 Received: by py-out-1112.google.com with SMTP id t32so1490321pyc for ; Mon, 26 Jun 2006 07:57:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GwEAB6NzdM1Yggr2ehx+swH5de9ltX6w2JnF2MjFYda53G+v3TOyKT9Psbz67R7LpSrm1OF9g+NBbHW1JH9QDCttTYQuUaeZPtejf44Ih9xkhIvYUhhuhD3/jsko4UPAYdYphU+QD1t9XcpsHxu/h+VxZp+ZZFMtpO1DlDJs8jE= Received: by 10.35.60.16 with SMTP id n16mr4574487pyk; Mon, 26 Jun 2006 07:57:38 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Mon, 26 Jun 2006 07:57:38 -0700 (PDT) Message-ID: <953beacc0606260757h14a62dco7c98cb3c37df336a@mail.gmail.com> Date: Mon, 26 Jun 2006 07:57:38 -0700 From: "Rohan Mahy" To: "Harrison Zhou" Subject: Re: [Simple] Could you review my draft please? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Miguel.An.Garcia@nokia.com, 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: , Errors-To: simple-bounces@ietf.org Hi Zhou, I may want to advertise different presence to different watchers. Some commercial presence systems already offer a primitive version of this ability now where the presentity advertises availability to one group (typically close friends or coworkers) and advertises that they are busy to the rest of their watchers. Similarly, I may want to provide very basic presence to most watchers, but very rich presence, possibly with geolocation information, to more trusted watchers. thanks, -rohan I can't do this if only one PIDF document is sent between On 6/22/06, Harrison Zhou wrote: > Dear sip experts, > > I've written a draft and this draft describe a new method for the Presence > Server to process presence in inter-domain scenarios . > The new method void duplicated messaging between Presence Servers. > I am interested in SIMPLE and will work on it. This is my first draft and I > hope someone can review my draft and give me some comments. Thanks! > > you can fetch a copy from: > http://www.ietf.org/internet-drafts/draft-zhou-simple-hierarchical-presence- > 00.txt > > Regards, > Hong > > > > _______________________________________________ > 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 Jun 26 11:38:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FutA5-0001nv-U5; Mon, 26 Jun 2006 11:38:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FutA4-0001nq-SV for simple@ietf.org; Mon, 26 Jun 2006 11:38:04 -0400 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FutA3-0002Eo-Cf for simple@ietf.org; Mon, 26 Jun 2006 11:38:04 -0400 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FutA0-0000pJ-Pk; Mon, 26 Jun 2006 15:38:00 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id EA384498003; Mon, 26 Jun 2006 16:39:29 +0100 (BST) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04492-04; Mon, 26 Jun 2006 16:39:21 +0100 (BST) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 9C80E498002; Mon, 26 Jun 2006 16:39:21 +0100 (BST) Date: Mon, 26 Jun 2006 16:37:52 +0100 Subject: Re: [Simple] Could you review my draft please? References: =?US-ASCII?Q??= <953beacc0606260757h14a62dco7c98cb3c37df336a@mail.gmail.com> In-Reply-To: <953beacc0606260757h14a62dco7c98cb3c37df336a@mail.gmail.com> MIME-Version: 1.0 Message-Id: <32030.1151336272.251321@peirce.dave.cridland.net> From: Dave Cridland To: Rohan Mahy Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Miguel Garcia , SIP for Instant Messaging and Presence Leveraging Extensions 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: , Errors-To: simple-bounces@ietf.org The below looks similar to a discussion happening in Jabber's Standards JIG, aimed at streamlining presence stanzas between domains in XMPP, which is pretty much the same issue tackled by Zhou's draft here, and I understand things. It might be useful to examine what is being considered there. On Mon Jun 26 15:57:38 2006, Rohan Mahy wrote: > I may want to advertise different presence to different watchers. > Some commercial presence systems already offer a primitive version > of > this ability now where the presentity advertises availability to one > group (typically close friends or coworkers) and advertises that > they > are busy to the rest of their watchers. Similarly, I may want to > provide very basic presence to most watchers, but very rich > presence, > possibly with geolocation information, to more trusted watchers. > > thanks, > -rohan > > I can't do this if only one PIDF document is sent between > > On 6/22/06, Harrison Zhou wrote: >> Dear sip experts, >> >> I've written a draft and this draft describe a new method for the >> Presence >> Server to process presence in inter-domain scenarios . >> The new method void duplicated messaging between Presence Servers. >> I am interested in SIMPLE and will work on it. This is my first >> draft and I >> hope someone can review my draft and give me some comments. Thanks! >> >> you can fetch a copy from: >> http://www.ietf.org/internet-drafts/draft-zhou-simple-hierarchical-presence- >> 00.txt >> >> Regards, >> Hong >> >> >> >> _______________________________________________ >> 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 -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jun 26 19:55:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv0vP-0006gH-M1; Mon, 26 Jun 2006 19:55:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv0vO-0006cK-6M for Simple@ietf.org; Mon, 26 Jun 2006 19:55:26 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv0vM-0001Qs-TH for Simple@ietf.org; Mon, 26 Jun 2006 19:55:26 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 26 Jun 2006 16:55:24 -0700 X-IronPort-AV: i="4.06,178,1149490800"; d="scan'208"; a="1833022717:sNHT36667638" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k5QNtOYv032550; Mon, 26 Jun 2006 16:55:24 -0700 Received: from [192.168.1.2] (sjc-vpn2-553.cisco.com [10.21.114.41]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5QNt4cM016503; Mon, 26 Jun 2006 16:55:23 -0700 (PDT) In-Reply-To: <0537E69D-4B0D-4C6A-812A-9755A8F799FC@estacado.net> References: <6405cd720606230332y524fc774ua239cbedea600b54@mail.gmail.com> <0537E69D-4B0D-4C6A-812A-9755A8F799FC@estacado.net> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Simple] MSRP-Size of Chunks Date: Mon, 26 Jun 2006 16:55:26 -0700 To: jos4711@googlemail.com X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=1166; t=1151366124; x=1152230124; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:Re=3A=20[Simple]=20MSRP-Size=20of=20Chunks; X=v=3Dcisco.com=3B=20h=3DDsjj9PRmYxDY6U/s2LemafEr7TU=3D; b=LBSQo3yE/9b1PxXMdxlJ5GFZNypOpV5tp1397JfReybutDTJckVIFamc1Bs0tO0x3B2WbDGf oCWoobJnzpg6uYYBMbU0oNPrezw1n/MTBDGqRRm+XpPv5v4wbwvTGwlo; Authentication-Results: sj-dkim-7.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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: , Errors-To: simple-bounces@ietf.org It seemed small enough that it would not cause a long blocking queuing latency on even a 9600 bps link and large enough that the protocol was not too inefficient even when not using blocks larger than this. Likely any number from 1k to 10k would work just about as well. On Jun 23, 2006, at 6:12 AM, Ben Campbell wrote: > It was a size that transfers quickly on most modern communication > technologies. But mostly we just picked a number. > > Keep in mind that it is not a "chunk-size" per se. It is a size > above which the sender must make the message interruptible. Actual > chunks can be larger or smaller. > > On Jun 23, 2006, at 5:32 AM, jos4711@googlemail.com wrote: > >> Hi! >> I have q question about the size of the chunks in the MSRP. >> How come its 2048 Bytes? What is the base for this size? >> >> Thank you! >> >> _______________________________________________ >> 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 Jun 26 21:32:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv2Rf-0006xa-A6; Mon, 26 Jun 2006 21:32:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv2Rd-0006vs-Rh for simple@ietf.org; Mon, 26 Jun 2006 21:32:49 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv2Rc-0008D0-2Z for simple@ietf.org; Mon, 26 Jun 2006 21:32:49 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1H00I9AX093R@szxga02-in.huawei.com> for simple@ietf.org; Tue, 27 Jun 2006 09:48:10 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1H001CXX0915@szxga02-in.huawei.com> for simple@ietf.org; Tue, 27 Jun 2006 09:48:09 +0800 (CST) Received: from z53160 ([10.164.5.15]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1H00MRVWC5H9@szxml03-in.huawei.com> for simple@ietf.org; Tue, 27 Jun 2006 09:33:45 +0800 (CST) Date: Tue, 27 Jun 2006 09:31:55 +0800 From: Harrison Zhou Subject: RE: [Simple] Could you review my draft please? In-reply-to: <953beacc0606260757h14a62dco7c98cb3c37df336a@mail.gmail.com> To: 'Rohan Mahy' Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcaZMOLZJxA/jYtERhG6ZL0gA+sctgAV2EVA X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Miguel.An.Garcia@nokia.com, '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: , Errors-To: simple-bounces@ietf.org Hi Rohan, I think this is a good issue. I doesn't know how to achieve the function you mentioned in currently SIMPLE presence. Maybe a feasible method is : the UA has its policy to different watchers, and UA tell its policy to its Presence Server, So the Presence Server can show different state to different watchers. Is it right? So in my draft, the Presence Server can tell UA's policy to another Presence Server. Regards, Hong -----Original Message----- From: Rohan Mahy [mailto:rohan.mahy@gmail.com] Sent: Monday, June 26, 2006 10:58 PM To: Harrison Zhou Cc: Robert Sparks; hisham.khartabil@telio.no; Jonathan Rosenberg; Spencer Dawkins; Miguel.An.Garcia@nokia.com; noga.tor@gmail.com; x.victoria@gmail.com; Simple WG Subject: Re: [Simple] Could you review my draft please? Hi Zhou, I may want to advertise different presence to different watchers. Some commercial presence systems already offer a primitive version of this ability now where the presentity advertises availability to one group (typically close friends or coworkers) and advertises that they are busy to the rest of their watchers. Similarly, I may want to provide very basic presence to most watchers, but very rich presence, possibly with geolocation information, to more trusted watchers. thanks, -rohan I can't do this if only one PIDF document is sent between On 6/22/06, Harrison Zhou wrote: > Dear sip experts, > > I've written a draft and this draft describe a new method for the Presence > Server to process presence in inter-domain scenarios . > The new method void duplicated messaging between Presence Servers. > I am interested in SIMPLE and will work on it. This is my first draft and I > hope someone can review my draft and give me some comments. Thanks! > > you can fetch a copy from: > http://www.ietf.org/internet-drafts/draft-zhou-simple-hierarchical-presence- > 00.txt > > Regards, > Hong > > > > _______________________________________________ > 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 Tue Jun 27 11:28:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvFU8-0000J7-K7; Tue, 27 Jun 2006 11:28:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvFU8-0000If-4O for simple@ietf.org; Tue, 27 Jun 2006 11:28:16 -0400 Received: from mango.cc.columbia.edu ([128.59.29.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvFU6-0006wd-Tz for simple@ietf.org; Tue, 27 Jun 2006 11:28:16 -0400 Received: from mango.cc.columbia.edu (localhost [127.0.0.1]) by mango.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k5RFS11P021512; Tue, 27 Jun 2006 11:28:01 -0400 (EDT) Received: from localhost (rs2194@localhost) by mango.cc.columbia.edu (8.13.7/8.12.3/Submit) with ESMTP id k5RFS1YZ021509; Tue, 27 Jun 2006 11:28:01 -0400 (EDT) X-Authentication-Warning: mango.cc.columbia.edu: rs2194 owned process doing -bs Date: Tue, 27 Jun 2006 11:28:01 -0400 (EDT) From: Ron Shacham To: simple@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.5 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: shacham@cs.columbia.edu Subject: [Simple] Updated draft on Presence Composition 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: , Errors-To: simple-bounces@ietf.org We have submitted an update to our draft on Presence Composition. It is currently available at: http://www.cs.columbia.edu/sip/drafts/simple/draft-schulzrinne- simple-composition-02.txt It discusses the composition of a presence document from multiple sources, before privacy and filtering steps are done. The steps involved are: Discarding tuples Deriving new presence information Resolving conflicts between sources Merging multiple tuples Based on the discussion, the draft proposes an XML format for specifying composition preferences. A few of the major updates since the -01 version: *We describe more precisely the method of conflict resolution *For simplicity, we have chosen to concentrate on merging of instances, and hold off on service instance merging. *We have cleaned up the format for presence derivation, and use a single XML patch "add" statement for each derivation, without requiring any additional XML elements. We would appreciate comments. Regards, Ron _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jun 28 10:50:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvbN8-0005Pf-Rp; Wed, 28 Jun 2006 10:50:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvbN7-0005Nv-3M for simple@ietf.org; Wed, 28 Jun 2006 10:50:29 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvbN6-0007sa-Fr for simple@ietf.org; Wed, 28 Jun 2006 10:50:29 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5SEoRbn001653 for ; Wed, 28 Jun 2006 17:50:27 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 17:50:26 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 17:50:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] I-D ACTION:draft-ietf-simple-messaging-requirements-00.txt Date: Wed, 28 Jun 2006 17:50:26 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-messaging-requirements-00.txt Thread-Index: AcaW1Ib2WG0LxSjnQ/GCy2feIqBpywD6HFAQ From: To: X-OriginalArrivalTime: 28 Jun 2006 14:50:26.0940 (UTC) FILETIME=[3160D3C0:01C69AC2] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 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: , Errors-To: simple-bounces@ietf.org Hi, I have taken the editorship of the Advanced Messaging Requirements = document. The purpose of the document is to cover all the messaging = related requirements that SIMPLE WG is planning to work on (or in some = cases has already worked on) beyond the basic page or session mode = functionality provided by SIP MESSAGE and MSRP. Currently this includes = the following items:=20 - IM dispostion notifications (IMDN)=20 - Is-Composing - Content capabilities - Page-mode groups The -00 version of the WG document has just been submitted. The baseline = for the WG document was an old draft by Jonathan Rosenberg, = draft-rosenberg-simple-messaging-requirements-01 that has been expired = for quite a while now. The update was based on discussion within an ad = hoc design team formed during IETF 65: myself, SIMPLE chairs, Eric = Burger, Ben Campbell, Sean Olson, Paul Kyzivat, Aki Niemi and Salvatore = Loreto. The main purpose at this point was to remove all the = requirements that we did not think SIMPLE anymore had interest to = address. At the moment the draft represents the rough consensus within = the team, and now a wider review and discussion within the SIMPLE WG is = expected. The main changes compared to the original draft are listed below. Please = review the draft and comment, especially if you think there are = messaging related functions that you think SIMPLE should work upon and = that are not covered in the current draft. --- Here are the main things I tried to do: - Remove all the requirements that we think we won't even try to = address. In case this was not clear based on the discussion so far, I = marked the requirement as an open issue. - Point out the cases where there are already existing specifications = (RFCs or mature WG drafts) that provide solutions to the requirements. = In practice these include MSRP, is-composing and multi-recipient MESSAGE = request specs. More specific changes since the version I received from Jonathan: - Added myself as a co-author. I kept Jonathan's name there as well, = since a lot of text is from him. It's up to Jonathan if he wants to = remain as a co-author. - Made small changes in abstract and intro to explain that the document = mainly lists requirements that are not addressed by baseline SIP MESSAGE = or MSRP specs but are on more advanced messaging capabilities. Also = explained that in some cases the specifications meeting the reqs = actually already exist, and in that case those specs are called out in = the relevant sections. - Added references to is-composing and multi-recipient MESSAGE specs in = sections where reqs met by them are presented. Also pointed out that = MSRP itself already addresses the req about maximum message size. - Section 2 - Renamed delivery notifications as disposition notifications - Removed reqs 9, 14, 18, 19, 20 - Reworded most of the other reqs. Some of this is just new = terminology, but there are also other changes. Please review! - There are open issues related to four requirements. The most = important of them is related to aggregation. - Note that there are now no reqs related to session-mode IMDN - Section 3 - Requirements remained untouched. I just added a comment that req 8 = is not addressed by the existing is-composing RFC. So, should it be = removed? - Section 4 - Reqs were untouched. Added a comment that req 1 is already met by = MSRP. Req 2 is an open issue. - Section 5 - Requirements were untouched. I believe multi-recipient MESSAGE = supports all of them. --- Regards, Markus ------------------------------- Markus Isom=E4ki markus.isomaki@nokia.com ------------------------------- =20 >-----Original Message----- >From: ext simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]=20 >Sent: 23 June, 2006 17:50 >To: i-d-announce@ietf.org >Cc: simple@ietf.org >Subject: [Simple] I-D=20 >ACTION:draft-ietf-simple-messaging-requirements-00.txt > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. >This draft is a work item of the SIP for Instant Messaging and=20 >Presence Leveraging Extensions Working Group of the IETF. > > Title : Advanced Instant Messaging=20 >Requirements for the Session Initiation Protocol (SIP) > Author(s) : M. Isomaki, J. Rosenberg > Filename :=20 >draft-ietf-simple-messaging-requirements-00.txt > Pages : 11 > Date : 2006-6-23 >=09 >Session Initiation Protocol (SIP) supports the basic instant=20 >messaging service in both page and session mode. This=20 >document defines a set of requirements for instant messaging=20 >capabilities that are beyond the scope of the baseline specifications. > > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-simple-messaging -requirements-00.txt > >To remove yourself from the I-D Announcement list, send a=20 >message to i-d-announce-request@ietf.org with the word=20 >unsubscribe in the body of the message. =20 >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=20 >with the username "anonymous" and a password of your e-mail=20 >address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-simple-messaging-requirements-00.txt". > >A list of Internet-Drafts directories can be found in=20 >http://www.ietf.org/shadow.html or=20 >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=20 >/internet-drafts/draft-ietf-simple-messaging-requirements-00.txt". >=09 >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 >mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 29 04:29:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvruB-0000rw-FK; Thu, 29 Jun 2006 04:29:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvruA-0000ol-B7 for simple@ietf.org; Thu, 29 Jun 2006 04:29:42 -0400 Received: from py-out-1112.google.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvru6-0005ly-9e for simple@ietf.org; Thu, 29 Jun 2006 04:29:42 -0400 Received: by py-out-1112.google.com with SMTP id d42so152596pyd for ; Thu, 29 Jun 2006 01:29:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=QR5qvc1v2Hdt1GdWrxMmEK7ooRGLqJKiiqjLW0nYBFf02wkNhXhfozCfg0Hfq2cDq9y+kYzjT9NQDX2Q9GwE+kX5oAixmvIpwnUbkomSj7jRE1bsMDOMSn57SwOlhKRKGTZQ5nngUg+cT9N05Yeo/v6u9cUzG6n7zXo2qdyp3VA= Received: by 10.35.88.18 with SMTP id q18mr1218745pyl; Thu, 29 Jun 2006 01:29:33 -0700 (PDT) Received: by 10.35.83.12 with HTTP; Thu, 29 Jun 2006 01:29:33 -0700 (PDT) Message-ID: <7759a74d0606290129g60a677d1le8c5b31019484d66@mail.gmail.com> Date: Thu, 29 Jun 2006 13:59:33 +0530 From: "Aniruddha Vaidya" To: simple@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.7 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Simple] Multiple Devices And Message Request 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="===============0298763116==" Errors-To: simple-bounces@ietf.org --===============0298763116== Content-Type: multipart/alternative; boundary="----=_Part_4364_13991861.1151569773854" ------=_Part_4364_13991861.1151569773854 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I have a query regarding the registration from multiple devices. User A register from a PC and a mobile. Both of the devices are using the user agent which is able to process the MESSAGE request. Now suppose A has registered both devices with a Registrar. And User B who's in the buddy list of A want to send the message to A. Using the presence information available to B, he can send the message to A on either his mobile or on his PC. So In such a case is it possible to send instant message to a particular device ? What should be the proxy behaviour ? Regards, Aniruddha ------=_Part_4364_13991861.1151569773854 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,
I have a query regarding the registration from multiple devices.

User A register from a PC and a mobile. Both of the devices are using the user agent which is able to process the MESSAGE request.

Now suppose A has registered both devices with a Registrar. And User B who's in the buddy  list of A want to send the message to A. Using the presence information available to B, he can send the message to A on either his mobile or on his PC.

So In such a case is it possible to send instant message to a particular device ?
What should be the proxy behaviour ?

Regards,
Aniruddha


------=_Part_4364_13991861.1151569773854-- --===============0298763116== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0298763116==-- From simple-bounces@ietf.org Thu Jun 29 08:20:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvvVL-0006ND-34; Thu, 29 Jun 2006 08:20:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvvVJ-0006Mo-K2 for simple@ietf.org; Thu, 29 Jun 2006 08:20:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvuBO-00074f-4y for simple@ietf.org; Thu, 29 Jun 2006 06:55:38 -0400 Received: from smtp3.infineon.com ([203.126.106.229]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fvu5x-0001W5-FF for simple@ietf.org; Thu, 29 Jun 2006 06:50:06 -0400 Received: from unknown (HELO sinse211.ap.infineon.com) ([172.17.65.149]) by smtp3.infineon.com with ESMTP; 29 Jun 2006 18:49:53 +0800 X-SBRS: None Received: from blrse201.ap.infineon.com ([172.20.20.12]) by sinse211.ap.infineon.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Jun 2006 18:49:53 +0800 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 Date: Thu, 29 Jun 2006 16:19:50 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal-Size parameter in MSRP start line Thread-Index: AcabVqfIGAKVL98gRxS9xPn3lMJqRwABnMbgAAL0RPAAAAPM4AAAATLA From: To: X-OriginalArrivalTime: 29 Jun 2006 10:49:53.0117 (UTC) FILETIME=[C08FF8D0:01C69B69] X-Spam-Score: -1.9 (-) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: fluffy@cisco.com, msrp@list.sipfoundry.org Subject: [Simple] Proposal-Size parameter in MSRP start line 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: , Errors-To: simple-bounces@ietf.org > Hi All, >=20 > To remove some implementation complexities I would like to propose > addition of size field in the start line of MSRP Request and MSRP > Response that gives the size of MSRP packet without affecting other > operations.=20 >=20 > Current start line for request and response are:=20 >=20 > req-start =3D pMSRP SP transact-id SP method CRLF > resp-start =3D pMSRP SP transact-id SP status-code [SP comment] CRLF >=20 > and the proposed changes are=20 >=20 > req-start =3D pMSRP SP size SP transact-id SP method CRLF > resp-start =3D pMSRP SP size SP transact-id SP status-code [SP = comment] > CRLF >=20 > The sender of the MSRP packet should include the size of the MSRP > packet.=20 >=20 > It will be easy for the receiver to know the size of the received > packet in advance. The receiver will not have search for the end line > in the received buffer to check weather a complete MSRP packet is > received or not. =20 >=20 > Example. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > SEND Request: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > MSRP 248 a786hjs2 SEND\r\n > To-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp\r\n > From-Path: msrp://atlanta.example.com:7654/jshA7we;tcp\r\n > Message-ID: 87652\r\n > Byte-Range: 1-25/25\r\n > Content-Type: text/plain\r\n > \r\n > Hey Bob, are you there?\r\n > -------a786hjs2$\r\n >=20 > MSRP Response: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > MSRP 178 a786hjs2 200 OK\r\n > To-Path: msrp://atlanta.example.com:7654/jshA7we;tcp\r\n > From-Path: msrp://biloxi.example.com:12763/kjhd37s2s2;tcp\r\n > Byte-Range: 1-25/25\r\n > -------a786hjs2$\r\n >=20 > REPORT Rquest: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > MSRP 192 dkei38sd REPORT\r\n > To-Path: msrp://alicepc.example.com:7777/iau39;tcp\r\n > From-Path: msrp://bob.example.com:8888/9di4ea;tcp\r\n > Message-ID: 12339sdqwer\r\n > Status: 000 200 OK\r\n > -------dkei38sd$\r\n >=20 > Reason for Proposing the New Parameter: >=20 > 1. Receiver has to traverse whole MSRP receive packet for end line. >=20 > 2. As the underlying protocol is TCP, the recv()/read() function call > returns the bytes available and that can be accommodated in the MSRP > passed buffer. So there may be two case: > a) Whole MSRP Send packet is not available (from Start line to > End line). > b) More then one MSRP Send packet is available and returned in > read. >=20 > 3. As per MSRP draft max body size is 2048 bytes but it does not talk > about the max packet size (content body size + header size). Max body > size for a chunk is fixed but there is no size restriction for the > header and header values. For example: Transaction id, message id, > session id etc can be of any length and there is also provision for > extension header and values. Receiver really does not know the buffer > size. so what will be criteria for allocating the buffer space for > reading MSRP data from TCP? >=20 > IP Protocol and ST, Internet Stream Protocol, are examples where both > header size as well as body size fields are present. There could be > other protocols which give both header size and body size. >=20 > Regards, > Amit Kumar Goel _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 29 09:09:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvwH4-0006nT-0H; Thu, 29 Jun 2006 09:09:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvwH3-0006kP-4N for simple@ietf.org; Thu, 29 Jun 2006 09:09:37 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvwH1-0003vD-Rt for simple@ietf.org; Thu, 29 Jun 2006 09:09:37 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 29 Jun 2006 09:09:36 -0400 X-IronPort-AV: i="4.06,192,1149480000"; d="scan'208"; a="91283557:sNHT29873836" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5TD9Znq025428; Thu, 29 Jun 2006 09:09:35 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Jun 2006 09:09:35 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Jun 2006 09:09:34 -0400 Message-ID: <44A3D10E.50205@cisco.com> Date: Thu, 29 Jun 2006 09:09:34 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Aniruddha Vaidya Subject: Re: [Simple] Multiple Devices And Message Request References: <7759a74d0606290129g60a677d1le8c5b31019484d66@mail.gmail.com> In-Reply-To: <7759a74d0606290129g60a677d1le8c5b31019484d66@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jun 2006 13:09:34.0971 (UTC) FILETIME=[448964B0:01C69B7D] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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: , Errors-To: simple-bounces@ietf.org Aniruddha, It MAY be possible, depending upon how A has published presence. A MAY publish presence as a single service, with the contact included being the AOR. In that case B will have no choice where its message goes. Or A MAY publish presence as two services, one for each of its devices, with the contact being the contact address of the particular device. (Or a GRUU for that device.) In that case, B may choose between those services and send to the corresponding contact, which will go only to the corresponding device. Paul Aniruddha Vaidya wrote: > Hi, > I have a query regarding the registration from multiple devices. > > User A register from a PC and a mobile. Both of the devices are using the > user agent which is able to process the MESSAGE request. > > Now suppose A has registered both devices with a Registrar. And User B > who's > in the buddy list of A want to send the message to A. Using the presence > information available to B, he can send the message to A on either his > mobile or on his PC. > > So In such a case is it possible to send instant message to a particular > device ? > What should be the proxy behaviour ? > > Regards, > Aniruddha > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Thu Jun 29 10:35:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxcA-00017I-Ls; Thu, 29 Jun 2006 10:35:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvxc9-00017D-9z for simple@ietf.org; Thu, 29 Jun 2006 10:35:29 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvx43-0001Fk-5Q for simple@ietf.org; Thu, 29 Jun 2006 10:00:15 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvwnW-0004Y6-M0 for simple@ietf.org; Thu, 29 Jun 2006 09:43:11 -0400 Received: from [192.168.1.101] (c-67-164-146-154.hsd1.tx.comcast.net [67.164.146.154]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k5TDflb4050370 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 29 Jun 2006 08:41:51 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Date: Thu, 29 Jun 2006 08:41:40 -0500 To: "" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.6 (--) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: fluffy@cisco.com, msrp@list.sipfoundry.org, simple@ietf.org Subject: [Simple] Re: Proposal-Size parameter in MSRP start line 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: , Errors-To: simple-bounces@ietf.org Hi, A long time back, the working group had an extended discussion about whether to do message framing by the inclusion of a length parameter vs the use of an end-marker. We chose the end-marker for the reason that it is very possible that a sender does not know the full length of the message when it begins sending. For example, it may be sending the input from some streaming device. Further comment inline: On Jun 29, 2006, at 5:49 AM, wrote: [...] >> >> Reason for Proposing the New Parameter: >> >> 1. Receiver has to traverse whole MSRP receive packet for end line. >> >> 2. As the underlying protocol is TCP, the recv()/read() function call >> returns the bytes available and that can be accommodated in the MSRP >> passed buffer. So there may be two case: >> a) Whole MSRP Send packet is not available (from Start line to >> End line). >> b) More then one MSRP Send packet is available and returned in >> read. >> >> 3. As per MSRP draft max body size is 2048 bytes but it does not talk >> about the max packet size (content body size + header size). MSRP does not have a maximum body size. The 2048 figure is a number of which the request must be constructed to be interruptible. In fact, if a sender has more than 2048 bytes to send, and has no reason to interrupt the request for more pressing traffic, it is encouraged to send it in one interruptible chunk. >> Max body >> size for a chunk is fixed but there is no size restriction for the >> header and header values. For example: Transaction id, message id, >> session id etc can be of any length and there is also provision for >> extension header and values. Receiver really does not know the >> buffer >> size. so what will be criteria for allocating the buffer space for >> reading MSRP data from TCP? >> >> IP Protocol and ST, Internet Stream Protocol, are examples where both >> header size as well as body size fields are present. There could be >> other protocols which give both header size and body size. >> >> Regards, >> Amit Kumar Goel _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jun 29 15:58:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw2eb-0007qi-S1; Thu, 29 Jun 2006 15:58:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw2Wb-0004mH-T2; Thu, 29 Jun 2006 15:50:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw2Wb-0001ZU-Qf; Thu, 29 Jun 2006 15:50:05 -0400 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fw2WY-0001vd-V7; Thu, 29 Jun 2006 15:50:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5TJo2UA025393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fw2WY-0003U1-DM; Thu, 29 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 29 Jun 2006 15:50:02 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-common-policy-caps-01.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: , Errors-To: simple-bounces@ietf.org --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) Representation for Expressing Policy Capabilities Author(s) : J. Rosenberg Filename : draft-ietf-simple-common-policy-caps-01.txt Pages : 14 Date : 2006-6-29 An important component of presence and location services is policy. Policy systems allow the presentity or location target to grant access to specific pieces of information to specific watchers or requestors. These policy systems can be extremely simple, allowing a user to accept or block requests based solely on the identity of the requestor, to extremely complex, allowing for time based rules that grant or deny specific pieces of information. Policy systems often support vendor proprietary features. To allow for interoperability between clients which set such policies, and servers which execute them, it is necessary for clients to be able to determine the capabilities of the server to which it is connected. This specification defines an Extensible Markup Language (XML) based format for expressing such capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-common-policy-caps-01.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-common-policy-caps-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-common-policy-caps-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-29114014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-common-policy-caps-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-common-policy-caps-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-29114014.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Thu Jun 29 16:01:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw2hO-0002Qd-NZ; Thu, 29 Jun 2006 16:01:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw2Wf-0004no-H0; Thu, 29 Jun 2006 15:50:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw2Wf-0001Zz-F0; Thu, 29 Jun 2006 15:50:09 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fw2WZ-0001vg-5G; Thu, 29 Jun 2006 15:50:09 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5TJo29F012775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fw2WY-0003UH-GZ; Thu, 29 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 29 Jun 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-pres-policy-caps-01.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: , Errors-To: simple-bounces@ietf.org --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) Representation for Expressing Presence Policy Capabilities Author(s) : J. Rosenberg Filename : draft-ietf-simple-pres-policy-caps-01.txt Pages : 10 Date : 2006-6-29 An important component of presence services is policy. Policy systems allow the presentity to grant access to specific pieces of information to specific watchers. To allow for interoperability between clients which set such policies, and servers which execute them, it is necessary for clients to be able to determine the capabilities of the server to which it is connected. This specification defines a set of Extensible Markup Language (XML) elements for expressing presence policy capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-pres-policy-caps-01.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-pres-policy-caps-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-pres-policy-caps-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-29114433.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-pres-policy-caps-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-pres-policy-caps-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-29114433.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Fri Jun 30 03:00:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwCyy-00081w-DA; Fri, 30 Jun 2006 03:00:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwCyx-00081i-VQ for simple@ietf.org; Fri, 30 Jun 2006 03:00:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwCyx-0006wz-TH for simple@ietf.org; Fri, 30 Jun 2006 03:00:03 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FwCyu-0008S9-6n for simple@ietf.org; Fri, 30 Jun 2006 03:00:03 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k5U6xoYf021160; Fri, 30 Jun 2006 08:59:51 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k5U6xoPj018145; Fri, 30 Jun 2006 08:59:50 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 08:59:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Simple] Group interest in draft-ietf-simple-common-policy-caps anddraft-ietf-simple-pres-policy-caps? Date: Fri, 30 Jun 2006 08:59:49 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Group interest in draft-ietf-simple-common-policy-caps anddraft-ietf-simple-pres-policy-caps? thread-index: AcaLXQtq+Tmj3CZ8QZmBSlli7OOHRwQX+bog From: "Tschofenig, Hannes" To: "Jonathan Rosenberg" , "Simple WG" X-OriginalArrivalTime: 30 Jun 2006 06:59:50.0528 (UTC) FILETIME=[C7FDC800:01C69C12] X-Spam-Score: -2.6 (--) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: 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: , Errors-To: simple-bounces@ietf.org Hi Jonathan,=20 your mail got lost in my inbox. Sorry for the late response.=20 I think that these documents are important since they address the = extensibility aspect of the authorization policy work.=20 The drafts outline a simple approach.=20 Ciao Hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Gesendet: Donnerstag, 8. Juni 2006 22:51 > An: Simple WG > Betreff: [Simple] Group interest in=20 > draft-ietf-simple-common-policy-caps=20 > anddraft-ietf-simple-pres-policy-caps? >=20 > These drafts expired some time ago. You can still retrieve=20 > them from my=20 > site: >=20 > http://www.jdrosen.net/papers/draft-ietf-simple-common-policy- > caps-00.txt > http://www.jdrosen.net/papers/draft-ietf-simple-pres-policy-ca ps-00.txt >=20 > These drafts define an xcap usage and corresponding schemas for=20 > declaring capabilities for authorization policies. A client=20 > application=20 > would fetch these at startup, and based on them, know what kind of=20 > authorization policies a user can specify. For example, if a service=20 > provider defines new permissions, like 'limited', 'full', and=20 > 'unfettered', the capabilities document would indicate to the client=20 > that these are presence, and the client could place them into a=20 > presence-rules document it uploads to the server. >=20 > These drafts are only really needed if we are worried about=20 > deployments=20 > where people implement subsets or extensions to=20 > presence-rules, and the=20 > clients don't otherwise worry about them. >=20 > The group has agreed in the past that these drafts were=20 > important and we=20 > agreed to adopt them as WG items. However, there hasn't been=20 > a lot of=20 > interest recently, and it will take effort for me to go and=20 > revive them=20 > and get them finished up. >=20 > So, I'd like to poll for interest - please let me know if you think=20 > these are important and would like to move forward with them, and=20 > whether you plan on implementing or using these (or already are). >=20 > Thanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=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 Fri Jun 30 11:24:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwKrG-0007zB-50; Fri, 30 Jun 2006 11:24:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwKrE-0007z6-Rx for simple@ietf.org; Fri, 30 Jun 2006 11:24:36 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwKrD-0005MK-Jt for simple@ietf.org; Fri, 30 Jun 2006 11:24:36 -0400 Received: from [172.17.2.252] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k5UFNFU9015559 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 30 Jun 2006 10:23:18 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Fri, 30 Jun 2006 10:23:15 -0500 To: simple@ietf.org X-Mailer: Apple Mail (2.750) Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: simple-ads@tools.ietf.org, simple-chairs@tools.ietf.org Subject: [Simple] IETF66 SIMPLE Agenda 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: , Errors-To: simple-bounces@ietf.org All - The proposed agenda for the SIMPLE session in Montreal is available at http://www3.ietf.org/proceedings/06jul/agenda/simple.html RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 30 15:42:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwOsZ-00071P-PZ; Fri, 30 Jun 2006 15:42:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwOsY-000715-BK; Fri, 30 Jun 2006 15:42:14 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwOsX-0001FZ-SV; Fri, 30 Jun 2006 15:42:14 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5UJg7Hj014455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Jun 2006 12:42:08 -0700 Received: from [10.0.1.5] (dhcp-campbell-28.qualcomm.com [129.46.225.24]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k5UJg36a022329; Fri, 30 Jun 2006 12:42:05 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Fri, 30 Jun 2006 12:42:01 -0700 To: geopriv@ietf.org, simple@ietf.org From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: Cullen Jennings , hartmans@mit.edu, phoffman@isc.org Subject: [Simple] Proposed Resolution to the draft-ietf-geopriv-common-policy issue. 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: , Errors-To: simple-bounces@ietf.org Howdy, During the IESG review of this draft, Sam Hartman raised an issue relate to the internationalization aspects of this draft and asked that it be given further review on that topic. Paul Hoffman was kind enough to review it, and after he and I discussed the issues Sam raised, we agreed that there was problem in the description in 7.1.3. Below there is a proposed RFC Editor note to resolve it. Paul also felt that it would be good to include an informative reference to RFC 3987 (the IRI spec) on the first mention of xs:anyURI, since it contains useful applicability language. He also suggested that the document highlight the statement made in section 5 that conditions are matched on equality by repeating and expanding on it in the beginning of Section 7. I propose adding a reference to xs:anyURI in Section 7, and combining those notes. regards, Ted Hardie In 7. OLD The access to data items needs to be matched with the rule set stored at the PS. Each instance of a request has different attributes (e.g., the identity of the requestor) that are used for authorization. A rule in a rule set might have a number of conditions that need to be met before executing the remaining parts of a rule (i.e., actions and transformations). Details about rule matching are described in Section 10. This document specifies only a few conditions (i.e., identity, sphere, and validity). Further condition elements can be added via extensions to this document. NEW The access to data items needs to be matched with the rule set stored at the PS. Each instance of a request has different attributes (e.g., the identity of the requestor) that are used for authorization. A rule in a rule set might have a number of conditions that need to be met before executing the remaining parts of a rule (i.e., actions and transformations). Details about rule matching are described in Section 10. This document specifies only a few conditions (i.e., identity, sphere, and validity). Further condition elements can be added via extensions to this document. As noted above in section five, conditions are matched on equality or "great than" style comparisons, rather than regular expressions. Equality is determined according to the rules for the data type associated with the element in the schema given in section 13 below, unless explicit comparison steps are included in this document. For xs:anyURI types, readers may wish to consult [RFC 3987] for its discussion xs:anyURI, as well as the text in [XML Schema]. Rationale: The statements that matching was based on equality or "greater than" style comparisons are repeated more prominently. An explicit reference to the XML Schema document and RFC 3987 will also help clarify how to construct conditions such that equality matching works as expected. In 7.1.3 OLD: 1. If the values of the 'domain' attribute and the value of the protocol domain identifier does not begin with xn--, attempt a string comparison. If the string comparison indicates equality, the comparison succeeds and the remaining steps are skipped. 2. Translate percent-encoding for either string and repeat (1). 3. Convert both domain strings using the toASCII operation described in RFC 3490 [2]. (Naturally, if one of the strings already begins with the ACE prefix xn--, the conversion operation has already been performed.) 4. Compare the two domain strings for ASCII equality, for each label. If the string comparison for each label indicates equality, the comparison succeeds. Otherwise, the domains are not equal. If the conversion fails in step (3), the domains are not equal. NEW: 1. Translate percent-encoding for either string. 3. Convert both domain strings using the toASCII operation described in RFC 3490 [2]. 4. Compare the two domain strings for ASCII equality, for each label. If the string comparison for each label indicates equality, the comparison succeeds. Otherwise, the domains are not equal. If the conversion fails in step (2), the domains are not equal. Rationale: The original step one described a potential optimization, in which the strings were first checked to see if they had already been converted using toASCII. Because the "for each label" text appeared only in Step 4., this was, however, an incomplete optimization. It only caught the cases where the first label was the label that had an IDN component; for all other cases, the string went through a second iteration of toASCII. This wasn't a problem, since applying toASCII to a string which has already been transformed by toASCII has no effect (as RFDC 3490, Section 4.1. puts it : "Applying the ToASCII operation multiple times has exactly the same effect as applying it just once.") It is, however, a bit confusing. To clarify this, I suggest we drop the optimization entirely. It does no harm to have multiple trips through ToASCII, and the process seems harder to get right in the presence of the optimization than in its absence. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jun 30 16:04:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwPDt-0006I2-11; Fri, 30 Jun 2006 16:04:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwPDr-0006Gi-6v; Fri, 30 Jun 2006 16:04:15 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwPDp-0003oT-RH; Fri, 30 Jun 2006 16:04:15 -0400 Received: from [10.0.1.105] ([::ffff:68.106.115.242]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 30 Jun 2006 16:04:31 -0400 id 01588118.44A583CF.000049F0 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5FA36EE9-2705-488A-8A8F-479506B650C6@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Fri, 30 Jun 2006 16:04:10 -0400 To: Ted Hardie X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: geopriv@ietf.org, hartmans@mit.edu, simple@ietf.org, phoffman@isc.org Subject: [Simple] Re: [Geopriv] Proposed Resolution to the draft-ietf-geopriv-common-policy issue. 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: , Errors-To: simple-bounces@ietf.org On Jun 30, 2006, at 3:42 PM, Ted Hardie wrote: > In 7. > > > NEW > > The access to data items needs to be matched with the rule set > stored > at the PS. Each instance of a request has different attributes > (e.g., the identity of the requestor) that are used for > authorization. A rule in a rule set might have a number of > conditions that need to be met before executing the remaining parts > of a rule (i.e., actions and transformations). Details about rule > matching are described in Section 10. This document specifies > only a > few conditions (i.e., identity, sphere, and validity). Further > condition elements can be added via extensions to this document. > > As noted above in section five, conditions are matched on equality > or "great than" style comparisons, rather than regular expressions. > s/great than/greater than/ > Equality is determined according to the rules for the data type > associated > with the element in the schema given in section 13 below, unless > explicit > comparison steps are included in this document. For xs:anyURI > types, > readers may wish to consult [RFC 3987] for its discussion > xs:anyURI, as > well as the text in [XML Schema]. > > In 7.1.3 [..snip..] > Rationale: > > The original step one described a potential optimization, in which > the strings were first checked > to see if they had already been converted using toASCII. Because > the "for each label" text appeared > only in Step 4., this was, however, an incomplete optimization. It > only caught the cases where the > first label was the label that had an IDN component; for all other > cases, the string went through > a second iteration of toASCII. This wasn't a problem, since > applying toASCII to a string which has > already been transformed by toASCII has no effect (as RFDC 3490, > Section 4.1. puts it : > "Applying the ToASCII operation multiple times has exactly the same > effect as applying it just once.") > It is, however, a bit confusing. To clarify this, I suggest we > drop the optimization entirely. It does > no harm to have multiple trips through ToASCII, and the process > seems harder to get right in the > presence of the optimization than in its absence. I agree. -andy _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple