From simple-bounces@ietf.org Thu Nov 02 04:08:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfYXr-0006Eg-6O; Thu, 02 Nov 2006 04:07:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfYXq-0006Bj-Dt for simple@ietf.org; Thu, 02 Nov 2006 04:07:30 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfYXo-0003bg-Nt for simple@ietf.org; Thu, 02 Nov 2006 04:07:30 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 89F721944CD for ; Thu, 2 Nov 2006 10:07:17 +0100 (CET) Received: from [192.168.1.29] ([192.168.1.29]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 10:07:18 +0100 In-Reply-To: <4545AC12.4020006@nokia.com> References: <4545AC12.4020006@nokia.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Subject: Re: [Simple] Re: IMDN: Do we need record-route? Date: Thu, 2 Nov 2006 10:06:35 +0100 To: Miguel Garcia X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 02 Nov 2006 09:07:19.0008 (UTC) FILETIME=[4C79F600:01C6FE5E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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 When you implement IMDN, you will not implement specific=20 implementations for SIP MESSAGE and MSRP SEND. It is not mandatory to=20 populate the IM and IMDN requests with the headers in question. Hisham On Oct 30, 2006, at 8:38 AM, Miguel Garcia wrote: > I am not really convinced that we need IMDN record route. Let's try to=20= > analyze it. > > I would expect that an MSRP IM receiver that gets a request for IMDN,=20= > builds an MSRP SEND request that has the same headers (namely=20 > From-Path and To-Path) than any other regular SEND request that the=20 > endpoint would send. So, if the network (relays, intermediaries,=20 > mixers, etc.) is able to route any asynchronous SEND request that such=20= > endpoint would send, it would route any IMDN in the same manner. > > I would not expect that the endpoint has to dig into the IMDN CPIM=20 > headers of the received IM to build an MSRP SEND request (that carries=20= > the IMDN) in a different manner than any other regular SEND request.=20= > Not having to take a look at the record-route headers will simplify=20 > implementations substantially, because the IMDN will be considered a=20= > special payload of a regular SEND request (at the moment the spec.=20 > considers it a special payload f a special SEND request). > > I would therefore, advocate for removing these headers in MSRP IMDN. > > /Miguel > > Eric Burger wrote: >> On the one hand, good point. On the other, won=B9t the MSRP relays be >> transparent? If so, then I would leave the specification as is,=20 >> especially >> since once we take it out someone will want to gateway from MSRP to=20= >> SMS ;-) >> On 10/26/06 5:42 AM, "Miguel Garcia" =20 >> wrote: >>> Hi: >>> >>> First, I want to express my support for the current version of the=20= >>> IMDN >>> draft, I think it is going in the right direction. Especially, it is >>> easier to read than earlier versions. >>> >>> The draft defines the Original-To, IMDN-Route, and IMDN-Record-Route >>> CPIM headers. I see the need for this CPIM headers when SIP is the >>> transport protocol. However, I don't find a reason for them if MSRP=20= >>> is >>> the transport protocol. I think endpoints will send IMDNs through = the >>> same MSRP logical session where the IM was received. If at the other >>> side there is an intermediary, for sure there is some logic on top=20= >>> that >>> is able to route back to the original sender. >>> >>> So is there a usage of these headers in MSRP? >>> >>> BR, >>> >>> Miguel >>> -- >>> Miguel A. Garcia tel:+358-50-4804586 >>> sip:miguel.garcia@neonsite.net >>> Nokia Research Center Helsinki, Finland >>> > > --=20 > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.garcia@neonsite.net > Nokia Research Center Helsinki, Finland > > _______________________________________________ > 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 Nov 02 04:24:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfYnW-0005bl-G3; Thu, 02 Nov 2006 04:23:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfYnU-0005Yy-Lx for simple@ietf.org; Thu, 02 Nov 2006 04:23:40 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfYnT-0006j0-53 for simple@ietf.org; Thu, 02 Nov 2006 04:23:40 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA29NY0A008456; Thu, 2 Nov 2006 11:23:34 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 11:23:35 +0200 Received: from [172.21.34.112] ([172.21.34.112]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 2 Nov 2006 11:23:34 +0200 Message-ID: <4549B916.4030201@nokia.com> Date: Thu, 02 Nov 2006 11:23:34 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Simple] Re: IMDN: Do we need record-route? References: <4545AC12.4020006@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 02 Nov 2006 09:23:34.0655 (UTC) FILETIME=[9201E0F0:01C6FE60] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061102112334-1E767BB0-1E474BCB/0-0/0-0 X-Nokia-AV: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-ext12.nokia.com id kA29NY0A008456 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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 But what you are saying is that, when you implement IMDN, you need to do=20 a specific implementation of MSRP for IMDN, which makes less sense. I disagree with your statement that when you implement IMDN you wouldn't=20 do specific implementations for SIP MESSAGE and MSRP SEND, at least, the=20 draft seems to indicate the opposite in Sections 12 and 13.=20 Specifically, Section 13.1.1 already contains normative text indicating=20 differences between SIP and MSRP. "Therefore, an IM Sender MUST NOT create MSRP SEND requests requiring a positive-delivery notification or a negative- delivery notification." /Miguel Hisham Khartabil wrote: > When you implement IMDN, you will not implement specific implementation= s=20 > for SIP MESSAGE and MSRP SEND. It is not mandatory to populate the IM=20 > and IMDN requests with the headers in question. >=20 > Hisham >=20 > On Oct 30, 2006, at 8:38 AM, Miguel Garcia wrote: >=20 >> I am not really convinced that we need IMDN record route. Let's try to= =20 >> analyze it. >> >> I would expect that an MSRP IM receiver that gets a request for IMDN,=20 >> builds an MSRP SEND request that has the same headers (namely=20 >> From-Path and To-Path) than any other regular SEND request that the=20 >> endpoint would send. So, if the network (relays, intermediaries,=20 >> mixers, etc.) is able to route any asynchronous SEND request that such= =20 >> endpoint would send, it would route any IMDN in the same manner. >> >> I would not expect that the endpoint has to dig into the IMDN CPIM=20 >> headers of the received IM to build an MSRP SEND request (that carries= =20 >> the IMDN) in a different manner than any other regular SEND request.=20 >> Not having to take a look at the record-route headers will simplify=20 >> implementations substantially, because the IMDN will be considered a=20 >> special payload of a regular SEND request (at the moment the spec.=20 >> considers it a special payload f a special SEND request). >> >> I would therefore, advocate for removing these headers in MSRP IMDN. >> >> /Miguel >> >> Eric Burger wrote: >>> On the one hand, good point. On the other, won=B9t the MSRP relays be >>> transparent? If so, then I would leave the specification as is,=20 >>> especially >>> since once we take it out someone will want to gateway from MSRP to=20 >>> SMS ;-) >>> On 10/26/06 5:42 AM, "Miguel Garcia" wro= te: >>>> Hi: >>>> >>>> First, I want to express my support for the current version of the I= MDN >>>> draft, I think it is going in the right direction. Especially, it is >>>> easier to read than earlier versions. >>>> >>>> The draft defines the Original-To, IMDN-Route, and IMDN-Record-Route >>>> CPIM headers. I see the need for this CPIM headers when SIP is the >>>> transport protocol. However, I don't find a reason for them if MSRP = is >>>> the transport protocol. I think endpoints will send IMDNs through th= e >>>> same MSRP logical session where the IM was received. If at the other >>>> side there is an intermediary, for sure there is some logic on top t= hat >>>> is able to route back to the original sender. >>>> >>>> So is there a usage of these headers in MSRP? >>>> >>>> BR, >>>> >>>> Miguel >>>> --=20 >>>> Miguel A. Garcia tel:+358-50-4804586 >>>> sip:miguel.garcia@neonsite.net >>>> Nokia Research Center Helsinki, Finland >>>> >> >> --=20 >> Miguel A. Garcia tel:+358-50-4804586 >> sip:miguel.garcia@neonsite.net >> Nokia Research Center Helsinki, Finland >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> >=20 --=20 Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Nov 02 10:01:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfe3g-00020w-KJ; Thu, 02 Nov 2006 10:00:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfe3f-000201-K9 for simple@ietf.org; Thu, 02 Nov 2006 10:00:43 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfdoX-0006B6-9P for simple@ietf.org; Thu, 02 Nov 2006 09:45:11 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 78AF71944EF for ; Thu, 2 Nov 2006 15:44:53 +0100 (CET) Received: from [192.168.1.29] ([192.168.1.29]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 15:44:53 +0100 In-Reply-To: <4549B916.4030201@nokia.com> References: <4545AC12.4020006@nokia.com> <4549B916.4030201@nokia.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <841aa4d81b232de99806f146d0d2fe1b@telio.no> Content-Transfer-Encoding: quoted-printable From: Hisham Khartabil Subject: Re: [Simple] Re: IMDN: Do we need record-route? Date: Thu, 2 Nov 2006 15:44:11 +0100 To: Miguel Garcia X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 02 Nov 2006 14:44:53.0195 (UTC) FILETIME=[74E9A1B0:01C6FE8D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 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 was referring to the processing of the IMDN. If there are=20 IMDN-Record-Route headers in the IM, then the client convert those into=20= IMDN-Route headers in the IMDN. If intermediaries don't add any=20 IMDN-Record-Route headers (in the case of MSRP relays), the client=20 realises there are none and routes the IMDN accordingly. Hisham On Nov 2, 2006, at 10:23 AM, Miguel Garcia wrote: > But what you are saying is that, when you implement IMDN, you need to=20= > do a specific implementation of MSRP for IMDN, which makes less sense. > > I disagree with your statement that when you implement IMDN you=20 > wouldn't do specific implementations for SIP MESSAGE and MSRP SEND, at=20= > least, the draft seems to indicate the opposite in Sections 12 and 13.=20= > Specifically, Section 13.1.1 already contains normative text=20 > indicating differences between SIP and MSRP. > > "Therefore, an IM Sender MUST NOT create MSRP SEND > requests requiring a positive-delivery notification or a negative- > delivery notification." > > /Miguel > > Hisham Khartabil wrote: >> When you implement IMDN, you will not implement specific=20 >> implementations for SIP MESSAGE and MSRP SEND. It is not mandatory to=20= >> populate the IM and IMDN requests with the headers in question. >> Hisham >> On Oct 30, 2006, at 8:38 AM, Miguel Garcia wrote: >>> I am not really convinced that we need IMDN record route. Let's try=20= >>> to analyze it. >>> >>> I would expect that an MSRP IM receiver that gets a request for=20 >>> IMDN, builds an MSRP SEND request that has the same headers (namely=20= >>> From-Path and To-Path) than any other regular SEND request that the=20= >>> endpoint would send. So, if the network (relays, intermediaries,=20 >>> mixers, etc.) is able to route any asynchronous SEND request that=20 >>> such endpoint would send, it would route any IMDN in the same=20 >>> manner. >>> >>> I would not expect that the endpoint has to dig into the IMDN CPIM=20= >>> headers of the received IM to build an MSRP SEND request (that=20 >>> carries the IMDN) in a different manner than any other regular SEND=20= >>> request. Not having to take a look at the record-route headers will=20= >>> simplify implementations substantially, because the IMDN will be=20 >>> considered a special payload of a regular SEND request (at the=20 >>> moment the spec. considers it a special payload f a special SEND=20 >>> request). >>> >>> I would therefore, advocate for removing these headers in MSRP IMDN. >>> >>> /Miguel >>> >>> Eric Burger wrote: >>>> On the one hand, good point. On the other, won=B9t the MSRP relays = be >>>> transparent? If so, then I would leave the specification as is,=20 >>>> especially >>>> since once we take it out someone will want to gateway from MSRP to=20= >>>> SMS ;-) >>>> On 10/26/06 5:42 AM, "Miguel Garcia" =20= >>>> wrote: >>>>> Hi: >>>>> >>>>> First, I want to express my support for the current version of the=20= >>>>> IMDN >>>>> draft, I think it is going in the right direction. Especially, it=20= >>>>> is >>>>> easier to read than earlier versions. >>>>> >>>>> The draft defines the Original-To, IMDN-Route, and=20 >>>>> IMDN-Record-Route >>>>> CPIM headers. I see the need for this CPIM headers when SIP is the >>>>> transport protocol. However, I don't find a reason for them if=20 >>>>> MSRP is >>>>> the transport protocol. I think endpoints will send IMDNs through=20= >>>>> the >>>>> same MSRP logical session where the IM was received. If at the=20 >>>>> other >>>>> side there is an intermediary, for sure there is some logic on top=20= >>>>> that >>>>> is able to route back to the original sender. >>>>> >>>>> So is there a usage of these headers in MSRP? >>>>> >>>>> BR, >>>>> >>>>> Miguel >>>>> --=20 >>>>> Miguel A. Garcia tel:+358-50-4804586 >>>>> sip:miguel.garcia@neonsite.net >>>>> Nokia Research Center Helsinki, Finland >>>>> >>> >>> --=20 >>> Miguel A. Garcia tel:+358-50-4804586 >>> sip:miguel.garcia@neonsite.net >>> Nokia Research Center Helsinki, Finland >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> > > --=20 > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.garcia@neonsite.net > Nokia Research Center Helsinki, Finland > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Nov 03 01:56:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfsvt-00086z-Tz; Fri, 03 Nov 2006 01:53:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfsvr-00080o-OV for simple@ietf.org; Fri, 03 Nov 2006 01:53:39 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfsvq-0005GA-4T for simple@ietf.org; Fri, 03 Nov 2006 01:53:39 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA36rVMM027419; Fri, 3 Nov 2006 08:53:32 +0200 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 08:53:32 +0200 Received: from [172.21.34.112] ([172.21.34.112]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 3 Nov 2006 08:53:30 +0200 Message-ID: <454AE76C.30904@nokia.com> Date: Fri, 03 Nov 2006 08:53:32 +0200 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Simple] Re: IMDN: Do we need record-route? References: <4545AC12.4020006@nokia.com> <4549B916.4030201@nokia.com> <841aa4d81b232de99806f146d0d2fe1b@telio.no> In-Reply-To: <841aa4d81b232de99806f146d0d2fe1b@telio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 03 Nov 2006 06:53:30.0498 (UTC) FILETIME=[C5864E20:01C6FF14] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061103085333-6B173BB0-05B3CE21/0-0/0-0 X-Nokia-AV: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-ext12.nokia.com id kA36rVMM027419 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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 But this is the problem: due to the IMDN processing, the implementation=20 now needs to do something especial: inspect the Record Route headers,=20 and send the message to that next-hop. What happens if the next hop is=20 an entity that does not have an active MSRP session with the IM=20 Receiver? Do we need to INVITE? To who, what happens if the Record-Route=20 contains an MSRP URI? Do you create an INVITE addressed in the=20 Request-URI to the MSRP URI? You see, things don't make sense (IMHO). I would expect that an IM receiver parses the request for an IMDN,=20 creates the IMDN, and blindly feeds the IMDN in the same MSRP session=20 where the IM was received. This works in scenarios with MSRP relays,=20 intermediaries, etc. And this simplifies the implementation and makes it=20 consistent with any other IM that the IM receiver would have got, and=20 reply to. /Miguel Hisham Khartabil wrote: > I was referring to the processing of the IMDN. If there are=20 > IMDN-Record-Route headers in the IM, then the client convert those into= =20 > IMDN-Route headers in the IMDN. If intermediaries don't add any=20 > IMDN-Record-Route headers (in the case of MSRP relays), the client=20 > realises there are none and routes the IMDN accordingly. >=20 > Hisham >=20 > On Nov 2, 2006, at 10:23 AM, Miguel Garcia wrote: >=20 >> But what you are saying is that, when you implement IMDN, you need to=20 >> do a specific implementation of MSRP for IMDN, which makes less sense. >> >> I disagree with your statement that when you implement IMDN you=20 >> wouldn't do specific implementations for SIP MESSAGE and MSRP SEND, at= =20 >> least, the draft seems to indicate the opposite in Sections 12 and 13.= =20 >> Specifically, Section 13.1.1 already contains normative text=20 >> indicating differences between SIP and MSRP. >> >> "Therefore, an IM Sender MUST NOT create MSRP SEND >> requests requiring a positive-delivery notification or a negative- >> delivery notification." >> >> /Miguel >> >> Hisham Khartabil wrote: >>> When you implement IMDN, you will not implement specific=20 >>> implementations for SIP MESSAGE and MSRP SEND. It is not mandatory to= =20 >>> populate the IM and IMDN requests with the headers in question. >>> Hisham >>> On Oct 30, 2006, at 8:38 AM, Miguel Garcia wrote: >>>> I am not really convinced that we need IMDN record route. Let's try=20 >>>> to analyze it. >>>> >>>> I would expect that an MSRP IM receiver that gets a request for=20 >>>> IMDN, builds an MSRP SEND request that has the same headers (namely=20 >>>> From-Path and To-Path) than any other regular SEND request that the=20 >>>> endpoint would send. So, if the network (relays, intermediaries,=20 >>>> mixers, etc.) is able to route any asynchronous SEND request that=20 >>>> such endpoint would send, it would route any IMDN in the same manner. >>>> >>>> I would not expect that the endpoint has to dig into the IMDN CPIM=20 >>>> headers of the received IM to build an MSRP SEND request (that=20 >>>> carries the IMDN) in a different manner than any other regular SEND=20 >>>> request. Not having to take a look at the record-route headers will=20 >>>> simplify implementations substantially, because the IMDN will be=20 >>>> considered a special payload of a regular SEND request (at the=20 >>>> moment the spec. considers it a special payload f a special SEND=20 >>>> request). >>>> >>>> I would therefore, advocate for removing these headers in MSRP IMDN. >>>> >>>> /Miguel >>>> >>>> Eric Burger wrote: >>>>> On the one hand, good point. On the other, won=B9t the MSRP relays = be >>>>> transparent? If so, then I would leave the specification as is,=20 >>>>> especially >>>>> since once we take it out someone will want to gateway from MSRP to= =20 >>>>> SMS ;-) >>>>> On 10/26/06 5:42 AM, "Miguel Garcia" =20 >>>>> wrote: >>>>>> Hi: >>>>>> >>>>>> First, I want to express my support for the current version of the= =20 >>>>>> IMDN >>>>>> draft, I think it is going in the right direction. Especially, it = is >>>>>> easier to read than earlier versions. >>>>>> >>>>>> The draft defines the Original-To, IMDN-Route, and IMDN-Record-Rou= te >>>>>> CPIM headers. I see the need for this CPIM headers when SIP is the >>>>>> transport protocol. However, I don't find a reason for them if=20 >>>>>> MSRP is >>>>>> the transport protocol. I think endpoints will send IMDNs through = the >>>>>> same MSRP logical session where the IM was received. If at the oth= er >>>>>> side there is an intermediary, for sure there is some logic on top= =20 >>>>>> that >>>>>> is able to route back to the original sender. >>>>>> >>>>>> So is there a usage of these headers in MSRP? >>>>>> >>>>>> BR, >>>>>> >>>>>> Miguel >>>>>> --=20 >>>>>> Miguel A. Garcia tel:+358-50-4804586 >>>>>> sip:miguel.garcia@neonsite.net >>>>>> Nokia Research Center Helsinki, Finland >>>>>> >>>> >>>> --=20 >>>> Miguel A. Garcia tel:+358-50-4804586 >>>> sip:miguel.garcia@neonsite.net >>>> Nokia Research Center Helsinki, Finland >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >> >> --=20 >> Miguel A. Garcia tel:+358-50-4804586 >> sip:miguel.garcia@neonsite.net >> Nokia Research Center Helsinki, Finland >> >=20 --=20 Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Nov 04 05:25:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgIfp-00089c-1l; Sat, 04 Nov 2006 05:22:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgIfo-00089X-B1 for simple@ietf.org; Sat, 04 Nov 2006 05:22:48 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgIfn-0007WW-2A for simple@ietf.org; Sat, 04 Nov 2006 05:22:48 -0500 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 kA4AMPVu022606 for ; Sat, 4 Nov 2006 05:22:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 4 Nov 2006 12:22:24 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [WARNING: VIRUS REMOVED]Returned mail: see transcript for details Thread-Index: Acb/+x7KA6y9D5SyTE6w9U1xIQZ/ywAAAAy5 From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Simple] Out of Office AutoReply: [WARNING: VIRUS REMOVED]Returned mail: see transcript for details 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="===============1736490292==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1736490292== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6FFFB.1EFCD080" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6FFFB.1EFCD080 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I am out of office on a business trip. I will be back on November 14, = 2006. I may not read and respond to e-mails during this period. If you = need to contact me urgently, please leave a voice mail message at my = office number. Regards, Dan ------_=_NextPart_001_01C6FFFB.1EFCD080 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Out of Office AutoReply: [WARNING: VIRUS REMOVED]Returned mail: = see transcript for details

I am out of office on a business trip. I will be back = on November 14, 2006.  I may not read and respond to e-mails during = this period.  If you need to contact me urgently, please leave a = voice mail message at my office number.

Regards,

Dan

------_=_NextPart_001_01C6FFFB.1EFCD080-- --===============1736490292== 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 --===============1736490292==-- From simple-bounces@ietf.org Sat Nov 04 23:42:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgZiO-0004x2-M0; Sat, 04 Nov 2006 23:34:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgZiM-0004uj-4r for simple@ietf.org; Sat, 04 Nov 2006 23:34:34 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgZap-0007C1-0l for simple@ietf.org; Sat, 04 Nov 2006 23:26:49 -0500 Received: from [192.168.0.41] (pool-141-153-178-200.mad.east.verizon.net [141.153.178.200]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kA54QfFS026995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sat, 4 Nov 2006 23:26:44 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <2F569078-7C51-48A1-9A6F-D29C006153E5@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: simple@ietf.org From: Henning Schulzrinne Date: Sat, 4 Nov 2006 23:26:15 -0500 X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Simple] New technical report on scaling presence 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 Vishal Singh, Markus Isomaki, Piotr Boni and I have put together a technical report looking at some of the opportunities for reducing the volume of notifications and subscriptions in large-scale presence systems, titled Presence Traffic Optimization Techniques You can find the report at http://mice.cs.columbia.edu/getTechreport.php?techreportID=426 Most of the ideas are exploratory, at best, and need lots of further refinement. Comments would be most welcome. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Nov 06 07:58:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh40d-0006C5-QF; Mon, 06 Nov 2006 07:55:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh40d-0006C0-72 for simple@ietf.org; Mon, 06 Nov 2006 07:55:27 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gh40Z-0004SL-BM for simple@ietf.org; Mon, 06 Nov 2006 07:55:27 -0500 X-VirusChecked: Checked X-Env-Sender: rnbk38@motorola.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1162817720!5980990!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 825 invoked from network); 6 Nov 2006 12:55:20 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-12.tower-128.messagelabs.com with SMTP; 6 Nov 2006 12:55:20 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id kA6CtKup007191 for ; Mon, 6 Nov 2006 05:55:20 -0700 (MST) Received: from zmy16exm61.ds.mot.com (zmy16exm61.ap.mot.com [10.179.4.32]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id kA6CtI9b004286 for ; Mon, 6 Nov 2006 06:55:19 -0600 (CST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 6 Nov 2006 20:55:17 +0800 Message-ID: <272D237EF0638B4CB7F1EA6F5223F6EA0141C021@zmy16exm61.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PIDF + Group-List (for ex. Family/friends/college/colleagues/Default...) Thread-Index: AccBos8MNGR70RBUTt2WUSGXbNETVw== From: "Konka Ravinder-rnbk38" To: X-Spam-Score: 0.6 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: [Simple] PIDF + Group-List (for ex. Family/friends/college/colleagues/Default...) 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="===============0980352212==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0980352212== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C701A2.CF425CE3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C701A2.CF425CE3 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, I have gone thru this paper http://mice.cs.columbia.edu/getTechreport.php?techreportID=3D426, sounds good. The point which I would like to add is, 1. Otherwise we could have a mechanism to send a group-list (for ex. Family/friends/college/colleagues/Default...) separately along with the list-of tuples allowed to view for a group. So that Servers can figure it out, on the fly which information of presentity can be notified to whom and where whenever a new PUBLISH occurs from presentity. 2. Same (PIDF+grouplist) could be used or modified and notified between inter/intra domain notifications i.e between RLS servers. Thanking you, Ravinder Konka. Work(DID): +91 40 23475222. Mobile:+91-9989499809. IM: rnbk38@im.mot.com Jabber:rnbk38@jabber.sourceforge.mot.com =20 =20 ------_=_NextPart_001_01C701A2.CF425CE3 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable PIDF + Group-List (for ex. = Family/friends/college/colleagues/Default...)

Hi,
I have gone thru this paper http://mice.cs.columbia.edu/getTechreport.php?techreportID=3D426, sounds good. The point = which I would like to add is,

1. Otherwise we could have a mechanism = to send a group-list (for ex. = Family/friends/college/colleagues/Default...) separately along with = the list-of tuples allowed to view for a group. So that Servers = can figure it out, on the fly which information of presentity can be = notified to whom and where whenever a new PUBLISH occurs from = presentity.

2. Same (PIDF+grouplist) = could be used or modified and notified between inter/intra domain notifications i.e between = RLS servers.

Thanking you,
Ravinder Konka.
Work(DID): +91 40 23475222.
Mobile:+91-9989499809.
IM: rnbk38@im.mot.com
Jabber:rnbk38@jabber.sourceforge.mot.com

 
 

------_=_NextPart_001_01C701A2.CF425CE3-- --===============0980352212== 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 --===============0980352212==-- From simple-bounces@ietf.org Mon Nov 06 08:41:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh4ig-0004Fr-9Y; Mon, 06 Nov 2006 08:40:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh4id-0004FJ-Ti for simple@ietf.org; Mon, 06 Nov 2006 08:40:55 -0500 Received: from mail.sbs.be ([193.109.72.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh4Sz-0007wc-QF for simple@ietf.org; Mon, 06 Nov 2006 08:24:51 -0500 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA6DOSkT017824; Mon, 6 Nov 2006 14:24:28 +0100 Received: from bru0032a.ww018.siemens.net (bru0032a.ww018.siemens.net [193.210.175.90]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA6DORJP021759; Mon, 6 Nov 2006 14:24:27 +0100 Received: from BRU0038A.ww018.siemens.net ([193.210.175.28]) by bru0032a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 14:24:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 6 Nov 2006 14:24:18 +0100 Message-ID: <67043E463DDBFD4A8087ED940BFF756B0101F447@BRU0038A.ww018.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments to draft-rang-simple-problem-statement-01.txt Thread-Index: AccBptyHgl7f2N4iR+uPZCDde5RoTQ== From: "Willekens, Marc" To: , , X-OriginalArrivalTime: 06 Nov 2006 13:24:26.0957 (UTC) FILETIME=[E1E727D0:01C701A6] X-Spam-Score: 0.1 (/) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d Cc: simple@ietf.org Subject: [Simple] Comments to draft-rang-simple-problem-statement-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: , Content-Type: multipart/mixed; boundary="===============0868495088==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0868495088== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C701A6.E1BC6DF2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C701A6.E1BC6DF2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 Some comments to the draft = http://www.ietf.org/internet-drafts/draft-rang-simple-problem-statement-0= 1.txt =20 This document clearly indicates the main problem for the existing = presence systems which are closed systems for a "limited" amount of = users. Inter-domain peering on a very large scale basis is even not = possible with the existing standards. It is not yet possible to provide = the presence service on a world-wide scale basis with different domains = and sub-domains. =20 Some comments to this draft document: =20 =A73.2 "o Complexity of presence & frequency of presence change" =3D> Complexity: it is important to consider the different possible = presence states of the network, device, application, end-user. =3D> Frequency: the probability of being in a certain state and the = intensity of state changes, i.e. having many different possible presence = states does not always imply a high amount of presence state change = messages. Instead, it can even help to reduce the amount of required = messages. =20 "o (A2) Presence state changes / hour ... We assumed 3 times an hour = for most calculations. Note that for some users in consumer messaging = systems, the actual numbers are likely to be much higher." =3D> I agree that 3 changes/hour is a very optimistic approach. However, = for the existing presence servers, the amount of presence states and = presence state changes is still quite limited, certainly in cases where = the IM service, making use of the presence info, is used on fixed = network broadband connections. For a "mobile" use of the IM service, the = network availability state also becomes a major concern: i.e. hot spot = coverage, handover between cellular and WLAN networks, ... application = transfer between different end user devices, etc... =20 "o (A12) ... the number will be (A1/A3)*A5." =3D> Should this not be 2*(A1/A3)*A5? (2 Messages: Notify + 200 OK) =20 "o (A16) ...(A7+A8)*A6" =3D> Is it not better to use the definition (A14+A15)*A6 to make the = distinction between the un-subscribe and the subscription phase? =20 =20 =A73.3 =3D> For the optimizations, only two optimization options, i.e. for = (A05) and (A12) are considered. Is it not possible to consider also the = optimization option for (A15), i.e. avoiding sending a NOTIFY for the = un-subscribe? However, I agree that the additional performance gain is = very limited (< 1%).=20 =20 =3D> The calculations show the effect for optimizations in a reduction = of the total amount of messages for the different deployment models with = indicated optimizations of 38.6%, 44.1%, 27.6% and 42.7%. =20 However, these models only consider a moderate status change of 3 or 6 = presence state changes per hour. This could be considered as a kind of = "normal" usage. However, when a higher intensity of presence state = changes is considered the indicated optimization effects becomes very = small: for a "medium" kind of presence state change with an intensity of = 5 min, the optimization effect becomes lower as 15% and for a "high" = intensity of 5 sec, the optimization effect is only 0,3%! This clearly = indicates the bottleneck for the server-to-server communication and not = only between inter-domains but also between presence servers in an own = proprietary intra-domain. =20 In the document, only the amount of messages is considered. For the = network resource usage, it is also important to consider the required = bandwidth for the information transfer. For the very large network = peering, this requires ca. 6 Gbps for the "normal" intensity, 10 Gbps = for the "medium" intensity and even 640 Gbps for the "high" intensity. =20 Conclusion: When we want to have a presence system which can be used on a world-wide = scale basis with 6 billion potential users, the existing client/server = dialog concept is not adequate. Further, it is very hard to predict the = amount of generated traffic due to many unknown factors, e.g. which new = future applications will make use of this presence information, what = will be the end-user acceptance and behavior? As such, a concept = architecture is needed which puts no constraints on the expansion of the = system and which allows for higher presence state change intensities = (normal, medium, high intensity changes). =20 Best regards, =20 Marc Willekens Mailto:marc.willekens@siemens.com =20 ------_=_NextPart_001_01C701A6.E1BC6DF2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Some comments to the draft http://www.ietf.org/internet-drafts/draft-rang-simple-prob= lem-statement-01.txt
 
This document clearly indicates = the main=20 problem for the existing presence systems which are closed systems for a = "limited" amount of users. Inter-domain peering on a very large = scale basis=20 is even not possible with the existing standards. It is not yet possible = to=20 provide the presence service on a world-wide scale basis with different domains and=20 sub-domains.
 
Some comments = to this=20 draft document:
 
=A73.2
"o  Complexity = of presence=20 & frequency of presence change"
=3D> Complexity:=20 it is important to consider the different possible presence = states=20 of the network, device, application, end-user.
=3D> Frequency: = the=20 probability of being in a certain state and the intensity of state=20 changes, i.e. having many different = possible=20 presence states does not always imply a high amount of presence state = change=20 messages. Instead, it can even help to reduce the amount of required=20 messages.
 
"o  (A2) = Presence state=20 changes / hour ... We assumed 3 times an=20 hour for most calculations. Note that for some users in consumer = messaging=20 systems, the actual numbers are likely to be much = higher."
=3D> I agree = that 3=20 changes/hour is a very optimistic approach. However, for = the existing=20 presence servers, the amount of presence states and presence state = changes is=20 still quite limited, certainly in cases where the IM service, = making use of=20 the presence info, is used on fixed network broadband=20 connections. For a "mobile" use of the IM service,=20 the network = availability state also becomes a major = concern: i.e. hot spot coverage, handover = between=20 cellular and WLAN networks, ... application transfer between different = end user=20 devices, etc...
 
"o  (A12) ... = the number=20 will be (A1/A3)*A5."
=3D> Should this = not be=20 2*(A1/A3)*A5?  (2 Messages: Notify + 200 = OK)
 
"o (A16) =20 ...(A7+A8)*A6"
=3D> Is it not = better to use=20 the definition (A14+A15)*A6 to make the distinction between = the un-subscribe and the subscription = phase?
 
 
=A73.3
=3D> For the optimizations, only two optimization options, = i.e. for=20 (A05) and (A12) are considered. Is it not possible to consider also = the=20 optimization option for (A15), i.e. avoiding sending a NOTIFY for = the un-subscribe? However, I agree that = the=20 additional performance gain is very limited (<=20 1%). 
 
=3D> The calculations show the effect for optimizations = in a=20 reduction of the total = amount of=20 messages for the different deployment models with indicated=20 optimizations of 38.6%, 44.1%, 27.6% and 42.7%.
 
However, these models only consider a = moderate status=20 change of 3 or 6 presence state changes per hour. This could be = considered=20 as a kind of "normal" usage. However, when a higher intensity of = presence state=20 changes is considered the indicated optimization effects becomes very = small: for=20 a "medium" kind of presence state change with an intensity of  5 = min, the=20 optimization effect becomes lower as 15% and for a "high" intensity of 5 = sec,=20 the optimization effect is only 0,3%! This clearly = indicates=20 the bottleneck for the server-to-server communication and not = only=20 between inter-domains but also between presence servers in an own = proprietary=20 intra-domain.
 
In the document, only the amount of messages is considered. For = the=20 network resource usage, it is also important to consider the required=20 bandwidth for the information = transfer.=20 For the very large network peering, this requires ca. 6 Gbps for the = "normal"=20 intensity, 10 Gbps for the "medium" intensity and even 640 Gbps for = the=20 "high" intensity.
 
Conclusion:
When we want to have a presence system which can be used on a world-wide scale = basis with=20 6 billion potential users, = the=20 existing client/server dialog concept is not adequate. Further, it is = very hard=20 to predict the amount of generated traffic due to many unknown factors, = e.g.=20 which new future applications will make use of this presence = information, what=20 will be the end-user acceptance and behavior? As such, a concept architecture = is needed=20 which puts no constraints on the expansion of the system and which = allows for=20 higher presence state change intensities (normal,=20 medium, high intensity changes).
 
Best=20 regards,
 
Marc=20 Willekens
Mailto:marc.willekens@siemens.com
------_=_NextPart_001_01C701A6.E1BC6DF2-- --===============0868495088== 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 --===============0868495088==-- From simple-bounces@ietf.org Mon Nov 06 22:18:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHSt-0002gX-U1; Mon, 06 Nov 2006 22:17:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHSr-0002ew-MG for simple@ietf.org; Mon, 06 Nov 2006 22:17:29 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhHSq-0008BC-Ah for simple@ietf.org; Mon, 06 Nov 2006 22:17:29 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 06 Nov 2006 19:17:28 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAMKIT0WrR7PDh2dsb2JhbACMSQEBAQgOKg X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="350442102:sNHT65477512" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA73HRuc010125 for ; Mon, 6 Nov 2006 19:17:27 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA73HRin027133 for ; Mon, 6 Nov 2006 19:17:27 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 19:17:27 -0800 Received: from [130.129.71.49] ([10.21.82.238]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 19:17:27 -0800 Message-ID: <454FFAC7.6000503@cisco.com> Date: Mon, 06 Nov 2006 22:17:27 -0500 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: 07 Nov 2006 03:17:27.0498 (UTC) FILETIME=[40A07AA0:01C7021B] DKIM-Signature: a=rsa-sha1; q=dns; l=1898; t=1162869447; x=1163733447; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:ICE=20tutorial=3A=20Lunch=20logistics=20update=20[DO=20NOT=20REPLY]; X=v=3Dcisco.com=3B=20h=3Dwvzj+J9U4bGAuwmnCCs9T7HKQa8=3D; b=JyxVVnmaFp1zEEFhZF6lgY/wBzX4GEdxcysPISR+y4H+HqmZsNam80yGLvqTYyS3p9f/YPRM PtI1MzPHtb42YWDTrbYXFhDOPi0CvVl23PskNVI0jT3cWmF77YS9FP2p; Authentication-Results: sj-dkim-4.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Simple] ICE tutorial: Lunch logistics update [DO NOT REPLY] 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 Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-12.txt) WHEN: Tuesday, November 7 1130-1300 Lunch will be provided at a nominal fee of $10 Sandwiches, salad and chips Bring-your-own beverage Please get me your $10 prior to the end of the IETF meeting. Only 90 lunches have been ordered, its first-come-first-served I am covering this out of my own pocket, so please do get me your $10 if you partake of the food. I'm not tracking who eats or pays - we're on the honor system here! WHERE: Grande Ballroom A WHO: Anyone with an interest in RAI work that would like to learn more about ICE. WHY: ICE is one of the 'core' SIP specifications (according to the SIP hitchhikers guide) and seeing some good adoption. It's the IETF tool for NAT traversal for SIP-based media. However, it's a complex specification. The tutorial will assume only basic familiarity with SIP, SDP and NAT, and explain the rest. Participants will emerge with a high level understanding of the operation of ICE. The tutorial will be based on the pending -12 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice). !DO NOT REPLY TO THIS NOTE! -- 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 Tue Nov 07 00:56:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhJvH-0008Ur-I8; Tue, 07 Nov 2006 00:54:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhJvG-0008Uc-8r for simple@ietf.org; Tue, 07 Nov 2006 00:54:58 -0500 Received: from rose.ctd.hcltech.com ([202.54.64.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhJvE-00074v-M8 for simple@ietf.org; Tue, 07 Nov 2006 00:54:58 -0500 X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Limited] Content-Class: urn:content-classes:message Received: from Ganesh.ctd.hcltech.com ([202.54.64.2]) by rose.ctd.hcltech.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 7 Nov 2006 11:24:54 +0530 Received: by Ganesh.ctd.hcltech.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Nov 2006 11:24:54 +0530 Message-ID: <012301731C23DE4DBFE035647C68F1CC044C6171@sindhu.ctd.hcltech.com> From: "Jayantheesh Srimushnam - TLS, Chennai" To: Date: Tue, 7 Nov 2006 11:24:53 +0530 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Internet Mail Service (5.5.2653.19) X-OriginalArrivalTime: 07 Nov 2006 05:54:54.0623 (UTC) FILETIME=[3F8D5AF0:01C70231] X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: Subject: [Simple] Open source XCAP server 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="===============0881660156==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0881660156== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70231.3EB6DCBA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70231.3EB6DCBA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="Windows-1252" Hi SIMPLE guys, =20 Is there any open source implementation for XCAP server is available? If = so, please send me the related link. =20 Thanks, Jayantheesh =20 DISCLAIMER=20 The contents of this e-mail and any attachment(s) are confidential and = intended for the=20 named recipient(s) only. It shall not attach any liability on the = originator or HCL or its=20 affiliates. Any views or opinions presented in this email are solely = those of the author and=20 may not necessarily reflect the opinions of HCL or its affiliates. Any = form of reproduction,=20 dissemination, copying, disclosure, modification, distribution and / or = publication of this=20 message without the prior written consent of the author of this e-mail = is strictly=20 prohibited. If you have received this email in error please delete it = and notify the sender=20 immediately. Before opening any mail and attachments please check them = for viruses and=20 defect. ------_=_NextPart_001_01C70231.3EB6DCBA Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi SIMPLE = guys,

 

Is there any = open source implementation for XCAP server is available? If so, please send me the = related link.

 

Thanks,

=

Jayantheesh=

 

------_=_NextPart_001_01C70231.3EB6DCBA-- --===============0881660156== 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 --===============0881660156==-- From simple-bounces@ietf.org Tue Nov 07 13:51:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhW2V-0002oM-SE; Tue, 07 Nov 2006 13:51:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhW2U-0002oE-KM for simple@ietf.org; Tue, 07 Nov 2006 13:51:14 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhW2S-0006Hl-AR for simple@ietf.org; Tue, 07 Nov 2006 13:51:14 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 07 Nov 2006 10:51:12 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA7IpBK3013982; Tue, 7 Nov 2006 10:51:11 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA7IpBW6006344; Tue, 7 Nov 2006 10:51:11 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 10:51:11 -0800 Received: from [10.21.81.62] ([10.21.81.62]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 10:51:10 -0800 Message-ID: <4550D59E.2070002@cisco.com> Date: Tue, 07 Nov 2006 13:51:10 -0500 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Ben Campbell Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2006 18:51:10.0864 (UTC) FILETIME=[B127B900:01C7029D] DKIM-Signature: a=rsa-sha1; q=dns; l=564; t=1162925471; x=1163789471; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:Paul=20Kyzivat=20 |Subject:Content-Disposition=20in=20MSRP; X=v=3Dcisco.com=3B=20h=3DzKMj+91Qi/fShr5xesnicPbBZKk=3D; b=LUSA2C19w8zNwGMeYGV+8zTI3UKuqZP2oalWuW2Ac6OXDkge6l9E7+VwbyA5mINxldS2L9is cw4QxwUVEx/4mkQ1rDXOQQ1g5gF+gmiaNmPMVoC9V7wlF+ekFNn7z+Uu; Authentication-Results: sj-dkim-2.cisco.com; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Simple WG Subject: [Simple] Content-Disposition in MSRP 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 just noticed something in the MSRP spec: I takes its definition of the Content-Disposition header from RFC 2183. SIP also used Content-Disposition, and bases its definition on 2183, but extends it, adding: - new dispositions: session, render, icon, alert - a new parameter: handling={"required"/"optional"} Its not clear if "session", "icon", or "alert" are useful for MSRP, but "render" and "handling" probably are. So I suggest the reference for definition of the content-disposition header be changed from 2183 to 3261. Thanks, Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 07 17:51:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZmR-0003GS-SG; Tue, 07 Nov 2006 17:50:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZmQ-0003GN-Ey for simple@ietf.org; Tue, 07 Nov 2006 17:50:54 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhZmO-00025G-Rj for simple@ietf.org; Tue, 07 Nov 2006 17:50:54 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA7Mopnh017109 for ; Wed, 8 Nov 2006 00:50:51 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 00:50:51 +0200 Received: from [10.162.253.76] ([10.162.253.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 8 Nov 2006 00:50:50 +0200 From: Aki Niemi To: SIMPLE WG Content-Type: text/plain; charset=UTF-8 Organization: Nokia-NRC/Helsinki Date: Tue, 07 Nov 2006 22:50:48 +0000 Message-Id: <1162939848.13314.14.camel@macbuster.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 07 Nov 2006 22:50:51.0076 (UTC) FILETIME=[2C6DF040:01C702BF] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061108005051-3C569BB0-57840886/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [Simple] [Fwd: [Sip] Updated draft-niemi-sip-subnot-etags] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: SIP WG 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 FYI, Any comments are welcome. Please send them to the SIP WG list. Cheers, Aki ------- V=C3=A4litetty viesti --------- > L=C3=A4hett=C3=A4j=C3=A4: ext Aki Niemi > Vastaanottaja: IETF SIP List > Aihe: [Sip] Updated draft-niemi-sip-subnot-etags > P=C3=A4iv=C3=A4ys: Sun, 05 Nov 2006 09:24:57 -0800 >=20 > Hodwy, >=20 > Managed to squeeze in an update to the conditional subscribe draft: >=20 > http://www.ietf.org/internet-drafts/draft-niemi-sip-subnot-etags-02.txt >=20 > Major changes include: >=20 > - Bunch of clarifications and fixes contributed by Johnny Vrancken >=20 > - Added the concept of "*" entity-tag, as suggested by Christian Schmidt >=20 > The rationale for the latter change is that it turns out if you're > suppressing NOTIFYs within the subscription, it doesn't matter what the > actual value of the entity-tag is; the superfluous notifications should > simply get suppressed by default. It is now possible by including >=20 > Suppress-Notify-If-Match: * >=20 > to the SUBSCRIBE in subscription refreshes/unsubscribes. This has some > other interesting uses as well, like being able to do a HEAD like query > for the current entity-tag, or a heartbeat-type function to check the > liveliness of a resource (without the extra cost of receiving the > notification). >=20 > In essence, the client need not bother tracking the etags unless it is > resuming a subscription, or using polling to query the state. To me, > this is a simple addition that doesn't introduce any complexity, and > ought to be the default behavior anyway. >=20 > I'm planning to make a fairly extensive rewrite of this draft to make it > look more like an implementation spec, including adding detailed > examples and moving some of the requirements text to an appendix. >=20 > However, before I commit to that, it would be nice to get some traction > to the draft from the working group. >=20 > Is this something the SIP WG is interested in progressing as a WG effort? >=20 > Cheers, > Aki >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 08 02:19:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghhgh-0007QV-TS; Wed, 08 Nov 2006 02:17:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghhgf-0007QK-PZ for simple@ietf.org; Wed, 08 Nov 2006 02:17:29 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghhgc-0006bP-Pp for simple@ietf.org; Wed, 08 Nov 2006 02:17:29 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id kA87HO9C064194 for ; Wed, 8 Nov 2006 07:17:24 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kA87KTXT2813956 for ; Wed, 8 Nov 2006 08:20:29 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kA87HO4b030923 for ; Wed, 8 Nov 2006 08:17:24 +0100 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kA87HO2p030920; Wed, 8 Nov 2006 08:17:24 +0100 In-Reply-To: <67043E463DDBFD4A8087ED940BFF756B0101F447@BRU0038A.ww018.siemens.net> To: "Willekens, Marc" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Wed, 8 Nov 2006 09:20:22 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.5.5HF607 | June 26, 2006) at 08/11/2006 09:20:28, Serialize complete at 08/11/2006 09:20:28 X-Spam-Score: 0.2 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 Cc: timrang@microsoft.com, simple@ietf.org Subject: [Simple] Re: Comments to draft-rang-simple-problem-statement-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: , Content-Type: multipart/mixed; boundary="===============0924018066==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============0924018066== Content-Type: multipart/alternative; boundary="=_alternative 00280D57C2257220_=" This is a multipart message in MIME format. --=_alternative 00280D57C2257220_= Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: base64 TWFyYywNCg0KVGhhbmtzIGZvciB0aGUgdmFsdWFibGUgY29tbWVudHMuIFNlZSBtb3JlIGlubGlu ZS4NCg0KLS1BdnNoYWxvbQ0KDQoNCg0KIldpbGxla2VucywgTWFyYyIgPE1hcmMuV2lsbGVrZW5z QHNpZW1lbnMuY29tPiB3cm90ZSBvbiAwNi8xMS8yMDA2IA0KMTU6MjQ6MTg6DQoNCj4gSGksDQo+ IA0KPiBTb21lIGNvbW1lbnRzIHRvIHRoZSBkcmFmdCBodHRwOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LQ0KPiBkcmFmdHMvZHJhZnQtcmFuZy1zaW1wbGUtcHJvYmxlbS1zdGF0ZW1lbnQtMDEudHh0 DQo+IA0KPiBUaGlzIGRvY3VtZW50IGNsZWFybHkgaW5kaWNhdGVzIHRoZSBtYWluIHByb2JsZW0g Zm9yIHRoZSBleGlzdGluZyANCj4gcHJlc2VuY2Ugc3lzdGVtcyB3aGljaCBhcmUgY2xvc2VkIHN5 c3RlbXMgZm9yIGEgImxpbWl0ZWQiIGFtb3VudCBvZiANCj4gdXNlcnMuIEludGVyLWRvbWFpbiBw ZWVyaW5nIG9uIGEgdmVyeSBsYXJnZSBzY2FsZSBiYXNpcyBpcyBldmVuIG5vdCANCj4gcG9zc2li bGUgd2l0aCB0aGUgZXhpc3Rpbmcgc3RhbmRhcmRzLiBJdCBpcyBub3QgeWV0IHBvc3NpYmxlIHRv IA0KPiBwcm92aWRlIHRoZSBwcmVzZW5jZSBzZXJ2aWNlIG9uIGEgd29ybGQtd2lkZSBzY2FsZSBi YXNpcyB3aXRoIA0KPiBkaWZmZXJlbnQgZG9tYWlucyBhbmQgc3ViLWRvbWFpbnMuDQoNCkludGVy ZG9tYWluIG9ubHkgaGlnaGxpZ2h0cyB0aGUgaXNzdWUgbW9yZSwgc2NhbGluZyB0byBtaWxsaW9u cyBvZg0KdXNlcnMgaW4gdGhlIHNhbWUgZG9tYWluIHdpbGwgaGF2ZSBzaW1pbGFyIHNjYWxpbmcg aXNzdWVzLg0KPiANCj4gU29tZSBjb21tZW50cyB0byB0aGlzIGRyYWZ0IGRvY3VtZW50Og0KPiAN Cj4gpzMuMg0KPiAibyAgQ29tcGxleGl0eSBvZiBwcmVzZW5jZSAmIGZyZXF1ZW5jeSBvZiBwcmVz ZW5jZSBjaGFuZ2UiDQo+ID0+IENvbXBsZXhpdHk6IGl0IGlzIGltcG9ydGFudCB0byBjb25zaWRl ciB0aGUgZGlmZmVyZW50IHBvc3NpYmxlIA0KPiBwcmVzZW5jZSBzdGF0ZXMgb2YgdGhlIG5ldHdv cmssIGRldmljZSwgYXBwbGljYXRpb24sIGVuZC11c2VyLg0KPiA9PiBGcmVxdWVuY3k6IHRoZSBw cm9iYWJpbGl0eSBvZiBiZWluZyBpbiBhIGNlcnRhaW4gc3RhdGUgYW5kIHRoZSANCj4gaW50ZW5z aXR5IG9mIHN0YXRlIGNoYW5nZXMsIGkuZS4gaGF2aW5nIG1hbnkgZGlmZmVyZW50IHBvc3NpYmxl IA0KPiBwcmVzZW5jZSBzdGF0ZXMgZG9lcyBub3QgYWx3YXlzIGltcGx5IGEgaGlnaCBhbW91bnQg b2YgcHJlc2VuY2UgDQo+IHN0YXRlIGNoYW5nZSBtZXNzYWdlcy4gSW5zdGVhZCwgaXQgY2FuIGV2 ZW4gaGVscCB0byByZWR1Y2UgdGhlIA0KPiBhbW91bnQgb2YgcmVxdWlyZWQgbWVzc2FnZXMuDQoN CldpbGwgY2xhcmlmeSBpbiB0aGUgbmV4dCB2ZXJzaW9uDQoNCj4gDQo+ICJvICAoQTIpIFByZXNl bmNlIHN0YXRlIGNoYW5nZXMgLyBob3VyIC4uLiBXZSBhc3N1bWVkIDMgdGltZXMgYW4gDQo+IGhv dXIgZm9yIG1vc3QgY2FsY3VsYXRpb25zLiBOb3RlIHRoYXQgZm9yIHNvbWUgdXNlcnMgaW4gY29u c3VtZXIgDQo+IG1lc3NhZ2luZyBzeXN0ZW1zLCB0aGUgYWN0dWFsIG51bWJlcnMgYXJlIGxpa2Vs eSB0byBiZSBtdWNoIGhpZ2hlci4iDQo+ID0+IEkgYWdyZWUgdGhhdCAzIGNoYW5nZXMvaG91ciBp cyBhIHZlcnkgb3B0aW1pc3RpYyBhcHByb2FjaC4gDQo+IEhvd2V2ZXIsIGZvciB0aGUgZXhpc3Rp bmcgcHJlc2VuY2Ugc2VydmVycywgdGhlIGFtb3VudCBvZiBwcmVzZW5jZSANCj4gc3RhdGVzIGFu ZCBwcmVzZW5jZSBzdGF0ZSBjaGFuZ2VzIGlzIHN0aWxsIHF1aXRlIGxpbWl0ZWQsIGNlcnRhaW5s eSANCj4gaW4gY2FzZXMgd2hlcmUgdGhlIElNIHNlcnZpY2UsIG1ha2luZyB1c2Ugb2YgdGhlIHBy ZXNlbmNlIGluZm8sIGlzIA0KPiB1c2VkIG9uIGZpeGVkIG5ldHdvcmsgYnJvYWRiYW5kIGNvbm5l Y3Rpb25zLiBGb3IgYSAibW9iaWxlIiB1c2Ugb2YgDQo+IHRoZSBJTSBzZXJ2aWNlLCB0aGUgbmV0 d29yayBhdmFpbGFiaWxpdHkgc3RhdGUgYWxzbyBiZWNvbWVzIGEgbWFqb3IgDQo+IGNvbmNlcm46 IGkuZS4gaG90IHNwb3QgY292ZXJhZ2UsIGhhbmRvdmVyIGJldHdlZW4gY2VsbHVsYXIgYW5kIFdM QU4gDQo+IG5ldHdvcmtzLCAuLi4gYXBwbGljYXRpb24gdHJhbnNmZXIgYmV0d2VlbiBkaWZmZXJl bnQgZW5kIHVzZXIgZGV2aWNlcywgDQpldGMuLi4NCj4gDQo+ICJvICAoQTEyKSAuLi4gdGhlIG51 bWJlciB3aWxsIGJlIChBMS9BMykqQTUuIg0KPiA9PiBTaG91bGQgdGhpcyBub3QgYmUgMiooQTEv QTMpKkE1PyAgKDIgTWVzc2FnZXM6IE5vdGlmeSArIDIwMCBPSykNCg0KV2UgbXVsdGlwbHkgYnkg MiBsYXRlciAtIGUuZy4gRTA3LCBFMDgsIEUxMA0KDQo+IA0KPiAibyAoQTE2KSAgLi4uKEE3K0E4 KSpBNiINCj4gPT4gSXMgaXQgbm90IGJldHRlciB0byB1c2UgdGhlIGRlZmluaXRpb24gKEExNCtB MTUpKkE2IHRvIG1ha2UgdGhlIA0KPiBkaXN0aW5jdGlvbiBiZXR3ZWVuIHRoZSB1bi1zdWJzY3Jp YmUgYW5kIHRoZSBzdWJzY3JpcHRpb24gcGhhc2U/DQoNCkFncmVlLg0KDQo+IA0KPiANCj4gpzMu Mw0KPiA9PiBGb3IgdGhlIG9wdGltaXphdGlvbnMsIG9ubHkgdHdvIG9wdGltaXphdGlvbiBvcHRp b25zLCBpLmUuIGZvciANCj4gKEEwNSkgYW5kIChBMTIpIGFyZSBjb25zaWRlcmVkLiBJcyBpdCBu b3QgcG9zc2libGUgdG8gY29uc2lkZXIgYWxzbyANCj4gdGhlIG9wdGltaXphdGlvbiBvcHRpb24g Zm9yIChBMTUpLCBpLmUuIGF2b2lkaW5nIHNlbmRpbmcgYSBOT1RJRlkgDQo+IGZvciB0aGUgdW4t c3Vic2NyaWJlPyBIb3dldmVyLCBJIGFncmVlIHRoYXQgdGhlIGFkZGl0aW9uYWwgDQo+IHBlcmZv cm1hbmNlIGdhaW4gaXMgdmVyeSBsaW1pdGVkICg8IDElKS4gDQoNCkl0IGlzIHZlcnkgbGltaXRl ZCBhbmQgaXQgbWF5IGJlIGJldHRlciBub3QgdG8gbWFrZSB0aGUgbW9kZWwgbW9yZSBjb21wbGV4 DQoNCj4gDQo+ID0+IFRoZSBjYWxjdWxhdGlvbnMgc2hvdyB0aGUgZWZmZWN0IGZvciBvcHRpbWl6 YXRpb25zIGluIGEgcmVkdWN0aW9uDQo+IG9mIHRoZSB0b3RhbCBhbW91bnQgb2YgbWVzc2FnZXMg Zm9yIHRoZSBkaWZmZXJlbnQgZGVwbG95bWVudCBtb2RlbHMgDQo+IHdpdGggaW5kaWNhdGVkIG9w dGltaXphdGlvbnMgb2YgMzguNiUsIDQ0LjElLCAyNy42JSBhbmQgNDIuNyUuDQo+IA0KPiBIb3dl dmVyLCB0aGVzZSBtb2RlbHMgb25seSBjb25zaWRlciBhIG1vZGVyYXRlIHN0YXR1cyBjaGFuZ2Ug b2YgMyBvcg0KPiA2IHByZXNlbmNlIHN0YXRlIGNoYW5nZXMgcGVyIGhvdXIuIFRoaXMgY291bGQg YmUgY29uc2lkZXJlZCBhcyBhIA0KPiBraW5kIG9mICJub3JtYWwiIHVzYWdlLiBIb3dldmVyLCB3 aGVuIGEgaGlnaGVyIGludGVuc2l0eSBvZiBwcmVzZW5jZQ0KPiBzdGF0ZSBjaGFuZ2VzIGlzIGNv bnNpZGVyZWQgdGhlIGluZGljYXRlZCBvcHRpbWl6YXRpb24gZWZmZWN0cyANCj4gYmVjb21lcyB2 ZXJ5IHNtYWxsOiBmb3IgYSAibWVkaXVtIiBraW5kIG9mIHByZXNlbmNlIHN0YXRlIGNoYW5nZSAN Cj4gd2l0aCBhbiBpbnRlbnNpdHkgb2YgIDUgbWluLCB0aGUgb3B0aW1pemF0aW9uIGVmZmVjdCBi ZWNvbWVzIGxvd2VyIA0KPiBhcyAxNSUgYW5kIGZvciBhICJoaWdoIiBpbnRlbnNpdHkgb2YgNSBz ZWMsIHRoZSBvcHRpbWl6YXRpb24gZWZmZWN0IA0KPiBpcyBvbmx5IDAsMyUhIFRoaXMgY2xlYXJs eSBpbmRpY2F0ZXMgdGhlIGJvdHRsZW5lY2sgZm9yIHRoZSBzZXJ2ZXItDQo+IHRvLXNlcnZlciBj b21tdW5pY2F0aW9uIGFuZCBub3Qgb25seSBiZXR3ZWVuIGludGVyLWRvbWFpbnMgYnV0IGFsc28g DQo+IGJldHdlZW4gcHJlc2VuY2Ugc2VydmVycyBpbiBhbiBvd24gcHJvcHJpZXRhcnkgaW50cmEt ZG9tYWluLg0KDQpBZ3JlZS4gVGhlIGludGVyIGRvbWFpbiBoZWxwcyB0byBkZW1vbnN0cmF0ZSB0 aGUgcHJvYmxlbSBtb3JlIGVhc2lseQ0Kc2luY2UgaW4gaW50cmEtZG9tYWluIHRoZXJlIG1heSBi ZSB3YXlzIHRvIGxvYWQgYmFsYW5jZSBiZXR3ZWVuIHRoZQ0Kc2VydmVycyBldGMuIGJ1dCB0aGUg Ym90dG9tIGxpbmUgaXMgdGhhdCB0aGUgc2FtZSBpc3N1ZXMgZXhpc3QgaW4gaW50cmENCmRvbWFp bi4gDQpJdCBpcyB0cnVlIHRoYXQgaWYgdGhlIGludGVuc2l0eSBvZiBjaGFuZ2VzIGluY3JlYXNl cyB0aGVuIHRoZSBjb25zaWRlcmVkDQpvcHRpbWl6YXRpb25zIHdpbGwgaGF2ZSBsZXNzIGFmZmVj dC4NCj4gDQo+IEluIHRoZSBkb2N1bWVudCwgb25seSB0aGUgYW1vdW50IG9mIG1lc3NhZ2VzIGlz IGNvbnNpZGVyZWQuIEZvciB0aGUgDQo+IG5ldHdvcmsgcmVzb3VyY2UgdXNhZ2UsIGl0IGlzIGFs c28gaW1wb3J0YW50IHRvIGNvbnNpZGVyIHRoZSANCj4gcmVxdWlyZWQgYmFuZHdpZHRoIGZvciB0 aGUgaW5mb3JtYXRpb24gdHJhbnNmZXIuIEZvciB0aGUgdmVyeSBsYXJnZSANCj4gbmV0d29yayBw ZWVyaW5nLCB0aGlzIHJlcXVpcmVzIGNhLiA2IEdicHMgZm9yIHRoZSAibm9ybWFsIiANCj4gaW50 ZW5zaXR5LCAxMCBHYnBzIGZvciB0aGUgIm1lZGl1bSIgaW50ZW5zaXR5IGFuZCBldmVuIDY0MCBH YnBzIGZvciANCj4gdGhlICJoaWdoIiBpbnRlbnNpdHkuDQoNCkFncmVlLCB3aWxsIGFkZCB0aGF0 IGNhbGN1bGF0aW9uIHRvIHRoZSBuZXh0IHZlcnNpb24uDQo+IA0KPiBDb25jbHVzaW9uOg0KPiBX aGVuIHdlIHdhbnQgdG8gaGF2ZSBhIHByZXNlbmNlIHN5c3RlbSB3aGljaCBjYW4gYmUgdXNlZCBv biBhIHdvcmxkLQ0KPiB3aWRlIHNjYWxlIGJhc2lzIHdpdGggNiBiaWxsaW9uIHBvdGVudGlhbCB1 c2VycywgdGhlIGV4aXN0aW5nIA0KPiBjbGllbnQvc2VydmVyIGRpYWxvZyBjb25jZXB0IGlzIG5v dCBhZGVxdWF0ZS4gRnVydGhlciwgaXQgaXMgdmVyeSANCj4gaGFyZCB0byBwcmVkaWN0IHRoZSBh bW91bnQgb2YgZ2VuZXJhdGVkIHRyYWZmaWMgZHVlIHRvIG1hbnkgdW5rbm93biANCj4gZmFjdG9y cywgZS5nLiB3aGljaCBuZXcgZnV0dXJlIGFwcGxpY2F0aW9ucyB3aWxsIG1ha2UgdXNlIG9mIHRo aXMgDQo+IHByZXNlbmNlIGluZm9ybWF0aW9uLCB3aGF0IHdpbGwgYmUgdGhlIGVuZC11c2VyIGFj Y2VwdGFuY2UgYW5kIA0KPiBiZWhhdmlvcj8gQXMgc3VjaCwgYSBjb25jZXB0IGFyY2hpdGVjdHVy ZSBpcyBuZWVkZWQgd2hpY2ggcHV0cyBubyANCj4gY29uc3RyYWludHMgb24gdGhlIGV4cGFuc2lv biBvZiB0aGUgc3lzdGVtIGFuZCB3aGljaCBhbGxvd3MgZm9yIA0KPiBoaWdoZXIgcHJlc2VuY2Ug c3RhdGUgY2hhbmdlIGludGVuc2l0aWVzIChub3JtYWwsIG1lZGl1bSwgaGlnaCANCj4gaW50ZW5z aXR5IGNoYW5nZXMpLg0KDQpJdCBzZWVtcyB0aGF0IHdlIG5lZWQgdG8gdGhpbmsgYWJvdXQgdGhl IHByb2JsZW0gaW4gYSBkaWZmZXJlbnQgd2F5Lg0KV2UgbmVlZCB0byB0aGluayBhYm91dCBzY2Fs YWJpbGl0eSBhcyBwYXJ0IG9mIHRoZSBwcm90b2NvbCBkZXNpZ24uDQpUaGUgSUVURiB0ZW5kcyBu b3QgdG8gdGhpbmsgYWJvdXQgYWN0dWFsIGRlcGxveW1lbnRzIHdoZW4gZGVzaWduaW5nDQphIHBy b3RvY29sIGJ1dCBpbiB0aGlzIGNhc2UgaXQgc2VlbXMgdGhhdCBpZiB3ZSBkbyBub3QgdGhpbmsg YWJvdXQNCnNjYWxhYmlsaXR5IHdpdGggdGhlIHByb3RvY29sIGRlc2lnbiBpdCB3aWxsIG5vdCBi ZSBwb3NzaWJsZSB0byBzY2FsZQ0Kc2luY2UgdGhlIGlzc3VlcyB0aGF0IHdlIGhhdmUgYXJlIGlu aGVyZW50IHRvIHRoZSBwcm90b2NvbCBhbmQgd2lsbCBub3QNCmJlIHNvbHZlZCBieSBzbWFydCBh cmNoaXRlY3R1cmUuDQoNCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gDQo+IE1hcmMgV2lsbGVrZW5z DQo+IE1haWx0bzptYXJjLndpbGxla2Vuc0BzaWVtZW5zLmNvbQ0K --=_alternative 00280D57C2257220_= Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5NYXJjLDwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPlRoYW5rcyBmb3IgdGhlIHZhbHVh YmxlIGNvbW1lbnRzLiBTZWUNCm1vcmUgaW5saW5lLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPi0tQXZzaGFsb208L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZxdW90O1dpbGxla2VucywgTWFyYyZxdW90OyAmbHQ7TWFyYy5XaWxsZWtlbnNAc2ll bWVucy5jb20mZ3Q7DQp3cm90ZSBvbiAwNi8xMS8yMDA2IDE1OjI0OjE4Ojxicj4NCjxicj4NCiZn dDsgSGksPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBTb21lIGNvbW1lbnRzIHRvIHRoZSBk cmFmdCBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LTxicj4NCiZndDsgZHJhZnRzL2RyYWZ0 LXJhbmctc2ltcGxlLXByb2JsZW0tc3RhdGVtZW50LTAxLnR4dDwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgVGhpcyBkb2N1bWVudCBjbGVhcmx5IGluZGljYXRlcyB0aGUgbWFpbiBwcm9ibGVt DQpmb3IgdGhlIGV4aXN0aW5nIDxicj4NCiZndDsgcHJlc2VuY2Ugc3lzdGVtcyB3aGljaCBhcmUg Y2xvc2VkIHN5c3RlbXMgZm9yIGEgJnF1b3Q7bGltaXRlZCZxdW90Ow0KYW1vdW50IG9mIDxicj4N CiZndDsgdXNlcnMuIEludGVyLWRvbWFpbiBwZWVyaW5nIG9uIGEgdmVyeSBsYXJnZSBzY2FsZSBi YXNpcyBpcyBldmVuIG5vdA0KPGJyPg0KJmd0OyBwb3NzaWJsZSB3aXRoIHRoZSBleGlzdGluZyBz dGFuZGFyZHMuIEl0IGlzIG5vdCB5ZXQgcG9zc2libGUgdG8gPGJyPg0KJmd0OyBwcm92aWRlIHRo ZSBwcmVzZW5jZSBzZXJ2aWNlIG9uIGEgd29ybGQtd2lkZSBzY2FsZSBiYXNpcyB3aXRoIDxicj4N CiZndDsgZGlmZmVyZW50IGRvbWFpbnMgYW5kIHN1Yi1kb21haW5zLjwvZm9udD48L3R0Pg0KPGJy Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SW50ZXJkb21haW4gb25seSBoaWdobGlnaHRzIHRoZSBp c3N1ZSBtb3JlLCBzY2FsaW5nDQp0byBtaWxsaW9ucyBvZjwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+dXNlcnMgaW4gdGhlIHNhbWUgZG9tYWluIHdpbGwgaGF2ZSBzaW1pbGFyIHNj YWxpbmcNCmlzc3Vlcy48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5i c3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFNvbWUgY29tbWVudHMg dG8gdGhpcyBkcmFmdCBkb2N1bWVudDo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IKczLjI8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJnF1b3Q7byAmbmJzcDtDb21w bGV4aXR5IG9mIHByZXNlbmNlICZhbXA7IGZyZXF1ZW5jeQ0Kb2YgcHJlc2VuY2UgY2hhbmdlJnF1 b3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ID0mZ3Q7IENvbXBsZXhp dHk6IGl0IGlzIGltcG9ydGFudCB0byBjb25zaWRlcg0KdGhlIGRpZmZlcmVudCBwb3NzaWJsZSA8 YnI+DQomZ3Q7IHByZXNlbmNlIHN0YXRlcyBvZiB0aGUgbmV0d29yaywgZGV2aWNlLCBhcHBsaWNh dGlvbiwgZW5kLXVzZXIuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ID0m Z3Q7IEZyZXF1ZW5jeTogdGhlIHByb2JhYmlsaXR5IG9mIGJlaW5nIGluDQphIGNlcnRhaW4gc3Rh dGUgYW5kIHRoZSA8YnI+DQomZ3Q7IGludGVuc2l0eSBvZiBzdGF0ZSBjaGFuZ2VzLCBpLmUuIGhh dmluZyBtYW55IGRpZmZlcmVudCBwb3NzaWJsZSA8YnI+DQomZ3Q7IHByZXNlbmNlIHN0YXRlcyBk b2VzIG5vdCBhbHdheXMgaW1wbHkgYSBoaWdoIGFtb3VudCBvZiBwcmVzZW5jZSA8YnI+DQomZ3Q7 IHN0YXRlIGNoYW5nZSBtZXNzYWdlcy4gSW5zdGVhZCwgaXQgY2FuIGV2ZW4gaGVscCB0byByZWR1 Y2UgdGhlIDxicj4NCiZndDsgYW1vdW50IG9mIHJlcXVpcmVkIG1lc3NhZ2VzLjwvZm9udD48L3R0 Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+V2lsbCBjbGFyaWZ5IGluIHRoZSBuZXh0IHZl cnNpb248L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZxdW90O28gJm5ic3A7KEEy KSBQcmVzZW5jZSBzdGF0ZSBjaGFuZ2VzIC8gaG91cg0KLi4uIFdlIGFzc3VtZWQgMyB0aW1lcyBh biA8YnI+DQomZ3Q7IGhvdXIgZm9yIG1vc3QgY2FsY3VsYXRpb25zLiBOb3RlIHRoYXQgZm9yIHNv bWUgdXNlcnMgaW4gY29uc3VtZXIgPGJyPg0KJmd0OyBtZXNzYWdpbmcgc3lzdGVtcywgdGhlIGFj dHVhbCBudW1iZXJzIGFyZSBsaWtlbHkgdG8gYmUgbXVjaCBoaWdoZXIuJnF1b3Q7PC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ID0mZ3Q7IEkgYWdyZWUgdGhhdCAzIGNoYW5n ZXMvaG91ciBpcyBhIHZlcnkgb3B0aW1pc3RpYw0KYXBwcm9hY2guIDxicj4NCiZndDsgSG93ZXZl ciwgZm9yIHRoZSBleGlzdGluZyBwcmVzZW5jZSBzZXJ2ZXJzLCB0aGUgYW1vdW50IG9mIHByZXNl bmNlDQo8YnI+DQomZ3Q7IHN0YXRlcyBhbmQgcHJlc2VuY2Ugc3RhdGUgY2hhbmdlcyBpcyBzdGls bCBxdWl0ZSBsaW1pdGVkLCBjZXJ0YWlubHkNCjxicj4NCiZndDsgaW4gY2FzZXMgd2hlcmUgdGhl IElNIHNlcnZpY2UsIG1ha2luZyB1c2Ugb2YgdGhlIHByZXNlbmNlIGluZm8sIGlzDQo8YnI+DQom Z3Q7IHVzZWQgb24gZml4ZWQgbmV0d29yayBicm9hZGJhbmQgY29ubmVjdGlvbnMuIEZvciBhICZx dW90O21vYmlsZSZxdW90Ow0KdXNlIG9mIDxicj4NCiZndDsgdGhlIElNIHNlcnZpY2UsIHRoZSBu ZXR3b3JrIGF2YWlsYWJpbGl0eSBzdGF0ZSBhbHNvIGJlY29tZXMgYSBtYWpvcg0KPGJyPg0KJmd0 OyBjb25jZXJuOiBpLmUuIGhvdCBzcG90IGNvdmVyYWdlLCBoYW5kb3ZlciBiZXR3ZWVuIGNlbGx1 bGFyIGFuZCBXTEFODQo8YnI+DQomZ3Q7IG5ldHdvcmtzLCAuLi4gYXBwbGljYXRpb24gdHJhbnNm ZXIgYmV0d2VlbiBkaWZmZXJlbnQgZW5kIHVzZXIgZGV2aWNlcywNCmV0Yy4uLjwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgJnF1b3Q7byAmbmJzcDsoQTEyKSAuLi4gdGhlIG51bWJlciB3aWxs IGJlIChBMS9BMykqQTUuJnF1b3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7ID0mZ3Q7IFNob3VsZCB0aGlzIG5vdCBiZSAyKihBMS9BMykqQTU/ICZuYnNwOygyDQpNZXNz YWdlczogTm90aWZ5ICsgMjAwIE9LKTwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBz aXplPTI+V2UgbXVsdGlwbHkgYnkgMiBsYXRlciAtIGUuZy4gRTA3LCBFMDgsIEUxMDwvZm9udD48 L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJnF1b3Q7byAoQTE2KSAmbmJzcDsuLi4oQTcrQTgp KkE2JnF1b3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ID0mZ3Q7IElz IGl0IG5vdCBiZXR0ZXIgdG8gdXNlIHRoZSBkZWZpbml0aW9uDQooQTE0K0ExNSkqQTYgdG8gbWFr ZSB0aGUgPGJyPg0KJmd0OyBkaXN0aW5jdGlvbiBiZXR3ZWVuIHRoZSB1bi1zdWJzY3JpYmUgYW5k IHRoZSBzdWJzY3JpcHRpb24gcGhhc2U/PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj5BZ3JlZS48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyCnMy4zPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ID0mZ3Q7IEZvciB0aGUgb3B0aW1pemF0aW9ucywgb25s eSB0d28gb3B0aW1pemF0aW9uDQpvcHRpb25zLCBpLmUuIGZvciA8YnI+DQomZ3Q7IChBMDUpIGFu ZCAoQTEyKSBhcmUgY29uc2lkZXJlZC4gSXMgaXQgbm90IHBvc3NpYmxlIHRvIGNvbnNpZGVyIGFs c28NCjxicj4NCiZndDsgdGhlIG9wdGltaXphdGlvbiBvcHRpb24gZm9yIChBMTUpLCBpLmUuIGF2 b2lkaW5nIHNlbmRpbmcgYSBOT1RJRlkNCjxicj4NCiZndDsgZm9yIHRoZSB1bi1zdWJzY3JpYmU/ IEhvd2V2ZXIsIEkgYWdyZWUgdGhhdCB0aGUgYWRkaXRpb25hbCA8YnI+DQomZ3Q7IHBlcmZvcm1h bmNlIGdhaW4gaXMgdmVyeSBsaW1pdGVkICgmbHQ7IDElKS4gPC9mb250PjwvdHQ+DQo8YnI+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj5JdCBpcyB2ZXJ5IGxpbWl0ZWQgYW5kIGl0IG1heSBiZSBiZXR0 ZXIgbm90IHRvIG1ha2UNCnRoZSBtb2RlbCBtb3JlIGNvbXBsZXg8L2ZvbnQ+PC90dD4NCjxicj4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7ID0mZ3Q7IFRoZSBjYWxjdWxhdGlvbnMgc2hvdyB0aGUgZWZmZWN0IGZv ciBvcHRpbWl6YXRpb25zDQppbiBhIHJlZHVjdGlvbjxicj4NCiZndDsgb2YgdGhlIHRvdGFsIGFt b3VudCBvZiBtZXNzYWdlcyBmb3IgdGhlIGRpZmZlcmVudCBkZXBsb3ltZW50IG1vZGVscw0KPGJy Pg0KJmd0OyB3aXRoIGluZGljYXRlZCBvcHRpbWl6YXRpb25zIG9mIDM4LjYlLCA0NC4xJSwgMjcu NiUgYW5kIDQyLjclLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJz cDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSG93ZXZlciwgdGhlc2Ug bW9kZWxzIG9ubHkgY29uc2lkZXIgYSBtb2RlcmF0ZQ0Kc3RhdHVzIGNoYW5nZSBvZiAzIG9yPGJy Pg0KJmd0OyA2IHByZXNlbmNlIHN0YXRlIGNoYW5nZXMgcGVyIGhvdXIuIFRoaXMgY291bGQgYmUg Y29uc2lkZXJlZCBhcyBhIDxicj4NCiZndDsga2luZCBvZiAmcXVvdDtub3JtYWwmcXVvdDsgdXNh Z2UuIEhvd2V2ZXIsIHdoZW4gYSBoaWdoZXIgaW50ZW5zaXR5DQpvZiBwcmVzZW5jZTxicj4NCiZn dDsgc3RhdGUgY2hhbmdlcyBpcyBjb25zaWRlcmVkIHRoZSBpbmRpY2F0ZWQgb3B0aW1pemF0aW9u IGVmZmVjdHMgPGJyPg0KJmd0OyBiZWNvbWVzIHZlcnkgc21hbGw6IGZvciBhICZxdW90O21lZGl1 bSZxdW90OyBraW5kIG9mIHByZXNlbmNlIHN0YXRlDQpjaGFuZ2UgPGJyPg0KJmd0OyB3aXRoIGFu IGludGVuc2l0eSBvZiAmbmJzcDs1IG1pbiwgdGhlIG9wdGltaXphdGlvbiBlZmZlY3QgYmVjb21l cw0KbG93ZXIgPGJyPg0KJmd0OyBhcyAxNSUgYW5kIGZvciBhICZxdW90O2hpZ2gmcXVvdDsgaW50 ZW5zaXR5IG9mIDUgc2VjLCB0aGUgb3B0aW1pemF0aW9uDQplZmZlY3QgPGJyPg0KJmd0OyBpcyBv bmx5IDAsMyUhIFRoaXMgY2xlYXJseSBpbmRpY2F0ZXMgdGhlIGJvdHRsZW5lY2sgZm9yIHRoZSBz ZXJ2ZXItPGJyPg0KJmd0OyB0by1zZXJ2ZXIgY29tbXVuaWNhdGlvbiBhbmQgbm90IG9ubHkgYmV0 d2VlbiBpbnRlci1kb21haW5zIGJ1dCBhbHNvDQo8YnI+DQomZ3Q7IGJldHdlZW4gcHJlc2VuY2Ug c2VydmVycyBpbiBhbiBvd24gcHJvcHJpZXRhcnkgaW50cmEtZG9tYWluLjwvZm9udD48L3R0Pg0K PGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+QWdyZWUuIFRoZSBpbnRlciBkb21haW4gaGVscHMg dG8gZGVtb25zdHJhdGUgdGhlIHByb2JsZW0NCm1vcmUgZWFzaWx5PC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj5zaW5jZSBpbiBpbnRyYS1kb21haW4gdGhlcmUgbWF5IGJlIHdheXMg dG8gbG9hZCBiYWxhbmNlDQpiZXR3ZWVuIHRoZTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+c2VydmVycyBldGMuIGJ1dCB0aGUgYm90dG9tIGxpbmUgaXMgdGhhdCB0aGUgc2FtZQ0K aXNzdWVzIGV4aXN0IGluIGludHJhPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5k b21haW4uIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SXQgaXMgdHJ1ZSB0aGF0 IGlmIHRoZSBpbnRlbnNpdHkgb2YgY2hhbmdlcyBpbmNyZWFzZXMNCnRoZW4gdGhlIGNvbnNpZGVy ZWQ8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPm9wdGltaXphdGlvbnMgd2lsbCBo YXZlIGxlc3MgYWZmZWN0LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAm bmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSW4gdGhlIGRvY3Vt ZW50LCBvbmx5IHRoZSBhbW91bnQgb2YgbWVzc2FnZXMNCmlzIGNvbnNpZGVyZWQuIEZvciB0aGUg PGJyPg0KJmd0OyBuZXR3b3JrIHJlc291cmNlIHVzYWdlLCBpdCBpcyBhbHNvIGltcG9ydGFudCB0 byBjb25zaWRlciB0aGUgPGJyPg0KJmd0OyByZXF1aXJlZCBiYW5kd2lkdGggZm9yIHRoZSBpbmZv cm1hdGlvbiB0cmFuc2Zlci4gRm9yIHRoZSB2ZXJ5IGxhcmdlDQo8YnI+DQomZ3Q7IG5ldHdvcmsg cGVlcmluZywgdGhpcyByZXF1aXJlcyBjYS4gNiBHYnBzIGZvciB0aGUgJnF1b3Q7bm9ybWFsJnF1 b3Q7DQo8YnI+DQomZ3Q7IGludGVuc2l0eSwgMTAgR2JwcyBmb3IgdGhlICZxdW90O21lZGl1bSZx dW90OyBpbnRlbnNpdHkgYW5kIGV2ZW4gNjQwDQpHYnBzIGZvciA8YnI+DQomZ3Q7IHRoZSAmcXVv dDtoaWdoJnF1b3Q7IGludGVuc2l0eS48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPkFncmVlLCB3aWxsIGFkZCB0aGF0IGNhbGN1bGF0aW9uIHRvIHRoZSBuZXh0IHZlcnNp b24uPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBDb25jbHVzaW9uOjwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBXaGVuIHdlIHdhbnQgdG8gaGF2ZSBhIHByZXNlbmNl IHN5c3RlbSB3aGljaA0KY2FuIGJlIHVzZWQgb24gYSB3b3JsZC08YnI+DQomZ3Q7IHdpZGUgc2Nh bGUgYmFzaXMgd2l0aCA2IGJpbGxpb24gcG90ZW50aWFsIHVzZXJzLCB0aGUgZXhpc3RpbmcgPGJy Pg0KJmd0OyBjbGllbnQvc2VydmVyIGRpYWxvZyBjb25jZXB0IGlzIG5vdCBhZGVxdWF0ZS4gRnVy dGhlciwgaXQgaXMgdmVyeQ0KPGJyPg0KJmd0OyBoYXJkIHRvIHByZWRpY3QgdGhlIGFtb3VudCBv ZiBnZW5lcmF0ZWQgdHJhZmZpYyBkdWUgdG8gbWFueSB1bmtub3duDQo8YnI+DQomZ3Q7IGZhY3Rv cnMsIGUuZy4gd2hpY2ggbmV3IGZ1dHVyZSBhcHBsaWNhdGlvbnMgd2lsbCBtYWtlIHVzZSBvZiB0 aGlzDQo8YnI+DQomZ3Q7IHByZXNlbmNlIGluZm9ybWF0aW9uLCB3aGF0IHdpbGwgYmUgdGhlIGVu ZC11c2VyIGFjY2VwdGFuY2UgYW5kIDxicj4NCiZndDsgYmVoYXZpb3I/IEFzIHN1Y2gsIGEgY29u Y2VwdCBhcmNoaXRlY3R1cmUgaXMgbmVlZGVkIHdoaWNoIHB1dHMgbm8NCjxicj4NCiZndDsgY29u c3RyYWludHMgb24gdGhlIGV4cGFuc2lvbiBvZiB0aGUgc3lzdGVtIGFuZCB3aGljaCBhbGxvd3Mg Zm9yIDxicj4NCiZndDsgaGlnaGVyIHByZXNlbmNlIHN0YXRlIGNoYW5nZSBpbnRlbnNpdGllcyAo bm9ybWFsLCBtZWRpdW0sIGhpZ2ggPGJyPg0KJmd0OyBpbnRlbnNpdHkgY2hhbmdlcykuPC9mb250 PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JdCBzZWVtcyB0aGF0IHdlIG5lZWQg dG8gdGhpbmsgYWJvdXQgdGhlIHByb2JsZW0gaW4NCmEgZGlmZmVyZW50IHdheS48L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPldlIG5lZWQgdG8gdGhpbmsgYWJvdXQgc2NhbGFiaWxp dHkgYXMgcGFydCBvZiB0aGUNCnByb3RvY29sIGRlc2lnbi48L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPlRoZSBJRVRGIHRlbmRzIG5vdCB0byB0aGluayBhYm91dCBhY3R1YWwgZGVw bG95bWVudHMNCndoZW4gZGVzaWduaW5nPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj5hIHByb3RvY29sIGJ1dCBpbiB0aGlzIGNhc2UgaXQgc2VlbXMgdGhhdCBpZiB3ZSBkbw0Kbm90 IHRoaW5rIGFib3V0PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5zY2FsYWJpbGl0 eSB3aXRoIHRoZSBwcm90b2NvbCBkZXNpZ24gaXQgd2lsbCBub3QgYmUNCnBvc3NpYmxlIHRvIHNj YWxlPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5zaW5jZSB0aGUgaXNzdWVzIHRo YXQgd2UgaGF2ZSBhcmUgaW5oZXJlbnQgdG8gdGhlDQpwcm90b2NvbCBhbmQgd2lsbCBub3Q8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPmJlIHNvbHZlZCBieSBzbWFydCBhcmNoaXRl Y3R1cmUuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNw OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBCZXN0IHJlZ2FyZHMsPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBNYXJjIFdpbGxla2VuczwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyBNYWlsdG86bWFyYy53aWxsZWtlbnNAc2llbWVucy5jb208 L2ZvbnQ+PC90dD4NCg== --=_alternative 00280D57C2257220_=-- --===============0924018066== 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 --===============0924018066==-- From simple-bounces@ietf.org Wed Nov 08 13:15:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhrwZ-0005oJ-DO; Wed, 08 Nov 2006 13:14:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhrwX-0005o6-SH for simple@ietf.org; Wed, 08 Nov 2006 13:14:33 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhrwW-0004JB-7P for simple@ietf.org; Wed, 08 Nov 2006 13:14:33 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 08 Nov 2006 10:14:31 -0800 X-IronPort-AV: i="4.09,401,1157353200"; d="scan'208"; a="87351411:sNHT47949138" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA8IEV83026310; Wed, 8 Nov 2006 10:14:31 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA8IEVAo005306; Wed, 8 Nov 2006 10:14:31 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 10:14:31 -0800 Received: from [130.129.71.49] ([10.21.98.223]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 10:14:31 -0800 Message-ID: <45521E86.7010909@cisco.com> Date: Wed, 08 Nov 2006 13:14:30 -0500 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 Subject: Re: [Simple] What is the proper winfo status when watcher is politely blocked References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2006 18:14:31.0108 (UTC) FILETIME=[BC695840:01C70361] DKIM-Signature: a=rsa-sha1; q=dns; l=1154; t=1163009671; x=1163873671; c=relaxed/simple; s=sjdkim3002; 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]=20What=20is=20the=20proper=20winfo=20status=20when=20wa tcher=20is=20politely=0A=20blocked; X=v=3Dcisco.com=3B=20h=3DlzoT0QXRNpo/HLXnroRRfj3HHtY=3D; b=lk8offxiNVoyuDpa4M9mfZ7iHoGUWH9qwMDBIlifxjmrz80gs4J3tNNldte228plIDc+K1SF qFWR47aCaOEwA3F8rzhBiLvkOgRmSmzNndqKvzoiNR3fyfbQlXK5S6XD; Authentication-Results: sj-dkim-3.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); 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 Its "active". The winfo state machine doesnt reflect the nuances of document filtering and manipulation, only the state of the presence subscription. -Jonathan R. Martin.Hynar@tietoenator.com wrote: > Hello all, > > I have encountered an issue with the watcher info. I can't find a clue in solvin this situation. > > 1. User A sets "polite-block" authorization policy on user B > 2. User A subscribes own watcher info > 3. User B subscribes user's A presence -> gets polite document > 4. User A receives winfo notification - now I dont know what shall be the proper value for "status" attribute? > > Any help is really appreciated. > > > br, Martin > > _______________________________________________ > 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 Mon Nov 13 04:41:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYHq-0001KL-FB; Mon, 13 Nov 2006 04:39:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjYHo-0001IQ-Vg for simple@ietf.org; Mon, 13 Nov 2006 04:39:28 -0500 Received: from mail.sbs.be ([193.109.72.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjYHh-0001Hq-Vf for simple@ietf.org; Mon, 13 Nov 2006 04:39:28 -0500 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kAD9d4JA006926; Mon, 13 Nov 2006 10:39:04 +0100 Received: from bru0032a.ww018.siemens.net (bru0032a.ww018.siemens.net [193.210.175.90]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kAD9d3i8018381; Mon, 13 Nov 2006 10:39:03 +0100 Received: from BRU0038A.ww018.siemens.net ([193.210.175.65]) by bru0032a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 10:38:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Nov 2006 10:38:58 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on presence-rules-08 Thread-Index: AccHB4tS0rXa6eL3QFiuo0eI48Fejw== From: "Vrancken, Johnny" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 13 Nov 2006 09:38:59.0900 (UTC) FILETIME=[8C0A4FC0:01C70707] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f Cc: simple@ietf.org Subject: [Simple] Comments on presence-rules-08 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="===============1904791754==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1904791754== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70707.8BBE3C7C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70707.8BBE3C7C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Jonathan, Here are a few comments / questions on = draft-ietf-simple-presence-rules-08.txt: =A73.2.1 Subscription Handling, page 8 In order to align with the terminology used in RFC 3857 / Figure 1 and = RFC 3858, the following changes are recommended: for block: subscriptions are placed in the "terminated" state = (authorization policy / decision =3D"reject") for polite-block & allow: subscriptions are placed in the "active" state = (authorization policy / decision =3D"accept") =A73.2.1 Subscription Handling, page 9, last paragraph: "If the sub-handling permission changes value to "polite-block" or = "allow", this causes an "approved" event to be generated into the state = machine for all affected subscriptions. " This is not completely true. If e.g. the sub-handling permission changes = from "allow" to "polite-block", or from "polite-block" to "allow", the = subscription is and remains in the "active" state and no event is = generated. So if the sub-handling permission changes value to "polite-block" or = "allow", the processing depends on the state of the affected = subscriptions. Only if the subscription is in the "pending" state, the = subscription state changes and a NOTIFY is sent. There is no change in = state if the subscription is in the active, waiting or terminated state. =A73.3 Transformations Considering the statements in =A73.3.1 and =A73.3.2, you need both a = fine gained access permission (=A73.3.2) and a corresponding coarse = grained access permission (=A73.3.1)to grant access to presence = attributes. So the most compact form of granting access of all presence attributes = to all watchers is the following rule: allow Question: is it a correct statement that a "false" valued boolean = permission serves no purpose unless combined with a = permission ? I.e. the following rule without a or = statement doesn't grant anything. allow false Question: is the following transformation in a single matching rule=20 true semantically equivalent to the following 2 transformations in 2 matching = rules, or are these 2 transformations meaningless ? In Rule 1: In Rule 2: true =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NITS: Page 8: ... Strictly speaking, it is not necessary to every RULESET TO = include an explicit block action Page 9: ... and the value of sub-handling that APPLIES to that = subscription is "CONFIRM", ... ("pending" to be replaced by "confirm" ) Page 17: ... that used VALUED "TRUE" for = some attribute, say foo. Page 18: ... will be granted access to THE PRESENCE DATA OF all = services whose contact URI .... Kind regards, Johnny ------_=_NextPart_001_01C70707.8BBE3C7C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on presence-rules-08

Dear = Jonathan,

Here are a = few  comments / questions on = draft-ietf-simple-presence-rules-08.txt:

=A73.2.1 = Subscription Handling, page 8
In order to align = with the terminology used in RFC 3857 / Figure 1 and RFC 3858, the = following changes are recommended:
for block: = subscriptions are placed in the "terminated" state = (authorization policy / decision =3D"reject")
for polite-block = & allow: subscriptions are placed in the "active" state = (authorization policy / decision =3D"accept")

=A73.2.1 = Subscription Handling, page 9, last paragraph:
"If = the sub-handling permission changes value to "polite-block" or = "allow", this causes an "approved" event to be = generated into the state machine for all affected subscriptions. = "

This is not = completely true. If e.g. the sub-handling permission changes from = "allow" to "polite-block", or from = "polite-block" to "allow", the subscription is and = remains in the "active" state and no event is = generated.

So if the = sub-handling permission changes value to "polite-block" or = "allow", the processing depends on the state of the affected = subscriptions. Only if the subscription is in the "pending" = state, the subscription state changes and a NOTIFY is sent. There is no = change in state if the subscription is in the active, waiting or = terminated state.

=A73.3 = Transformations
Considering the = statements in =A73.3.1 and =A73.3.2, you need both a fine gained access = permission (=A73.3.2) and a corresponding coarse grained access = permission (=A73.3.1)to grant access to presence = attributes.

So the most = compact form of granting access of all presence attributes to all = watchers is the following rule:
<rule = id=3D"GrantAll" >
  = <actions> <sub-handling>allow</sub-handling> = </actions>
  = <transformations>
    <provide-persons> = <all-persons/> </provide-persons>
    <provide-services> = <all-services/> </provide-services>
    <provide-devices> = <all-devices/> </provide-devices>
    = <provide-all-attributes/>
  = </transformations>
</rule>

Question: is it a = correct statement that a "false" valued boolean permission = serves no purpose unless combined with a <provide-all-attributes/> = permission ?

I.e. the following = rule without a <provide-persons> or <provide-all-attributes> = statement doesn't grant anything.
<rule = id=3D"GrantAllPersonsExceptMood" >
  = <actions> <sub-handling>allow</sub-handling> = </actions>
  = <transformations>
    <provide-persons> = <all-persons/> </provide-persons>
    = <provide-all-attributes/>
    <provide-mood> false = </provide-mood>
  = </transformations>
</rule>

Question: is the = following transformation in a single matching rule
<transformations>
    <provide-persons> = <all-persons/> </provide-persons>
    <provide-status-icon> true = </provide-status-icon>
 </transformations>

semantically = equivalent to the following 2 transformations in 2 matching rules, or = are these 2 transformations meaningless ?

In Rule 1: = <transformations>
    <provide-persons> = <all-persons/> </provide-persons>
</transformations>
In Rule 2: = <transformations>
    <provide-status-icon> true = </provide-status-icon>
</transformations>

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
NITS:
Page 8: … = Strictly speaking, it is not necessary to every RULESET TO include an = explicit block action
Page 9: … = and the value of sub-handling that APPLIES to that subscription is = "CONFIRM", ... ("pending" to be replaced by = "confirm" )

Page 17: … = that used <provide-unknown-attribute> VALUED "TRUE" for = some attribute, say foo.
Page  18: = … will be granted access to THE PRESENCE DATA OF all services = whose contact URI ….

Kind = regards,
Johnny



------_=_NextPart_001_01C70707.8BBE3C7C-- --===============1904791754== 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 --===============1904791754==-- From simple-bounces@ietf.org Wed Nov 15 15:52:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRic-0004rW-IW; Wed, 15 Nov 2006 15:50:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRiL-0004iF-9b; Wed, 15 Nov 2006 15:50:33 -0500 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 1GkRiK-00025v-HC; Wed, 15 Nov 2006 15:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GkRiK-0006KV-55; Wed, 15 Nov 2006 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 0EB782AC60; Wed, 15 Nov 2006 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GkRhp-0008Fc-Pw; Wed, 15 Nov 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 15 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-pidf-format-08.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 Information Data format (PIDF) Extension for Partial Presence Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-pidf-format-08.txt Pages : 17 Date : 2006-11-15 The Presence Information Document Format (PIDF) specifies the baseline XML based format for describing presence information. One of the characteristic of the PIDF is that the document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist it is often beneficial to limit the amount of transported information over the network. This document introduces a new MIME type which enables transporting of either only the changed parts or the full PIDF based presence information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-08.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-pidf-format-08.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-pidf-format-08.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-11-15120459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-pidf-format-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-15120459.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 Nov 20 11:41:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmCCI-0005gQ-BD; Mon, 20 Nov 2006 11:40:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmCCG-0005gE-Kg for simple@ietf.org; Mon, 20 Nov 2006 11:40:40 -0500 Received: from rat.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmCCC-0005Qz-A6 for simple@ietf.org; Mon, 20 Nov 2006 11:40:40 -0500 Received: by mail.iptel.org (Postfix, from userid 103) id 66ACB20A2F0; Mon, 20 Nov 2006 17:40:31 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on rat.iptel.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost.localdomain (nat.sip-server.net [213.192.30.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "V?clav Kubart", Issuer "iptel.org" (verified OK)) by mail.iptel.org (Postfix) with ESMTP id 290E120A2E5 for ; Mon, 20 Nov 2006 17:40:31 +0100 (CET) Received: by localhost.localdomain (Postfix, from userid 1001) id D0C6632001A; Mon, 20 Nov 2006 17:40:32 +0100 (CET) Date: Mon, 20 Nov 2006 17:40:32 +0100 From: Vaclav Kubart To: simple@ietf.org Message-ID: <20061120164032.GB7206@vencore.sip-server.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Simple] draft-ietf-simple-presence-rules-08.txt - XCAP naming conventions 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, I'm trying to implement presence server and I encountered a problem how to get authorization rules for specific user from XCAP server. In section 8.7 Naming Conventions is: 'When a presence agent receives a subscription for some user foo within a domain, it will look for all documents within http://[xcap root]/pres-rules/users/foo, and use all documents found beneath that point to guide authorization policy. If only a single document is used, it SHOULD be called "index".' But as far as I know there is no possibility to list documents for a user in XCAP server... Missed I something? Or should be the file "index" in user's directory used to union all other user's files? thanks for your advices, Vaclav _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 21 02:08:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmPic-0000MT-6I; Tue, 21 Nov 2006 02:06:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmPia-0000MN-WE for simple@ietf.org; Tue, 21 Nov 2006 02:06:57 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmPiY-0000wO-8M for simple@ietf.org; Tue, 21 Nov 2006 02:06:56 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAL75ZLi021107; Tue, 21 Nov 2006 09:06:43 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 09:06:32 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 21 Nov 2006 09:06:32 +0200 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int01.ntc.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAL76V5e031357; Tue, 21 Nov 2006 09:06:31 +0200 Received: from [172.21.38.148] (esdhcp038148.research.nokia.com [172.21.38.148]) by kusti.research.nokia.com (Postfix) with ESMTP id 9A87E93B78; Tue, 21 Nov 2006 09:06:31 +0200 (EET) Message-ID: <4562A577.1080602@nokia.com> Date: Tue, 21 Nov 2006 09:06:31 +0200 From: Jari Urpalainen User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: ext Lisa Dusseault References: <9B380A4E-C4B0-40E8-8620-470AEC7F43F4@osafoundation.org> In-Reply-To: <9B380A4E-C4B0-40E8-8620-470AEC7F43F4@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2006 07:06:32.0598 (UTC) FILETIME=[9320CB60:01C70D3B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: w3c-dist-auth@w3c.org, simple@ietf.org Subject: [Simple] Re: Belated review of draft-urpalainen-simple-xcap-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 Thanks Lisa for your comments, more inline. And sorry for cross-posting but this might interest both groups. ext Lisa Dusseault wrote: > > Hi Jari, > > I finally got around to reviewing this draft, version -01. The basic > model I completely agree with, it's the easiest one and quite useful. great. > > Some comments: > > - Is it necessary to say that the ETag used with XCAP operations > is the exact same as the one used in WebDAV operations? This allows a > client to use both XCAP and WebDAV without repeating ETag queries or > worrying about keeping two sets of ETags. This may be obvious already > since both WebDAV and XCAP only use HTTP ETags. imo, (and being an implementer) yes they must not be separate. And even implementation on top of Apache is simple (though it does response with weak ETags, but it is easy to patch it once you do have source code ;-) ) > > - Section 4.6: I'm not 100% sure that existing software out there > will all work with a WebDAV Principals namespace of the form > "http://principals.example.com/". More typically you see principal > namespaces inside the same domain name as the server that hosts the > content. So you might see "http://example.com/principals" or > "http://example.com/servlet/acl/principals". I do not know if these > forms have any disadvantages over the form you suggest but in ACL > deployment so far they're more likely to be seen. I agree that > principal namespaces on different domains is probably OK, but we might > want to think for a moment about whether it would be OK for a server > with content at "example.com" could have its principals at a > completely different DNS tree, e.g. "identities.example.ru". ok, I just not wanted to mess up with xcap conventions, i.e. principal entities would not interfere with an xcap application usage. If is better inline with current deployments I'm fine with that as well (virtual hosting is easy imo and/or reverse proxy configurations do help here anyway). Anyhow, this is only a recommendation and just to try to help the provisioning nightmare... And of course this should be (or have been) in rfc3744, imo, i.e. some conventions, though not being mandatory are typically useful for implementations. > > - You might want to add that the location for principals can be > discovered by doing an OPTIONS request and asking for the principals > namespace. Is there an alternative (XCAP) way of discovering the > location? > XCAP hasn't anything for this (just capability au). Are you proposing adding some mime type for OPTIONS * ? Certainly it would help provisioning... > - In section 4.6, you say "The user "joe" is thus an XCAP user > identity (XUI)". This is descriptive, not normative. Would it be > better to turn this into a normative requirement? E.g. > "A server that implements both WebDAV and XCAP MUST support the > same principal namespace for both WebDAV ACL usage and XCAP user > identities (XUI). That is, every valid WebDAV principal MUST also be > a XUI, and vice versa." right, I agree. > > - You might add a property to a principal, such that an > application that knows "who am I" (it has discovered its principal > identity as currently authenticated) can discover where its XCAP > application "home directories" are. For example, this could be a > multi-valued property valid on a Principal Resource, e.g. > > > > http://example.com/com.example.anAUID/joe/ > http://example.com/resource-lists/joe/ > > > > Even more generally, this property could identify the user's XCAP > documents of all kinds directly. right, again sounds reasonable to have xcap home directory principal property, the xcap capability extension lists available AUs. This seems to add some content to this i-d, btw ;-). > > - You might want to note that XCAP applications can add their own > privileges to the set of base WebDAV privileges. For example, let's > say we had an XCAP application defined for conferencing. Part of the > conference application has conference room setup -- what server it's > on, what bandwidth reserved. But another part of the conference > application is for moderation: who can provide input without > moderation, who is on the "moderate their input" lists, and who is > entirely blocked. For this application, we might want to define a > special XCAP conferencing "moderator" privilege that could do some set > of functions but not as much as the administrator who can edit the > entire XCAP document. The XCAP server would of course apply the > custom privilege and would allow or disallow PUT and DELETE to XCAP > node selector URLs, based on the privilege and the principal. > > > > > right. rfc3744 is extensible (and the basic model/idea is very reasonable, imo). > - Section 5, error handling: Since this document says that a > client is not to send WebDAV requests to XML node selector URLs, I > think the best response to seeing such a request would be in the > 400-series -- possibly 403 Forbidden. To make it clear what exactly > is forbidden, you can define an XML error code for return in the error > body, e.g. > > > > agreed, some deterministic (and documented) responses are definitely better. > > You can send these comments to a WG or discussion list if you like. > Thanks, > Lisa > Thank you, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 21 06:25:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmTjJ-0006pK-0S; Tue, 21 Nov 2006 06:23:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmTjH-0006pE-GO for simple@ietf.org; Tue, 21 Nov 2006 06:23:55 -0500 Received: from smtp3.infineon.com ([203.126.106.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmTjG-0008Rs-1x for simple@ietf.org; Tue, 21 Nov 2006 06:23:55 -0500 Received: from unknown (HELO sinse301.ap.infineon.com) ([172.20.70.22]) by smtp3.infineon.com with ESMTP; 21 Nov 2006 19:23:51 +0800 X-SBRS: None Received: from sinse303.ap.infineon.com ([172.20.70.24]) by sinse301.ap.infineon.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 19:23:51 +0800 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: Tue, 21 Nov 2006 19:23:50 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: query regarding Message Summary and Message Waiting Indication Event package RFC-3842. Thread-Index: AccNX4SsSePRxOMfRcanASEfMy948w== From: To: X-OriginalArrivalTime: 21 Nov 2006 11:23:51.0338 (UTC) FILETIME=[855590A0:01C70D5F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Simple] query regarding Message Summary and Message Waiting Indication Event package RFC-3842. 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 a query regarding Message Summary and Message Waiting Indication Event package RFC-3842. The syntax for the notify message for Message-summary event as specified in RFC-3842 is as below. *********** message-summary =3D msg-status-line CRLF [msg-account CRLF] [*(msg-summary-line CRLF)] [ *opt-msg-headers ] =20 msg-status-line =3D "Messages-Waiting" HCOLON msg-status msg-status =3D "yes" / "no" msg-account =3D "Message-Account" HCOLON Account-URI Account-URI =3D SIP-URI / SIPS-URI / absoluteURI =20 msg-summary-line =3D message-context-class HCOLON newmsgs SLASH = oldmsgs [ LPAREN new-urgentmsgs SLASH old-urgentmsgs RPAREN ] =20 opt-msg-headers =3D CRLF 1*(extension-header CRLF) =20 newmsgs =3D msgcount oldmsgs =3D msgcount new-urgentmsgs =3D msgcount old-urgentmsgs =3D msgcount msgcount =3D 1*DIGIT ; MUST NOT exceed 2^32-1 *********** We receive a Notify message in which we get a list of msg-summary-line's followed by a list of opt- msg-headers each of which contains a messages id to identify the message. If the application wants to retrieve messages based on message-contest-class, How would we identify which message-id corresponds to which message-contest-class? Thanks & Regards Subbu. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 21 11:19:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYKI-0005Fi-LG; Tue, 21 Nov 2006 11:18:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYKH-0005FX-Gk for simple@ietf.org; Tue, 21 Nov 2006 11:18:25 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmYKD-0005jT-3W for simple@ietf.org; Tue, 21 Nov 2006 11:18:25 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7CB321422E1; Tue, 21 Nov 2006 08:18:16 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18997-02; Tue, 21 Nov 2006 08:18:15 -0800 (PST) Received: from [192.168.1.102] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 145AF1422E0; Tue, 21 Nov 2006 08:18:15 -0800 (PST) In-Reply-To: <4562A577.1080602@nokia.com> References: <9B380A4E-C4B0-40E8-8620-470AEC7F43F4@osafoundation.org> <4562A577.1080602@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <967E07C9-DE7D-4587-AEF4-AFF44BB576AB@osafoundation.org> From: Lisa Dusseault Date: Tue, 21 Nov 2006 08:18:13 -0800 To: Jari Urpalainen X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: w3c-dist-auth@w3c.org, simple@ietf.org Subject: [Simple] Re: Belated review of draft-urpalainen-simple-xcap-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: , Content-Type: multipart/mixed; boundary="===============1250242479==" Errors-To: simple-bounces@ietf.org --===============1250242479== Content-Type: multipart/alternative; boundary=Apple-Mail-20--1012383366 --Apple-Mail-20--1012383366 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Sorry, I got confused -- the ability to discover where principal resources can be found is an existing feature in ACL but it isn't done via OPTIONS, it's done via PROPFIND of a property called 'principal-collection-set'. http://rfc.net/rfc3744.html#s5.8. Lisa On Nov 20, 2006, at 11:06 PM, Jari Urpalainen wrote: >> >> - You might want to add that the location for principals can >> be discovered by doing an OPTIONS request and asking for the >> principals namespace. Is there an alternative (XCAP) way of >> discovering the location? >> > XCAP hasn't anything for this (just capability au). Are you > proposing adding some mime type for OPTIONS * ? Certainly it would > help provisioning... --Apple-Mail-20--1012383366 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Sorry, I got confused -- = the ability to discover where principal resources can be found is an = existing feature in ACL but it isn't done via OPTIONS, it's done via = PROPFIND of a property called 'principal-collection-set'.


Lisa

On = Nov 20, 2006, at 11:06 PM, Jari Urpalainen wrote:


=A0 =A0 - You = might want to add that the location for principals can be discovered by = doing an OPTIONS request and asking for the principals namespace.=A0 Is there an alternative = (XCAP) way of discovering the location?


XCAP hasn't anything for this (just capability au). Are you = proposing adding some mime type for OPTIONS * ?=A0 Certainly it would help = provisioning...


= --Apple-Mail-20--1012383366-- --===============1250242479== 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 --===============1250242479==-- From simple-bounces@ietf.org Wed Nov 22 04:50:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmojF-0003Hm-0X; Wed, 22 Nov 2006 04:49:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmojD-0003He-Nj for simple@ietf.org; Wed, 22 Nov 2006 04:49:15 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GmojA-0007HV-GM for simple@ietf.org; Wed, 22 Nov 2006 04:49:15 -0500 X-VirusChecked: Checked X-Env-Sender: rnbk38@motorola.com X-Msg-Ref: server-7.tower-128.messagelabs.com!1164188548!3979104!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9593 invoked from network); 22 Nov 2006 09:42:28 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-128.messagelabs.com with SMTP; 22 Nov 2006 09:42:28 -0000 Received: from il06exb01.corp.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id kAM9gQlH016876 for ; Wed, 22 Nov 2006 02:42:28 -0700 (MST) Received: from zmy16exm61.ds.mot.com (zmy16exm61.ap.mot.com [10.179.4.32]) by il06exb01.corp.mot.com (8.13.1/8.13.0) with ESMTP id kAM9gOUs010429 for ; Wed, 22 Nov 2006 03:42:25 -0600 (CST) 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, 22 Nov 2006 17:42:23 +0800 Message-ID: <272D237EF0638B4CB7F1EA6F5223F6EA015212F0@zmy16exm61.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE:I-D ACTION:draft-ietf-simple-partial-pidf-format-08.txt thread-index: AccNPBMsJWHFfLjMQeWKwXvcU5Q3eAA27EaQ From: "Konka Ravinder-rnbk38" To: X-Spam-Score: 0.5 (/) X-Scan-Signature: a38f40f81e96f7c17c0b6f9de20b7099 Subject: [Simple] RE:I-D ACTION:draft-ietf-simple-partial-pidf-format-08.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 These are my open comments which comes to view when I was going thru the = partial-pidf!!! Just an insight!!!. May be we could handle partial pidf in a different perspective?. 1. We could have a mechanism where the published pidf whether it is = partial or full, pidf needs to be updated/ modified with elements = present in the pidf published recently with keeping other elements in = older pidf intact. 2. This avoids the overhead at network side as well as at terminal/ua = side. 3. And also if 'application/pidf-diff+xml' MIME type is introduced, then = this may lead to problems in real time scenarios,=20 Where user tries to publish pidf-diff, but there was no pidf-full = already exist, or else pidf exist but the specific entities/elements are = doesn't exist in pidf. 4. Best way to publish the content of a presentity is keeping the MIME = type 'application/pidf+xml' intact, and follow the procedure in step 1, = outlined above. =20 -----Original Message----- From: simple-request@ietf.org [mailto:simple-request@ietf.org]=20 Sent: Tuesday, November 21, 2006 12:37 PM To: simple@ietf.org Subject: Simple Digest, Vol 31, Issue 4 Send Simple mailing list submissions to simple@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/simple or, via email, send a message with subject or body 'help' to simple-request@ietf.org You can reach the person managing the list at simple-owner@ietf.org When replying, please edit your Subject line so it is more specific than = "Re: Contents of Simple digest..." Today's Topics: 1. Re: What is the proper winfo status when watcher is politely blocked (Jonathan Rosenberg) 2. Comments on presence-rules-08 (Vrancken, Johnny) 3. I-D ACTION:draft-ietf-simple-partial-pidf-format-08.txt=20 (Internet-Drafts@ietf.org) 4. draft-ietf-simple-presence-rules-08.txt - XCAP naming conventions (Vaclav Kubart) 5. Re: Belated review of draft-urpalainen-simple-xcap-webdav (Jari Urpalainen) ---------------------------------------------------------------------- Message: 1 Date: Wed, 08 Nov 2006 13:14:30 -0500 From: Jonathan Rosenberg Subject: Re: [Simple] What is the proper winfo status when watcher is politely blocked To: Martin.Hynar@tietoenator.com Cc: simple@ietf.org Message-ID: <45521E86.7010909@cisco.com> Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed Its "active". The winfo state machine doesnt reflect the nuances of = document filtering and manipulation, only the state of the presence = subscription. -Jonathan R. Martin.Hynar@tietoenator.com wrote: > Hello all, >=20 > I have encountered an issue with the watcher info. I can't find a clue = in solvin this situation. >=20 > 1. User A sets "polite-block" authorization policy on user B 2. User A = > subscribes own watcher info 3. User B subscribes user's A presence ->=20 > gets polite document 4. User A receives winfo notification - now I=20 > dont know what shall be the proper value for "status" attribute? >=20 > Any help is really appreciated. >=20 >=20 > br, Martin >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 --=20 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 ------------------------------ Message: 2 Date: Mon, 13 Nov 2006 10:38:58 +0100 From: "Vrancken, Johnny" Subject: [Simple] Comments on presence-rules-08 To: "Jonathan Rosenberg" Cc: simple@ietf.org Message-ID: Content-Type: text/plain; charset=3D"iso-8859-1" Dear Jonathan, Here are a few comments / questions on = draft-ietf-simple-presence-rules-08.txt: =A73.2.1 Subscription Handling, page 8 In order to align with the terminology used in RFC 3857 / Figure 1 and = RFC 3858, the following changes are recommended: for block: subscriptions are placed in the "terminated" state = (authorization policy / decision =3D"reject") for polite-block & allow: = subscriptions are placed in the "active" state (authorization policy / = decision =3D"accept") =A73.2.1 Subscription Handling, page 9, last paragraph: "If the sub-handling permission changes value to "polite-block" or = "allow", this causes an "approved" event to be generated into the state = machine for all affected subscriptions. " This is not completely true. If e.g. the sub-handling permission changes = from "allow" to "polite-block", or from "polite-block" to "allow", the = subscription is and remains in the "active" state and no event is = generated. So if the sub-handling permission changes value to "polite-block" or = "allow", the processing depends on the state of the affected = subscriptions. Only if the subscription is in the "pending" state, the = subscription state changes and a NOTIFY is sent. There is no change in = state if the subscription is in the active, waiting or terminated state. =A73.3 Transformations Considering the statements in =A73.3.1 and =A73.3.2, you need both a = fine gained access permission (=A73.3.2) and a corresponding coarse = grained access permission (=A73.3.1)to grant access to presence = attributes. So the most compact form of granting access of all presence attributes = to all watchers is the following rule: allow Question: is it a correct statement that a "false" valued boolean = permission serves no purpose unless combined with a = permission ? I.e. the following rule without a or = statement doesn't grant anything. allow false Question: is the following transformation in a single matching rule = true = semantically equivalent to the following 2 transformations in 2 matching = rules, or are these 2 transformations meaningless ? In Rule 1: = In Rule 2: true =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NITS: Page 8: ... Strictly speaking, it is not necessary to every RULESET TO = include an explicit block action Page 9: ... and the value of = sub-handling that APPLIES to that subscription is "CONFIRM", ... = ("pending" to be replaced by "confirm" ) Page 17: ... that used = VALUED "TRUE" for some attribute, say foo. Page 18: ... will be granted access to THE PRESENCE DATA OF all = services whose contact URI .... Kind regards, Johnny -------------- next part -------------- An HTML attachment was scrubbed... URL: = http://www1.ietf.org/pipermail/simple/attachments/20061113/dc8c49d3/attac= hment-0001.html ------------------------------ Message: 3 Date: Wed, 15 Nov 2006 15:50:01 -0500 From: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-pidf-format-08.txt To: i-d-announce@ietf.org Cc: simple@ietf.org Message-ID: Content-Type: text/plain; charset=3D"us-ascii" 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 Information Data format (PIDF) Extension for Partial = Presence Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-pidf-format-08.txt Pages : 17 Date : 2006-11-15 =09 The Presence Information Document Format (PIDF) specifies the baseline XML based format for describing presence information. One of the characteristic of the PIDF is that the document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist it is often beneficial to limit the amount of transported information over the network. This document introduces a new MIME type which enables transporting of either only the changed parts or the full PIDF based presence information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format= -08.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.=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 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-pidf-format-08.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-pidf-format-08.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. Below is the data which will enable a MIME compliant mail reader = implementation to automatically retrieve the ASCII version of the = Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative ------------------------------ Message: 4 Date: Mon, 20 Nov 2006 17:40:32 +0100 From: Vaclav Kubart Subject: [Simple] draft-ietf-simple-presence-rules-08.txt - XCAP naming conventions To: simple@ietf.org Message-ID: <20061120164032.GB7206@vencore.sip-server.net> Content-Type: text/plain; charset=3Dus-ascii Hi all, I'm trying to implement presence server and I encountered a problem how = to get authorization rules for specific user from XCAP server. In = section 8.7 Naming Conventions is: 'When a presence agent receives a subscription for some user foo within a domain, it will look for all documents within http://[xcap root]/pres-rules/users/foo, and use all documents found beneath that point to guide authorization policy. If only a single document is used, it SHOULD be called "index".' But as far as I know there is no possibility to list documents for a = user in XCAP server... Missed I something? Or should be the file "index" in user's directory = used to union all other user's files? thanks for your advices, Vaclav ------------------------------ Message: 5 Date: Tue, 21 Nov 2006 09:06:31 +0200 From: Jari Urpalainen Subject: [Simple] Re: Belated review of draft-urpalainen-simple-xcap-webdav To: ext Lisa Dusseault Cc: w3c-dist-auth@w3c.org, simple@ietf.org Message-ID: <4562A577.1080602@nokia.com> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Thanks Lisa for your comments, more inline. And sorry for cross-posting = but this might interest both groups. ext Lisa Dusseault wrote: > > Hi Jari, > > I finally got around to reviewing this draft, version -01. The basic=20 > model I completely agree with, it's the easiest one and quite useful. great. > > Some comments: > > - Is it necessary to say that the ETag used with XCAP operations=20 > is the exact same as the one used in WebDAV operations? This allows a = > client to use both XCAP and WebDAV without repeating ETag queries or=20 > worrying about keeping two sets of ETags. This may be obvious already = > since both WebDAV and XCAP only use HTTP ETags. imo, (and being an implementer) yes they must not be separate. And even = implementation on top of Apache is simple (though it does response with = weak ETags, but it is easy to patch it once you do have source code ;-) = ) > > - Section 4.6: I'm not 100% sure that existing software out there=20 > will all work with a WebDAV Principals namespace of the form=20 > "http://principals.example.com/". More typically you see principal=20 > namespaces inside the same domain name as the server that hosts the=20 > content. So you might see "http://example.com/principals" or=20 > "http://example.com/servlet/acl/principals". I do not know if these=20 > forms have any disadvantages over the form you suggest but in ACL=20 > deployment so far they're more likely to be seen. I agree that=20 > principal namespaces on different domains is probably OK, but we might = > want to think for a moment about whether it would be OK for a server=20 > with content at "example.com" could have its principals at a=20 > completely different DNS tree, e.g. "identities.example.ru". ok, I just not wanted to mess up with xcap conventions, i.e. principal = entities would not interfere with an xcap application usage. If = is better inline with current = deployments I'm fine with that as well (virtual hosting is easy imo = and/or reverse proxy configurations do help here anyway). Anyhow, this = is only a recommendation and just to try to help the provisioning = nightmare... And of course this should be (or have been) in rfc3744, = imo, i.e. some conventions, though not being mandatory are typically = useful for implementations. > > - You might want to add that the location for principals can be=20 > discovered by doing an OPTIONS request and asking for the principals=20 > namespace. Is there an alternative (XCAP) way of discovering the=20 > location? > XCAP hasn't anything for this (just capability au). Are you proposing = adding some mime type for OPTIONS * ? Certainly it would help = provisioning... > - In section 4.6, you say "The user "joe" is thus an XCAP user=20 > identity (XUI)". This is descriptive, not normative. Would it be=20 > better to turn this into a normative requirement? E.g. > "A server that implements both WebDAV and XCAP MUST support the=20 > same principal namespace for both WebDAV ACL usage and XCAP user=20 > identities (XUI). That is, every valid WebDAV principal MUST also be=20 > a XUI, and vice versa." right, I agree. > > - You might add a property to a principal, such that an=20 > application that knows "who am I" (it has discovered its principal=20 > identity as currently authenticated) can discover where its XCAP=20 > application "home directories" are. For example, this could be a=20 > multi-valued property valid on a Principal Resource, e.g. > > > =20 > http://example.com/com.example.anAUID/joe/ > = http://example.com/resource-lists/joe/ > > > > Even more generally, this property could identify the user's XCAP=20 > documents of all kinds directly. right, again sounds reasonable to have xcap home directory principal = property, the xcap capability extension lists available AUs. This seems = to add some content to this i-d, btw ;-). > > - You might want to note that XCAP applications can add their own=20 > privileges to the set of base WebDAV privileges. For example, let's=20 > say we had an XCAP application defined for conferencing. Part of the=20 > conference application has conference room setup -- what server it's=20 > on, what bandwidth reserved. But another part of the conference=20 > application is for moderation: who can provide input without=20 > moderation, who is on the "moderate their input" lists, and who is=20 > entirely blocked. For this application, we might want to define a=20 > special XCAP conferencing "moderator" privilege that could do some set = > of functions but not as much as the administrator who can edit the=20 > entire XCAP document. The XCAP server would of course apply the=20 > custom privilege and would allow or disallow PUT and DELETE to XCAP=20 > node selector URLs, based on the privilege and the principal. > > namespace"/> > > > right. rfc3744 is extensible (and the basic model/idea is very = reasonable, imo). > - Section 5, error handling: Since this document says that a=20 > client is not to send WebDAV requests to XML node selector URLs, I=20 > think the best response to seeing such a request would be in the=20 > 400-series -- possibly 403 Forbidden. To make it clear what exactly=20 > is forbidden, you can define an XML error code for return in the error = > body, e.g. > > > > agreed, some deterministic (and documented) responses are definitely = better. > > You can send these comments to a WG or discussion list if you like. > Thanks, > Lisa > Thank you, Jari ------------------------------ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple End of Simple Digest, Vol 31, Issue 4 ************************************* _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 22 08:03:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmrkW-0000j4-CX; Wed, 22 Nov 2006 08:02:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmrkU-0000iy-TH for simple@ietf.org; Wed, 22 Nov 2006 08:02:46 -0500 Received: from mail.genaker.net ([193.145.84.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmrkT-0006en-2B for simple@ietf.org; Wed, 22 Nov 2006 08:02:46 -0500 Received: (qmail 21888 invoked by uid 107); 22 Nov 2006 14:00:52 -0000 Received: from unknown (HELO ?172.16.14.46?) (David.Viamonte@genaker.net@172.16.14.46) by mail.genaker.net with AES256-SHA encrypted SMTP; 22 Nov 2006 14:00:52 -0000 Message-ID: <45644A8D.5040705@genaker.net> Date: Wed, 22 Nov 2006 14:03:09 +0100 From: David Viamonte User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: simple@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Subject: [Simple] Comments on SIMPLE problem statement and TR on scaling Presence wrt Content Indirection 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="===============0684981681==" Errors-To: simple-bounces@ietf.org --===============0684981681== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear SIMPLE experts,

Following up on this topic, I would like to ask if there is any agreed position at the SIMPLE WG wrt application of Content Indirection to SIMPLE Presence publications / notifications (e.g.: RFC 4483).

I have seen there is no reference to this topic in the "Scaling Presence" report (http://mice.cs.columbia.edu/getTechreport.php?techreportID=426).

In http://www.ietf.org/internet-drafts/draft-rang-simple-problem-statement-01.txt a reference is made, although the mechanism is questioned due to a couple of issues (which I comment below). Since this mechanism would seem -at first sight- as a good and simple baseline to reduce Presence traffic, I would like to get some feedback from the experts to understand the technical reasons why this is currently not in scope of the Presence optimizations discussions (maybe it is implicitly considered, or disregarded for some reason I am missing?). Any feedback and light on this will be appreciated ;-)

Now, regarding the reference to Content Indirection in section 7.2 of "draft-rang-simple-problem-statement-01", I would like to make some additional comment, and I will appreciate any feedback about them:

"This optimization may be useful in some cases but in reality it may have several drawbacks:

1. Due to partial/privacy/filtering and other functionalities, it will be relatively a rare case where many watchers will get exactly the same presence document".

I agree that partial/privacy/filtering mechanisms diminish the effectiveness of Content Indirection. However, I do not see the case of several watchers getting the same Presence document as an extremely "rare case". If we consider Privacy, for example, a Presence Source may have 2-4 different privacy profiles for its subscribed watchers, but I do not expect having an extremely tailored Presence document for each and every potential Watcher out there. This is simply by applying common sense: I do not expect users being able to manage their Privacy settings in an extremely complex manner (particularly from wireless devices), so I would expect maybe three different spheres: professional, family, friends... or something like this.

I don't mean that things "will be" like I say in the previous paragraph, but I also don't see why the Problem Statement I-D should assume the opposite case. If I take common Messaging / Presence / VoIP tools on the Internet, I think the common trend is using very simple policies wrt to Privacy ("Show / Hide my Presence to User X"), and this behaviour still provides a lot of value to end users, so I don't see why we should assume that SIMPLE Presence should behave in an extremely more complex manner...

Consider a not-so-conservative case: a Presentity has 25 subscribed Watchers, for which it defines four different spheres (family, friends, work, default). In such case, Content Indirection would help to reduce the amount of PIDF information exchanged across domains by 84% (21/25), as only four docs would be downloaded and reused for the four different types of Watchers (SIP overhead remains the same). This applies to (re-)subscriptions and real notifications.

Observe that Partial / Filtering mechanisms can be managed directly by the RLS (once the PS has already applied Privacy, since the PS is -for the time being- the one that knows the Privacy settings of the Presentity). So once Privacy is applied, a common document can be exchanged across domains for each different Privacy setting, and the RLS may further process the Presence document to deliver tailored versions of it to its Watchers. If we apply content indirection to the RLS - PS path, we would significantly reduce the amount of PIDF/RPID payload exchanged between the RLS and the PS.


"2. There should be a mechanism that will enable removing the content from the content server at the appropriate time. Defining the appropriate time is far from trivial since the removal should be synchronized with all the watcher that need to get the content."

I agree this should be thought a bit deeper. Two comments on this, though:

- Once a NOTIFY with a URL has been sent, the Presence document may not need to be removed until a subsequent Presence update is received. Thus, no need arises to calculate "when" a Presence document should be removed. Simply, when the next Presence update is received, that document will be obsoleted, and a new NOTIFY with a new link (including something like an ETag) will be sent. This gives enough time to any RLS to retrieve the document, and does not pose any additional security threat (pending further analysis), as the same information is available via Content Indirection, as it would be via a regular NOTIFY message.
- I do agree that additional authorization mechanisms may be required to implement this function. This is because if the URL is static across publications of the same Presentity, an RLS (or even a Watcher) could keep trying to retrieve the document even if its subscription has expired or has been cancelled, if the HTTP "leg" is not secured someway (HTTPs?). Thus, I think that some sort of combination of Content Indirection + Authorization is required, to avoid security holes, but I don't see this issue as something un-workable...

Sorry for this long mail. I would appreciate any feedback on this, as I would like to understand whether it is wise or stupid to still consider Content Indirection as a potentially good mechanism to further reduce Presence traffic (e.g.: across domains). Obviously, this would not be in any manner against to other well-known mechanisms being discussed in this list.

Thanks for any feedback. Hope the above comments are useful for some of the currently ongoing discussions.

Kind regards,

David


--===============0684981681== 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 --===============0684981681==-- From hqvdjswiq@tpnet.pl Fri Nov 24 00:57:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnU4L-0005Ln-Cg for simple-archive@lists.ietf.org; Fri, 24 Nov 2006 00:57:49 -0500 Received: from eop156.internetdsl.tpnet.pl ([83.15.227.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnU4J-0003z7-Nv for simple-archive@lists.ietf.org; Fri, 24 Nov 2006 00:57:49 -0500 From: "" To: simple-archive@lists.ietf.org Subject: Traders Daily Report Date: Fri, 24 Nov 2006 06:57:45 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0004_01C70F95.D83ABBA0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccPldg6qn5jgKsyRhq8t+xVFA7j9g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 3.9 (+++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 ------=_NextPart_000_0004_01C70F95.D83ABBA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Market Closed On Thursday Take Advantage Of this Situation!

Company: Bralorne Mining Company
Symbol: BLNM.OB
Price: $0.17
3 Day Target: $0.55

BLNM.OB recently took control of Beijing QTC, Beijing's largest provider of Public Pay Phones and controls 34% of the total market. Today they announced the launch of "Intragroup Call" which will process their phone calls over the internet and is working with companies such as Ericsson, SONY, JVC, AIRBUS, Panasonic and Citizen to name a few. This launch is expected to increase profits by over $1.5 Million dollars annually.

Folks we are primed to jump.

This news is just releasing and it is happening on a holiday. With only Friday left to trade this week, Monday this will explode. Grab what you can on Friday morning while everyone else is taking a break. You can reap the profits on Monday.

Don't Miss Out!

------=_NextPart_000_0004_01C70F95.D83ABBA0-- From simple-bounces@ietf.org Fri Nov 24 13:25:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnfiA-0007PH-48; Fri, 24 Nov 2006 13:23:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnfi7-0007Ip-Rk for simple@ietf.org; Fri, 24 Nov 2006 13:23:39 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gnfi4-0007qK-Gc for simple@ietf.org; Fri, 24 Nov 2006 13:23:39 -0500 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id kAOIh4fb011450; Fri, 24 Nov 2006 12:43:05 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 12:23:19 -0600 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] Re: I-D ACTION:draft-ietf-simple-imdn-01.txt Date: Fri, 24 Nov 2006 13:23:17 -0500 Message-ID: <95D8C1105D54EB41864F8831E6C4EB750233B10A@ecamlmw720.eamcs.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Re: I-D ACTION:draft-ietf-simple-imdn-01.txt Thread-Index: AcbxZ/F7KgfNP0LAQcKqfBbAj/UHrwejFy3Q From: "Nancy Greene \(QA/EMC\)" To: "Hisham Khartabil" , X-OriginalArrivalTime: 24 Nov 2006 18:23:19.0391 (UTC) FILETIME=[9DE6EEF0:01C70FF5] X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 In this text from section 6.4, shouldn't the Original-To header field contain the address of the original IM **Receiver**?: 6.4. Original-To The Original-To header field is sometimes added to an IM by an intermediary and populated with of the address of the IM Sender. It is used by the IM Recipient to indicate in the IMDNs (by populating the element) the original address the IM was sent to. This header is mandatory if the intermediary changes the CPIM To header field value. The header MUST NOT appear more than once in an IM. The header field value MUST NOT be changed by an intermediary if it was already present. The syntax is defined in Section 10. Nancy --------------------- nancy.greene@ericsson.com=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Nov 25 21:22:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Go9dQ-00036H-J7; Sat, 25 Nov 2006 21:20:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Go9dQ-00036C-1b for simple@ietf.org; Sat, 25 Nov 2006 21:20:48 -0500 Received: from outbound.cantata.com ([208.236.123.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Go9dO-00021J-OF for simple@ietf.org; Sat, 25 Nov 2006 21:20:48 -0500 Received: from ma02exchtmp01.Cantata.com ([10.128.18.41]) by outbound.Cantata.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Nov 2006 21:20:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Simple] Re: I-D ACTION:draft-ietf-simple-imdn-01.txt Date: Sat, 25 Nov 2006 21:20:45 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Re: I-D ACTION:draft-ietf-simple-imdn-01.txt Thread-Index: AcbxZ/F7KgfNP0LAQcKqfBbAj/UHrwejFy3QAENLHlg= From: "Burger, Eric" To: "Nancy Greene \(QA/EMC\)" , "Hisham Khartabil" X-OriginalArrivalTime: 26 Nov 2006 02:20:46.0198 (UTC) FILETIME=[7B248960:01C71101] X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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="===============0608513746==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0608513746== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71101.7AA75C7E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71101.7AA75C7E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure, but we say "To:" and not "Receiver:" in the IM, as well. -- Sent from my wireless device. Sorry if terse. Can't wait for lemonade! = What is lemonade? See -----Original Message----- From: Nancy Greene (QA/EMC) [mailto:nancy.greene@ericsson.com] Sent: Friday, November 24, 2006 01:23 PM Eastern Standard Time To: Hisham Khartabil; Burger, Eric Cc: simple@ietf.org Subject: RE: [Simple] Re: I-D ACTION:draft-ietf-simple-imdn-01.txt=20 In this text from section 6.4, shouldn't the Original-To header field contain the address of the original IM **Receiver**?: 6.4. Original-To The Original-To header field is sometimes added to an IM by an intermediary and populated with of the address of the IM Sender. It is used by the IM Recipient to indicate in the IMDNs (by populating the element) the original address the IM was sent to. This header is mandatory if the intermediary changes the CPIM To header field value. The header MUST NOT appear more than once in an IM. The header field value MUST NOT be changed by an intermediary if it was already present. The syntax is defined in Section 10. Nancy --------------------- nancy.greene@ericsson.com=20 ------_=_NextPart_001_01C71101.7AA75C7E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Simple] Re: I-D ACTION:draft-ietf-simple-imdn-01.txt =

Sure, but we say "To:" and not = "Receiver:" in the IM, as well.

--
Sent from my wireless device. Sorry if terse. Can't wait for = lemonade!  What is lemonade? See <http://flyingfox.canta= ta.com/i-d/lemonade>

 -----Original Message-----
From:   Nancy Greene (QA/EMC) [mailto:nancy.greene@ericsson.co= m]
Sent:   Friday, November 24, 2006 01:23 PM Eastern Standard = Time
To:     Hisham Khartabil; Burger, Eric
Cc:     simple@ietf.org
Subject:        RE: [Simple] Re: I-D = ACTION:draft-ietf-simple-imdn-01.txt

In this text from section 6.4, shouldn't the Original-To header = field
contain the address of the original IM **Receiver**?:

6.4.  Original-To

   The Original-To header field is sometimes added to an IM by = an
   intermediary and populated with of the address of the IM = Sender.  It
   is used by the IM Recipient to indicate in the IMDNs (by = populating
   the <original-recipient-uri> element) the original = address the IM was
   sent to.  This header is mandatory if the intermediary = changes the
   CPIM To header field value.  The header MUST NOT = appear more than
   once in an IM.  The header field value MUST NOT be = changed by an
   intermediary if it was already present.  The syntax is = defined in
   Section 10.

Nancy
---------------------
nancy.greene@ericsson.com

------_=_NextPart_001_01C71101.7AA75C7E-- --===============0608513746== 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 --===============0608513746==-- From knunxslgiag@tpnet.pl Sun Nov 26 09:52:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoLMW-0006ss-0m for simple-archive@lists.ietf.org; Sun, 26 Nov 2006 09:52:08 -0500 Received: from cxu58.internetdsl.tpnet.pl ([83.19.154.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoLMT-0000D2-HB for simple-archive@lists.ietf.org; Sun, 26 Nov 2006 09:52:07 -0500 From: "TruceNYPD" To: simple-archive@lists.ietf.org Subject: Stock Trader Alert! Date: Sun, 26 Nov 2006 15:52:05 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0005_01C71172.D20AB710" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccRctIMLzkOe8jyT+yPEOIzwfvsRw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <3C78AB4B9B72E45.C944C6E887@tpnet.pl> X-Spam-Score: 3.8 (+++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d ------=_NextPart_000_0005_01C71172.D20AB710 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
We Told You!!! BLNM Volume UP 4000% and Price Up 47.06%!
Can You feel The Rocket!??

Company: Bralorne Mining Company
Symbol: BLNM.OB
Price: $0.25 (+47.06% in 1 day)
3 Day Target: $0.75

The News Are Out! Read The Latest on BLNM!

BLNM.OB: Beijing QTC Launches Broadband Phone Service to Beijing Tianzh Airport.
The Bralorne Mining Company (BLNM) announced that its wholly holding subsidiary, Beijing Quan Tong Chang Information Services Limited ("Beijing QTC"), has launched "Intragroup Call," a broadband phone service, to Beijing Tianzhu Airport Industrial Zone which offers more than 300 companies and business partners in the zone broadband phone service, targeting $1.5 million annual profit.

They are working with companies such as Ericsson, SONY, JVC, AIRBUS, Panasonic and Citizen.

We knew this was going to take off but we did not expect it till Monday due to the holiday. Well today we saw it climb 47% in price and the volume is up over 4000%. WOW!

We have been told that there will be big news beginning of the week. Monday this will be off the scale. Set your buys for first thing Monday morning. We could see the 3 day projection hit in one day at this rate. Waste no time.

Grab BLNM first thing Monday Morning!!
------=_NextPart_000_0005_01C71172.D20AB710-- From simple-bounces@ietf.org Mon Nov 27 08:56:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogxZ-0000I4-Kb; Mon, 27 Nov 2006 08:55:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogxY-0000Hz-67 for simple@ietf.org; Mon, 27 Nov 2006 08:55:48 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GogxW-0002Zz-Nz for simple@ietf.org; Mon, 27 Nov 2006 08:55:48 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 404BC19451B for ; Mon, 27 Nov 2006 14:55:46 +0100 (CET) Received: from [192.168.1.93] ([192.168.1.93]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 14:55:34 +0100 In-Reply-To: <95D8C1105D54EB41864F8831E6C4EB750233B10A@ecamlmw720.eamcs.ericsson.se> References: <95D8C1105D54EB41864F8831E6C4EB750233B10A@ecamlmw720.eamcs.ericsson.se> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <821799a0a70e048f7ff1f6474d3c2add@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Re: I-D ACTION:draft-ietf-simple-imdn-01.txt Date: Mon, 27 Nov 2006 14:55:16 +0100 To: "Nancy Greene \(QA/EMC\)" X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 27 Nov 2006 13:55:34.0810 (UTC) FILETIME=[B5E7A7A0:01C7122B] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: 'simple@ietf.org'WG, 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 Yes you are right. This has been pointed to me earlier. I just submitted a version of the draft but forgot to make the change. I will make that change after the end of the WGLC, which should be announced shortly after this newly submitted version is announced. Regards, Hisham On Nov 24, 2006, at 7:23 PM, Nancy Greene ((QA/EMC)) wrote: > In this text from section 6.4, shouldn't the Original-To header field > contain the address of the original IM **Receiver**?: > > 6.4. Original-To > > The Original-To header field is sometimes added to an IM by an > intermediary and populated with of the address of the IM Sender. It > is used by the IM Recipient to indicate in the IMDNs (by populating > the element) the original address the IM > was > sent to. This header is mandatory if the intermediary changes the > CPIM To header field value. The header MUST NOT appear more than > once in an IM. The header field value MUST NOT be changed by an > intermediary if it was already present. The syntax is defined in > Section 10. > > Nancy > --------------------- > nancy.greene@ericsson.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Nov 28 05:49:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp0VR-0007A8-0w; Tue, 28 Nov 2006 05:48:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp0VP-000779-KR for simple@ietf.org; Tue, 28 Nov 2006 05:48:03 -0500 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp0VN-0007Rs-3C for simple@ietf.org; Tue, 28 Nov 2006 05:48:03 -0500 Received: from S4DE9JSAAHV.ost.t-com.de (S4DE9JSAAHV.ost.t-com.de [10.125.177.138]) by tcmail21.telekom.de with ESMTP; Tue, 28 Nov 2006 11:47:57 +0100 Received: from S4DE9JSAAMW.ost.t-com.de ([10.125.177.114]) by S4DE9JSAAHV.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 11:47:56 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 28 Nov 2006 11:47:56 +0100 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IM rules Thread-Index: AccS2q3OXQV1itiOTlm/J5pqiQNsWA== From: "Alexeitsev, D" To: X-OriginalArrivalTime: 28 Nov 2006 10:47:56.0787 (UTC) FILETIME=[AA036C30:01C712DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: Gonzalo.Camarillo@ericsson.com Subject: [Simple] IM rules 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="===============0946290202==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0946290202== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C712DA.A9AAA150" This is a multi-part message in MIME format. ------_=_NextPart_001_01C712DA.A9AAA150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All Can anyone comment on the SIMPLE way of policing the IM communication? Different organisations, foras are currently defining their own solutions for the issue, that obviously leads to the interoperability problems. Which one of the listed or not listed options is the SIMPLE IM policing? A) use of the consent framework B) extension of the common policy, as OMA does:=20 xmlns:cme=3D"urn:oma:xml:xdm:commonpol-media-ext"> -> =20 -> accept =20 C) use of CPL to police=20 Greetings, Denis Alexeitsev ------_=_NextPart_001_01C712DA.A9AAA150 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IM rules

Hello All

Can anyone comment on the SIMPLE way of = policing the IM communication?

Different organisations, foras are = currently defining their own solutions for the issue, that obviously = leads to the interoperability problems.

Which one of the listed or not listed = options is the SIMPLE IM policing?

A) use of the consent framework

B) extension of the common policy, as = OMA does:

<?xml version=3D"1.0" = encoding=3D"UTF-8"?>
<ruleset = xmlns=3D"urn:ietf:params:xml:ns:common-policy"
xmlns:poc=3D"urn:oma:xml:poc:poc-rules"
   = xmlns:ocp=3D"urn:oma:xml:xdm:common-policy">
   = xmlns:cme=3D"urn:oma:xml:xdm:commonpol-media-ext">
  <rule = id=3D"m3s47b0">
    = <conditions>
      = <identity>
        <one = id=3D"tel:+1-212-555-1234"/>
        <one = id=3D"sip:alice@example.com"/>
      = </identity>
      = <cme:media>
->     = <cme:message-session/>
->     = <cme:pager-mode-message/>
        = <cme:file-transfer/>
        = <cme:group-advertisement/>
      = </cme:media>
    = </conditions>
    = <actions>
      = <poc:allow-invite>accept</poc:allow-invite>   =   
    = </actions>
  </rule>

C) use of CPL to police

Greetings,
Denis Alexeitsev

------_=_NextPart_001_01C712DA.A9AAA150-- --===============0946290202== 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 --===============0946290202==-- From simple-bounces@ietf.org Tue Nov 28 06:26:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp161-0000w1-MG; Tue, 28 Nov 2006 06:25:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp160-0000vp-GR for simple@ietf.org; Tue, 28 Nov 2006 06:25:52 -0500 Received: from rose.ctd.hcltech.com ([202.54.64.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp15v-0007oV-11 for simple@ietf.org; Tue, 28 Nov 2006 06:25:52 -0500 X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Limited] Content-Class: urn:content-classes:message Received: from Ganesh.ctd.hcltech.com ([202.54.64.2]) by rose.ctd.hcltech.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Nov 2006 16:55:44 +0530 Received: by Ganesh.ctd.hcltech.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Nov 2006 16:55:44 +0530 Message-ID: <012301731C23DE4DBFE035647C68F1CC04789A48@sindhu.ctd.hcltech.com> From: "Jayantheesh Srimushnam - TLS, Chennai" To: "Alexeitsev, D" , Subject: RE: [Simple] IM rules Date: Tue, 28 Nov 2006 16:55:41 +0530 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-OriginalArrivalTime: 28 Nov 2006 11:25:44.0920 (UTC) FILETIME=[F1ED0D80:01C712DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4c463dcf97e2b913ab242796279c24d2 Cc: Gonzalo.Camarillo@ericsson.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0981642383==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0981642383== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C712DF.EFEA038C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C712DF.EFEA038C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="Windows-1252" Hi Denis, =20 "Simple-presence-rules-08.txt" and "geopriv-common-policy-11.txt" = provides basic framework for the simple presence authorization. It would be = better, if we follow some common rules as specified in the standard. Propriety solution definitely leads to interoperability problems. =20 Thanks, Jayantheesh =20 _____ =20 From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net]=20 Sent: Tuesday, November 28, 2006 4:18 PM To: simple@ietf.org Cc: Gonzalo.Camarillo@ericsson.com Subject: [Simple] IM rules =20 Hello All=20 Can anyone comment on the SIMPLE way of policing the IM communication?=20 Different organisations, foras are currently defining their own = solutions for the issue, that obviously leads to the interoperability problems. Which one of the listed or not listed options is the SIMPLE IM policing? = A) use of the consent framework=20 B) extension of the common policy, as OMA does:=20 =20 =20 xmlns:cme=3D"urn:oma:xml:xdm:commonpol-media-ext">=20 =20 =20 =20 =20 =20 =20 =20 -> =20 -> =20 =20 =20 =20 =20 =20 accept =20 =20 =20 C) use of CPL to police=20 Greetings,=20 Denis Alexeitsev=20 DISCLAIMER=20 The contents of this e-mail and any attachment(s) are confidential and = intended for the=20 named recipient(s) only. It shall not attach any liability on the = originator or HCL or its=20 affiliates. Any views or opinions presented in this email are solely = those of the author and=20 may not necessarily reflect the opinions of HCL or its affiliates. Any = form of reproduction,=20 dissemination, copying, disclosure, modification, distribution and / or = publication of this=20 message without the prior written consent of the author of this e-mail = is strictly=20 prohibited. If you have received this email in error please delete it = and notify the sender=20 immediately. Before opening any mail and attachments please check them = for viruses and=20 defect. ------_=_NextPart_001_01C712DF.EFEA038C Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable IM rules

Hi = Denis,

 

“Simple-presence-rules-08.txt= ” and “geopriv-common-policy-11.txt” provides basic framework = for the simple presence authorization. It would be better, if we follow some = common rules as specified in the standard. Propriety solution definitely leads = to interoperability problems.

 

Thanks,

=

Jayantheesh=

 

From: = Alexeitsev, D [mailto:D.Alexeitsev@t-com.net]
Sent: Tuesday, November = 28, 2006 4:18 PM
To: simple@ietf.org
Cc: = Gonzalo.Camarillo@ericsson.com
Subject: [Simple] IM = rules

 

Hello All

Can anyone comment on the SIMPLE way of policing the IM = communication?

Different organisations, foras are currently defining their own solutions for the = issue, that obviously leads to the interoperability = problems.

Which one of the listed or not listed options is the SIMPLE IM = policing?

A) use of the consent framework

B) extension of the common policy, as OMA does: =

<?xml version=3D"1.0" = encoding=3D"UTF-8"?>
<ruleset xmlns=3D"urn:ietf:params:xml:ns:common-policy" =
xmlns:poc=3D"urn:oma:xm= l:poc:poc-rules"
   xmlns:ocp=3D"urn:oma:xml:xdm:common-policy"> =
   xmlns:cme=3D"urn:oma:xml:xdm:commonpol-media-ext">
  <rule id=3D"m3s47b0">
    <conditions>
    &nbs= p; <identity>
    &nbs= p;   <one id=3D"tel:+1-212-555-1234"/>
    &nbs= p;   <one id=3D"sip:alice@example.com"/>
    &nbs= p; </identity>
    &nbs= p; <cme:media>
->    = ; <cme:message-session/>
->    = ; <cme:pager-mode-message/>
    &nbs= p;   <cme:file-transfer/>
    &nbs= p;   <cme:group-advertisement/>
    &nbs= p; </cme:media>
    </conditions>
    <actions>
    &nbs= p; <poc:allow-invite>accept</poc:allow-invite>   =   
    </actions>
  </rule>

C) use of CPL to police

Greetings,
Denis Alexeitsev

------_=_NextPart_001_01C712DF.EFEA038C-- --===============0981642383== 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 --===============0981642383==-- From simple-bounces@ietf.org Tue Nov 28 08:53:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp3NO-0005H7-Gn; Tue, 28 Nov 2006 08:51:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp3NN-0005H1-4F for simple@ietf.org; Tue, 28 Nov 2006 08:51:57 -0500 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp3NL-0007b3-Lo for simple@ietf.org; Tue, 28 Nov 2006 08:51:57 -0500 Received: from [192.168.1.100] (adsl-68-94-29-120.dsl.rcsntx.swbell.net [68.94.29.120]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id kASDpnH8057401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Nov 2006 07:51:50 -0600 (CST) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Ben Campbell Subject: Re: [Simple] IM rules Date: Tue, 28 Nov 2006 07:51:43 -0600 To: "Alexeitsev, D" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 68.94.29.120 is authenticated by a trusted mechanism) X-Spam-Score: 0.1 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: simple@ietf.org, Gonzalo.Camarillo@ericsson.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1720191442==" Errors-To: simple-bounces@ietf.org --===============1720191442== Content-Type: multipart/alternative; boundary=Apple-Mail-1--416373871 --Apple-Mail-1--416373871 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed The SIMPLE wg has not defined any standard rules for policing IM per se. There has been a lot of work on defining rules for presence. The difference is that presence, by it's nature, is assumed to be often delivered by an element in the network, and there must be a way for a presentity to express policy to that element about what presence to deliver to whom. While this may be the case in certain particular networks for IM, it is not assumed to be true in the general sense. On Nov 28, 2006, at 4:47 AM, Alexeitsev, D wrote: > Hello All > > Can anyone comment on the SIMPLE way of policing the IM communication? > > Different organisations, foras are currently defining their own > solutions for the issue, that obviously leads to the > interoperability problems. > > Which one of the listed or not listed options is the SIMPLE IM > policing? > > A) use of the consent framework > > B) extension of the common policy, as OMA does: > > > xmlns:poc="urn:oma:xml:poc:poc-rules" > xmlns:ocp="urn:oma:xml:xdm:common-policy"> > xmlns:cme="urn:oma:xml:xdm:commonpol-media-ext"> > > > > > > > > -> > -> > > > > > > accept > > > > C) use of CPL to police > > Greetings, > Denis Alexeitsev > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple --Apple-Mail-1--416373871 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
The SIMPLE wg has not = defined any standard rules for policing IM per se. There has been a lot = of work on defining rules for presence.

The difference is that = presence, by it's nature, is assumed to be often delivered by an element = in the network, and there must be a way for a presentity to express = policy to that element about what presence to deliver to whom. While = this may be the case in certain particular networks for IM, it is not = assumed to be true in the general sense.

On Nov 28, = 2006, at 4:47 AM, Alexeitsev, D wrote:

Hello All

Can anyone comment on the SIMPLE way of policing the IM = communication?

Different = organisations, foras are currently defining their own solutions for the = issue, that obviously leads to the interoperability = problems.

Which one of the = listed or not listed options is the SIMPLE IM policing? =

A) use of the consent = framework

B) extension of = the common policy, as OMA does:

<?xml version=3D"1.0" encoding=3D"UTF-8"?> =
<ruleset xmlns=3D"urn:ietf:params:xml:ns:common-policy" =
xmlns:poc=3D"urn:oma:xml:poc:poc-rules"
=A0=A0 xmlns:ocp=3D"urn:oma:xml:xdm:common-policy">
=A0=A0 xmlns:cme=3D"urn:oma:xml:xdm:commonpol-media-ext"> =
=A0 <rule id=3D"m3s47b0">=
=A0=A0=A0 <conditions> =
=A0=A0=A0=A0=A0 = <identity>
=A0=A0=A0=A0=A0= =A0=A0 <one id=3D"tel:+1-212-555-1234"/>
=A0=A0=A0=A0=A0=A0=A0 <one id=3D"sip:alice@example.com"/> =
=A0=A0=A0=A0=A0 = </identity>
=A0=A0=A0=A0=A0= <cme:media>
->=A0=A0=A0= =A0 <cme:message-session/>
->=A0=A0=A0=A0 <cme:pager-mode-message/> =
=A0=A0=A0=A0=A0=A0=A0 = <cme:file-transfer/>
=A0=A0=A0=A0=A0=A0=A0 = <cme:group-advertisement/>
=A0=A0=A0=A0=A0 </cme:media>
=A0=A0=A0 </conditions>
=A0=A0=A0 <actions>
=A0=A0=A0=A0=A0 = <poc:allow-invite>accept</poc:allow-invite>=A0=A0=A0=A0=A0 =
=A0=A0=A0 = </actions>
=A0 = </rule>

C) use of = CPL to police

Greetings,
Denis= Alexeitsev

Simple mailing list
=

= --Apple-Mail-1--416373871-- --===============1720191442== 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 --===============1720191442==-- From simple-bounces@ietf.org Tue Nov 28 15:50:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9u6-0007Af-Hr; Tue, 28 Nov 2006 15:50:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9ty-000755-7c; Tue, 28 Nov 2006 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp9tx-00049a-W6; Tue, 28 Nov 2006 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id D74E03289D; Tue, 28 Nov 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gp9tx-0001A0-Gh; Tue, 28 Nov 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 28 Nov 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-imdn-02.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 : Instant Message Disposition Notification Author(s) : E. Burger, H. Khartabil Filename : draft-ietf-simple-imdn-02.txt Pages : 34 Date : 2006-11-28 Instant Messaging (IM) refers to the transfer of messages between users in real-time. This document provides a mechanism whereby endpoints can request Instant Message Disposition Notifications (IMDN), including delivery, processing and read notifications, for page-mode as well as session mode instant messages. The Common Profile for Instant Messaging (CPIM) data format specified in RFC 3862 is extended with new headers that enable endpoints to request IMDNs. A new message format is also defined to convey IMDNs. 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-02.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-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-imdn-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-11-28104833.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-imdn-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-imdn-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-28104833.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 Wed Nov 29 04:45:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpLzp-0008L6-Ku; Wed, 29 Nov 2006 04:44:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpLzo-0008L1-T9 for simple@ietf.org; Wed, 29 Nov 2006 04:44:52 -0500 Received: from smtp3.infineon.com ([203.126.106.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpLzm-0005fw-9b for simple@ietf.org; Wed, 29 Nov 2006 04:44:52 -0500 Received: from unknown (HELO sinse302.ap.infineon.com) ([172.20.70.23]) by smtp3.infineon.com with ESMTP; 29 Nov 2006 17:44:47 +0800 X-SBRS: None Received: from sinse303.ap.infineon.com ([172.20.70.24]) by sinse302.ap.infineon.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 17:44:46 +0800 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: Wed, 29 Nov 2006 17:44:45 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: query regarding Deferred Message Deletion in OMA-TS-IM_SIMPLE-V1_0-20061117-D : section 12.1.3 Thread-Index: AccNX4uR689v8TOyS42u5cGWqG8+7QGOVB0AAACC35A= From: To: X-OriginalArrivalTime: 29 Nov 2006 09:44:46.0936 (UTC) FILETIME=[017FCD80:01C7139B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Simple] query regarding Deferred Message Deletion in OMA-TS-IM_SIMPLE-V1_0-20061117-D : section 12.1.3 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, > Can I get some examples of the sip Message and Sdp Body for the REFER > Message in case of Deleting the deferred messages in the IM Server. >=20 > Can I also have an example of the NOTIFY Message which is received as > part of the same dialog as the previously sent SIP REFER request for > deleting the deferred messages. >=20 > Thanks & Regards > K.V.Subramanyam Gupta >=20 >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Nov 29 08:31:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpPWN-0006ii-97; Wed, 29 Nov 2006 08:30:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpPWM-0006ic-8f for simple@ietf.org; Wed, 29 Nov 2006 08:30:42 -0500 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpPWJ-0002Ql-LH for simple@ietf.org; Wed, 29 Nov 2006 08:30:42 -0500 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id E6CE7194502 for ; Wed, 29 Nov 2006 14:30:30 +0100 (CET) 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, 29 Nov 2006 14:30:20 +0100 Mime-Version: 1.0 (Apple Message framework v624) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-imdn-02.txt Date: Wed, 29 Nov 2006 14:30:01 +0100 To: 'simple@ietf.org' WG X-Mailer: Apple Mail (2.624) X-OriginalArrivalTime: 29 Nov 2006 13:30:20.0073 (UTC) FILETIME=[83E0A190:01C713BA] 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 made the minor update of replacing the MSRP section with text supplied by Miguel discussing why we do not need IMDN for MSRP. I believe this is now ready for WGLC. Thanks, Hisham On Nov 28, 2006, at 9:50 PM, 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-02.txt > Pages : 34 > Date : 2006-11-28 > > Instant Messaging (IM) refers to the transfer of messages between > users in real-time. This document provides a mechanism whereby > endpoints can request Instant Message Disposition Notifications > (IMDN), including delivery, processing and read notifications, for > page-mode as well as session mode instant messages. > > The Common Profile for Instant Messaging (CPIM) data format > specified in RFC 3862 is extended with new headers that enable > endpoints to > request IMDNs. A new message format is also defined to convey > IMDNs. > > 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-02.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-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-simple-imdn-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2006-11-28104833.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