From simple-bounces@ietf.org Mon Apr 02 02:34:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYG7A-0004l8-Dc; Mon, 02 Apr 2007 02:34:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYG78-0004kN-S0; Mon, 02 Apr 2007 02:34:02 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYG71-0002YE-5b; Mon, 02 Apr 2007 02:34:02 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6BB5F213A1; Mon, 2 Apr 2007 08:33:42 +0200 (CEST) X-AuditID: c1b4fb3e-ad1e9bb0000061ca-b3-4610a3c6819d Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4B2562122C; Mon, 2 Apr 2007 08:33:42 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 08:33:41 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 08:33:41 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1915A2358; Mon, 2 Apr 2007 09:33:41 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8AD034DB21; Mon, 2 Apr 2007 09:33:40 +0300 (EEST) Received: from localhost.localdomain (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id ECC804DA97; Mon, 2 Apr 2007 09:33:39 +0300 (EEST) From: Salvatore Loreto To: Paul Kyzivat In-Reply-To: <460D4B96.5000107@cisco.com> References: <460A860E.3010008@unina.it> <460D4B96.5000107@cisco.com> Content-Type: text/plain Date: Mon, 02 Apr 2007 09:33:49 +0300 Message-Id: <1175495629.3453.29.camel@n95.nomadiclab.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 02 Apr 2007 06:33:41.0191 (UTC) FILETIME=[DA9AF570:01C774F0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Lorenzo Miniero , xcon@ietf.org, simple@ietf.org Subject: [Simple] Re: [XCON] Chat and Instant Messaging in XCON 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 am forwarding this mail also to the simple mailing list, because chatting is something in between this two WGs. I was just wondering how should be possible to register a Nick Name not only restrictedly to the duration of a conference/chat, but register it *permanently*, so this nick will be always associated to the same user and only to him. Of course this permanent registration should be limited on a conference server base or instead have a larger validity, for example on a nicknaming services provider base. /sal On Fri, 2007-03-30 at 13:40 -0400, Paul Kyzivat wrote: > > Lorenzo Miniero wrote: > > > 2) Of course, chat and IM mean nicknames... should them be unique in the > > whole conferencing system or in a specific conference instance only? I > > tend to prefer the first option, but since the "key" to identify an user > > will be its XCON userid, this could be not mandatory (even if > > recommended...) and mostly fall in 'social' and security matters. > > Besides, in case we choose to have IM gateway functionality, potential > > conflicts and alignment problems on nicknames could arise which should > > be addressed. > > I think nicknames would best be handled by simply getting an AOR from a > suitable "nickname provider". You could actually register with this > provider, or it could simply retarget requests to some other AOR you > own. If need be you could bundle this with an anonymizer or use a > separate anonymizer as well. > > There could be some advantages to collocating such a provider with a > conference server, but thats just an implementation issue. > > Paul > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon On Wed, 2007-03-28 at 17:13 +0200, Lorenzo Miniero wrote: > Dear all, > > even though this may be premature, considering the current status and > slowness of the ongoing work here in XCON, I'd like to start some seeds > of discussion upon a sentitive matter: chat and instant messaging. > As far as I remember from previous discussions, in fact, it was > specified that this would have fallen in XCON duties and nowhere else. > > > That said, starting from some discussions I had with some people on the > matter and from the issues which arose there, I have some questions I'd > like to know your opinion about. > > > 1) Being XCON a CSP agnostic framework, does this apply to IM protocols > too? i.e., will we envisage a gateway functionality for IM protocols as > we do for CSP? We've only talked about MSRP so far, but I'm thinking to > protocols as IRC, XMPP, etc. as well. > > 2) Of course, chat and IM mean nicknames... should them be unique in the > whole conferencing system or in a specific conference instance only? I > tend to prefer the first option, but since the "key" to identify an user > will be its XCON userid, this could be not mandatory (even if > recommended...) and mostly fall in 'social' and security matters. > Besides, in case we choose to have IM gateway functionality, potential > conflicts and alignment problems on nicknames could arise which should > be addressed. > > 3) Should nicknames appear in the base data model, or in subsequent > extensions? And in both cases, how? Considering the gateway case, a > mapping among nicknames in different IM protocols could naturally come > from there, as happens for CSP URIs. > > 4) Will XCON file transfer functionality fall in IM field (since almost > all such protocols envisage it), or will we address it in other ways? > > > That's all. As I said at the beginning, these questions are intended to > be only seeds for a hopefully soon-to-start wider discussion upon IM in > XCON. I'm looking forward to hear your comments and opinions about these > matters. > > Regards, > Lorenzo > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Apr 02 02:47:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYGJR-0004UF-Jv; Mon, 02 Apr 2007 02:46:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYGJP-0004L9-MA for simple@ietf.org; Mon, 02 Apr 2007 02:46:43 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYGJO-0005lS-5a for simple@ietf.org; Mon, 02 Apr 2007 02:46:43 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l326k5oa021094; Mon, 2 Apr 2007 09:46:31 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 09:46:22 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 09:46:22 +0300 Received: from [172.21.59.40] ([172.21.59.40]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 09:46:22 +0300 Message-ID: <4610A6BD.70002@nsn.com> Date: Mon, 02 Apr 2007 09:46:21 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Matthias Granberry Subject: Re: [Simple] Presence dictionary. Reviewers needed References: <460B5B1A.7040007@nokia.com> <460E0748.8050600@nokia.com> In-Reply-To: <460E0748.8050600@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2007 06:46:22.0212 (UTC) FILETIME=[A0358C40:01C774F2] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Andrew Allen , "Kiss Krisztian \(Nokia-SIR/PaloAlto\)" , Avshalom Houri , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi: I have submitted version -04 of the presence dictionary, which will be soon officially distributed, but you can get a copy in the meantime from: http://people.nokia.net/~miguel/drafts/draft-garcia-simple-presence-dictionary-04.txt Besides the contact information, the only other change is Appendix A, which has been properly updated and is now synchronized with the binary dictionary. This is the version that reviewers should use to perform the review. /Miguel Miguel Garcia wrote: > Ouch, this is an embarrassing oversight. I forgot to update the > Appendix, although the binary dictionary was correctly updated. > > I will create a new version and submitted in the next hours. > > Reviewers, please, hold your review until a new version is out. > > Matthias, thanks for pointing this out. > > /Miguel > > Matthias Granberry wrote: >> There are mismatches between Appendix A and figure 3. The 3-character >> strings haven't been removed from the appendix. >> >> On Mar 29, 2007, at 1:22 AM, Miguel Garcia wrote: >> >>> Hi: >>> >>> A new version of the presence dictionary is available: >>> http://www.ietf.org/internet-drafts/draft-garcia-simple-presence-dictionary-03.txt >>> >>> >>> This version has removed those strings that are 3 characters or less, >>> as per Adam's suggestion. >>> >>> At this time, I am soliciting for reviewers of the document. During >>> the meeting in Prague we got a few volunteers. I remember Adam Roach, >>> Krisztian Kiss, and Andrew Allen volunteered, but there were more >>> volunteers, although I didn't get their names. Please send me a note >>> if you want to review the document. >>> >>> A few guidelines for the reviewers: >>> >>> You should focus on two aspects in the draft: >>> >>> 1) Are all the the RFCs and Internet-Drafts that we can see in >>> presence XML documents included in the dictionary or is there any >>> missing extension? >>> >>> 2) Is the priority value for each string correct? >>> >>> Please send your comments to the list and copy myself too. >>> >>> /Miguel >>> >>> --Miguel A. Garcia tel:+358-50-4804586 >>> Nokia Research Center Helsinki, Finland >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> > -- Please note my new e-mail address: miguel.garcia at nsn.com Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 03 20:42:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYtYL-00006U-QJ; Tue, 03 Apr 2007 20:40:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYtYH-0008Ta-0W; Tue, 03 Apr 2007 20:40:41 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYtYF-0003Yt-N0; Tue, 03 Apr 2007 20:40:40 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id A4F2A32A6B; Wed, 4 Apr 2007 00:40:37 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HYtYD-0003yP-IG; Tue, 03 Apr 2007 20:40:37 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 03 Apr 2007 20:40:37 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: simple chair , Internet Architecture Board , simple mailing list , RFC Editor Subject: [Simple] Protocol Action: 'The Message Session Relay Protocol' to Proposed Standard X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org The IESG has approved the following documents: - 'The Message Session Relay Protocol ' as a Proposed Standard - 'Relay Extensions for the Message Sessions Relay Protocol (MSRP) ' as a Proposed Standard These documents are products of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group. The IESG contact persons are Jon Peterson and Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-19.txt Technical Summary A series of related instant messages between two or more parties can be viewed as part of a "message session", that is, a conversational exchange of messages with a definite beginning and end. This is in contrast to individual messages each sent independently. Messaging schemes that track only individual messages can be described as "page-mode" messaging, whereas messaging that is part of a "session" with a definite start and end is called "session-mode" messaging. This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Working Group Summary This document reflects WG consensus. It defines the Message Session Relay Protocol (MSRP). The working group has been working on this draft for years and have arrived at this after several re-starts. Protocol Quality This document was reviewed for the IESG by Jon Peterson. Hisham Khartabil was the PROTO shepherd for this document. RFC Editor Note On draft-ietf-simple-message-sessions-19.txt: Section 7.2 paragraph 3 OLD The endpoint then inserts an appropriate To-Path header field. If the request triggering the response was a SEND request, the To-Path header field is formed by copying the last (right-most) URI in the From-Path header field of the request. (Responses to SEND requests are returned only to the previous hop.) For responses to all other request methods, the To-Path header field contains the full path back to the original sender. This full path is generated by taking the list of URIs from the From-Path of the original request, reversing the list, and writing the reversed list into the To-Path of the response. (Legal REPORT requests do not request responses, so this specification doesn't exercise the behavior described above, however we expect that extensions for gateways and relays will need such behavior.) NEW The endpoint then inserts an appropriate To-Path header field. If the request triggering the response was a SEND request, the To-Path header field is formed by copying the first (left-most) URI in the From-Path header field of the request. (Responses to SEND requests are returned only to the previous hop.) For responses to all other request methods, the To-Path header field contains the full path back to the original sender. This full path is generated by copying the list of URIs from the From-Path of the original request into the To- Path of the response. (Legal REPORT requests do not request responses, so this specification doesn't exercise the behavior described above, however we expect that extensions for gateways and relays will need such behavior.) Section 7.1.1 paragraph 7 OLD If the value of "Failure-Report" is set to "yes", then the sender of the request runs a timer. If a 200 response to the transaction is not received within 30 seconds from the time the last byte of the transaction is sent, or submitted to the operating system for sending, the element MUST inform the user that the request probably failed. If the value is set to "partial", then the element sending the transaction does not have to run a timer, but MUST inform the user if it receives a non-recoverable error response to the transaction. NEW If the value of "Failure-Report" is set to "yes", then the sender of the request runs a timer. If a 200 response to the transaction is not received within 30 seconds from the time the last byte of the transaction is sent, or submitted to the operating system for sending, the element MUST inform the user that the request probably failed. If the value is set to "partial", then the element sending the transaction does not have to run a timer, but MUST inform the user if it receives a non-recoverable error response to the transaction. There is no requirement to wait for a response prior to sending the next request. Section 7.2 Last Paragraph OLD Finally, the endpoint inserts a From-Path header field containing the URI that identifies it in the context of the session, followed by the end-line after the last header field. The response MUST be transmitted back on the same connection on which the original request arrived. NEW Finally, the endpoint inserts a From-Path header field containing the URI that identifies it in the context of the session, followed by the end-line after the last header field. Since a response is never chunked, the continuation flag in the end-line will always contain a dollar sign ("$"). The response MUST be transmitted back on the same connection on which the original request arrived. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 04 05:40:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ1xA-0001C2-GP; Wed, 04 Apr 2007 05:38:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ1x8-0001Bw-SR for simple@ietf.org; Wed, 04 Apr 2007 05:38:54 -0400 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ1x7-0001UO-2r for simple@ietf.org; Wed, 04 Apr 2007 05:38:54 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id l349cq53072510 for ; Wed, 4 Apr 2007 09:38:52 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.8/8.13.8/NCO v8.3) with ESMTP id l349cqHt3624978 for ; Wed, 4 Apr 2007 11:38:52 +0200 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 l349cp7F023969 for ; Wed, 4 Apr 2007 11:38:51 +0200 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 l349cplZ023966; Wed, 4 Apr 2007 11:38:51 +0200 In-Reply-To: <6981A4FA-59B8-497A-87AB-CF7CCC5C7219@estacado.net> To: Ben Campbell Subject: Re: [Simple] Comments on interdomain scaling analysis MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Wed, 4 Apr 2007 12:38:50 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 04/04/2007 12:38:51, Serialize complete at 04/04/2007 12:38:51 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0718149173==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============0718149173== Content-Type: multipart/alternative; boundary="=_alternative 0034F3D8C22572B3_=" This is a multipart message in MIME format. --=_alternative 0034F3D8C22572B3_= Content-Type: text/plain; charset="US-ASCII" Ben, Thanks a lot for your comments. I encourage others to review the scaling analysis part of the document so we will be able to progress to WGLC as soon as possible. Started to reply to your email last Thu (22nd March) when my computer crashed. It took more a week to recover... --Avshalom Ben Campbell wrote on 22/03/2007 11:42:02: > Hi, > > Here are some comments on draft-ietf-simple-interdomain-scaling- > analysis-00.txt. > > One big concern is this draft claims to be standards track. That > seems incorrect. The only milestone I see in the new charter that > this could fall under is for an informational RFC. > > I have a few nits on the model for the non optimized model, and a > concern about the approach for the optimized models. It is a typo. It should infromational. > > First the approach concern: > > I'm starting to be uncomfortable with the idea of this draft talking > about optimizations at all. We're doing sort of a backwards strawman > here--putting up a potential optimization that has not been thought > through by the work group as a whole, then assigning a value to it > through optimization. This risks sending us down some false trails, > or going down rat-holes arguing about the optimizations in the draft. > it also risks getting us prematurely attached to a particular > optimization, which could later turn out to be technically unfeasible. > > Bottom line is, I think discussion of particular optimizations should > be treated in a separate document than the analysis of the status quo. > > Analysis model for non-optimized SIMPLE: > > I think there are at least 2 errors and two areas that are likely to > be misinterpreted. As we said in the meeting we will separae the current document into 3 docs: - Scaling analysis - WG doc - informational - Requirements doc - Personal - SIPPING - Suggestions doc - Personal - More as a place holder until we will progress with the requirements work. > > Errors: > > 1) I think we have one too many rounds of subscription refreshes in > the 8 hour period. Looking at a timeline, there should be an initial > subscription at t=0, one refresh at each of t=1 through t=7, and one > tear-down at t=8. That's 1 initiation, 1 teardown, and _7_ refreshes, > not 8. Agree. It's like how many cuts you need to cut a bread to get N slices. Will fix. > > 2) The bandwidth calculation multiplies the number of messages times > a size factor that includes an assumed request and response for each. > But we already accounted for responses in the previous calculations > on which this depends. Doing it here again causes a false doubling. > (Not really quite double, since we assume a different size for > responses than requests.) > Will fix. > Areas that should be clarified: > > 1) There are several lines labeled in the form of /200 OK. > That makes me think we are counting transactions. But in fact, we are > counting messages. I think messages are the appropriate choice for > this analysis, so it might make more sense to have a line item for > each request type and a separate line for the associated responses. A > misinterpretation here will make people think the numbers are twice > as bad as they really are. > Yes. I need to work on the way that the calculations are presented to make them clearer. > 2) The population is listed as 20,000. But there is a buried > assumption in the calculation that one domain has 20K people, and the > peer domain also has 20K people, and the interdomain link is carrying > traffic from all 40K people. People are likely to misinterpret this > so that the numbers appear twice as bad as they really are. I suggest > just acknowledging the population is 40K and removing the multiplier. > > Keep in mind that if people fall into _both_ of this traps, they will > misinterpret the numbers by a factor of 4. Will fix. > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple --=_alternative 0034F3D8C22572B3_= Content-Type: text/html; charset="US-ASCII"
Ben,

Thanks a lot for your comments. I encourage others to review
the scaling analysis part of the document so we will be able to
progress to WGLC as soon as possible.

Started to reply to your email last Thu (22nd March) when my
computer crashed. It took more a week to recover...

--Avshalom

Ben Campbell <ben@estacado.net> wrote on 22/03/2007 11:42:02:

> Hi,
>
> Here are some comments on draft-ietf-simple-interdomain-scaling-
> analysis-00.txt.
>
> One big concern is this draft claims to be standards track. That  
> seems incorrect. The only milestone I see in the new charter that  
> this could fall under is for an informational RFC.
>
> I have a few nits on the model for the non optimized model, and a  
> concern about the approach for the optimized models.

It is a typo. It should infromational.

>
> First the approach concern:
>
> I'm starting to be uncomfortable with the idea of this draft talking  
> about optimizations at all. We're doing sort of a backwards strawman  
> here--putting up a potential optimization that has not been thought  
> through by the work group as a whole, then assigning a value to it  
> through optimization. This risks sending us down some false trails,  
> or going down rat-holes arguing about the optimizations in the draft.  
> it also risks getting us prematurely attached to a particular  
> optimization, which could later turn out to be technically unfeasible.
>
> Bottom line is, I think discussion of particular optimizations should  
> be treated in a separate document than the analysis of the status quo.
>
> Analysis model for non-optimized SIMPLE:
>
> I think there are at least 2 errors and two areas that are likely to  
> be misinterpreted.

As we said in the meeting we will separae the current document into
3 docs:
- Scaling analysis - WG doc - informational
- Requirements doc - Personal - SIPPING
- Suggestions doc - Personal - More as a place holder until we will
progress with the requirements work.
 
>
> Errors:
>
> 1) I think we have one too many rounds of subscription refreshes in  
> the 8 hour period.  Looking at a timeline, there should be an initial  
> subscription at t=0, one refresh at each of t=1 through t=7, and one  
> tear-down at t=8. That's 1 initiation, 1 teardown, and _7_ refreshes,  
> not 8.

Agree. It's like how many cuts you need to cut a bread to get N slices.
Will fix.

>
> 2) The bandwidth calculation multiplies the number of messages times  
> a size factor that includes an assumed request and response for each.  
> But we already accounted for responses in the previous calculations  
> on which this depends. Doing it here again causes a false doubling.  
> (Not really quite double, since we assume a different size for  
> responses than requests.)
>
Will fix.

> Areas that should be clarified:
>
> 1) There are several lines labeled in the form of  <Method>/200 OK.  
> That makes me think we are counting transactions. But in fact, we are  
> counting messages. I think messages are the appropriate choice for  
> this analysis, so it might make more sense to have a line item for  
> each request type and a separate line for the associated responses. A  
> misinterpretation here will make people think the numbers are twice  
> as bad as they really are.
>
Yes. I need to work on the way that the calculations are presented to make
them clearer.

> 2) The population is listed as 20,000. But there is a buried  
> assumption in the calculation that one domain has 20K people, and the  
> peer domain also has 20K people, and the interdomain link is carrying  
> traffic from all 40K people. People are likely to misinterpret this  
> so that the numbers appear twice as bad as they really are. I suggest  
> just acknowledging the population is 40K and removing the multiplier.
>
> Keep in mind that if people fall into _both_ of this traps, they will  
> misinterpret the numbers by a factor of 4.
Will fix.
>
>
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
 --=_alternative 0034F3D8C22572B3_=-- --===============0718149173== 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 --===============0718149173==-- From simple-bounces@ietf.org Wed Apr 04 07:10:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ3NA-0000u6-Dl; Wed, 04 Apr 2007 07:09:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ3N8-0000u1-AB for simple@ietf.org; Wed, 04 Apr 2007 07:09:50 -0400 Received: from mail.genaker.net ([193.145.84.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ3N6-0003Wh-6w for simple@ietf.org; Wed, 04 Apr 2007 07:09:50 -0400 Received: (qmail 28836 invoked by uid 107); 4 Apr 2007 11:53:29 -0000 Received: from 203.pool85-52-255.static.orange.es (HELO ?10.1.1.11?) (David.Viamonte@genaker.net@85.52.255.203) by mail.genaker.net with AES256-SHA encrypted SMTP; 4 Apr 2007 11:53:29 -0000 Message-ID: <4613878F.3090608@genaker.net> Date: Wed, 04 Apr 2007 13:10:07 +0200 From: David Viamonte User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Avshalom Houri , Simple WG Subject: Re: [Simple] Comments on interdomain scaling analysis References: In-Reply-To: X-Spam-Score: 1.2 (+) X-Scan-Signature: abb8110dde048486ea2be9c769692569 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: , Content-Type: multipart/mixed; boundary="===============0113419367==" Errors-To: simple-bounces@ietf.org --===============0113419367== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

Following your encourage to review, I provide some feedback I've gathered in the last weeks. It is in line with previous comments posted in the past, so will appreciate if you can share your point of view on them. 

Extracted from section 7.2 in the I-D:

o Content Indirection [7] enables sending only the URI of the presence document to the watcher thus offloading the presence server from sending the presence document to the watcher. 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.

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.

Two comments on the above statement: 

1. "Partial / privacy / filtering"

Privacy policies are -in the current model- handled by the PS. So I agree that due to privacy reasons different Presence docs may be shared between the PS and the RLS through the interdomain link.

However, partial and filtering mechanisms could be fully handled in the "watcher domain" (e.g.: section 4.5 of RFC 4662), so this does not justify the creation of new Presence documents between the PS and the RLS (documents can be created in the "watcher domain" and delivered differently to each Watcher; thus it does not constitute an "interdomain" issue).

Now, if we consider only Privacy filtering and think about "common sense" implementations, let us consider a Presentity that has W subscribed Watchers. In such case, it seems reasonable that, through Privacy, the Presentity may have P "privacy profiles". For large W, it seems unrealistic to think that the Presentity will have exactly P=W "privacy profiles" (NOTE). If you agree with this comment, then the actual Presence document may only need to be sent (approximately) W/P times, instead of W times. The rest of times (up to W) the RLS can reuse the information already downloaded from the content server. For example, for W=25 subscribed watchers, and P=5 profiles, the Presence document needs to be uploaded 5 times to the content server, but then the remaining 20 times the RLS can reuse the cached document directly, without having to download it again. Observe that the W/P optimization applies to each and every NOTIFY message sent by the PS, so it may end-up representing a meaningful improvement.

(NOTE) Having a tailor-made Presence privacy setting for each Watcher would be too complex, technically challenging and unpractical for the Presentity, as W grows.

2. Regarding the mechanism to remove the content, I don't really see any big issue not already covered by the Content Indirection RFC and the existing Subscribe/Notify framework. Observe that content is kept in synch via NOTIFY and Etag values, so RLS's can be certain that information is up-to-date, regardless of having received it directly or via Indirection. 

I don't want to complicate things further and include more calculations in the draft. However, I think the current way Content Indirection is presented is too pessimistic. I reckon it does not reduce the number of dialogs, but it is fair to acknowledge it can reduce the amount of info exchanged in the interdomain link, and it can be quite interesting in some cases. Further, the currently stated drawbacks, IMMO are not fully justified, as I explain above.

Regarding some proposed "potential new optimizations", a very brief comment, since I understand these will probably go into another RFC and the current one be dedicated only to analysis of the current situation (please, correct if this assumption is not valid):

- The "many-to-many" subscription list concept outlined in the doc (section 7.2) seems to be an interesting idea, with a lot of technical challenges to be thought of. So fully agree with evaluating it separately. 

- The "consolidated subscription" concept may imply sharing of privacy documents between the PS and the RLS. This idea poses new challenges in terms of: a) is the full privacy document shared accorss domains or: b) only the sections relevant for a given domain?

If a) applies this seems to be an important privacy issue.

If b) applies (i.e.: only the privacy settings relevant for an RLS according to the users it serves), then:

b.1) a mechanism to construct "partial" privacy documents should be developed (probably this is trivial but should be described somewhere?)
b.2) how to manage "black-lists" thatcontain TEL URL addresses? Should the PS ENUM all TEL URL's to determine the SIPv domain they belong to, in order to share the document? This might represent a new architectural issue.
b.3) a mechanism to keep the distributed document in synch across all trusted domains must be designed.
b.4) I am not sure if policies and existing regulation would easily allow worldwide sharing –even between trusted domains– of a "privacy" document that "belongs" to a served user, and is directly managed by the user (via XCAP). This is already outlined in section 7.2.

Conclusion (just joining what other list members have indicated): moving away from the RLS-PS challenges, will probably lead into having to carefully design this mechanism, which –after careful analysis– may pose additional technical challenges that have not been though of yet. Hence, it may be too optimistic to calculate any numbers assuming that some proposed estimations will effectively be implemented, since new challenges may arise when carefully designing those optimizations.

Hope this helps. Please let me know your opinions about these comments. 

Kind Regards,

David



Avshalom Houri escribió:

Ben,

Thanks a lot for your comments. I encourage others to review
the scaling analysis part of the document so we will be able to
progress to WGLC as soon as possible.

Started to reply to your email last Thu (22nd March) when my
computer crashed. It took more a week to recover...

--Avshalom

Ben Campbell <ben@estacado.net> wrote on 22/03/2007 11:42:02:

> Hi,
>
> Here are some comments on draft-ietf-simple-interdomain-scaling-
> analysis-00.txt.
>
> One big concern is this draft claims to be standards track. That  
> seems incorrect. The only milestone I see in the new charter that  
> this could fall under is for an informational RFC.
>
> I have a few nits on the model for the non optimized model, and a  
> concern about the approach for the optimized models.

It is a typo. It should infromational.

>
> First the approach concern:
>
> I'm starting to be uncomfortable with the idea of this draft talking  
> about optimizations at all. We're doing sort of a backwards strawman  
> here--putting up a potential optimization that has not been thought  
> through by the work group as a whole, then assigning a value to it  
> through optimization. This risks sending us down some false trails,  
> or going down rat-holes arguing about the optimizations in the draft.  
> it also risks getting us prematurely attached to a particular  
> optimization, which could later turn out to be technically unfeasible.
>
> Bottom line is, I think discussion of particular optimizations should  
> be treated in a separate document than the analysis of the status quo.
>
> Analysis model for non-optimized SIMPLE:
>
> I think there are at least 2 errors and two areas that are likely to  
> be misinterpreted.

As we said in the meeting we will separae the current document into
3 docs:
- Scaling analysis - WG doc - informational
- Requirements doc - Personal - SIPPING
- Suggestions doc - Personal - More as a place holder until we will
progress with the requirements work.
 
>
> Errors:
>
> 1) I think we have one too many rounds of subscription refreshes in  
> the 8 hour period.  Looking at a timeline, there should be an initial  
> subscription at t=0, one refresh at each of t=1 through t=7, and one  
> tear-down at t=8. That's 1 initiation, 1 teardown, and _7_ refreshes,  
> not 8.

Agree. It's like how many cuts you need to cut a bread to get N slices.
Will fix.

>
> 2) The bandwidth calculation multiplies the number of messages times  
> a size factor that includes an assumed request and response for each.  
> But we already accounted for responses in the previous calculations  
> on which this depends. Doing it here again causes a false doubling.  
> (Not really quite double, since we assume a different size for  
> responses than requests.)
>
Will fix.

> Areas that should be clarified:
>
> 1) There are several lines labeled in the form of  <Method>/200 OK.  
> That makes me think we are counting transactions. But in fact, we are  
> counting messages. I think messages are the appropriate choice for  
> this analysis, so it might make more sense to have a line item for  
> each request type and a separate line for the associated responses. A  
> misinterpretation here will make people think the numbers are twice  
> as bad as they really are.
>
Yes. I need to work on the way that the calculations are presented to make
them clearer.

> 2) The population is listed as 20,000. But there is a buried  
> assumption in the calculation that one domain has 20K people, and the  
> peer domain also has 20K people, and the interdomain link is carrying  
> traffic from all 40K people. People are likely to misinterpret this  
> so that the numbers appear twice as bad as they really are. I suggest  
> just acknowledging the population is 40K and removing the multiplier.
>
> Keep in mind that if people fall into _both_ of this traps, they will  
> misinterpret the numbers by a factor of 4.
Will fix.
>
>
>
> _______________________________________________
> 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
--===============0113419367== 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 --===============0113419367==-- From simple-bounces@ietf.org Wed Apr 04 10:57:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6uB-0007au-9E; Wed, 04 Apr 2007 10:56:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6uA-0007aa-95; Wed, 04 Apr 2007 10:56:10 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZ6u8-000839-QX; Wed, 04 Apr 2007 10:56:10 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZ6tn-0000n2-8a; Wed, 04 Apr 2007 09:55:48 -0500 From: "Brian Rosen" To: "'Salvatore Loreto'" , "'Paul Kyzivat'" Date: Wed, 4 Apr 2007 10:56:00 -0400 Message-ID: <1e1c01c776c9$5eaba600$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <1175495629.3453.29.camel@n95.nomadiclab.com> Thread-Index: Acd08GUSq/BKui4vS/eTUJqu0B5n5gB2C85w X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: xcon@ietf.org, simple@ietf.org Subject: [Simple] RE: [XCON] Chat and Instant Messaging in XCON 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 Please see: http://tools.ietf.org/html/draft-niemi-simple-chat-06 There was some discussion of nicknames in the past. There is some discussion happening with the authors of this work on that subject now. Brian > -----Original Message----- > From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] > Sent: Monday, April 02, 2007 2:34 AM > To: Paul Kyzivat > Cc: xcon@ietf.org; simple@ietf.org > Subject: Re: [XCON] Chat and Instant Messaging in XCON > > Hi all, > > I am forwarding this mail also to the simple mailing list, because > chatting is something in between this two WGs. > > I was just wondering how should be possible to register a Nick Name not > only restrictedly to the duration of a conference/chat, but register it > *permanently*, so this nick will be always associated to the same user > and only to him. > > Of course this permanent registration should be limited on a conference > server base or instead have a larger validity, for example on a > nicknaming services provider base. > > > /sal > > > On Fri, 2007-03-30 at 13:40 -0400, Paul Kyzivat wrote: > > > > Lorenzo Miniero wrote: > > > > > 2) Of course, chat and IM mean nicknames... should them be unique in > the > > > whole conferencing system or in a specific conference instance only? I > > > tend to prefer the first option, but since the "key" to identify an > user > > > will be its XCON userid, this could be not mandatory (even if > > > recommended...) and mostly fall in 'social' and security matters. > > > Besides, in case we choose to have IM gateway functionality, potential > > > conflicts and alignment problems on nicknames could arise which should > > > be addressed. > > > > I think nicknames would best be handled by simply getting an AOR from a > > suitable "nickname provider". You could actually register with this > > provider, or it could simply retarget requests to some other AOR you > > own. If need be you could bundle this with an anonymizer or use a > > separate anonymizer as well. > > > > There could be some advantages to collocating such a provider with a > > conference server, but thats just an implementation issue. > > > > Paul > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > On Wed, 2007-03-28 at 17:13 +0200, Lorenzo Miniero wrote: > > Dear all, > > > > even though this may be premature, considering the current status and > > slowness of the ongoing work here in XCON, I'd like to start some seeds > > of discussion upon a sentitive matter: chat and instant messaging. > > As far as I remember from previous discussions, in fact, it was > > specified that this would have fallen in XCON duties and nowhere else. > > > > > > That said, starting from some discussions I had with some people on the > > matter and from the issues which arose there, I have some questions I'd > > like to know your opinion about. > > > > > > 1) Being XCON a CSP agnostic framework, does this apply to IM protocols > > too? i.e., will we envisage a gateway functionality for IM protocols as > > we do for CSP? We've only talked about MSRP so far, but I'm thinking to > > protocols as IRC, XMPP, etc. as well. > > > > 2) Of course, chat and IM mean nicknames... should them be unique in the > > whole conferencing system or in a specific conference instance only? I > > tend to prefer the first option, but since the "key" to identify an user > > will be its XCON userid, this could be not mandatory (even if > > recommended...) and mostly fall in 'social' and security matters. > > Besides, in case we choose to have IM gateway functionality, potential > > conflicts and alignment problems on nicknames could arise which should > > be addressed. > > > > 3) Should nicknames appear in the base data model, or in subsequent > > extensions? And in both cases, how? Considering the gateway case, a > > mapping among nicknames in different IM protocols could naturally come > > from there, as happens for CSP URIs. > > > > 4) Will XCON file transfer functionality fall in IM field (since almost > > all such protocols envisage it), or will we address it in other ways? > > > > > > That's all. As I said at the beginning, these questions are intended to > > be only seeds for a hopefully soon-to-start wider discussion upon IM in > > XCON. I'm looking forward to hear your comments and opinions about these > > matters. > > > > Regards, > > Lorenzo > > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 04 23:53:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZJ0j-0006xD-I4; Wed, 04 Apr 2007 23:51:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZJ0i-0006x8-5t for simple@ietf.org; Wed, 04 Apr 2007 23:51:44 -0400 Received: from smtp3.infineon.com ([203.126.106.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZJ0e-0008N5-Kr for simple@ietf.org; Wed, 04 Apr 2007 23:51:44 -0400 Received: from unknown (HELO sinse301.ap.infineon.com) ([172.20.70.22]) by smtp3.infineon.com with ESMTP; 05 Apr 2007 11:51:38 +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); Thu, 5 Apr 2007 11:51:38 +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: Thu, 5 Apr 2007 11:51:37 +0800 Message-ID: <27BE9204A2EE7F4F9CDF0186B64AE26EB01821@sinse303.ap.infineon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Content type header for binary files Thread-Index: Acd3NbXHLhjZbXBbQYeDSqXBnYuEaQ== X-Priority: 1 Priority: Urgent Importance: high From: To: X-OriginalArrivalTime: 05 Apr 2007 03:51:38.0354 (UTC) FILETIME=[B6950520:01C77735] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [Simple] Content type header for binary files 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, Can someone please clarify what should be the default Content-Type header value for transferring binary payloads in MSRP SEND request?=20 Thanks in advance, Reshma _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 05 00:41:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZJmQ-0002p5-PL; Thu, 05 Apr 2007 00:41:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZJmO-0002mR-FN for simple@ietf.org; Thu, 05 Apr 2007 00:41:00 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZJmN-00034b-5x for simple@ietf.org; Thu, 05 Apr 2007 00:41:00 -0400 Received: from [10.0.1.2] (adsl-68-94-33-134.dsl.rcsntx.swbell.net [68.94.33.134]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l354evem093650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Apr 2007 23:40:58 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <27BE9204A2EE7F4F9CDF0186B64AE26EB01821@sinse303.ap.infineon.com> References: <27BE9204A2EE7F4F9CDF0186B64AE26EB01821@sinse303.ap.infineon.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 1 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8558B9ED-7D86-4086-9818-284F57211263@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Content type header for binary files Date: Wed, 4 Apr 2007 23:40:57 -0500 To: "" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 68.94.33.134 is authenticated by a trusted mechanism) X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 There is not a default content-type header value. If the request contains content, the Content-Type header must be present and must indicate the MIME media type for the content. Hope this helps! Ben. On Apr 4, 2007, at 10:51 PM, wrote: > Hi All, > > Can someone please clarify what should be the default Content-Type > header value for transferring binary payloads in MSRP SEND request? > > Thanks in advance, > Reshma > > _______________________________________________ > 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 Apr 05 01:20:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZKNh-0007yI-3J; Thu, 05 Apr 2007 01:19:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZKNe-0007wc-VC for simple@ietf.org; Thu, 05 Apr 2007 01:19:30 -0400 Received: from smtp3.infineon.com ([203.126.106.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZKNc-0006HR-4P for simple@ietf.org; Thu, 05 Apr 2007 01:19:30 -0400 Received: from unknown (HELO sinse301.ap.infineon.com) ([172.20.70.22]) by smtp3.infineon.com with ESMTP; 05 Apr 2007 13:19:25 +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); Thu, 5 Apr 2007 13:19:25 +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 Subject: RE: [Simple] Content type header for binary files Date: Thu, 5 Apr 2007 13:19:24 +0800 Message-ID: <27BE9204A2EE7F4F9CDF0186B64AE26EB018BE@sinse303.ap.infineon.com> In-Reply-To: <8558B9ED-7D86-4086-9818-284F57211263@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Content type header for binary files Thread-Index: Acd3PKZ1nnyyvrD2Sky8pd1KzQCd3wABFlIQ From: To: X-OriginalArrivalTime: 05 Apr 2007 05:19:25.0957 (UTC) FILETIME=[FA517350:01C77741] X-Spam-Score: 0.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Hi Ben, Thanks for the reply.=20 I have one more query. If we want to support all file types dynamically, and say want to send a file for which the MIME media type is not known, what is the default Content-Type header value that needs to go. Can we make use of=20 "application/octet-stream" as the MIME media type for such binary files. Best Regards, Reshma -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Thursday, April 05, 2007 10:11 AM To: Prabhakar Reshma (IFIN SW WS IMS) Cc: simple@ietf.org Subject: Re: [Simple] Content type header for binary files Importance: High There is not a default content-type header value. If the request contains content, the Content-Type header must be present and must indicate the MIME media type for the content. Hope this helps! Ben. On Apr 4, 2007, at 10:51 PM, wrote: > Hi All, > > Can someone please clarify what should be the default Content-Type=20 > header value for transferring binary payloads in MSRP SEND request? > > Thanks in advance, > Reshma > > _______________________________________________ > 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 Apr 05 01:50:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZKrD-0005nd-Qo; Thu, 05 Apr 2007 01:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZKrA-0005hh-W1 for simple@ietf.org; Thu, 05 Apr 2007 01:50:01 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZKr9-0004q8-8X for simple@ietf.org; Thu, 05 Apr 2007 01:50:00 -0400 Received: from [10.0.1.2] (adsl-68-94-33-134.dsl.rcsntx.swbell.net [68.94.33.134]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l355nw4G096517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Apr 2007 00:49:58 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <27BE9204A2EE7F4F9CDF0186B64AE26EB018BE@sinse303.ap.infineon.com> References: <27BE9204A2EE7F4F9CDF0186B64AE26EB018BE@sinse303.ap.infineon.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2F200742-18B5-46F1-ABE7-1019EB29536A@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] Content type header for binary files Date: Thu, 5 Apr 2007 00:49:57 -0500 To: "" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 68.94.33.134 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Apr 5, 2007, at 12:19 AM, wrote: > Hi Ben, > > Thanks for the reply. > > I have one more query. If we want to support all file types > dynamically, > and say want to send a file for which the MIME media type is not > known, > what is the default Content-Type header value that needs to go. Can we > make use of > "application/octet-stream" as the MIME media type for such binary > files. > I don't see why not, as it's a valid type for when you don't know anything except that it's binary data. I would avoid that unless all attempts at inferring more about the content have been exhausted, though. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Apr 09 15:24:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HazSt-0005hH-4t; Mon, 09 Apr 2007 15:23:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HazSs-0005h9-F6 for simple@ietf.org; Mon, 09 Apr 2007 15:23:46 -0400 Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk225.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HazSq-0007lD-34 for simple@ietf.org; Mon, 09 Apr 2007 15:23:46 -0400 Received: from wrk225.corp.jabber.com (localhost [127.0.0.1]) by wrk225.corp.jabber.com (Postfix) with ESMTP id 6899D60D04B for ; Mon, 9 Apr 2007 13:24:15 -0600 (MDT) Message-ID: <461A92DE.8020206@jabber.org> Date: Mon, 09 Apr 2007 13:24:14 -0600 From: Peter Saint-Andre Organization: XMPP Standards Foundation User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2pre) Gecko/20070116 Thunderbird/2.0b2 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: simple@ietf.org Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Subject: [Simple] "last call" #2 on SIMPLE-XMPP interworking I-D X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1239431968==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1239431968== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070105030205050609040703" This is a cryptographically signed message in MIME format. --------------ms070105030205050609040703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Last June I asked for an informal "last call" on an informational I-D that specifies interworking between SIMPLE and XMPP for basic messaging and presence: http://www1.ietf.org/mail-archive/web/simple/current/msg06569.html Since then the authors have received feedback from a number of people, which as far as I know has been fully incorporated. Therefore it seems appropriate to request a second "last call" regarding this I-D: http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-simple-09.txt http://www.xmpp.org/internet-drafts/draft-saintandre-xmpp-simple-09.html Once again, please note that this I-D seeks to define only basic messaging and presence interoperability between SIMPLE and XMPP. Use cases such as chat and multi-party messaging (e.g. between MSRP and XMPP messages of type 'chat' or'groupchat') and rich or extended presence are not covered by this specification. However, it is the intent of the authors to address more advanced interworking in future specifications. Please send feedback to the SIMPLE list or to the authors directly. Thanks! Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml --------------ms070105030205050609040703 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA3MDQwOTE5MjQxNFowIwYJKoZIhvcNAQkEMRYEFPndltQ8t80qzqyyvrOUMsW47xT6MFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBAB3omgNxUk613sb7OzhQBQuKEdkzU3jGa2yBppA20nh+ tskVGXM4CB38UuDkqLDSD0ijAaWf60K+b05b/gHz9BySKJcSVO5lzUzI5B9WX/AN9wlenkFj pnh9uvWST+zxUzCq6rCw46omrOPKMCKv13xzR1rAZ2ttbCP7nDI5O6FtlbCrcjh0Ik0YUUig YxeHgmKzI7GhiIPTczZnEIQ22GZSrjmgQ+qDBVy8o/4osbWo7CwXZejecRoMMC1fkuKK7lTw Rzra/8QtS1fYitSeh/+g5aUjXEOnhcYn03ZeN/1nsVWpIazfkZ8y4GsosgW6zuI/LpsFx/uQ H9vJJVWEx1cAAAAAAAA= --------------ms070105030205050609040703-- --===============1239431968== 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 --===============1239431968==-- From simple-bounces@ietf.org Mon Apr 09 17:06:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb149-0007OJ-OZ; Mon, 09 Apr 2007 17:06:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb148-0007OE-Qr for simple@ietf.org; Mon, 09 Apr 2007 17:06:20 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb146-00081M-FG for simple@ietf.org; Mon, 09 Apr 2007 17:06:20 -0400 Received: from [172.17.2.61] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l39L6Hir012381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Apr 2007 16:06:17 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <461AAAC9.6050907@nostrum.com> Date: Mon, 09 Apr 2007 16:06:17 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Peter Saint-Andre Subject: Re: [Simple] "last call" #2 on SIMPLE-XMPP interworking I-D References: <461A92DE.8020206@jabber.org> In-Reply-To: <461A92DE.8020206@jabber.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Peter: This version addresses all security-related concerns that I have previously raised. Thanks. /a Peter Saint-Andre wrote: > Last June I asked for an informal "last call" on an informational I-D > that specifies interworking between SIMPLE and XMPP for basic > messaging and presence: > > http://www1.ietf.org/mail-archive/web/simple/current/msg06569.html > > Since then the authors have received feedback from a number of people, > which as far as I know has been fully incorporated. Therefore it seems > appropriate to request a second "last call" regarding this I-D: > > http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-simple-09.txt > > http://www.xmpp.org/internet-drafts/draft-saintandre-xmpp-simple-09.html > > Once again, please note that this I-D seeks to define only basic > messaging and presence interoperability between SIMPLE and XMPP. Use > cases such as chat and multi-party messaging (e.g. between MSRP and > XMPP messages of type 'chat' or'groupchat') and rich or extended > presence are not covered by this specification. However, it is the > intent of the authors to address more advanced interworking in future > specifications. > > Please send feedback to the SIMPLE list or to the authors directly. > > Thanks! > > Peter > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 11 06:10:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbZls-0000W1-GA; Wed, 11 Apr 2007 06:09:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbZlr-0000Vv-EC for simple@ietf.org; Wed, 11 Apr 2007 06:09:47 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbZlY-0005KK-RW for simple@ietf.org; Wed, 11 Apr 2007 06:09:47 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGB00AYQW6NT6@szxga03-in.huawei.com> for simple@ietf.org; Wed, 11 Apr 2007 18:08:47 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGB009T0W6NZL@szxga03-in.huawei.com> for simple@ietf.org; Wed, 11 Apr 2007 18:08:47 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGB000XJW6IG2@szxml04-in.huawei.com> for simple@ietf.org; Wed, 11 Apr 2007 18:08:47 +0800 (CST) Date: Wed, 11 Apr 2007 18:08:42 +0800 From: Qian Sun To: simple@ietf.org Message-id: <000801c77c21$626d1730$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Thread-index: Acd8IWIenjURYprBQoi5xxyu+vH46Q== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Simple] Appear Offline 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, "Appear Offline" is very popular in current IM software. People = sometimes want to hide themselves, i.e. appear =E2=80=9Coffline=E2=80=9D = when they are actually =E2=80=9Conline=E2=80=9D, at the same time they = can get their buddies=E2=80=99 presence information. Can anybody tell me how to realize this feature in SIMPLE way? Thanks in advance, Qian Sun Research & Standardization Dept. Huawei Technologies Co., Ltd. =20 E-mail:sunqian@huawei.com Tel:+86-755-28979550 Fax:+86-755-28975471 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 11 09:01:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbcQy-0003t0-6b; Wed, 11 Apr 2007 09:00:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbcQx-0003so-1F for simple@ietf.org; Wed, 11 Apr 2007 09:00:23 -0400 Received: from gurgaon.orgltd.com ([61.247.231.160] helo=mail.orgltd.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbcQu-0005ho-CB for simple@ietf.org; Wed, 11 Apr 2007 09:00:23 -0400 Received: from osibisa (unknown [219.91.223.66]) by mail.orgltd.com (Postfix) with ESMTP id A65A4DEDBA; Wed, 11 Apr 2007 17:50:26 +0530 (IST) From: "Vikas Tandon" To: "'Qian Sun'" , Subject: RE: [Simple] Appear Offline Date: Wed, 11 Apr 2007 18:28:59 +0530 Organization: ORG Telecom Ltd MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acd8IWIenjURYprBQoi5xxyu+vH46QAFu7Lw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <000801c77c21$626d1730$7c6c460a@china.huawei.com> Message-Id: <20070411122026.A65A4DEDBA@mail.orgltd.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vikas.tandon@orgltd.com List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Dear Qian, It can be processed as the note in the Presence tuple where status will be online but the note will be appear offline. The Notifier should process presence notification accordingly. Would be interesting to hear any other way this can be done. Regards, Vikas Tandon -----Original Message----- From: Qian Sun [mailto:sunqian@huawei.com] Sent: Wednesday, April 11, 2007 3:39 PM To: simple@ietf.org Subject: [Simple] Appear Offline Hi All, "Appear Offline" is very popular in current IM software. People sometimes want to hide themselves, i.e. appear "offline" when they are actually "online", at the same time they can get their buddies' presence information. Can anybody tell me how to realize this feature in SIMPLE way? Thanks in advance, Qian Sun Research & Standardization Dept. Huawei Technologies Co., Ltd. E-mail:sunqian@huawei.com Tel:+86-755-28979550 Fax:+86-755-28975471 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 11 09:32:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbcvf-0003sa-15; Wed, 11 Apr 2007 09:32:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbcvd-0003sH-Dt for simple@ietf.org; Wed, 11 Apr 2007 09:32:05 -0400 Received: from datnt07.tieto.com ([194.110.47.24] helo=mail2.tieto.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbcvV-0005Bv-S3 for simple@ietf.org; Wed, 11 Apr 2007 09:32:05 -0400 X-AuditID: c26e2f18-00001cc0000011ac-8b-461ce32a60bb Received: from veyron.eu.tieto.com ([194.110.47.230]) by mail2.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 16:31:22 +0300 Received: from sagaris.eu.tieto.com ([131.207.197.143]) by veyron.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 16:31:41 +0300 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] Appear Offline Date: Wed, 11 Apr 2007 16:31:40 +0300 Message-ID: In-Reply-To: <20070411122026.A65A4DEDBA@mail.orgltd.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Appear Offline Thread-Index: Acd8IWIenjURYprBQoi5xxyu+vH46QAFu7LwAAFAhnA= From: To: , , X-OriginalArrivalTime: 11 Apr 2007 13:31:41.0477 (UTC) FILETIME=[BD56A550:01C77C3D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.2 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 Hello,=20 In my opinion, you are considered offline by other clients if they do not get presence information for you. So "appear offline" can be achieved when you do not publish your presence information, or you publish it but you do not authorize other people to get it by default. Regards,=20 Silvestr >-----Original Message----- >From: Vikas Tandon [mailto:vikas.tandon@orgltd.com] >Sent: Wednesday, April 11, 2007 2:59 PM >To: 'Qian Sun'; simple@ietf.org >Subject: RE: [Simple] Appear Offline > >Dear Qian, >It can be processed as the note in the Presence tuple where status will be >online but the note will be appear offline. The Notifier should process >presence notification accordingly. >Would be interesting to hear any other way this can be done. > >Regards, >Vikas Tandon > > >-----Original Message----- >From: Qian Sun [mailto:sunqian@huawei.com] >Sent: Wednesday, April 11, 2007 3:39 PM >To: simple@ietf.org >Subject: [Simple] Appear Offline > >Hi All, >"Appear Offline" is very popular in current IM software. People sometimes >want to hide themselves, i.e. appear "offline" when they are actually >"online", at the same time they can get their buddies' presence >information. > >Can anybody tell me how to realize this feature in SIMPLE way? > >Thanks in advance, >Qian Sun >Research & Standardization Dept. >Huawei Technologies Co., Ltd. > >E-mail:sunqian@huawei.com >Tel:+86-755-28979550 >Fax:+86-755-28975471 > > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 11 10:16:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbdcy-00017h-1n; Wed, 11 Apr 2007 10:16:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbdcw-00017X-Dn for simple@ietf.org; Wed, 11 Apr 2007 10:16:50 -0400 Received: from mail.genaker.net ([193.145.84.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbdcu-0004Zs-Lq for simple@ietf.org; Wed, 11 Apr 2007 10:16:50 -0400 Received: (qmail 2304 invoked by uid 107); 11 Apr 2007 14:18:11 -0000 Received: from 203.pool85-52-255.static.orange.es (HELO ?10.1.1.11?) (David.Viamonte@genaker.net@85.52.255.203) by mail.genaker.net with AES256-SHA encrypted SMTP; 11 Apr 2007 14:18:11 -0000 Message-ID: <461CEDF4.5060802@genaker.net> Date: Wed, 11 Apr 2007 16:17:24 +0200 From: David Viamonte User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: simple@ietf.org Subject: Re: [Simple] Appear Offline References: In-Reply-To: X-Spam-Score: 1.2 (+) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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="===============0485570880==" Errors-To: simple-bounces@ietf.org --===============0485570880== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Just my 2c:

To me, "offline" is not the same as "unknown".

IMMO, the latter (unknown) would apply if a Notifier or a Watcher is not able to gather consistent Presence info about a Presentity.

The former (offline) would apply when the Notifier has got information that the Presentity is actually "offline" or unavailable (<status><basic>closed</basic></status> in PIDF terms).

To appear "offline" when the Presentity is actually reachable could be achieved by publishing Presence where status is actually marked as "closed", while the actual communication with the service is not dropped down. The fact that a Source publishes application X availability as "closed" may not necessarily mean that the Presentity is actually unreachable for that application. To my understanding, the dialog maintained between a Presence Source and the Presence Server is independent from the communications that are actually maintained between any other SIP application residing in a client device, and the corresponding Application Server that hosts that application. I am not sure this could be considered BCP, but would see it as a potential way of accomplishing the requested goal.

Additionally, the communication that a Presence Source establishes with a Presence Server is independent of the SIP subscription that a Watcher (possibly co-located with the Presence Source) establishes to receive Presence info about other contacts (i.e.: nothing would prevent -in theory- publishing my status as "offline", while still receiving Presence information about my contacts).

I think the above comments apply well to application availability. When it comes to general (global) availability this may be a bit harder to achieve in some cases. As an example, I don't think it would be wise/feasible to overrule the IMS registration status in 3GPP SIP deployments (i.e.: it seems difficult to publish an "IMS unregistered" status, and still try to be registered to the IMS).

To me, relying on the "note" element is not a proper way to ensure that implementations will interoperate smoothly. IMMO, <note> is supposed to be understood by humans, so Notifiers are not supposed to process it. In fact, RFC 2778 discourages its usage to substitute the status of its parent element.

Regardless, I think things are not 100% clear to be sure that IOP issues could not arise in this area.

Does it all make any sense?

Cheers,

David


Silvestr.Peknik@tietoenator.com escribió: 
Hello, 

In my opinion, you are considered offline by other clients if they do
not get presence information for you. So "appear offline" can be
achieved when you do not publish your presence information, or you
publish it but you do not authorize other people to get it by default.

Regards, 
Silvestr

  
-----Original Message-----
From: Vikas Tandon [mailto:vikas.tandon@orgltd.com]
Sent: Wednesday, April 11, 2007 2:59 PM
To: 'Qian Sun'; simple@ietf.org
Subject: RE: [Simple] Appear Offline

Dear Qian,
It can be processed as the note in the Presence tuple where status will
    
be
  
online but the note will be appear offline. The Notifier should process
presence notification accordingly.
Would be interesting to hear any other way this can be done.

Regards,
Vikas Tandon


-----Original Message-----
From: Qian Sun [mailto:sunqian@huawei.com]
Sent: Wednesday, April 11, 2007 3:39 PM
To: simple@ietf.org
Subject: [Simple] Appear Offline

Hi All,
"Appear Offline" is very popular in current IM software. People
    
sometimes
  
want to hide themselves, i.e. appear "offline" when they are actually
"online", at the same time they can get their buddies' presence
information.

Can anybody tell me how to realize this feature in SIMPLE way?

Thanks in advance,
Qian Sun
Research & Standardization Dept.
Huawei Technologies Co., Ltd.

E-mail:sunqian@huawei.com
Tel:+86-755-28979550
Fax:+86-755-28975471



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



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

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple
--===============0485570880== 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 --===============0485570880==-- From simple-bounces@ietf.org Wed Apr 11 16:55:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbjqX-00060L-Oh; Wed, 11 Apr 2007 16:55:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbjqW-000606-C0 for simple@ietf.org; Wed, 11 Apr 2007 16:55:16 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbjqV-00038Z-0y for simple@ietf.org; Wed, 11 Apr 2007 16:55:16 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.13.8/8.13.8) with ESMTP id l3BKt8Av052579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Apr 2007 15:55:09 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <000801c77c21$626d1730$7c6c460a@china.huawei.com> References: <000801c77c21$626d1730$7c6c460a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Robert Sparks Subject: Re: [Simple] Appear Offline Date: Wed, 11 Apr 2007 15:55:07 -0500 To: Qian Sun X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Look at RFC 3856 and RFC 2779 - search for "polite blocking". RjS On Apr 11, 2007, at 5:08 AM, Qian Sun wrote: > Hi All, > "Appear Offline" is very popular in current IM software. People =20 > sometimes want to hide themselves, i.e. appear =93offline=94 when they = =20 > are actually =93online=94, at the same time they can get their = buddies=92 =20 > presence information. > > Can anybody tell me how to realize this feature in SIMPLE way? > > Thanks in advance, > Qian Sun > Research & Standardization Dept. > Huawei Technologies Co., Ltd. > > E-mail:sunqian@huawei.com > Tel:+86-755-28979550 > Fax:+86-755-28975471 > > > > _______________________________________________ > 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 Apr 12 03:47:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbu1a-0007tE-2Y; Thu, 12 Apr 2007 03:47:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbu1Y-0007t6-BE for simple@ietf.org; Thu, 12 Apr 2007 03:47:20 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbu1S-0003sI-1g for simple@ietf.org; Thu, 12 Apr 2007 03:47:20 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGD0028SK988U@szxga03-in.huawei.com> for simple@ietf.org; Thu, 12 Apr 2007 15:46:20 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGD002ENK9884@szxga03-in.huawei.com> for simple@ietf.org; Thu, 12 Apr 2007 15:46:20 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGD00CQ1K94MB@szxml03-in.huawei.com> for simple@ietf.org; Thu, 12 Apr 2007 15:46:20 +0800 (CST) Date: Thu, 12 Apr 2007 15:46:16 +0800 From: Qian Sun Subject: RE: [Simple] Appear Offline In-reply-to: To: 'Robert Sparks' Message-id: <001601c77cd6$a6dfaa30$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable Thread-index: Acd8e7OjU1d0s74aQ8+7T/crT9+0MAALpPcg X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 Dear all, I have received several different answers so far: 1. The first one is from "Presence Authorization Rules" as Robert = indicated, = http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules-09.t= xt=20 It uses a specific Action in presence rules, i.e. = polite-block, to "tell = the server to place the subscription into the "active" state, and to = produce a presence document that indicates that the presentity is = unavailable. A reasonable document would exclude device and person = information elements, and include only a single service whose basic = status is set to closed." 2. The second one is from IM SIMPLE of OMA, it looks like what David = replied. "The IM subscriber SHALL be shown to his contacts with presence status = =E2=80=9Coffline=E2=80=9D to his contacts when the = =E2=80=9Cinvisible=E2=80=9D option is switched on." "Upon receiving a service setting request containing the = element, as defined in Appendix E, from an IM User the IM Server SHALL = act as a Presence Source." "In the case when the value of the active attribute of the = element is =E2=80=9Cclosed=E2=80=9D, the IM Server SHALL perform the = publication of presence information as defined in [OMA-Pres-Spec] = =E2=80=9CPublication of presence information=E2=80=9D. The IM Server: = SHALL set the value of =E2=80=9CApplication-specific Availability for = IM=E2=80=9D Presence information element to unavailable" 3. I did saw some products had realized this feature using = element. :) 4. Do not publish your presence information, very simple! Maybe we can also use "transformations" to archive this job,=20 , this transformation turns the status of all service into = "closed". It looks not bad. Anyway, should we do something here to avoid confusion and potential IOP = issues?=20 Best Regard, Qian -----Original Message----- From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 Sent: Thursday, April 12, 2007 4:55 AM To: Qian Sun Cc: simple@ietf.org Subject: Re: [Simple] Appear Offline Look at RFC 3856 and RFC 2779 - search for "polite blocking". RjS On Apr 11, 2007, at 5:08 AM, Qian Sun wrote: > Hi All, > "Appear Offline" is very popular in current IM software. People =20 > sometimes want to hide themselves, i.e. appear = =E2=80=9Coffline=E2=80=9D when they =20 > are actually =E2=80=9Conline=E2=80=9D, at the same time they can get = their buddies=E2=80=99 =20 > presence information. > > Can anybody tell me how to realize this feature in SIMPLE way? > > Thanks in advance, > Qian Sun > Research & Standardization Dept. > Huawei Technologies Co., Ltd. > > E-mail:sunqian@huawei.com > Tel:+86-755-28979550 > Fax:+86-755-28975471 > > > > _______________________________________________ > 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 Apr 12 16:24:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc5q2-0005PP-CY; Thu, 12 Apr 2007 16:24:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc5q0-0005Kw-UD for simple@ietf.org; Thu, 12 Apr 2007 16:24:12 -0400 Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk225.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc5py-0002mI-Dc for simple@ietf.org; Thu, 12 Apr 2007 16:24:12 -0400 Received: from wrk225.corp.jabber.com (localhost [127.0.0.1]) by wrk225.corp.jabber.com (Postfix) with ESMTP id C8A0E60DF74 for ; Thu, 12 Apr 2007 14:24:35 -0600 (MDT) Message-ID: <461E9583.3020204@jabber.org> Date: Thu, 12 Apr 2007 14:24:35 -0600 From: Peter Saint-Andre Organization: XMPP Standards Foundation User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2pre) Gecko/20070116 Thunderbird/2.0b2 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: simple@ietf.org Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Subject: [Simple] [Fwd: I-D ACTION:draft-saintandre-xmpp-presence-analysis-00.txt] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1835228747==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1835228747== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080804070801030403090000" This is a cryptographically signed message in MIME format. --------------ms080804070801030403090000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI. I will update this document once -01 of the problem statement I-D is published. -------- Original Message -------- To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 12 Apr 2007 15:50:02 -0400 Subject: I-D ACTION:draft-saintandre-xmpp-presence-analysis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Interdomain Presence Scaling Analysis for the Extensible Messaging and Presence Protocol (XMPP) Author(s) : P. Saint-Andre Filename : draft-saintandre-xmpp-presence-analysis-00.txt Pages : 11 Date : 2007-4-12 This document analyzes the traffic that is generated as a result of presence subscriptions between users of federated domains that support the Extensible Messaging and Presence Protocol (XMPP). This analysis is provided as a source of comparison with a similar analysis being performed regarding domains that support federated presence using Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-presence-analysis-00.txt --------------ms080804070801030403090000 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA3MDQxMjIwMjQzNVowIwYJKoZIhvcNAQkEMRYEFGM0tleyXtFnABeg7F+OHcaeT8QAMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBACgPuzeCxWhdvZdACDH42rb2qu8djwDCmJDSBhL+O1pc aT1iuOCauVKUCsEdQEp2UyWlp6TD3N3GHtlAlmYZAOr4Rr+w4PLlb2nbBDGJPwWmHsfYWh2Z 2n625Dx2tMDo4BrdUZFfOS+tErjDVuVDBcraQQUzTJhGoG+et3nkEhajWZ5/iCoGJQELmiG5 CO12WoVaZ5sd0QE6bnPMcx0kucHGqgK5jfJAG8UMFwStPAf1XZLtcnv2pTcQBd3+Vu5IPcMF nQUlKzk8pn/1YXnYOQSHYr64yXiHM1o/6d4TF8eBLvzfRbND/37w8FgxmNDuKichXiCnN9Vl g41g2iz1aZcAAAAAAAA= --------------ms080804070801030403090000-- --===============1835228747== 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 --===============1835228747==-- From simple-bounces@ietf.org Fri Apr 13 02:04:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcEsx-0003Uu-9b; Fri, 13 Apr 2007 02:03:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcEsw-0003Um-21 for simple@ietf.org; Fri, 13 Apr 2007 02:03:50 -0400 Received: from mail.tieto.com ([194.110.47.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcEsv-0000AH-DV for simple@ietf.org; Fri, 13 Apr 2007 02:03:50 -0400 Received: from veyron.eu.tieto.com ([194.110.47.230]) by mail.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 09:03:43 +0300 Received: from sagaris.eu.tieto.com ([131.207.197.143]) by veyron.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 09:03:47 +0300 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] Appear Offline Date: Fri, 13 Apr 2007 09:03:46 +0300 Message-ID: In-Reply-To: <001601c77cd6$a6dfaa30$7c6c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Appear Offline Thread-Index: Acd8e7OjU1d0s74aQ8+7T/crT9+0MAALpPcgADlOu0A= From: To: X-OriginalArrivalTime: 13 Apr 2007 06:03:47.0904 (UTC) FILETIME=[80445400:01C77D91] X-Spam-Score: 0.2 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 Hi I've been thinking about it, and my previous suggestion (do not publish anything) is not correct. I agree with David Viamonte, that if you want to appear offline you simply set your status to closed.=20 You want to appear offline, which means that you want to be able to use IM service, but you do not want to be seen. Setting your presence status to "closed" should not have impact on your usage of IM. So I think you do not need "appear offline" option in presence document. When you indicate to your IM client that you want to appear offline, it will set presence status of IM service tuple to closed while keeping your online. Does it make sense? Silvestr >-----Original Message----- >From: Qian Sun [mailto:sunqian@huawei.com] >Sent: Thursday, April 12, 2007 9:46 AM >To: 'Robert Sparks' >Cc: simple@ietf.org >Subject: RE: [Simple] Appear Offline > >Dear all, >I have received several different answers so far: >1. The first one is from "Presence Authorization Rules" as Robert >indicated, http://www.ietf.org/internet-drafts/draft-ietf-simple-presence- >rules-09.txt >It uses a specific Action in presence rules, i.e. handling>polite-block, to "tell the server to >place the subscription into the "active" state, and to produce a presence >document that indicates that the presentity is unavailable. A reasonable >document would exclude device and person information elements, and >include only a single service whose basic status is set to closed." > >2. The second one is from IM SIMPLE of OMA, it looks like what David >replied. >"The IM subscriber SHALL be shown to his contacts with presence status >"offline" to his contacts when the "invisible" option is switched on." >"Upon receiving a service setting request containing the >element, as defined in Appendix E, from an IM User the IM Server SHALL act >as a Presence Source." >"In the case when the value of the active attribute of the >element is "closed", the IM Server SHALL perform the publication of >presence information as defined in [OMA-Pres-Spec] "Publication of presence >information". The IM Server: SHALL set the value of "Application-specific >Availability for IM" Presence information element to unavailable" > >3. I did saw some products had realized this feature using element. >:) >4. Do not publish your presence information, very simple! > >Maybe we can also use "transformations" to archive this job, >services>, this transformation turns the status of all >service into "closed". It looks not bad. > >Anyway, should we do something here to avoid confusion and potential IOP >issues? > >Best Regard, >Qian > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Apr 13 08:15:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKgE-0006m3-Uf; Fri, 13 Apr 2007 08:15:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcKgD-0006lc-Ik for simple@ietf.org; Fri, 13 Apr 2007 08:15:05 -0400 Received: from node06.dns-hosting.info ([83.149.75.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcKgA-0001ZA-8R for simple@ietf.org; Fri, 13 Apr 2007 08:15:05 -0400 Received: from titan.dns-hosting.info ([193.230.183.40]:44346 helo=[10.0.0.1]) by node06.dns-hosting.info with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1HcKg8-0001tI-BD for simple@ietf.org; Fri, 13 Apr 2007 14:15:00 +0200 Message-ID: <461F745D.4090901@ag-projects.com> Date: Fri, 13 Apr 2007 15:15:25 +0300 From: Mircea Amarascu User-Agent: Thunderbird 1.5.0.7 (X11/20060927) MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 193.230.183.40 X-SA-Exim-Mail-From: mircea@ag-projects.com X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on node06.dns-hosting.info X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 X-SA-Exim-Version: 4.2.1 (built Sun, 03 Dec 2006 00:39:09 +0000) X-SA-Exim-Scanned: Yes (on node06.dns-hosting.info) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Simple] XML schema for presence rules documents X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hello, I have a question regarding the XML Schema that validates the presence rules documents, schema defined in Section 6 of draft-ietf-simple-presence-rules-09 Because XML Schema allows any global element to be a document root element for a document that can be valid against the schema, it results that documents like: true are valid, though meaningless in regards to a complete presence rules document containing conditions, actions and transformations sections. I could: 1. Validate the document against both presence rules and common policy schemas, but that's inefficient. 2. Validate the document against the presence rules schema and then check its root element is a "ruleset" one. Is there something that I miss here ? Thank you. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Apr 13 09:13:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcLaW-0000YS-On; Fri, 13 Apr 2007 09:13:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcLaV-0000Va-Hb for simple@ietf.org; Fri, 13 Apr 2007 09:13:15 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcLaU-0004px-2H for simple@ietf.org; Fri, 13 Apr 2007 09:13:15 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3DDClNG020745; Fri, 13 Apr 2007 16:13:10 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 16:13:08 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 16:13:07 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 16:13:07 +0300 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3DDD5pe009907; Fri, 13 Apr 2007 16:13:06 +0300 Received: from [172.21.40.44] (esdhcp04044.research.nokia.com [172.21.40.44]) by kusti.research.nokia.com (Postfix) with ESMTP id B50D493B77; Fri, 13 Apr 2007 16:13:05 +0300 (EEST) Message-ID: <461F81E1.2090208@nokia.com> Date: Fri, 13 Apr 2007 16:13:05 +0300 From: Jari Urpalainen User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: ext Mircea Amarascu Subject: Re: [Simple] XML schema for presence rules documents References: <461F745D.4090901@ag-projects.com> In-Reply-To: <461F745D.4090901@ag-projects.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2007 13:13:07.0476 (UTC) FILETIME=[7A2B1540:01C77DCD] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org ext Mircea Amarascu wrote: > Hello, > > I have a question regarding the XML Schema that validates the presence > rules documents, schema > defined in Section 6 of draft-ietf-simple-presence-rules-09 > > Because XML Schema allows any global element to be a document root > element for a document that can be valid against the schema, it > results that documents like: > > > xmlns="urn:ietf:params:xml:ns:pres-rules">true > > are valid, though meaningless in regards to a complete presence rules > document containing conditions, actions and transformations sections. > > I could: > > 1. Validate the document against both presence rules and common policy > schemas, but that's inefficient. > 2. Validate the document against the presence rules schema and then > check its root element is a "ruleset" one. > > Is there something that I miss here ? > > Thank you. No, you are not missing anything here. The tool is just deficient. Even for describing content models it has quite many other shortcomings as well. But if you need to do runtime checks (which is not that self-evident either) you'd better use other tools, like relax, but then you need also those schemas. Alternatively, you could write also better combination schemas with w3c/xml schema, but there would still be some deficiency anyhow. br, jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Apr 15 01:51:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcxeE-0000dg-L0; Sun, 15 Apr 2007 01:51:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcxeC-0000YL-QM; Sun, 15 Apr 2007 01:51:36 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcxeC-0000q7-8i; Sun, 15 Apr 2007 01:51:36 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3F5pOS5024915; Sun, 15 Apr 2007 08:51:29 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Apr 2007 08:51:26 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Apr 2007 00:51:24 -0500 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] Appear Offline Date: Sun, 15 Apr 2007 00:51:23 -0500 Message-ID: <6231925C3635AF47B2B149033DD9186502CA6FF3@daebe103.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Appear Offline Thread-Index: Acd8e7OjU1d0s74aQ8+7T/crT9+0MAALpPcgADlOu0AAS4J9cA== References: <001601c77cd6$a6dfaa30$7c6c460a@china.huawei.com> From: To: , X-OriginalArrivalTime: 15 Apr 2007 05:51:24.0102 (UTC) FILETIME=[19C0A660:01C77F22] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070415085129-5D79FBB0-0F86C488/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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 >Does it make sense? Yes. The presence source needs to publish status 'closed' in order to appear to be offline. Cheers, Krisztian >-----Original Message----- >From: ext simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]=20 >Sent: Thursday, April 12, 2007 11:04 PM >To: sunqian@huawei.com >Cc: simple@ietf.org >Subject: RE: [Simple] Appear Offline > >Hi > >I've been thinking about it, and my previous suggestion (do not publish >anything) is not correct. I agree with David Viamonte, that if=20 >you want to appear offline you simply set your status to closed.=20 > >You want to appear offline, which means that you want to be=20 >able to use IM service, but you do not want to be seen.=20 >Setting your presence status to "closed" should not have=20 >impact on your usage of IM. So I think you do not need "appear=20 >offline" option in presence document. When you indicate to=20 >your IM client that you want to appear offline, it will set=20 >presence status of IM service tuple to closed while keeping=20 >your online. > >Does it make sense? > >Silvestr > > >>-----Original Message----- >>From: Qian Sun [mailto:sunqian@huawei.com] >>Sent: Thursday, April 12, 2007 9:46 AM >>To: 'Robert Sparks' >>Cc: simple@ietf.org >>Subject: RE: [Simple] Appear Offline >> >>Dear all, >>I have received several different answers so far: >>1. The first one is from "Presence Authorization Rules" as Robert=20 >>indicated, >http://www.ietf.org/internet-drafts/draft-ietf-simple-presence- >>rules-09.txt >>It uses a specific Action in presence rules, i.e. >handling>polite-block, to "tell the server to >>place the subscription into the "active" state, and to produce a >presence >>document that indicates that the presentity is unavailable. A >reasonable >>document would exclude device and person information elements, and=20 >>include only a single service whose basic status is set to closed." >> >>2. The second one is from IM SIMPLE of OMA, it looks like what David=20 >>replied. >>"The IM subscriber SHALL be shown to his contacts with=20 >presence status=20 >>"offline" to his contacts when the "invisible" option is switched on." >>"Upon receiving a service setting request containing the=20 >=20 >>element, as defined in Appendix E, from an IM User the IM Server SHALL >act >>as a Presence Source." >>"In the case when the value of the active attribute of the=20 >=20 >>element is "closed", the IM Server SHALL perform the publication of=20 >>presence information as defined in [OMA-Pres-Spec] "Publication of >presence >>information". The IM Server: SHALL set the value of >"Application-specific >>Availability for IM" Presence information element to unavailable" >> >>3. I did saw some products had realized this feature using >element. >>:) >>4. Do not publish your presence information, very simple! >> >>Maybe we can also use "transformations" to archive this job, >>>services>, this transformation turns the status of >all >>service into "closed". It looks not bad. >> >>Anyway, should we do something here to avoid confusion and potential >IOP >>issues? >> >>Best Regard, >>Qian >> > >_______________________________________________ >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 gfyrwldlelu@bisys.com Sun Apr 15 09:51:17 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd58P-000472-6b for simple-archive@lists.ietf.org; Sun, 15 Apr 2007 09:51:17 -0400 Received: from [89.123.24.162] (helo=MERLIN) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hd58L-00024c-KV for simple-archive@lists.ietf.org; Sun, 15 Apr 2007 09:51:17 -0400 From: "Gig Readst" To: simple-archive@lists.ietf.org Subject: Hi Date: Sun, 15 Apr 2007 16:51:30 -0300 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0002_01C77F7E.50C345D0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acd/flDDPylGxPihSuaW79BP1DqfTw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <5679CC18B8CDDAE.E3FB661FB4@bisys.com> X-Spam-Score: 4.0 (++++) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 ------=_NextPart_000_0002_01C77F7E.50C345D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0003_01C77F7E.50C345D0" ------=_NextPart_001_0003_01C77F7E.50C345D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit deal subject. recent objects church pantheism truth distinct between worshiped object. reality moving interpret ------=_NextPart_001_0003_01C77F7E.50C345D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

deal subject. = recent

objects church pantheism = truth distinct between worshiped object. reality moving = interpret

------=_NextPart_001_0003_01C77F7E.50C345D0-- ------=_NextPart_000_0002_01C77F7E.50C345D0 Content-Type: image/gif; name="pic01.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhMgJ2AIcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAAMgJ2AAcI/gD/CRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhzHjygs6fP n0CDCh1KtKjRoz6LIV3KtKnTp1CjDuwntWrBBFazat1alA/Xr2DDih1LtqzZs2jTql3Ltq3b t3Djyp1Lt67du3jz6t3Lt6/fvwdzAN4abbDhw4gTK/57ZLHjx5AjS55MubLly5gza97MufPc b55Da0YnurRpjJVOh8aiurXr1xGHwZ5Nu7btsPxu687Jr3fuf79/E/QtfGDxicR7bzxuXCDz hMQdKkcYfaVv49MNPgd+/WDwh9t3/qsuTl57c4/fNW5P31B4+OHQ4afMTR/4efjMy5u3L118 7fLs3Uefcu5l1x132Z1XXXcMKnhddc4ReOCBAkZY4IDraTchhQg6Jx+DCda3H34jYjcdeyAa 6B9tAHpY0IIKNucef9S5aN+MHs6o43387WijhSjSKKJ3Fr5Io5EupufjiyHmx2OPCd6YpIwx rghbi0f+KKSWyRW535JgbonjlDlCSGaY4em3YJQ4KhldhsfFaeaRwT1IppR3Wtkalk7K1yOV NSIZZo6A4kmnjUN+iaiY8RUap58FPulkfWMu6qehIgZZqZ6vwZhllmNuKGGUdyYqap0E8phq khy2aeCJ/08ieCGG+TU5nJ0aXoikpKf+6WWbnAYL1KYnxVHiTO8JqxMdyrrE4UvJNgvVH9JW a+21Cy2jmzPYduvtt+CGK+645JZrLm0ApAuAQOse1C5B7b6LkLzzFqQuvRrhe+6+Z72r70D/ /hMwuwzR669HA/Or8FcH+3tvugJDHK+6BLNLccQOQwwvwBbHyzHBF1/M8b0Aa7zwyVI1XPHH Bws88ssug/xxyRq37LHLKhu0bs4xo+xzUzyHvPLNOMP8cM8G28ty0TuTrO/OMP8sNdBRG720 zFgnvfLWSM9MNNdYFw321HU1M9AvpZEcs9oSsyyy0xPXLDLYc7eMMdQ6d43xzP5uQUL234AH 3logghdu+MIKHK744npJwvjjkEcu+eQk7UD55X3NXfBCCQuUz+f5DAR66P+QXrrop2OuOlB2 b65Q56mnbnros6Nu+uq446Q1zhLHnfHQCdUeO+m0n0587sjrbjLeN+Mt9vMKCT+67cZ7nvz1 N3ncfNjOOx896rFTX3z42Je/ks1rV9x917BLf5Dw5Jsv/0l1X9308jXzXdD01hsE/+0Mmcf8 BogwAtoENAZ0ickSyMAGOvCBEIygBOkyhwla8IKiASAGN0gStW0MI6AT3ecQAkANcvCECWmd Roo3vviNUIQojCHnRta2jtFMf9TrH/la2EIZ+hBeQv5TX9Q6F8LhvS+HFOHFD61UBKLs7mt3 a1/1dEiQ48VviTF8IvBgZz0Wgm9/nuMfFhfWBJ1o0YYdg2IVX1g6Nt6uhGOMo0hMKBJzyPGO eMzjADGhxz768Y+ADKQgwXKJQRpSPGyjW0nUqLQPfkReXGxIJDMSyUmmb15vCyL7HCkRLloS JZAc2yPrdcmKLPBod0MjEH+nSlFGxJILzFvPZsg3fH1yIp6kH0huacoOpvBqz+PZLHeZk1AO syW8lKW7tta6oOnNlRCBpUNyabVGxu2GqUyjvfKHtN5pc22ZPGXIwmnMRLotY2yTm+9Wec29 OVKTYvOgB3n3L/QJEWpfS/8n/mJJNN/VbZzqZGXDwonNbO5NnvwkqDaDRrH7dXOd23SoLM05 S2c2E6DXBOjQNNfQhG5PkhtTI/OGuMllZs1+JXXmMlUqxJb2c5gvVeFKvfZBe25vCMGs6S/V 9zamMVN/3rNm1Y5JUosW9ag/LSlRc2pUmLqUpDSt5xZridSKAvWZOZNq2Ka6VGXGU2fovF8N wbm7ll5yfTEFakOhataPojKIwtRcKsOq06eWcn3AVKZIfWpVnqpzouek21q5p1S0RnSs5aQh Rwcb1SFy86M5baxX2VrYZ+rNaV7DbCuVylVqnlRpUDwjVT971pRStql9tdvyfplWr7JUqBsF Jl7+zarXsan2nZZ1am6DilrDElaYlm1tbXt7TLwpoq3BHSrwCCvZyHLVuWVNKvRMO024Ajab cAsoWCG7PXPabLGI/SZyLcZO7LYTndv13jxZSd7xrre9ButpbaW7znlutHdyO2xl3TnXwH5z vXi1rz5pVt//klegamUkJPfpX/6CF70XraF93WnLx+KQIXigpExkuhcO+ySZZAFxTERcFxJv RK6Zi+VPVEwXEyvwkDCGyhdiTOMa2zgr8rgxZhqj4x43KzmPCtRCQqSlRnlECtDJVESIRSRQ UURJy4HInGIFnl5tiVDY+dSxAqTlIe+qPww5jhbIxWWFRMvJXT5WSYL+jJz2FPkiZa7ImX/0 nDk32VeYKlSat/zmfwihylmWspv5hSo3ZacQLpJDkUQlKxMxCVasOhGbUrToVLXqQQ06U5No hSgKhQrKj/6VpEflpTvfCkOhbvSugiQlJS9a1F2qNKQhNKdXwXpWql7SuTRlqUQx6kOOgtSv 81yhUPmKzYvyUaV4nWYog7rYFSLRlb+0KkMlW1IOUhGl6FyqL+PZ1cSm0raxHO4pxXlczHbV iHytKTOhSUbuDjaWy5xpTM1KTY4i1bZdjWwhrWlVsS4Rrdgt72hPCk/4ptN03iEoQA1K3Hke FIzOLa50x4jNBB/2qofta2hfG8/meXeXmX2qqV7nieMbp7iq0OxxlsfZ2FWqM5qVXfAzoVzi e0b3x4EFKkhn2VVEjnShgXTqAGW6TkUn+pWH/nOHP2vpJ+8QcDZhoqGPmt69mjSrq05lmNtc 6baieZLYwSZNs/rfXpcjk6msHsat/SN2luHTS86RuKNs7uixu4/3zve++/3vgA98UUwh+MIb /vCIT7ziF8/4xjv+8WARIOQnT/k7YqPymM+85jfP+c6HJCAAOw== ------=_NextPart_000_0002_01C77F7E.50C345D0-- From simple-bounces@ietf.org Sun Apr 15 11:37:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd6mh-0005HS-Kd; Sun, 15 Apr 2007 11:36:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd6mg-0005GR-Tb for simple@ietf.org; Sun, 15 Apr 2007 11:36:58 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hd6kn-0007Gf-3U for simple@ietf.org; Sun, 15 Apr 2007 11:35:02 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGJ000B6PYBMV@usaga01-in.huawei.com> for simple@ietf.org; Sun, 15 Apr 2007 08:35:00 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGJ00L6JPY9DV@usaga01-in.huawei.com> for simple@ietf.org; Sun, 15 Apr 2007 08:34:58 -0700 (PDT) Received: from [172.24.1.6] (Forwarded-For: [62.159.183.141]) by szxmc04-in.huawei.com (mshttpd); Sun, 15 Apr 2007 23:34:58 +0800 Date: Sun, 15 Apr 2007 23:34:58 +0800 From: sunqian 32328 Subject: RE: [Simple] Appear Offline To: simple@ietf.org Message-id: <3c61b783c643a0.3c643a03c61b78@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 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, Sometimes a user just wants to appear offline to some specific persons, not all of his buddies, especially not the person who is communicating with the user. How to realize this feature? Best Regards, Qian Sun ----- Original Message ----- From: krisztian.kiss@nokia.com Date: Sunday, April 15, 2007 1:51 pm Subject: RE: [Simple] Appear Offline > >Does it make sense? > > Yes. The presence source needs to publish status 'closed' in order to > appear to be offline. > > Cheers, > Krisztian > > >-----Original Message----- > >From: ext simple-bounces@ietf.org [simple-bounces@ietf.org] > >Sent: Thursday, April 12, 2007 11:04 PM > >To: sunqian@huawei.com > >Cc: simple@ietf.org > >Subject: RE: [Simple] Appear Offline > > > >Hi > > > >I've been thinking about it, and my previous suggestion (do not > publish>anything) is not correct. I agree with David Viamonte, > that if > >you want to appear offline you simply set your status to closed. > > > >You want to appear offline, which means that you want to be > >able to use IM service, but you do not want to be seen. > >Setting your presence status to "closed" should not have > >impact on your usage of IM. So I think you do not need "appear > >offline" option in presence document. When you indicate to > >your IM client that you want to appear offline, it will set > >presence status of IM service tuple to closed while keeping > >your online. > > > >Does it make sense? > > > >Silvestr > > > > > >>-----Original Message----- > >>From: Qian Sun [sunqian@huawei.com] > >>Sent: Thursday, April 12, 2007 9:46 AM > >>To: 'Robert Sparks' > >>Cc: simple@ietf.org > >>Subject: RE: [Simple] Appear Offline > >> > >>Dear all, > >>I have received several different answers so far: > >>1. The first one is from "Presence Authorization Rules" as > Robert > >>indicated, > >http://www.ietf.org/internet-drafts/draft-ietf-simple-presence- > >>rules-09.txt > >>It uses a specific Action in presence rules, i.e. >>handling>polite-block, to "tell the server to > >>place the subscription into the "active" state, and to produce a > >presence > >>document that indicates that the presentity is unavailable. A > >reasonable > >>document would exclude device and person information elements, > and > >>include only a single service whose basic status is set to closed." > >> > >>2. The second one is from IM SIMPLE of OMA, it looks like what > David > >>replied. > >>"The IM subscriber SHALL be shown to his contacts with > >presence status > >>"offline" to his contacts when the "invisible" option is > switched on." > >>"Upon receiving a service setting request containing the > > > >>element, as defined in Appendix E, from an IM User the IM Server > SHALL>act > >>as a Presence Source." > >>"In the case when the value of the active attribute of the > > > >>element is "closed", the IM Server SHALL perform the publication > of > >>presence information as defined in [OMA-Pres-Spec] "Publication of > >presence > >>information". The IM Server: SHALL set the value of > >"Application-specific > >>Availability for IM" Presence information element to unavailable" > >> > >>3. I did saw some products had realized this feature using > >element. > >>:) > >>4. Do not publish your presence information, very simple! > >> > >>Maybe we can also use "transformations" to archive this job, > >> >>services>, this transformation turns the > status of > >all > >>service into "closed". It looks not bad. > >> > >>Anyway, should we do something here to avoid confusion and potential > >IOP > >>issues? > >> > >>Best Regard, > >>Qian > >> > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Apr 16 07:57:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdPpL-0004dT-So; Mon, 16 Apr 2007 07:56:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdPpK-0004dO-Am for simple@ietf.org; Mon, 16 Apr 2007 07:56:58 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdPpI-0007G2-Op for simple@ietf.org; Mon, 16 Apr 2007 07:56:58 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3GBuKBI028387; Mon, 16 Apr 2007 14:56:45 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 14:56:44 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 06:56:41 -0500 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] Appear Offline Date: Mon, 16 Apr 2007 06:56:29 -0500 Message-ID: <6231925C3635AF47B2B149033DD9186502CA734F@daebe103.NOE.Nokia.com> In-Reply-To: <3c61b783c643a0.3c643a03c61b78@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Appear Offline Thread-Index: Acd/dAErGOoPjViKQY2QAosru/zi6AAexMyQ References: <3c61b783c643a0.3c643a03c61b78@huawei.com> From: To: , X-OriginalArrivalTime: 16 Apr 2007 11:56:41.0739 (UTC) FILETIME=[4C1865B0:01C7801E] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Qian, Sources may publish multiple tuples (one with status 'open', one with status 'closed') and set authorization rules appropriately. Cheers, Krisztian=20 >-----Original Message----- >From: ext sunqian 32328 [mailto:sunqian@huawei.com]=20 >Sent: Sunday, April 15, 2007 8:35 AM >To: simple@ietf.org >Subject: RE: [Simple] Appear Offline > >Hi, >Sometimes a user just wants to appear offline to some specific=20 >persons, not all of his buddies, especially not the person who=20 >is communicating with the user. > >How to realize this feature? > >Best Regards, >Qian Sun > >----- Original Message ----- >From: krisztian.kiss@nokia.com >Date: Sunday, April 15, 2007 1:51 pm >Subject: RE: [Simple] Appear Offline > >> >Does it make sense? >>=20 >> Yes. The presence source needs to publish status 'closed' in=20 >order to=20 >> appear to be offline. >>=20 >> Cheers, >> Krisztian >>=20 >> >-----Original Message----- >> >From: ext simple-bounces@ietf.org [simple-bounces@ietf.org] >> >Sent: Thursday, April 12, 2007 11:04 PM >> >To: sunqian@huawei.com >> >Cc: simple@ietf.org >> >Subject: RE: [Simple] Appear Offline >> > >> >Hi >> > >> >I've been thinking about it, and my previous suggestion (do not >> publish>anything) is not correct. I agree with David Viamonte, >> that if >> >you want to appear offline you simply set your status to closed.=20 >> > >> >You want to appear offline, which means that you want to be able to=20 >> >use IM service, but you do not want to be seen. >> >Setting your presence status to "closed" should not have impact on=20 >> >your usage of IM. So I think you do not need "appear=20 >offline" option=20 >> >in presence document. When you indicate to your IM client that you=20 >> >want to appear offline, it will set presence status of IM service=20 >> >tuple to closed while keeping your online. >> > >> >Does it make sense? >> > >> >Silvestr >> > >> > >> >>-----Original Message----- >> >>From: Qian Sun [sunqian@huawei.com] >> >>Sent: Thursday, April 12, 2007 9:46 AM >> >>To: 'Robert Sparks' >> >>Cc: simple@ietf.org >> >>Subject: RE: [Simple] Appear Offline >> >> >> >>Dear all, >> >>I have received several different answers so far: >> >>1. The first one is from "Presence Authorization Rules" as >> Robert >> >>indicated, >> >http://www.ietf.org/internet-drafts/draft-ietf-simple-presence- >> >>rules-09.txt >> >>It uses a specific Action in presence rules, i.e. > >>handling>polite-block, to "tell the server to >> >>place the subscription into the "active" state, and to produce a >> >presence >> >>document that indicates that the presentity is unavailable. A >> >reasonable >> >>document would exclude device and person information elements, >> and >> >>include only a single service whose basic status is set to closed." >> >> >> >>2. The second one is from IM SIMPLE of OMA, it looks like what >> David >> >>replied. >> >>"The IM subscriber SHALL be shown to his contacts with >> >presence status >> >>"offline" to his contacts when the "invisible" option is >> switched on." >> >>"Upon receiving a service setting request containing the >> > >> >>element, as defined in Appendix E, from an IM User the IM Server >> SHALL>act >> >>as a Presence Source." >> >>"In the case when the value of the active attribute of the >> > >> >>element is "closed", the IM Server SHALL perform the publication >> of >> >>presence information as defined in [OMA-Pres-Spec] "Publication of >> >presence >> >>information". The IM Server: SHALL set the value of >> >"Application-specific >> >>Availability for IM" Presence information element to unavailable" >> >> >> >>3. I did saw some products had realized this feature using >> >element. >> >>:) >> >>4. Do not publish your presence information, very simple! >> >> >> >>Maybe we can also use "transformations" to archive this job, >> >>> >>services>, this transformation turns the >> status of >> >all >> >>service into "closed". It looks not bad. >> >> >> >>Anyway, should we do something here to avoid confusion and=20 >potential >> >IOP >> >>issues? >> >> >> >>Best Regard, >> >>Qian >> >> >> > >> >_______________________________________________ >> >Simple mailing list >> >Simple@ietf.org >> >https://www1.ietf.org/mailman/listinfo/simple >> > >>=20 > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Apr 16 09:17:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdR4g-0006wl-MY; Mon, 16 Apr 2007 09:16:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdR4e-0006vn-C8 for simple@ietf.org; Mon, 16 Apr 2007 09:16:52 -0400 Received: from gurgaon.orgltd.com ([61.247.231.160] helo=mail.orgltd.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdR4V-00086x-CR for simple@ietf.org; Mon, 16 Apr 2007 09:16:52 -0400 Received: from osibisa (unknown [219.91.223.66]) by mail.orgltd.com (Postfix) with ESMTP id 959E6DEC31; Mon, 16 Apr 2007 18:06:51 +0530 (IST) From: "Vikas Tandon" To: , , Subject: RE: [Simple] Appear Offline Date: Mon, 16 Apr 2007 18:46:31 +0530 Organization: ORG Telecom Ltd MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd/dAErGOoPjViKQY2QAosru/zi6AAexMyQAA5Zf5A= In-Reply-To: <6231925C3635AF47B2B149033DD9186502CA734F@daebe103.NOE.Nokia.com> Message-Id: <20070416123651.959E6DEC31@mail.orgltd.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vikas.tandon@orgltd.com 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 If the Facet header is present in a particular PUBLISH, the buddy ids for which this PUBLISH is valid will also be there. This way the authorization rules can be set at the Notifier (Presence Server). E.g. if vikas@abc.com sends a publish with status closed with sunqian@huawei.com in the facet header, then sunqian@huawei.com will see vikas@abc.com as offline while others may see him as online). We've implemented this and works just fine. Would be great to hear other's views. Regards, Vikas -----Original Message----- From: krisztian.kiss@nokia.com [mailto:krisztian.kiss@nokia.com] Sent: Monday, April 16, 2007 5:26 PM To: sunqian@huawei.com; simple@ietf.org Subject: RE: [Simple] Appear Offline Hi Qian, Sources may publish multiple tuples (one with status 'open', one with status 'closed') and set authorization rules appropriately. Cheers, Krisztian >-----Original Message----- >From: ext sunqian 32328 [mailto:sunqian@huawei.com] >Sent: Sunday, April 15, 2007 8:35 AM >To: simple@ietf.org >Subject: RE: [Simple] Appear Offline > >Hi, >Sometimes a user just wants to appear offline to some specific persons, >not all of his buddies, especially not the person who is communicating >with the user. > >How to realize this feature? > >Best Regards, >Qian Sun > >----- Original Message ----- >From: krisztian.kiss@nokia.com >Date: Sunday, April 15, 2007 1:51 pm >Subject: RE: [Simple] Appear Offline > >> >Does it make sense? >> >> Yes. The presence source needs to publish status 'closed' in >order to >> appear to be offline. >> >> Cheers, >> Krisztian >> >> >-----Original Message----- >> >From: ext simple-bounces@ietf.org [simple-bounces@ietf.org] >> >Sent: Thursday, April 12, 2007 11:04 PM >> >To: sunqian@huawei.com >> >Cc: simple@ietf.org >> >Subject: RE: [Simple] Appear Offline >> > >> >Hi >> > >> >I've been thinking about it, and my previous suggestion (do not >> publish>anything) is not correct. I agree with David Viamonte, >> that if >> >you want to appear offline you simply set your status to closed. >> > >> >You want to appear offline, which means that you want to be able to >> >use IM service, but you do not want to be seen. >> >Setting your presence status to "closed" should not have impact on >> >your usage of IM. So I think you do not need "appear >offline" option >> >in presence document. When you indicate to your IM client that you >> >want to appear offline, it will set presence status of IM service >> >tuple to closed while keeping your online. >> > >> >Does it make sense? >> > >> >Silvestr >> > >> > >> >>-----Original Message----- >> >>From: Qian Sun [sunqian@huawei.com] >> >>Sent: Thursday, April 12, 2007 9:46 AM >> >>To: 'Robert Sparks' >> >>Cc: simple@ietf.org >> >>Subject: RE: [Simple] Appear Offline >> >> >> >>Dear all, >> >>I have received several different answers so far: >> >>1. The first one is from "Presence Authorization Rules" as >> Robert >> >>indicated, >> >http://www.ietf.org/internet-drafts/draft-ietf-simple-presence- >> >>rules-09.txt >> >>It uses a specific Action in presence rules, i.e. > >>handling>polite-block, to "tell the server to >> >>place the subscription into the "active" state, and to produce a >> >presence >> >>document that indicates that the presentity is unavailable. A >> >reasonable >> >>document would exclude device and person information elements, >> and >> >>include only a single service whose basic status is set to closed." >> >> >> >>2. The second one is from IM SIMPLE of OMA, it looks like what >> David >> >>replied. >> >>"The IM subscriber SHALL be shown to his contacts with >> >presence status >> >>"offline" to his contacts when the "invisible" option is >> switched on." >> >>"Upon receiving a service setting request containing the >> > >> >>element, as defined in Appendix E, from an IM User the IM Server >> SHALL>act >> >>as a Presence Source." >> >>"In the case when the value of the active attribute of the >> > >> >>element is "closed", the IM Server SHALL perform the publication >> of >> >>presence information as defined in [OMA-Pres-Spec] "Publication of >> >presence >> >>information". The IM Server: SHALL set the value of >> >"Application-specific >> >>Availability for IM" Presence information element to unavailable" >> >> >> >>3. I did saw some products had realized this feature using >> >element. >> >>:) >> >>4. Do not publish your presence information, very simple! >> >> >> >>Maybe we can also use "transformations" to archive this job, >> >>> >>services>, this transformation turns the >> status of >> >all >> >>service into "closed". It looks not bad. >> >> >> >>Anyway, should we do something here to avoid confusion and >potential >> >IOP >> >>issues? >> >> >> >>Best Regard, >> >>Qian >> >> >> > >> >_______________________________________________ >> >Simple mailing list >> >Simple@ietf.org >> >https://www1.ietf.org/mailman/listinfo/simple >> > >> > > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Apr 16 10:33:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSGi-0001TG-JF; Mon, 16 Apr 2007 10:33:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSGh-0001T6-W3 for simple@ietf.org; Mon, 16 Apr 2007 10:33:23 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdSGc-0000Rh-RB for simple@ietf.org; Mon, 16 Apr 2007 10:33:23 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGL00BLNHNYLN@usaga01-in.huawei.com> for simple@ietf.org; Mon, 16 Apr 2007 07:31:11 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGL00BQHHNXLQ@usaga01-in.huawei.com> for simple@ietf.org; Mon, 16 Apr 2007 07:31:10 -0700 (PDT) Received: from [172.24.1.6] (Forwarded-For: [62.159.183.141]) by szxmc04-in.huawei.com (mshttpd); Mon, 16 Apr 2007 22:31:09 +0800 Date: Mon, 16 Apr 2007 22:31:09 +0800 From: sunqian 32328 Subject: RE: [Simple] Appear Offline To: krisztian.kiss@nokia.com Message-id: <3d165cd3d1a48c.3d1a48c3d165cd@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 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 Hi, In that case you have to set appear offline or the alike in tuples of the presence document, and at the same time set appear offline in the Presence Authorization Rules. I prefer to only use "polite-block" Action in the Presence Authorization Rules, it needn't set anything in the presence document. this seems simpler. And you know, the Watcher Information[rfc3857] will disclose who are subscribing the presence information of a presentity. So a user can not indeed hide himself in a SIMPLE presence service with Watcher Information mechanism. Because if you are offline, you must not have a active subscription. In fact, the usage of Watcher Information is primarily presence authorization of the pending subscription mentioned in [rfc3857]. Maybe we should use other method e.g. consent mechanism mentioned in [rfc4453] and discard Watcher Information mechanism, or don't provide the presentity with the Watcher Information which subscription is "active", you can find this don't affect the presence authorization of the pending subscription, because it just need the "pending" subscription. Best Regards, Qian ----- Original Message ----- From: krisztian.kiss@nokia.com Date: Monday, April 16, 2007 7:56 pm Subject: RE: [Simple] Appear Offline > Hi Qian, > > Sources may publish multiple tuples (one with status 'open', one with > status 'closed') and set authorization rules appropriately. > > Cheers, > Krisztian > > >-----Original Message----- > >From: ext sunqian 32328 [sunqian@huawei.com] > >Sent: Sunday, April 15, 2007 8:35 AM > >To: simple@ietf.org > >Subject: RE: [Simple] Appear Offline > > > >Hi, > >Sometimes a user just wants to appear offline to some specific > >persons, not all of his buddies, especially not the person who > >is communicating with the user. > > > >How to realize this feature? > > > >Best Regards, > >Qian Sun > > > >----- Original Message ----- > >From: krisztian.kiss@nokia.com > >Date: Sunday, April 15, 2007 1:51 pm > >Subject: RE: [Simple] Appear Offline > > > >> >Does it make sense? > >> > >> Yes. The presence source needs to publish status 'closed' in > >order to > >> appear to be offline. > >> > >> Cheers, > >> Krisztian > >> > >> >-----Original Message----- > >> >From: ext simple-bounces@ietf.org [simple-bounces@ietf.org] > >> >Sent: Thursday, April 12, 2007 11:04 PM > >> >To: sunqian@huawei.com > >> >Cc: simple@ietf.org > >> >Subject: RE: [Simple] Appear Offline > >> > > >> >Hi > >> > > >> >I've been thinking about it, and my previous suggestion (do not > >> publish>anything) is not correct. I agree with David Viamonte, > >> that if > >> >you want to appear offline you simply set your status to > closed. > >> > > >> >You want to appear offline, which means that you want to be > able to > >> >use IM service, but you do not want to be seen. > >> >Setting your presence status to "closed" should not have > impact on > >> >your usage of IM. So I think you do not need "appear > >offline" option > >> >in presence document. When you indicate to your IM client that > you > >> >want to appear offline, it will set presence status of IM > service > >> >tuple to closed while keeping your online. > >> > > >> >Does it make sense? > >> > > >> >Silvestr > >> > > >> > > >> >>-----Original Message----- > >> >>From: Qian Sun [sunqian@huawei.com] > >> >>Sent: Thursday, April 12, 2007 9:46 AM > >> >>To: 'Robert Sparks' > >> >>Cc: simple@ietf.org > >> >>Subject: RE: [Simple] Appear Offline > >> >> > >> >>Dear all, > >> >>I have received several different answers so far: > >> >>1. The first one is from "Presence Authorization Rules" as > >> Robert > >> >>indicated, > >> >http://www.ietf.org/internet-drafts/draft-ietf-simple-presence- > >> >>rules-09.txt > >> >>It uses a specific Action in presence rules, i.e. > >> >>handling>polite-block, to "tell the server to > >> >>place the subscription into the "active" state, and to > produce a > >> >presence > >> >>document that indicates that the presentity is unavailable. A > >> >reasonable > >> >>document would exclude device and person information elements, > >> and > >> >>include only a single service whose basic status is set to > closed.">> >> > >> >>2. The second one is from IM SIMPLE of OMA, it looks like what > >> David > >> >>replied. > >> >>"The IM subscriber SHALL be shown to his contacts with > >> >presence status > >> >>"offline" to his contacts when the "invisible" option is > >> switched on." > >> >>"Upon receiving a service setting request containing the > >> > > >> >>element, as defined in Appendix E, from an IM User the IM Server > >> SHALL>act > >> >>as a Presence Source." > >> >>"In the case when the value of the active attribute of the > >> > > >> >>element is "closed", the IM Server SHALL perform the publication > >> of > >> >>presence information as defined in [OMA-Pres-Spec] > "Publication of > >> >presence > >> >>information". The IM Server: SHALL set the value of > >> >"Application-specific > >> >>Availability for IM" Presence information element to unavailable" > >> >> > >> >>3. I did saw some products had realized this feature using > >> >element. > >> >>:) > >> >>4. Do not publish your presence information, very simple! > >> >> > >> >>Maybe we can also use "transformations" to archive this job, > >> >> >> >>services>, this transformation turns the > >> status of > >> >all > >> >>service into "closed". It looks not bad. > >> >> > >> >>Anyway, should we do something here to avoid confusion and > >potential > >> >IOP > >> >>issues? > >> >> > >> >>Best Regard, > >> >>Qian > >> >> > >> > > >> >_______________________________________________ > >> >Simple mailing list > >> >Simple@ietf.org > >> >https://www1.ietf.org/mailman/listinfo/simple > >> > > >> > > > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Apr 16 18:56:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hda7S-0000em-RC; Mon, 16 Apr 2007 18:56:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hda7R-0000eU-Kd for simple@ietf.org; Mon, 16 Apr 2007 18:56:21 -0400 Received: from corp-fw-main.jabber.com ([207.182.164.14] helo=wrk225.corp.jabber.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hda7O-0003t0-4V for simple@ietf.org; Mon, 16 Apr 2007 18:56:21 -0400 Received: from wrk225.corp.jabber.com (localhost [127.0.0.1]) by wrk225.corp.jabber.com (Postfix) with ESMTP id B3CC460FD99 for ; Mon, 16 Apr 2007 16:56:54 -0600 (MDT) Message-ID: <4623FF36.5020600@jabber.org> Date: Mon, 16 Apr 2007 16:56:54 -0600 From: Peter Saint-Andre Organization: XMPP Standards Foundation User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: simple@ietf.org Jabber-ID: stpeter@jabber.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Subject: [Simple] mapping im: and pres: URIs 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="===============0590565284==" Errors-To: simple-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0590565284== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010805010008010709030406" This is a cryptographically signed message in MIME format. --------------ms010805010008010709030406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In draft-saintandre-xmpp-simple-09, we define mappings of sip:, sips:, pres:, and im: URIs to XMPP addresses and vice-versa. Unfortunately I am confused about exactly which characters are reserved, unreserved, and forbidden (i.e., to-be-escaped) for the relevant addressing schemes. In this mail I ask about im: and pres: URIs (I still need to research sip/sips URIs further before posting). RFC 3859 defines the syntax of the pres: URI scheme as follows (the im: URI scheme is defined equivalently in RFC 3860): The syntax follows the existing mailto: URI syntax specified in RFC 2368. The ABNF is: PRES-URI = "pres:" [ to ] [ headers ] to = mailbox headers = "?" header *( "&" header ) header = hname "=" hvalue hname = *uric hvalue = *uric Here the symbol "mailbox" represents an encoded mailbox name as defined in RFC 2822 [3], and the symbol "uric" denotes any character that is valid in a URL (defined in RFC 2396 [10]). A few questions: 1. What does it mean to follow the syntax of the mailto scheme from RFC 2368 but specify that the "mailbox" rule follows RFC 2822 rather than RFC 822 (to which RFC 2368 refers)? 2. What does the term "encoded mailbox name" mean? (As far as I can see, it is not defined in RFC 2822.) Does this mean a mailbox as specified according to RFC 2822 but encoded according to the rules in RFC 2368 (e.g., percent-encoding reserved characters such as "%", "&", "=", and "?" from RFC 2368)? 3. Was it really intended for pres: and im: URIs to completely track the mailbox format (from 822 or 2822), so that things like the following are URIs of good standing? pres:%20Juliet%20Capulet%20 4. In draft-saintandre-xmpp-simple-09 we make the simplifying assumption that we are interested in mapping local-part addresses only (leaving domain mapping out of scope), so that in the previous address would be interested in mapping "juliet" only (since domains are what they are and the phrase is immaterial to address mapping for routing purposes); do folks on this list think that is reasonable? Thanks! Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml --------------ms010805010008010709030406 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYVDCC B3AwggbZoAMCAQICAQkwDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUxMDNaFw0xMDA0MDQxNDUxMDNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOOY75tn3YhiCOsNXQn9/4WfpNrX8HLIUlBTLrGtMINvcYJ0 3Nlr9kJyOF5Z8g+2G9Zg+zN8iWGBEpl37bgjYdea3q0AaO9uyZOMLa0rztjFeo7Uw8AjdDmW kaJQU1c6q9OoieOT6Tf4MvHMGqtbnaOL3Xvz4o6XnH+Ek9h8zPgYgiUw2tIF0ueLayTGiInH dWM5eYMoz7OnVlUeIurDweT4C9V1TtwplnhWZ7bilcuN4w3/8hndqryqqflbCMlLZWn+1uaT 21d12cdpjBOaqtg6hqiTY4S4+wVAmGrAiOPQ3Z574gljhUKf5ehz7p9xtsb+mjvM1I4yPP8/ vjKZoRUCAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBS4Zr17owi6irSy+USIcU+li0GzUTCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQDss9KK Fx/bCifYjAQTmBtRoHFsdR5ZQ1nlagXKoyJ+IwmdGdiYqAKeaDfjT6bTXHfQvK8kp5xSoz0I PcpSwztY7UKtylgJwplu1q6vjj4BGB621sD60qzirAhLSqxmpBgjl8HMMMoiM28DCLsshihl g7wG7Oi/rPIuR8dawiaDejCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STCCCGwwggdUoAMCAQICAwDocDANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDIgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDYwNzA3MTYwNTAwWhcNMDcwNzA3MTYwNTAwWjCBvjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAkNPMQ8wDQYDVQQHEwZEZW52ZXIxIzAhBgNVBAoTGkphYmJlciBT b2Z0d2FyZSBGb3VuZGF0aW9uMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZp Y2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkB FhJzdHBldGVyQGphYmJlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr zNmM5bxrSxV81PynU608wdGBJaKs0I7Y93//cyNPaooH0M1P20FAkmVjNZ2DhHsb4J4H6Koz XDJWVpY04lIS7JIhcmy1pL2Aac0ZvPaGANVRexbuxToFF0q3YoO/NLIQXiuIu8BbNl0BHmZz BHKgsofvKlsLDTQjen85U5GY2Rgg0yRd5/RIRZJwnflJF50VJi8rxYpL6H9W5q9zYtLurjAd 0SSdtCY98YG73vYJyZ5V0ARBUAkc4tg50/XJvubdpmCVJMy6X2zGtKoPfo7LdoOEWbTSCEVu bA0EQSTlybkGnnkG97Kn44lqm7UGpMWx76IGZQ3IrM/dYDnuUaQpAgMBAAGjggR+MIIEejAM BgNVHRMEBTADAgEAMAsGA1UdDwQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFGvThDnN4P4ucEfDmnKw2an31COrMIHdBgNVHSMEgdUwgdKAFLhmvXuj CLqKtLL5RIhxT6WLQbNRoYG2pIGzMIGwMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNyYWVs MQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEaMBgGA1UECxMRQ0Eg QXV0aG9yaXR5IERlcC4xKTAnBgNVBAMTIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmeCAQkwggFABgNVHSAEggE3 MIIBMzCCAS8GCysGAQQBgbU3AQECMIIBHjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3Rh cnRjb20ub3JnL2ludGVybWVkaWF0ZS5wZGYwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZy9wb2xpY3kucGRmMIGzBggrBgEFBQcCAjCBpjAUFg1TdGFydENvbSBMdGQu MAMCAQEagY1MaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGlt aXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIFBvbGljeSBhdmFpbGFi bGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwZAYDVR0fBF0wWzAs oCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0 dHA6Ly9jcmwuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwgYQGCCsGAQUFBwEBBHgwdjA3 BggrBgEFBQcwAYYraHR0cDovL29jc3Auc3RhcnRjb20ub3JnL3N1Yi9jbGFzczIvdXNlci9j YTA7BggrBgEFBQcwAoYvaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3N1Yi5jbGFzczIudXNl ci5jYS5jcnQwEQYJYIZIAYb4QgEBBAQDAgWgMDcGCWCGSAGG+EIBDQQqFihTdGFydENvbSBB dXRoZW50aWNhdGVkIEVtYWlsIENlcnRpZmljYXRlMDIGCWCGSAGG+EIBBAQlFiNodHRwOi8v Y2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDA1BglghkgBhvhCAQMEKBYmaHR0cDovL2Nl cnQuc3RhcnRjb20ub3JnL2NydHUyLWNybC5jcmwwMgYJYIZIAYb4QgEIBCUWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMCMGA1UdEgQcMBqGGGh0dHA6Ly9jZXJ0LnN0 YXJ0Y29tLm9yZzANBgkqhkiG9w0BAQUFAAOCAQEAi8Q3OPqmaAnBgIBm/7dSnbT+613ejmlb DG6f00pgf+PVLyidelTcCbZckHJvH/Q2tQweEtMVluY5NhELU/gwL9VD0Yn4/aPJpgm4bxJn 0/GeWmqcASfcBwb1XgrZDe17rD22YniJdSP4E6VXWxcS2elHdD08yTPlX+Cab9zLrAv0CVxh BOYdDX6aNqY5/YxIfdaJKWClkAz+/GRUI24HSMly9SLEz2Lhvz2WitBflWE4+aOIJx7+UPKM LTSSQfk4WjwTOrQgpc9kjja0q7RdNXOPzOV7WehZo9sUncrIDDg5RkcoclifwOWXe66l6HKZ uYJCLgc0S5jgHntNU6X/STGCBCwwggQoAgEBMIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UE CBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2Vy dGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEVt YWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAOhwMAkG BSsOAwIaBQCgggJJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA3MDQxNjIyNTY1NFowIwYJKoZIhvcNAQkEMRYEFCMcSr4ClV7bU19ndTPvqo277/XjMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHIBgkrBgEEAYI3EAQxgbowgbcwga8xCzAJ BgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xIzAh BgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYDVQQDEyZTdGFydENvbSBD bGFzcyAyIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3Rh cnRjb20ub3JnAgMA6HAwgcoGCyqGSIb3DQEJEAILMYG6oIG3MIGvMQswCQYDVQQGEwJJTDEP MA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1 cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwID AOhwMA0GCSqGSIb3DQEBAQUABIIBAEgaB9g6i1VpTZO0lEpZBAy4L0JCHyzy2lGLFwQ+babG 5ndQsi7T2DjY2QC6p2R9kT00WUPBcb8EuEzS8Rj1wCpuYaEMzyOWIvhIcqy00fLSO3EQyMKq n0kGuho0604z272Mcn/kyyJNFYnDW0qOQY0KQOChJFL9AbrSjPzkYNI1FBo/b/HfBPTlp8lQ ek6XzIyFWYtGsNC1Wosa8fCQbgbuLza4x3XyaTPZYS+HURlIZvBTvGh9vj8Ax0B/BvP93tNg 5nnArI14wnMnOLDjG19NTSuGps9kVt36KvyOOLfohgCBMi57L84RQg7wTpiPK+tFaHFJ6yw0 2d6/UNJ80+IAAAAAAAA= --------------ms010805010008010709030406-- --===============0590565284== 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 --===============0590565284==-- From jameszhao.Quaye@abatebycisd.com Tue Apr 24 21:37:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgWRr-0007yf-9I for simple-archive@lists.ietf.org; Tue, 24 Apr 2007 21:37:35 -0400 Received: from 201-42-123-148.dsl.telesp.net.br ([201.42.123.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgWRp-0007zZ-Ti for simple-archive@lists.ietf.org; Tue, 24 Apr 2007 21:37:35 -0400 Received: by 10.99.125.33 with SMTP id KgsWDQYUcAgPF; Tue, 24 Apr 2007 22:39:12 -0300 (GMT) Received: by 192.168.226.155 with SMTP id MuGbNXPCSNaCIE.7474363176768; Tue, 24 Apr 2007 22:39:10 -0300 (GMT) Date: Tue, 24 Apr 2007 22:39:07 -0300 From: "jameszhao Quaye" Reply-To: "jameszhao Quaye" Message-ID: <770227479147.979529850268@abatebycisd.com> To: Subject: Immense, gains on frankfurt! MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Spam-Score: 4.8 (++++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 easily From simple-bounces@ietf.org Wed Apr 25 09:20:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HghPp-0005pj-0f; Wed, 25 Apr 2007 09:20:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HghPo-0005pd-DB for simple@ietf.org; Wed, 25 Apr 2007 09:20:12 -0400 Received: from mail.tieto.com ([194.110.47.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HghPl-0006Nc-HU for simple@ietf.org; Wed, 25 Apr 2007 09:20:12 -0400 Received: from viper.eu.tieto.com ([194.110.47.167]) by mail.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 16:20:07 +0300 Received: from sagaris.eu.tieto.com ([131.207.197.143]) by viper.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 16:20:08 +0300 Received: from 10.15.1.83 ([10.15.1.83]) by sagaris.eu.tieto.com ([131.207.197.143]) via Exchange Front-End Server email2.tietoenator.com ([192.176.143.12]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Apr 2007 13:20:07 +0000 Received: from localhost by email2.tietoenator.com; 25 Apr 2007 15:20:20 +0200 From: Martin Hynar To: IETF WG SIMPLE Date: Wed, 25 Apr 2007 15:20:20 +0200 Message-Id: <1177507220.3863.11.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-1.fc6) X-OriginalArrivalTime: 25 Apr 2007 13:20:08.0151 (UTC) FILETIME=[71DDFE70:01C7873C] X-Spam-Score: 0.1 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Subject: [Simple] PUT of xml fragment into rls-services document 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="===============1242562656==" Errors-To: simple-bounces@ietf.org --===============1242562656== Content-Type: multipart/alternative; boundary="=-3wip0qPM+yvaZ+rdP3/s" --=-3wip0qPM+yvaZ+rdP3/s Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello, I am facing one interesting problem which I cannot decide how to solve. See the situation 1. I store rls-services document with XCAP PUT request. The content is following presence 2. Now I want to insert new on 3rd position using following requets PUT /rls-services/.../index/~~/rls-services/service[@uri="sip:friends@example.com"]/list/rl:entry[3]?xmlns(rl=urn:ietf:params:xml:ns:resource-lists) 3. What shall be the resulting document? - Is the content of 2nd PUT correct? Is it possible to have 2 parseable items (comment and regular element) on the same level? - Is comment addressable with XCAP document/node selector? I will be happy for all suggestions. Thanks in advance, Martin Hynar +-------------------------------------+ Martin Hynar Software Specialist TietoEnator Czech Software Center Phone: +420 597 459 713 Mobile: +420 724 432 817 E-mail: Martin.Hynar@TietoEnator.com Vystavni 292/13 CZ-709 16 Ostrava www.tietoenator.com Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorized use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You. --=-3wip0qPM+yvaZ+rdP3/s Content-Type: text/html; charset=utf-8 Hello,

I am facing one interesting problem which I cannot decide how to solve. See the situation

1. I store rls-services document with XCAP PUT request. The content is following

<?xml version="1.0" encoding="UTF-8"?>
<rls-services xmlns="urn:ietf:params:xml:ns:rls-services" xmlns:rl="urn:ietf:params:xml:ns:resource-lists">
<service uri="sip:friends@example.com">
<list name="friends">
<rl:entry uri="sip:presentity_A@example.com" />
<rl:entry uri="sip:presentity_B@example.com" />
<rl:entry uri="sip:presentity_D@example.com" />
</list>
<packages>
<package>presence</package>
</packages>
</service>
</rls-services>

2. Now I want to insert new <entry> on 3rd position using following requets

PUT /rls-services/.../index/~~/rls-services/service[@uri="sip:friends@example.com"]/list/rl:entry[3]?xmlns(rl=urn:ietf:params:xml:ns:resource-lists)

<!--some comment -->
<rl:entry uri="sip:presentity_C@example.com" />


3. What shall be the resulting document?
  - Is the content of 2nd PUT correct? Is it possible to have 2 parseable items (comment and regular element) on the same level?
  - Is comment addressable with XCAP document/node selector?


I will be happy for all suggestions. Thanks in advance, Martin Hynar

+-------------------------------------+
  Martin Hynar
  Software Specialist

  TietoEnator
  Czech Software Center
  Phone: +420 597 459 713
  Mobile: +420 724 432 817
  E-mail: Martin.Hynar@TietoEnator.com

  Vystavni 292/13
  CZ-709 16 Ostrava

www.tietoenator.com


Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorized use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You.
--=-3wip0qPM+yvaZ+rdP3/s-- --===============1242562656== 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 --===============1242562656==-- From krgdz@ib-hainz.de Wed Apr 25 23:15:31 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HguSB-00042l-Ll for simple-archive@lists.ietf.org; Wed, 25 Apr 2007 23:15:31 -0400 Received: from ont-static-208.57.136.32.mpowercom.net ([208.57.136.32]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HguS8-0006K0-0k for simple-archive@lists.ietf.org; Wed, 25 Apr 2007 23:15:31 -0400 Received: from ptol ([33.190.175.46]) by ont-static-208.57.136.32.mpowercom.net with Microsoft SMTPSVC(5.0.2195.5329); Wed, 25 Apr 2007 20:18:11 -0700 Message-ID: <002d01c787b1$84df8230$2eafbe21@ptol> From: "Hayes Baldwin" To: Subject: HEAVY RAINS THROUGHOUT THE SOUTH SKUNK RIVER BASIN OVER THE PAST FEW DAYS WILL PRODUCE MINOR FLOODING IN MANY. Date: Wed, 25 Apr 2007 20:18:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.7 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 CHFR continues its Steady Climb, UP Another 23% Since Monday! China Fruits Corporation Symbol: CHFR Price: $0.42 CHFR is climbing steady all week. UP over 23% since Monday, investors are enjoying the solid climb. Read CHFR's recent news, and get on it Thursday! MORE RAIN IS IN THE FORECAST TONIGHT WHICH COULD CAUSE ADDITIONAL RISES. 0 FEET SATURDAY AFTERNOON. IAC099-261424- 924 PM CDT WED APR 25 2007 A FLOOD ADVISORY CONTINUES FOR THE SOUTH SKUNK RIVER AT COLFAX. SEVERAL ROUNDS OF MODERATE TO OCCASIONALLY HEAVY RAINS OVER SOUTHERN IOWA HAVE PRODUCED MINOR FLOODING ALONG PORTIONS OF THE CHARITON RIVER. 0 AGSI4 Issuing Weather Forecast Office Homepage Flood Warning Henry (Iowa) FLOOD WARNING NATIONAL WEATHER SERVICE QUAD CITIES IA IL 1147 AM CDT WED APR 25 2007 . FORECAST FALL BACK TO FLOOD STAGE LATE TUESDAY AFTERNOON. 0 FEET WATER FLOODS MOST OF THE AGRICULTURAL LAND NEAR THE RIVER. 3 WAPI4 SKUNK RIVER SIGOURNEY 16. 7 FEET WATER AFFECTS THE CAMELOT CAMPGROUND. IAC127-261436- 936 PM CDT WED APR 25 2007 THE FLOOD WARNING CONTINUES FOR THE IOWA RIVER AT MARSHALLTOWN. DO NOT STAY IN AREAS SUBJECT TO FLOODING WHEN WATER BEGINS RISING. STREAMS AND OTHER LOW LYING AREAS ARE SUBJECT TO FLOODING. HOWEVER WATER WAS STILL RUNNING IN HIS BASEMENT WITH THE SUMP PUMP NOT BEING ABLE TO KEEP UP. AND SPOTTERS INDICATED MULTIPLE ROAD CLOSURES OVER MUCH OF CENTRAL AND WEST CENTRAL IOWA. HEAVY RAINS THROUGHOUT THE SOUTH SKUNK RIVER BASIN OVER THE PAST FEW DAYS WILL PRODUCE MINOR FLOODING IN MANY. From hqbi@yahoo.co.jp Thu Apr 26 02:56:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgxuT-0000S2-15 for simple-archive@lists.ietf.org; Thu, 26 Apr 2007 02:56:57 -0400 Received: from [85.101.235.39] (helo=olwvvdo) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgxuQ-0003Sy-3Y for simple-archive@lists.ietf.org; Thu, 26 Apr 2007 02:56:57 -0400 Received: from ext ([175.145.239.183]) by olwvvdo (8.13.5/8.13.5) with SMTP id l3Q734qC003615; Thu, 26 Apr 2007 10:03:04 +0300 Message-ID: <001501c787d0$47690240$b7ef91af@ext> From: "Elliott Evelina" To: Subject: nostril Date: Thu, 26 Apr 2007 09:58:22 +0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0011_01C787E9.6CB290C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.5 (++) X-Scan-Signature: b7d359b68a3f49c28e099a438f5724db ------=_NextPart_000_0011_01C787E9.6CB290C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0012_01C787E9.6CB37B20" ------=_NextPart_001_0012_01C787E9.6CB37B20 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Early orders are more than twice as strong as the pre-sale numbers for = "Pokemon FireRed" and "Pokemon LeafGreen," which launched in 2004 and = went on to sell more than 3. This week we answer caller's questions, do more DP promo speculation, = discuss the English Pokemon Anime Preview as aired on Cartoon Network, = and much more. It seems that the Japanese will give almost any Pokemon that is easy to = breed for an early game catch-em-in-the-dozens Pokemon with an English = name. An admission fee is charged at the door and varies depending on = event location. , the world's largest video game and entertainment = software retailer, today announced that it will host early morning video = game launch events at over 3,000 of its U. These figures will be available individually (each includes a = collectible marble! Players are divided into three divisions: Junior Division (born in 1996 = or later); Senior Division (born in 1992, 1993, 1994, or 1995) and = Masters Division (born in 1991 or earlier). EAs' Tiger Woods PGA Tour 07 is at number seven with another Ubisoft PC = title, Prince of Persia: The Sands of Time, at number eight. sells new and used video game software, hardware and accessories for = next generation video game systems from Sony, Nintendo, and Microsoft. Downloads: : Bulbacast Season 2 Episode 15(96kbps). (Please check local listings for times in your area. All you need is a = microphone, Skype, and show up in the IRC chat (irc. and Japanese DP versions confirmed possible - Friend codes confirmed = compatible between languages. The only way to get more of them is to = breed them, which is labor intensive and probably takes over 30 minutes = of play time to create. It is not clear whether direct trading with a foreign version over = Nintendo Wi-Fi Connection or over Wireless Communication is sufficient = to unlock the world map. And why haven't the Japanese traded each other = MagiCarps for 6 months? This Raining pokeBalls commercial first aired on = 13 April 2007, and appears to be a much better commercial then the = previous 'pre-release' one. Early orders are more than twice as strong as the pre-sale numbers for = "Pokemon FireRed" and "Pokemon LeafGreen," which launched in 2004 and = went on to sell more than 3. Back in Twinleaf Town the player's mother = gives him or her running shoes and then the player leaves for Sandgem = Town. ------=_NextPart_001_0012_01C787E9.6CB37B20 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable
3D"essay"
Early orders are more than twice as = strong as the=20 pre-sale numbers for "Pokemon FireRed" and "Pokemon LeafGreen," which = launched in=20 2004 and went on to sell more than 3.
This week we answer caller's questions, = do more DP=20 promo speculation, discuss the English Pokemon Anime Preview as aired on = Cartoon=20 Network, and much more.
It seems that the Japanese will give = almost any=20 Pokemon that is easy to breed for an early game catch-em-in-the-dozens = Pokemon with=20 an English name. An admission fee is charged at the door and varies = depending on=20 event location. , the world's largest video game and entertainment = software=20 retailer, today announced that it will host early morning video game = launch events=20 at over 3,000 of its U.
These figures will be available = individually (each=20 includes a collectible marble!
Players are divided into three = divisions: Junior=20 Division (born in 1996 or later); Senior Division (born in 1992, 1993, = 1994, or=20 1995) and Masters Division (born in 1991 or earlier).
EAs' Tiger Woods PGA Tour 07 is at = number seven=20 with another Ubisoft PC title, Prince of Persia: The Sands of Time, at = number=20 eight.
sells new and used video game software, = hardware=20 and accessories for next generation video game systems from Sony, = Nintendo, and=20 Microsoft.
Downloads: : Bulbacast Season 2 = Episode=20 15(96kbps).
(Please check local listings for times = in your=20 area. All you need is a microphone, Skype, and show up in the IRC = chat=20 (irc.
and Japanese DP versions confirmed = possible -=20 Friend codes confirmed compatible between languages. The only way to get = more of=20 them is to breed them, which is labor intensive and probably takes over = 30 minutes=20 of play time to create.
It is not clear whether direct trading = with a=20 foreign version over Nintendo Wi-Fi Connection or over Wireless = Communication is=20 sufficient to unlock the world map. And why haven't the Japanese traded = each other=20 MagiCarps for 6 months? This Raining pokeBalls commercial first aired on = 13 April=20 2007, and appears to be a much better commercial then the previous = 'pre-release'=20 one.
Early orders are more than twice as = strong as the=20 pre-sale numbers for "Pokemon FireRed" and "Pokemon LeafGreen," which = launched in=20 2004 and went on to sell more than 3. Back in Twinleaf Town the player's = mother=20 gives him or her running shoes and then the player leaves for Sandgem=20 Town.
------=_NextPart_001_0012_01C787E9.6CB37B20-- ------=_NextPart_000_0011_01C787E9.6CB290C0 Content-Type: image/gif; name="middle age.gif" Content-Transfer-Encoding: base64 Content-ID: <001001c787d0$47646e60$b7ef91af@ext> R0lGODdhIQEbAfYAAJ/BgNx66VqOtFXrt2GFeuGAr2uEl+JftHB6jWrR7cVwmlGblVFFLq3d1KTg g4nl56tboXfexvqXoEW2ipumx/6ol4VqcE+ZndpvcHiDsJpj1IdbkN2y7a3Y2dKyWjk+CbuSVMWk Zf+RYZnXTO2d8VIgArPE2ZiRcrOuZ/SrvTFHReO+5VkxBX30W7xlce9tZq6fritNB4zombSX+KzC 0KlzwqFhcLzph+qdVFbMdJB9xdLxnjkyCK7pj/VaeM51XO7putPt1YXQ/pnOkYX3uZBR4aKmjSkQ KIDInMDGYgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwA AAAAIQEbAQAH/4A8DB8fLAyHhIlHgzxHjkc8kY6DiSyCjY88iZElmJGRKpCfn4MxMSqUDCqhDKYf oZmdpJWHlISLjJmSk5WXmI6aH5ydwKCio4IfpqeprMuvsciUhrWJH4vCj8e8vQy/wIScv5+hyJGl zImqi66wwLLntIjW2OOfR5vzhIPY2qIl3D4wMPRNVDhi26CZe6UsnapV+NrpGoUvny1+/XSVAIhN IMGCwXhs9NQI2rFIDJehEgiRkMST9yxevIZRY8CB3vxBOmgPXzlkKdOxDNXwFSxzFcPpQ5SxWCMe rnigihSDXy5g+DjaEiiVY7FwohzdkvpOZCcVDakKXNcqhslHAP+zQY06teq1elg/bLwpVYXXndnC 4oPkTqRhtMvUsm379ghHuXTrWhXmKWtArn79hRQ8mCwkWWfTzmXJzi1EuPiejpbqrerkymEblpiq KZemRzE+P7o4u2BEmiRLliuhN7Sya6YOsSrqznFC2VMFUt7pKLfZ3ftmqyh4fBJJn8P1Sk3k9khy VujecoxpSrs36U9vmdc9KVVvnd1zFvP5mZDx8suwVZR620QUw2zvIRJfdfvNJUg10jl210laqWOI TpCUp4o393gCjyaI5XacUaU1BlCHDkJIiYROccINTgzoBNVdG3YYDUpoNfTbaYy5s54kKap4DXF3 jaJVKhfKqCH/Khw+VdYnQVVkmjNuEXhPhjE8OBOLMKHklpb7ZLNXi7ulIgiGyjSiCmUUdYlIljNO WAohpzkH1JfzUNLImMhgx9WZ/qSpJlpIwVQNnOVhV6WPJ0L55YNh7snnlS8CGmiWi6zC5i7mvPlJ othUaeUox0EaqWM/poalIKu8NxaK9B1yjiXNgSOMcpJM1+UrbWliyi+t0IkKaoGlGJ0isMY6K62a WbRdapyS2uqvaWoTLK/axPXUr6y6eg1FQHrF4UCeaRNSLc/quhAq3FY7iajDOqLttlnWGMy3QKq2 k1vuaQIiA7IwKJK1+ABc676D3sKmU5iV0sgy2J1Ti7yC+apX/3Q4AoxJbvQtUrDBzf6a6TWbfuVN q9WaYi1lE1MM5IgI+surxgL/FaNAs8lYrXIkXwnlyQ4/zHE9Esdo58v80iYMrwg5ZaB2hAbj1y74 7nIzwEZrlmiOMyL0M0ttmafyIwqv5TJ7B2oK5SsIFXnP1VgrubUw/Hpd21rs5jY22SQfghraaUct bNsweYxz1uaCSii/wUm3IcR7J/Xx2bm2pylldDbd6KqgNHnEdtFCOclOxnAXmKbctihd3p8CW3W2 2zjIGkWgt4iSxyGR9c0mjoToM0qUsA7VN/zs8je9cNLWyCqho0QT6Z7tHtjnoqk+SN6Iuo4v7B1y y+Q9tZ/N+f/skoAe3O24U1ZOoKf7fv7qvVLleoGUc6788s3fHmPu6/N9umiNC178MIUdzohvLsnz HPPOF4z0GQMS2gBL76p3EvglZnh+MmCj6NU5BRoPSiV5lCoo4rkuqekY+zNeRXoXInUBj06tcFTE 2nQMsJRqhCTMnyRSeA4DrpB6rnChdGAIJ2WsjIY1DCGezIcJDtluhyjcD98e0cIP3o1X7RqanihF qhDeaoE75NR6xrcK4uDvSt8ikgPJIh9w/MJ95rrbSthEwM9xTGod42BfNpIN85GtP7jzFxubhYkQ wUkXa+FVOIb3RusIiz7IA4VfTofGzxBnjS0xl67giMjr2UL/flRUgSMV4hU9rmKSZ/wEMSonrzK+ jWbzMQwU/UMUynBEcWlp2ng8GUOqDE2UuSLld4yonZHssGnWCZjRaAktr8wtMV5DCyKYhKi9AbMi EDFMbIjpyrchJJnKrIh2mlkd+fhOl9KcWS+teU06fSZfEXHMKeGxiA91AjLyMlrAXPnE5/kra3uS 0ISAKB5MlCAVWHSJyHzyqp/IAp8HhUv5dEkqj5HOaAEVKBWLErCDqiOhyyAgQ0SRTcPIBSqO0Sf4 7FbR/d0Ko84h0oQQU9A9IZSaDRHpSEtnFn9lKKUqXV7ATBqfUYRin7RxCh/PJMijDOyebxTNdJLh SfK4Ahii/4QTiN7pU0F6Zp9OVOqt3Ki7gTnGp0Bs11NuSomQFgmYzhtOV716VPCF1Uhjpes/zipB 94GFqjNTaKJAoVVSQhV6xgArMg6bu3XAwAgpcIELQEcBGBSAB0a4wAUMcMKmru9EbSRopwZRVYXK xSjfeoUqGcuybPbRitvwW1MhuJcGTrBUo6hGaZ8RH7QAxnyHhd46NhO+0K1Rd87JgBGMMFPc5pa0 RmnrlwziWxAZqatsGu5rcwVV551iNjrQgBEkoAAF1LOyCogBBdaLhEhkAAEWuEAEkACRFERABwtQ ACNZyK1dzIYri3CUEQkDV0JcICvd1UQE/AKRgNVzF9a50v/NREIUVJ2IgKfsryNkoKmccKgodyyw DROsAARMQAUUqKvVvkmmCVN4MBtRrhEwnNU2/Vc/H3bL0KRSxGz4x6vKKKOK64MSECbFLzCogShg AIPPdaLJwqABDVCSgfcaYL5+SwESdGAAGGygSplaBeMMuh3bbOuSv72ZARZQZQQgoMj4oO84t+GX 9S4AHxGAAfoKkGQNRNS/jllShsWzYeYxYgP0QvO/KgJClCwXBidYAJthUYMaTBQTm7pNlzcAAAD8 WQfrPUKnBS3K4pA5GUDKEJp3Miw2LdKng3Pq8qJG1N2gogCZuAXoYBACDFDABCYQyTUycAQEfKC9 ZBnCZyD/UKVB1TgSSLDsESQgiALUQAMa0IEoCDCBI/A6BPHigA7ajACoyoAGQ6ANBIzg7SZvZ70G cES0hV3eAlg721I5AbcnkAEYlCrMz0aCDGSQCQYYYd030PMoKGAAAIwACblWpSaWOwl+N8LXvw4C B2pnYiQIXNgUUO66jXADqRihBhxg+KijXQAGkLcAWsUKJJx4PrLFy6u1DrN+qKM2cUxvQ7i21eci wWtfA1vYRyC2sZEdCmWLhNlgeUh/WT7tal8729vu9rfDPe73lttf5043h9bd7qHDW956Jk69762D fO+73/9+SMAHXvCDk1zhn1D5wyPuc4ovwuJHwLgJNM7x/wl4XAYgF/lyS66Ck6e84QCIActdrgCY +wwYNCeTWG6+qeA+ZOe36bksf86AoANGTTxgsgJqsN5ReF2QMdLzItIrMqm7pdMAsGwB9Fv5AGBb B+zmAbejrfp4BeC6mhjCEGAgKx4owAi5r3SAeUBsSOC9vL3HtxEUsO951z7DX8oBEoZQWwaUF/pN 3skMQo6ETmeNTbJY7va5nZPVs54GAQiwmyeQA/EPIRIUoAPnB32CYGmNkAEeFwO513LY12wGNXOv JnSYFy+dB2e4AHrFIkjBhQuX5T9D14FHIH2fMG4n8GoqAANbVl5F4WxuoXyYYG/Opx/UZx4fsADs 5gjgZv80xwd/PsV8tcADJwAA+KBklIUJwccDGIABlQcD2IZZJSZpRlAALBB3Ujcd6XdP5gdB5bR+ FDB+QwBQGhgM24cANpgT0qdr1Bdp/TdvPJCCCnACQRgJSqYmHqcMRqAmGFBqusJXsqKFDrh5GJU7 nveDU5QVoJNgk1ADpleHywOC2HYM2sZcm3CCRpABCtAaV6UcpqB8unSJbEJsprAAQ5ODMRIAvYFZ 3dVkDxGCwGBpn4NijTAE8RYJSagmmwADFiBpSNByo3GBWSUe6bcT5nclv7J+XjgxF+NzukJfjiCC faRcCzABhqdwd7gIleZvPDCHPNCF7RUDBqBkBZCHz6D/S4l0D78yNqxxM9rhc8azDnx3IIxAVE2k AikQXjrQf0aUAwVAAyGIbTPwGdq2FZrAjx9QAwpAJBqiif2HZimAhKrVCNoWioHhb8MSADXQdXcI Vfy4itrmCDqQGxsRcuIXgJBQXhhQA/WoAR+QAybxAS1HHAmpiQfyAcGIEvoFCcpnCtgob0xiHh7F CTpwj5iQA5SmZPiQfyWQAT2BWd+oAEGpAyUHfDCwflXGkjGgbSkgkzOJSKoFQUEUGNgCj/G4ge5I NrzFId01geGlAcCQJSegAHp2df+YjeO2FR9AAw3gb0cQAv4mGgqZAxFAA0GZAtOGkkH5iDxgAwZw AqnH/2Q1MCwxcJFVJg4wgJcwsACHwJds2QPK9QsZkANHIJiWJAGGqZI5YACKuZiXOIX9JZMXIACV iZeioJk50AM9ABVIEAAiuWB+gyecgG2nqZgnsA6VpgEzoAHHl3RGcAKaBZufsQA1EAKEoAEs+QFG kJtJ95nKMJhayUWg4CRxUiyQyTLsWHDNMReEEo/3slYH80ETsWVKuRUpQAPU1gj6ZTE8QA1ZNQCC 2ZHZeJLXBkEugACMyWRMxivpqZ5IMJ8SgASHoIRs6QCdaS5PFA/HBgADSqCoh1v6GQMLIAALOp8G oQAawJiYkJuCmQMgggrpSRkBEAAfgKFvVpZXtwuLKf9pIDpa1vCQ3rGd+akccGUPteEkp9dbaxIP a+MJZfkVhHKIC7GkUuSex2AIO/oTo/ArB4VDNCRJ+sJImLYSUeOkpEIacfQdWjilW1FSnwInWcpE VvQs3UM1KNOkwwAUUFoxnOIULECliWClkRABASgSQNonTgGnegSIDCEMYkoqd/oKaSMMG7FU53Aw g6EqMrcTHjWJ1OEfWFoLsqIXE1I0RJol8gEVaCFKG0EokbopjXoXxaJJmaqo5UAyJcAtWfqpalQM feiHt4Elp/qoZiGprIImYpGn4LARnzSrJAOobXeruBqqEjOqpNqWvwqsq5pbB+Oo+zAMZjSpP/FH JyH/c1i4o9CAHKSaJSWgn5PUNMcAp7YSGKegrdtqFqyaTYV4efJyRdZQYefKCfpJHA5WDM+ihZsh Nr86r/RKCqd0pm5jrPc0RH26Qv2arugCsCAhFUTqPBtTrfMqrKzSP9hkGpBqTMCTQrrQOw5bG/pA PZlWN4O6MO/gUewjnnTSDiNrp/szESh7qVhoC7d1pf7RpjgXCzXBNySRI6UWNSSrsjkrRcwjrsGw sjmyKS6LKzD7DkUrFjRrFCLbU4zatCHLEMH6tZyxC8WVr2vhs1wDtMj6EF4VCzIbQRI0Ho7atUur smd6JQP7Cz2rCCwLtMVhtVsat3J7tDUrtl5bsmBr/7Z7i7aJpGub8CmBK7gqJKgDpbWegLRJe7Nk +wuHi0OR+lwwJXNcA7UQ0kevJj8U+4OUgkLL866YVrNuAbofoiVnqoWEIkWdoA/lk7pYSg1NUrm+ 8Dm24rmfC1wf4ql5y0Kvelamgrq+KxLAG7yacQnEW7xay7UsUaeiq4U5kbTcKki4IHN627j9cbp/ a46T23yEVgw/eb2LhHmzZhp1ujAM4AAVUHNDF6XEoQ/XsLZCs77Oo0uZ+rrQkgk6AAMAAL48gAMW oKLTMTHBQUWe8FgGsBE5oA/pFrkPs74fxq6Wa8AHPHOFRL9eG8FNyw+bK3Eo3CDzgQtmuru8ewQL 8P+ReiM20luxW9kizwILxgQDJtADEUCEKyyPauIADakvHCOD/vW8qHvD0PSv7QGtfWHAAUsBF6AD KNADptECLYADNpADCjAdkmayD7MbmAAANYAENXyP+kBsqDMfvyvFq9auIhywGFHED7VDPKTC7aBK x1ADGDACHuABEJSNN1isjkAB+eqpYJEDNnwMdbMP23G1qKICLpAD7FYDy1WgeAmoKfaLhxiuR9AC KYAC+jIh02NQD+ICvKMC+nYSkzxCESgv2vG/EoUJNMAPN+AKIzACnHCHkaBvBMB8h1ypigwAmBCU GXwIJQbHiCHJxdG/ldy6qYrLucwLvfPHZiVhKTT/D0UsSzpgkCiQBEkQyEqJxo4gAKz8vJ+jA4Sw iyHgK8IGQ4SKKgzwA3CoAjVQZSaqigwgAIertH3ioPPMAwZgABOwjRgQYNlJctrWCUmgz3BIhPp2 J/V8P20ImguwiwXQR/kKLAZ3A0mLFhT9CcRsBDxEKTlxAGsMyTogwyUWb5cDAAPAAxeQAeiqduUM hHLYz/r2vqfhYPqgxx8yvhLTp3QCyLknCeZsG0oJLA0QAezsCBCwARvAAAYwCK6IgEiQAQbZjQVl FF0EFwd1Ao9QZWfFbocg0HSy1AODDBlgfsKwXOJHAwWA1gzw1coVfRINAnB4AtUIy9Y5ZWpRAgpw /9Ummnc5gIBgXQM7F9JqolxvTSeAjdYojdZGQAMnJWGNwHqNjYBgUo3UcwIDMF+UvRHknASAjVmV lgGLWW6RHdK4sK9wXVuvpA6DMBsia0vSycdbdGCHxABTnc5HAAHIfQJdVgAH0GTKNwS3AHHtwUet ogm5iio+/TmadVYnQAHFTUtda1aUgQQ1cACLZNPmodcQhxVK1gngRg+w7ALd3QANIDYRUADJndDW fWzKFro9LNlH8NW7rYeEQgBxsZgnIN8UEIG1BxtHQH6sYp13kSOAmRszptpGEQIleAIet1kJfhaF RNtpezHhPTAorNuguiiHeNBqUguYEpE7JAwLjv8J2JbVlkWTbcg8WRIBEdFTp+AXByK+Z+XK7xzR QOjdMkAJMHnbxYCAFFAAEQAnymwebL3QJeF8Z4UCU5sNy5kl9B0ReUaiG+BmtdoJ7WXL43G98DAA E5CZMKmC22EBJyIAnTycMeSVmDIIzB0YGbC7aIGN+NNe1zBjkaBfP16rRsBkOkDnJxAavSPZI77k DxnXwO0NCjIaalMCwmw1YTOH1uANCSAfTfgBGYAWNXBsrScMEXDY98Q8mNPEP0AZ0ucYNpDUlGGz 3YwEXXgEATBfplCNPPDRKxlMDS3RD0GT1yDoPNABHUAV6IVtbiZIZ47dtBbSMpADC2AAwhwD5RX/ AhMNARvEAwBgAyqtMqqhDva2xh5HAfc0XxRgBKEGCcocCQZQJRiworFugIERGjZGCpeO65QO3JDi S6glEpveRJ0OGNsa6ncx6qVekKhOAf6y6l3T6tUs5J0Q6z8tL7VuKgSvqsCg6xDX60jw608h7Cpa Eh9Q7DyQBMeul8rO7M4OAySqAdE+3gbF703MA9ee7dve7d8e7uNe7tZhEPuQ7h6n6+2u6/DOyPL+ CfVOCPduFPlugTq/82Dy8bYUrj/4uCPyJ0bA4iEQAp5yfPciEEeQAD6FbZ1gAKbeheu1XgFABJ+S AAkgBEF28XP7A6Dzoo4w7ow54i7RsQCh64w8//eGf508IAQwcAMrKY3aHgIvIC8j8AM2YAOcLAzE NpCG7XxeckqawHqGj1V+5LzXPgHablUhUPku8gmAHzRrIxBNJvrr3QlEwPQe1wiNj3ioP2Mx8AJK uPo/gMhGEAACkAFCWMVXAg+CPyJNskEXOHPzEESqCgMvEAKC3NCHUAMnEAAZ0Hb+AgNDQAFviYTI 7WeQpQJ8doNdOAPmuF6h/uMoQSSegAOr1/3J2QNwKP3Tb7e1iwuAYGSUNMST0LHD85GTs5ABw3N0 xFOCo6BQ8/GRodPDcwIDU3ikAIMBoaGjo8LDUwBjlEIhycOg8tEaeVRSElnLwKAZM/xxS5nbev9y BBzzMZmL+8EgiatLKX2rGYnowNOYQRxSg9HC+nkSwNkzaavdKtnLDhz8QZx9jLzMEClNT1xcrYQG CjXeAauBThUxHgaGwDih4AOGFy8glIilooA7WjFKxDiCRFWreipYddTkjBYQhJI+7nrXz18zY61K PIsETJiKZc0UAaOF68iHXsCyqRpy5ISBhh8/GJkIQVVJHidT0pp6xCUvmDnr2Qt4E2ewGDuZRZs2 SZtQotnUTurYtN5IsiarSppUklVWeDD7CZvpzmYuffymKfpXrGZYsWR5xqAnjZquob/ovXuriIcA DRqGkrwVA5quIyVTXo7XL+0/c5TC6mPQGDb/5MhC+RGd55Zq6GrNSngtHTrzXdK3nt1Fbdhrs8St kTEuKxslWrWUcefenav3Z68jR+d1dppf5MPLpzYfPEne3K/HXOcsi1I6LWu52qH05Y6CsFZ0hVZT dFde+bwkzz7kAVSTLwa9t0x8mqD1jnP2BaWIO4fx1587VhHH2nG+ADOSVwjGc5M+xZgYH4QR1tcW hRZeSFVJ/lVjVV4dEtgKiAeW1h566Y2nHDaKOadPbJDxwAKEd9U3IZDO9URSWqKlV9p/S/qXHDG2 5CLYYPPEdh+SSoZVlHzdZRdNlJmtSSVNo/2YnIhbtuYebDs1qE2SV95UVFvJPRlNY2dSyKGV/7RQ k2UzRQ2ZTyslTfMXNmDl896dwexTgooKstOipikNw5+MKPnmC4d6hTZfXpDWI+mkCwYj46U1qWgc p/LNByCooe6kCamlCpjVZY6qsCqr7dTUpVjFxCoNJWgZF6EtfuKqSVbB9ecfqW1ihepNj/qn6LHn 5UjlNGOFa45N873WGE+YqutfS7ammJZvHHnWmFe9EPpdbY+lR5q5xkqrmHHz2Okusnd9SkuTEHr2 1lC+5dtRhb8Wx5thAZuIrsIGMxPrY5TAK5S8tVT5YL3VUoXvnfXsWypxzuDy7zvENhjunOrWVy6e 1eo83ILtHslLSy6h16mUyAwz8U48ZJBBd//bBiWUxhtDtox58F4Gss+4FL2Xa6TduiaGvKhJI7/G LKzxzV05o/PWz8GnDdhh+zht2WZHqTShMk9mWCRuoyQJ0PMFvvEzuEj79ZLKYtss2Oh552DgyMhl MQ+q0OidjA2XeLOU0hqzsy45tdvPyOvWOrZ0ls8FTdpTSuL55zY/mxnjBS/4G6Kqr/5m0s7BaKGG wd/JDugP58hj6YiH3p3ucnPseeSlWxNg5YsRX83mUtNeey3KA3Vy86uf7jKIktOXveuLYZ558Z0H /Tzui/NIJ+/DpP97rcHTOzzMFY9zwwmf5RK3Jumtq20qqlYAHMGDG1BggoqrFFDetScdwOD/Knkj EpR6ArVeUY1Dw1mGcaD3M4LJzSewAor1DlUivLjPg9pgVYjONr8SMnBJP9Oa4/xyorS8a2erk2HK hpeVQGnIM8fT4aFQ2ENWkMyEcFrYRwJwgQx8oAcTFEIFR3cnkRVNahqEh3lSNoQhmMAEW0xAQS4U woq5hTjDwV3VqPGRPjXuJv3Ii9EwKBxqmDFE47nGjGAnlI7si2q1K9yhUpPIrN2jdH30Y1aGKCVB DrJClrOXhkCVyEVeppF2pI1XJLnHBmnsX1WKBA1o8AEIhGI+KDhBBijgxxoggQEUEAIvWMCCAtSg BkdoADwQgAAYUCACkaEAEnrgiQL4AAP4//rAK6kSohyq8lCsdMuxrvcgaVFDGl8rQZJcErZe8OqI lFFQNTGTTfDVcTyXnMY9sla3+YRTnFUrpzlhIy++rDNOvcDPxJoBz43QsXCpiUQ31fLNu1wqPYq4 UzaOQAMkGAECw9TFIE5gBAqEYicwQIIBlmkCgWggAAqICg0iYQSoKcAIQziBYaI2sgKsqRlIQILF agg+S9EGPzu5KD7bw8c+6XOIwWAfXvgkpTHuNG1pApAlt4mfE13UPkgdyTw855OR8aKprOOB08Rn sTHypic/pREJVamxirYObqQz3YNoZFG5cIABRvjAMNVlBE6OdCcy2OUHUqqKBungpUeIaf8GjAAA AFggMhnoaQlSUAA+LmdQG/EcPXIykqJi7qjgrCTbytmgPWVqOEO1GzTYusSg1O6zaRMtqhSouJhU r6mqCwYMd/Es2kxifRWCLSFlK9S7hrZ1tyWdRMmZHRllgwQMQMIHNrCB1pzAq1CTkQx8QoMSDLNB PKBAKzKwFCTIAAAGEN8RoMaDFIDzmtmqULUseSnexmiu+EylV/kpRImRd1OOWhLuXBvPUdnXVAzV 73632kpKfvVOPumVTcg6mAInb0nEtVh94/NW2kZXZnSt24VRgqr+gIYEWROJTRCAn6VISwaXjAAP /roMBcwiBjqYlQMysDGoxWJnnqEv/O7/syyBodihtm2uf4UI4Meglh4mW22AIORaJoonOD9Vlc+6 1RjQiMW5FA2n56Q85U99xFlX5jCRccgPLnd5cEvOSlHFTFp1NRVVyyLODWiQAgYoYAYzEIBNjCAB GoBUxiqoAA3MO4QImCAUnDGCAnTQAR5oYCkUMEILagCD0DUWGmsxTVoo46Bv4QmbQrkz4Qz3SKW6 UMCwORoykAe9y5WaohVapCa8TN5uaXWrsBaPrO1La1vfmna4I7XEwHPqgsZH1aDl850h7LGmLlFw NxhAoAdd6NZUYNLKyFoIlHkEGcjABK1QBQA+oIMHTOIGEvQBAw5QgJIkAGoGAOrwsmnf/0t5toYE zEYeabK1koERUY2zzKHYDL7puPXf8SPn6BiaOeGARh8IfyRdd9vUE4/GF1Z+lMQBRPEBCtxS2ibg 2A5uqJbHUwXd/jahBSBuchdOBeeehbrZrTkdvDve8673vfOtgn2j19//ju3KGVpVjQvjqHT6kSR3 2/DcDPdZqtbQ9gB+14uTV34v5zhYfvTx9IWcvFeCuMnHifKm/yfsnpV5IDcuLpz4TNc8WkaEVogT sManaL4t0clolwBVwPg/FM+Mr28RKxTNvVA4IXnQDGJJ+xK+8NHyHAobf7lj/HpZZdk7qfvu9+E6 DvMUHvyJHccpZi8P9I5fJORLb3oA/f8t9Qbxmi5QdQ+H549PCLMW0y68j3HGnjg/8Y/eIuR8ZOvF hG8LCvCDTyHJPYMZ7RqGIl8zGU5ZNHRIJlJfCGkOR87G+oJzB4aJuP3ie//7IFrY8oFdQySKJ3aJ caTvg9V+izNCaLFnkxGAYmF5YQE3ZDEz3tdbKbEyRSF7HDEYz1Zm+DB6/hds/CA495R8v0NqtYYx oAI2hQceX8VsHMFluxYhX1MhRkWANMNnB1h5qqeAPIEx3EF4VnGCthBxFHgZEIMfCZKBVLSBtXGA qSdRqVUttYJ3vnUZAAM3FuJ9AiYsyOCDAWM/4mMlQShtALGETAgelJNHYzhyChcmuiH/YP7DJBbV bIuDhDGEagBhFQIzI054SlA4cvywatnRG12yeofHfDzkXtVQK73ygnVohyszSvWQWkvIW4aoC2KW IzEDMLHzWiS4FaNhcZ4naq3AAvY1IM7xIKaDccJBhpVYVnxUPJq4iQwna6L2DKH4IvQRIvVHfXMX M6ARHB8Ie5iYiWKFHp2Ia80Wihlni7doOgIjNY3YixpmLsA4iU2YfCWUTfoFLlYoLJ34gwtzThbC WrHTQvrgd2dCOXDzJjy0ONjIKryQLAGGDSnIWt84IJLBSeMYjaLRiD+Tji5UC4yXSNrYggLXZt5o Fj5ij3eFPPmoN7TDj2alfmu1ixsB/32pclvQhiGqQyLsgA3FqC64wAIiEg8Uxn91N2Coco6bAjB4 0S1Q+Bah4Y4EwpEdyWzwApLtaDPUghKeNWCsNo1qUZFXcZHQoom7QCL/CGDE8pFIEpK9ITirt5ML eZLY0zoKIpW+BUpkeDQrGVp5tGaK84e7YBX/FI/MxgLzcU66Qhq4cmqklFooWUCOeIk8pAIuAVD4 8Yc2YS+7kCQEGTBniZa1NhgkeWp9FpHOAJfgI5eWmBZ1yRPQ0o56uZdkmYV/iZZpmZPr8oLIk4vB 8lsbt3MRqTgZxosPt4zFUIaTc3wvcRoTdWUMsDOZ4oCZ2YLFUJl22JBmtZjng5qn6P8Lx6eXrema Wig5silna1lmv5aFSqY0vgAcpvlcjulgL1k0rwhcwkWctDBWuvKUD6ecVwkeAKmb6BREBDglH3If D1c49FAcvAUUYYke5pQyV0YfIWlDT9koOxmGBkIh6Ek1FcmePyOJrKKN8ABM8xkwV9iUVnJWWfVr /qcjhPILWjcaAdqTqrGGp2Gfz5KguLKgtFmbQURF/Al9/0g15Vk45zmT/wkwXdGehoihUqUL8omd xFKfwmCIDeqgUlmO/TmT7GNXdDhgGFqgfLmh9HmjbIWfIYqihIGK8kChzwWG2HgYGTqjR0qfHnqf yJlh+gmhZ0JRDjc2ltKTEnpP6sn/UMaAYb9ZTgOSKc0SIJ+IbIPZdqMHnt/jnCNEUWmqDRgWMW16 Gm9ajW+nTy/CpYUJeeoXiaXiKCNkibAigCXaE+4Yn7IyiXIqijZDYW1pmMzoYXk6iRBJjgbimZMI WmiKJ+25ZhgoYFsBD58FNqFTUGcTGbigo40pqqPqUFRJLI7aor+mqsNFSNU5o28qDepCLGgxq+FU Gw2qOKzAcilaqlfGohWagbUmrL1GrK8aTsiqrFySMrbqrBVlVtGafFnJbNWQqIcZL6NkVIwJK6nJ JVwimZeRJLUQq8/SC1tRM6MHlKXBmYtoGj/ZdtEpnf9RUApTUHdxr7A5gXzRC48R/yf3NCwiGoPt eo6o2iAHi7D0Gpy60LAOmzhGeQz96q/OeXuQODOM6JD3haKW8aQkhj1vYlZ81rHIQqkzeinAVJD7 ukj8+R3OOaZkuqgT6asjVxI2myAeu7DcygCAOYgv4WtAuzYFtq4x2IztM7NIa7MBwbRNK6hP27P7 ykkh0ncQmQ1Eq4sA0xZjwzZOuiKXp7F4gROMl7Bgs5H3ijTVOK+FZCP8siGRYSAZtocF6zh6oV8J q5FvoreXyrei57eo135sw5AKUri8FjSIm7geK5NH0Limuof7YjlBSyVNeEeDG7dsOX2C+7QRy5iB pJJCVLeUcbcxSTWZcoyMlHyKm/8ySUK6NhOE5sICEZuYSoOqXlW3ZMu5I4S7gdShCSsfvrs2JwQ4 wuu6ZcWiXAmnDaK8YmUTt/u0tAi6fHGLniu9PooVpzu817uH9mQatOGwxZtJmLswqsplils0TUiW Uxcw4LEVogtcNmKK7yq4NoGu5DOzJTSl94u/8WKg/kCtwipt05ApwOJIxXFq5mLAsQu7v9VqKQEb 84oM35sS/wTB/audokfBFZy+9oTBPrEMRVO85DK98HuWMSuWpvZbuml6+CsY4EsMLvEokfC/5CIm jHPBbiG4NxyzvtGEVHkVUxgQDcwmwNUM6DTEUsszYlIaS1jDSzy/M/rEeyJDULf/tFwyv5kCG3I5 xESMD4Fzvhdcw8J7w37DCzczfbrXujgMMzA0chDFW4o7JEFhrKD0vLy7E2rcd3icx3AzvFn7ElGq jnWLLM7xw4R8Lt6xu6SYyLojOPZEH47cxwAzykGZOQMmyM2ByZnMbO+AyK+6yGjRyMsATH1crHhs DSD8yH4TyVT5x0EBWvgwwplUyN1ioyQLDZ2sOxuTvgCyx03sYXs6yagsyJdMxKzcyqyZzAFME8wc yrRcynzxn5Z4yoE8PD98zdhso268zdwsW7Kcy7S8yzFzx/ZUjanxtM04o1dIzmoKs9V8apHQl94X cfscIpMATATDzMesviqqzZqZ/7kCeLODrBZpicXHzLvgIb2306GIQstgatBsibR9GhiWHNDmW2tC nKzsXCG0sNGJw9Csm7uW+C2rC1EbPDmwy5hgyL0UVwJta05NiVAdDb2EzMLiCs9wF8M4bYvVqsAv mso10SJ8KSIpgdGXg8mtVNOcCMxMHcpn+CbLMoVRTQlALZ/EIHssvRFHXa4/YdOmw9Rx6r4qmEck PCAIcAIDaxw0VrO+2bRlnZ4JTdD968qeUS2/RDCq9sLDsNTRV6xjHIUsSV6XgNcoQHItItApLcRk 5cRO7Az/JCA1bRW6EcOHdBqmy8FJ25MJO1xtAbIpLXuEbNiHvdFvt9h2addcQ/9WelFcH30JCgAC IKALG5AJYH0ESFGz59ccKexwY8UdNIUECPDbZOsWRx3MpIEfACDPrTAC8RnONFuX/AARCkDcli2s XXHNyjG+s+phLHwLp9rIeZS7hjLK0owX4R19RHQMYvqmhpzF1K0W1u1wvC2X+Vw2DaMJfbl+yyDd GAAAOIADg1EDDHAC1vUBoUgBOoAUs5YguAKR/3YuKgADABDdl4ABtZYDCnAECHECJ1BQXBQMaRRo XfFuJpIBOeAAFZAEUQgDBXACOWBjpKqOFpADrrpdBQbiytGr8ZjSIirMOZLgBwNiTdVTbNkgIRSK 1TjJSOUtXxfikOGDtSai2Qr/5VFefVO4h32xjimyRUWQEhD+DOLV4gsQCk8bATWg3Y5jAJAAAMRU IicSQLyoAijwAUVQEi+QSCk+TC1+5DzQAxEgFOqWAr+w50lQeAygAzieApY9MkggUi4A5HprjR9g AyPDPibw6HeeCzCwCnsOA0lALEiwACqA45FCkkRyH9ZBTstwAgtA56heMJiuA9JwryWUFrVUApW1 LoDOyb/xWaJiD7degbkO5r5VeCK9EOssZTdAVo8kXkYQDKHQLCowC46DABkQAgBQUsq36QoAYz47 nqGBAjegARJYa0bg58chFJCuG2xkVuceApe+CN5eAiFhCjkwAPtQEiSjCC7g/1QfAAM00AAREAET 1AusrgPnju6tgAQ5kOktkAIpQAyVVUbqQgMXcATz3hnl6gGg3le8TgAEEPHGNBRHMGmbM+4l5fE6 cOzuTvI8Dx4Uxt68iCFMHu3D8b0Kku37ILFo7sdx1hHrTE43kBZ3sWbiVTiCcKwqIADGvgmZVV3z gQQFEALubgC+sRUG5xQ3oAP2Xg95zZmCQQTiQQNRvw8F4J48sABVZhM6QAEOnvA/PX0L8wMgbA1G 0Go7YWhDgfOskhUevxMFoBExgAAGMAF+jwEmn0VGwPYdgQIokAQ/0OIFMQkxX2UYdWnDfqwHoEs7 v/f14O77kFgw4TSdrZuO7/99YV7VyPOOiWT3LOQiARUhoCLl0qDdexkWfs4AyETsDND11thvy0AB g5sBNaAAnm4EiOwVfQUDwMoTcI/0k9AAkUDxdV8Z3U9lBU8LPtUKOcBQCd+Xxs4DIFButoBTCLCS htYKEECHjL0IywIINTUMMRQfKkdHBSWJPEgZRzwxMTwoKEkgJydGH0clmo08ooxHEBAfHwwsBYmt SJExrwwqSEiiPJGNJbc8hx+TR6gxh4iEw4etjLeNkzwMz6ipnSWdkbyivx/O0KkhCp4lSUnWJ0gX RycuLicfDREZSBGtiQaURzAq2o41B0gURte2/QJ4rBWDEwTKXTiXiJE7ePH/Cmh7BkOatiNDkPCz JQrAgAcwTuRIJYrBvEQfECY0p80FryMZbkHYxuCXKCTVBNU0hAwGuCMcew0LESJJCITscGki1WBZ KQg1UxUw2WoISltHGAwYoM9pQGiURA0zmA0VoobWbmUTiKomrhKkAq59FpWBN3DiyJlDp47dw3gn 6+HCp09jv39fa8YgiMogUnMMPR35G3Eig4pRcWXceMsjSJEknZ0MplJhy5cxRc2ka9NRzkEfeCLy CReo2qFFjya8uDRRU1GJTNWdOs9qMKxauV4LxQvsrbGJFEc7K/na3KjS3sbFdVESpVkqGPT6gEGB eUvWjMDQccSIphM8Gsig/2BAXqsNCCoegIFExc3CMMgV3gJGhPCLPYm4YIF6OuhAlWTzJRIBDJTg B0MBB0QTiT8FAHcEAEgkgJgzLLDAA3WNfGDBgjDMwoMmFDQgHwWiwKCABvghYIwjj/hDQVY4HcLA jw1N0N0k5s3CwIKNGeHeCTHiwgMjSZbUIXWQKBKBLSCGyJ2HAu4oFC7RHSNkMsEA550z4WHT2DJq SplNCSq0qQ155nkYQySkRBcMA3SepAECGcRQQA39oeJPAFuO2It4AxpgxBGT7BmdPnRRpQyZQn0w aAYFdNhLeLskYumUBv0JKIqRHIjLLJ3YYEQHHcjQiI0aDKqjTbVQ8Ep0/v8YQUECNLQiQw4LSCqU eUX9AEENFYXHAACyUhoJBTbeqEEwoSLaayKM2iLssJ10xRxJ4bVGqaVZdUUXWnDO2WYvowJKJnPB TEJnnfqYtQuZnbyU1Z8lPDiPJNXkow0FARDBg6PSKAlMpfM01pamaXGnL79qHVJqMMy9qmrBo3mX sDbDwMXpo6lIXIOv7KL0T4gPHjuBpPlOEsIIP3xQAyfEfBywAtlqUMSfh/r6KzPVHJEPwh+rVZPE E8esYcvwLnPgvqi4qcLH1UnZjCjz4uIfmLxUYxK9J+ZS8UVO5zN2yNKEN7Yk99aU1jybih1W2Waj nfbA45HtNkpdJyJ3WCv/syykoTAYgeCl1py0KSxjlx234G4Srs9Z9wYDt9OuNs6y3WNPHlXlaMKZ +TPLnN2KWhpjejZw4nG+zNol7d1KY3EfqM+5Udl9G1nLnXvRXLfjrjvuGfN+EvCLd72yRY9jE7Nb Tp2r8TBsCpx7yLunRZWHiLdSPfrYFC/mL2R1dW/atbPZfFZgxoX5LXVSE7hTAaNGJ9b2OdEdbHSL Q5816pYZsdxLBacyC59mt78Tfc1/TuteAAe4QMM1LUVkWlxYZveomqRLHyNU3J7GU6cJ5sI7f/sa 3G6HEj5Rw3NkQ8QH2aa40h3sdNhxoPog2CpkoKoRFayTDP93i1IBB36e/+jf7uxlKj6VDxWBsh4p oEO6ZoDtRAwkxHPYBcEnGjFqGoviBXcHthX+a2Ciy+IoWgEdEU6JU/mAhrTCQjEVcocYVqycMNT4 L9x9zI1vNAkWW6iPLVLPVV/Mo5CewUcyllF0iLijlNK4r6+xkRe7OFJDNAUcKZKvFzh80Fs8Abwe psxDBWvL44TRDJQozBqZ1KQoSdaQUn5xcOebCBJJIUD1Ce+NsZSl3Q5Uy2DkA5e5DOUm98TLQjoN jcBs1TaGycpWyu0D1kymCSnJTID5ApfWUNkun9FLs73xjt2RHyLeWKfxpQUuwmQb6FAlTWOObXjO YGA0KlWNE93tEDZQgP+TOCEn/rXTafaMgAkCoANDiEabbZujJ+jlyn9KqS5CouUkClpGr1mxO2xr mzXnFTL/EdChcwzlDEuXuICOMyoEDUVJR2VDjqZUpaUcHzwb6lB6svSeLsXoPhnRz45iQ01TC6lI SXpQFSR0ofF06EbNFtGJVlSYSk1nL2daqadGAqQnrBR0DNqxTPbzqYZbqT1Bmc+uRHOjietiWGoa VWlNVaeMO+Nb5blViF5jsLbTpuLQljEcWjAXymhlF+X3MAr0FTsjlRO/WoUCG7jACAAAAL0Q4AIE 8AAGKZCABBRQAwRswFceEgANOFBRGmXlpRn9yXiMuZbmQGOcU9VswMz/0kSOYnQWRfxfKPCF29xG 1pu99W3d0gq+BT5zVKD0qbsyeREagjOlwvgaIjKggyxlgIrWWo4ip2QAA7hgGspIYZ3uhosIUCCP r8oAebNxqvmKggSiDUZo6eXeDRQitRI4FHkpYNk3UmCFNCLTerMIjviGcL6Mawi/xIM/oQyjv3tN 3Hfl9wvxblXChwzZwBqpQ93iTXEQZByZ6ESS6GgPipEoqYhHfJv+zdNDsAPvHz2mggvoQAMZYLAO PIkS66wYnAtxySpLUBDwQPC7ZLpvQHHRIA1I4oZFDM8RAkA72r33EPhAhAJO+zBP4sKiD0Plk0kG S0+MxcpX/ti+tvxC/30V9EzWE/IfTdxYJqcpm9Gg85SpPEAlpkzP/uFen8HcKjF3JdDLC9o+zfa0 URg3K21aQCMYfF8jpOAVBwiAk3iQAQsc4RusvsUJjlADHcCAGsfgwcvKe7dEEMkZuNDvtgRmFpOQ WX7STEetAzSYn3WChkMwQQrmA2bctphPawE1hsE0Ow6bDmBiBqGnhwdqDs/u2eyT0g0JWMANZhs8 vXYbsKWkYlsGM7twA4+5WxW84n4adhfIQBF6wGBcGOEGVkl1g3igAwR41kkwiDACMAABW6cAhkao wQygRSFzJUAZ3AMT8EoSnhoc2tO9mHjFmd0eFDC0wzyIdgp6oN6n8v/uVWvSdozJXZsts2/kSvqd v/MKuwPi/NvOs3nlcldLeOd6xmcNdIqaxiaqINust923ceHa1KzzgAY1gAAMYFAsFVQAODyJBKIe JoQPMPtQuRgCCw4UIFBHAHzA8QFexUMDsJsqr85kABAu3ouCh5IVWWkA7CZVEXTfJBEF8ME1gpjR V829us+YL7nH6m065vVMoWhk4aJT9N85/l4BuwV2Cmj5y18E3tZLRgnpTanYBz70os83XVBfDXCe TZpARlGNDJ4EHgjrTcy2rNtREYBcDkE8SBogA5Aw0u8inmW1AMi6JDE7aY0dCQYwfC/InAgatHBS iq0TBZLMLQy8JIj/ucT5SLO+c7C1KuSmokR/3+X7cZMbuUbnNIeTergTDdqQS7dlMrcVY690btCw DM0ADDnGTr73ezwUHcKHQrE0bsHHAcXSCg/mCQEya8twax9wXsvnKTWgQ88nQJxwW0bAgINXAOWB DSrQd9pXfagnZjAgA0EyCkdmcjpAA0NQhEaQJfADF+v3CqLgfvjULl2DDCADKNmQdbPgZz90CLSn g/ZmEjGwgbokYaySL9VBQtgGhVHYYs+Aa9J3hViIe/6RC9UHN2fyhQ84VAbBKsw0ERzIKQxAAjSA BAqwAa9lDylAATYwOzQwbR+ABDLwASYgCBoQAAfwMjSgCooiAwBg/wCbwICoFSqsQDZqAguAdyJe aBmjUAOTSGsU0HcwkAEGwAyhwyk2NBEGKIUDdHmMk3nxplO0hzBwY4qnOG//EowAODuTMz/YFlC3 qIaYODa82Iv8Q2/AGIxihne503VscjCT8DQhFw0fRQJAoQANwjo0MD8hUAEywGpIwACRqIofcAAK YFu58wEy4AAZcALR2D3t03kYpVmwIhAd81HHuFwUlDHN0YyyIx69xQK82D0L5G2cAlDEEJAhN3rb eBLsQ0KTt3paKGGdwgMOCW/82D6/GHv10mnfaIysQja22DHd8YfjWI4eco6zk47rCA/uKInxOI9H Z4/4qI9uWJItc/+S8RIe3riSBNmSs3hKJaGQztOQD6lAJsk6PDQqSPmSA3lWY7iRTskN0wFkITmS /pVuj3KSFJmVT7mVXKmRo3KAKJc2BdkIRiAB56iMaeGQzYiQa1IwLpI80LRJsABA6dJpFpg2qcCU K4NEzKGX0xF/YhEWftk86RaHruMhFekLJzIKhdQ+Xdk4jHkLJbJ6kBmZU5J5lMmRluk3mFmYXXOY cjmGh/CFTwMX+KR6Y4gRFWACozM/4LR6GVUu4ORFmcKQlFYSRUcmlDByMZAPEAQXtXmbuDkawBOM B5RMB8hdwUBlkpkpvVBMoVB6yiln3uGctKkNtuk/JDcaIHNojNn/KnABf0W0ncTpneBEdci5hcvJ DOZ5nlMines5PVcWGra5XQhYQ43lNqHkkcjQCc1gEyVAljJkf9Mob+BoKuYZDdmoniSXSaaHL4ez oLfYoJQyJlNCltTwRiQUhxYKN904m23RRBxqZQNYbzM2Hh6pQw46JhFKFxMaOrj0i6NHKf0Zo/8p P+AxgDAanZ2JNem2WLS4d2BJOpT1aKiZUrMTnx8kOtZoFiMVndbBTvPjISx6LwuKHT0kP8cQny4i P1mqN9MTjGC0pI3UpO8ypjAWpTI1pQqjpuDkl20Kkae5paKDR2ZxZWAql2tjelf2l7bpW+dzkAqj pzRxoZPKC5TQ/6O7J6glYTZTR4deOgyO2pk0cThu8zQGuQtgWUqB1pcjmTucOj6gA3jTIaq3ozKq d6eSiqoKipyWCo7PcaLeCZHWwGHUMaSPaauc2ZGLij9OMwy/p041UgDmwVogWidRGgHUwBqNcanA YaWb+l0ktIECWKh+yGnQuqzmwgBDEGAJWqacsq2rR6UQCK71KK66kBnlunnA9qwf+Z88pKu+k0Gh iU98Cqy4YK/1SKHkSh3k1q/+Gq1wdVtuozeI2hXABwM1UK01UCwJS3qLqa2VmjiLYy1e9Kpf84X4 KYoCeGsq2i5xA625V4KgFSftQQFTAZobBZbdBT97UlaamrIqq/+acXgWLwuzFzuzryKm9MYu5gZL qhpEwfOz2xehKDq0qumpD0U5ESt6AXtzFvulTbQ3g8BOHlsDFXAENIABGKB9R2ABFyCymUKyB5IW j9YW/mEuyUBjTkMBaFsBbxRwJ2ABGPaRfcMDPWAEB/FCpxVxMCABvdlL3NqzK/Qcf5qYhYM+0PlM 1PGyYQutvzewYpoLH2Sd4DCynAY/lluggapA0PlsfANkCSO2R+QUTMsNF+tvoqAB7wIQuiYBNxAB C0UmFlAfW/UMApABkwI0JJap0wGrmruBGQB2qvUvRrAAsFi8BpC7miQKPZAVLpAxLOcDWnejPEuv aeO8QhIQDeH/l921tbflpcTgtUB2c93ztGbKFs/mrTwqQIADtW4RN1sLltyLq7jDO7grs7rLA7zL Tr5bA8ArvKuWCMUrD/+CvMrbHgjLo88LmFrKatQrAdaLvQagvQXMC9/LAOHLC+NbvpI7r/zLweub PGz6voVFevLLMd0rYfaLPvgre3zKvxDqv9ALwN1ltPVbq5oJsFNUrNihMLeaFqZmAzawAPARCRJQ dzbWCAJwvPGgA4JIAH2KATkgCK/UCz5wdrSzt+KRJaq1UZMCDQiAAL5guNZAAD0gBBlAxnL6MHqn dS8stTH8SsRgHTMWn0BqTQQclqiiXgGcPE8LxNwQQq36aFiJ/5iHvG+yt7QGCMWc2VhgCQ10IrON lCampg4GYD2sMEJP28WnSxgfoAAIoDB7XMbk+IX45AMpYJytpDIqEH4+0Uux2DIrMspLTAoIkMe1 3KoVhXMHubN9+mwaUjX4VE+8XA2PWrTtxB2iPKCdxgjr2kAJaw+RDMR9mqYOui4FWk/fqSGny6JI zM3drMBzNDyhXBNsWMiNbHxWaA/fwMrLwxAqkwJ9ymnKW8brkam7oAASkLLA10v5gC3msVG2QMwW kM+huzeKK0YGJzmvMjxwo6rRHDjLWS6ZKglKRGVN5cuwe2IldJ9mErrvR0lNS87Lk7+wEnv+sZ+t sQvN6dBYt/8Lz1SuhdQy+FwWUTxFsHOHX1qbkYBk6EdJMQADbNuxNBCjGYAA9YEEA53TG9AKkQMA tWXJhdwvsHQiC9CEGNAQd/kMcywWLSADTp0WYW0MMbAAABAJjTc+wLOg/DJyVTpiSsQ2IS3UetuZ TP2l6ImQtwUMm6ShfyR7iWmA4iYWWHTJl3ajnXbWyMk9ij1HM82QYGkm2XgEGqADUa0YMBACGEAB JsCbqQATczwBv1ICRLh+RjATiRAganoLF4Kt/WKNE5ABqx0CDREE7TPH0SADj7ih1jB2insgBgAA I4AEe31u5vvXwVil2jPYZt19NOTSLTNQx1DaM90aMHlv2W3/gBOJqXv100LWCNjqFEU9ueU9tkp9 VtxQfbXJvuSUMXdidfNTAhGnAwoANxpbazPwI2v622dzn8ZI28xGJjQQABSV1bvSiEOgmQZ8wJMA D6FVESXUZLrQMpNa2QkL04PdzvMTkFBLkDj12aS6tGNBP7HtntiW09tdryr+4Pfph97aS/q936S8 w0srz7RkFqV83s2ZFZl148b1XToOHBqbAQueM8anAPCtsq1kQYhnKSVQAxTlIES+xPvMySXm5AF+ b9u5DQXNDF+4J61xINjK5QeDrdZyuki+h98MyopRDIQQ4FPHHSLN3sxAZaLz3nVu5/KN52BuRmV+ qX2TgH/S/ypzKNMz3eTGgB0CjhJR20CyiEIpU2Jys8Ywdn03qiqWfgxJrdSaHgOr1+lSzq2c8qCW jWs/Peehs1may82rzuqgnemADusaijiEPrLBuJyrS+o09UC8nuptseqHGuzctg3aI+ObdMDIwKDn Yzo6Hk+X1ho/ba5yFjf3s1FDfu3HnO1Zt+0j2u0IOeVFdGmVxEj9Mg8rnr/67SbYzlwmFL8G2O3Z ziaGnrnaIxb2fu8wNt+pnp8eNr93NLC+7mHKeuYeDujg6JDvmavR3FyWLRTctcapq7ekG9sP/5cW n3WaDqwaL28cX+xw9fHhhVEA1W9UWenjMVKOqmKUdBZB1P/yLu/mferxCAPyHeRT5k7yAENAOr/z yzHxe+j0wg7w2tDyY+rmAf+PMt/k8T3y/Cg6TF/xKU8XK289Vh8ymQfzPwU+M0/Yo6jDTWnySb7z ft7kaCiSqsQcqAnzgW30cNUdSf/1OC88mUftcVJPiW6rSz5FgNQu4sFLcPJRHX8u+YfwOvrjuaBE cYggOWRp2ZDT1N7uLTQ1owDvYKLjqoQN22f5cVTzg12iK4P4AzXZn8z4SuT4p2mGUKXdAt8YqdNC rU9vmp+wjSP7n+/ih7uoYqYYokr3S9fzZfL4fQI8K/Ttcg9mUJPmW4P0SlQuktCsy3/8870d/VwM sP7JCHr/Kt8eTDcENbimQ1+IkcFzaLCe+SYBFiaO/gdMCKN//rXxO4BwdBRzxMOgovKh+MFQ+FGi WBjz+BGjIlhZwvPBUyiI+HHEGdPI06nSyFDJyHBoWiJoauiJeqS6aKvyKhjb2WopeMtZAjtIWGj6 ucjoKGsaEwMJvMm52XkK2ila+pmKe6jLU4wczAAsPFx87Kys2NgsC01ceWlNfX2Uzct8miqc+2pc sl+IbC0SN25dsnb8qsWLRi9WNU6e8iXSxq+fwUgAxfEyVUojMk7ghn30pcrSpW0Ie2nTlm9ZRmeV TCmyedMaL0QrC4UUaQ3cxWILW0XcxqAluaUxF7VCJqsm/86pNmEW/Bgy37tmJXeRMwptJSOlS2E2 dQc1agyq93Tu7DlLllaJILMR9UXrHc5cusaNNHp1U1JiH3vFAoXWWbJJmxjjhGT1Kq+stRyFaoXI o0tWH1ZSG0zU5WGnPxffXPUY8ltek/N+jATO699bnscSC82UR6LEigdxWjWRklnJwWLNtXw5s19b xplhItSV8GyeK0m1rIpJUInMn5HNEzVx7XNNN1e3bv6ukq3omzFfhQa62T7t4Zx6D3WwcadM5Cla ZM2cJ6w8x9dNd7FCnSDW3SafKLxsh9NPkIBnEzT7RdPWJz0FKGB60BSomUHckGJReYek04s7QmGi CkIssP9gjoLamXJJYo9ocg0lk8Sy1j3miWgcibtpc6JmUSEoFiPpwHjMIDPWaCOOI0kTCg89+vjf ZPwM8tSQuRiYIivgsJhOCUzK+CR4pSgi5SbS7GglVRpq+VQnQh70ZYiqcLPJSrvlScxLgq3oCGjE tFiWbsisGRA8jt1zmoYr7Wlcn00FM5SggwYmGEIlIFpWPSA1Q1hVVgb3228W9URpjp1deuIwgooZ mG23IbpQIaKuiaI90ATXVig8BTNgjpfslpysxCppk5815WnkZ+6R6alBxh1x6D56KaVWTqgmc9Ut RjUbU4+AboaktiiqUhi2W20Ti3RQoRZseZKJG9yxz7L/NxKtYrXYErsVuavtR9Id6RiqFIXr1ET6 7jvUsgC/Wq4vF0Wr4pjblGltRdmy2MvBFXqLUzVZijuxvuYWeZe0kjFLmMAev+scWd1Shee97uRb MYgH+kttwKEM/GnB8basSMIlLzxpw+TuJh7LdDqkEqzIYtyKxoLdCAuu19AYy7vclrzfI9REMqyI AFv5cLImpTitRKrEbHIyYIdtsEBTgWc2LgmK6BDbVg95YNa13kL31197JrbIe7N5trAMM/vMsX/G KnTSdhaUSNSEVwo0lxwLTMgrW1VWyMHCJSPV2X3Wgo54wHTu+duebNoTKetyVHrRO+klr5smaz5V Z4h4/6O5giqjFPHtKr53i9AK9n76VtzeOPyVkB6/UfKzd24xigbFKQrnl4cT4n6G18ZmzAo546f1 UYkyofN9L8P9RuS/ilhysnWoMeS47313O45i8DOhr0EOf/lrkXjKV6LLuCJ9atLaMtznElnE7yQ2 oV8CLYMjBr5jXOLhH2I6Ip0WeWth6sGckRzEl39Vo2v+eYnv8kehKikGZzvTWPRI1hToXEwgDhKK DD0SvUr5ziLpmUhaaBKcPaVNhQ5hIXSK9ELYpI0zSPTP7W6IiiZu4olHOpIUJ0VF7JQLWngRBk1K 5Au76W0gtVoE3URjiA3SZYcHFMfZElEQf+RnjDyhSP9SUscauRDqbDETmN00Vhl78JEmflQEIAPZ vTfqwxbXmKPF2Ne+jpEjj93QS+AmmQ5qXDJAbuwgHDn5le75RzxDSuILZUGQ6cmja4cEj0/8FEZM /GaHAlKYLopjFDzRspYU4daizAEMY0SDl72sEiQrc5BTkmOFnSmKLClCy5zgCjcgMUd1oDHN9cDE msDE5jB7U7YjdbM4srQTuG4CKlaOAiOnMNEho9VBc+IHndLzpSEOUUoeyQV7zvOjKoe2FQfuBxsm 6iTSbBGWga4lhUOzJma6waMr0U+HpHooRIllpRL202T/bNkYBQoeC90xOwcFpl5EOtKGVrIzJ0Wp Slf/GkfWeMOXS+ncekh6rcvkJKWTKJWm6pJQujTCIUsx20PPw65I5Mqo7JJLczL5jKbeJYMfPc5I ZlG3hdzvT8jEj1a1QTtr5Yp1+nvIjXKDS5u+ZhaisBtG1jq09VjrrXBtYWCZMzG7KeNK/2xXGSsk 00Ct84wakh8LXOfVA46FnokdGPgM8bXCyFMtG72NWvcESbHx4LJLXQgUW0Gk8WGnsBYC7cD82hbI esqrSgog6kxx2dw+9TNE8sZsaQuSu6XisYWFKA+AkAIYHKEGOoABDD5wAiPs4AZGOEHZLKADI6RA ApntrV73waSlsqaKSkIjJ01lFdiY5TUkWZsoxAoL/7lsjRF6RK85ArfeCKliUu+FL0NgCaAjuMAC JAHwKpxqN/PyQgAZWC+M/uvVfUSIYoiNCjtgpdwCq/dSnISudKlrXexql7veBQ94xUte10qYiRb+ L1U1vGH3JsXA7UAwgO4xLtbhFyqFckd/MZHeD2NCwBRbrocXgiwfs2bBDWbHg/Or3xkfgcI1xnCu lvwZDjtZks19L4EBZqGKUFgHNahBIVIQ3elWFwYqOMEJdrCD7n7NBhmAAAwkUABNYIW/PUEFDZbM gko09RQZXES4jMuDPnu2PK79CA1gQKQqSSIGRmCQoH1i5PiNgxOJXjSj5+XoM1MNH2cJrVlcYIOo kf80pS0JVNgILQgKM6AYnLAuDBadDw6mujVofkk7FkfsUKS5ExkQgAB0AO1YpEAbNWiWDY5ghBi0 2CYZuFGgA2smKf5OushgQbOdHW3PRBi7NlAAto0w1AzoYGD5gMA6rlUI6x4jRjmKgQE8PbRwi1sr LDgJk0SqbkdY915bhrYODMDqNreZ3Nc4gQGczQMXqAA6pev3XeehAwpYd+BbZkDBkeHr2gbbMKrc 0FAfGN8mIRSxOqyGDgSgmw9E+82+DgBgbOACI9yYBwiYpgRwpI1POUcQIacAUW7u7DWfOsIpQAHQ jQAAAAyVBzpgh242cO+lqCIFMbDuDLqeDB1koNP/hJGSuyhVyoN9qrbgqhQF7h5dcjPA2RmQ99pl Yd0ABKAGVfcEABRwcQEgQOPVTcEHFNBmBGy67SXgQNOju/SS7/pov0a4aC05c5rDw25GxQSBRdyJ eRsCT0eAgRFqAAOf38IG7QZYLDYQ8vESGVuJXjoMIkCBlzy872oPfrC9TgJLKiDrIzRF18lRA3lz IgOY5gESOgEDVVjXCEaANsQ7QYEMnCCUsT8CCQDwInfA4OIqcMEGNtCLUjuE+khAgvGBL3LXB8Pv GQj/tmEveBpwfrEAADBhAC6gcxSQAgxQAG1WYY1xV0dgAr+Xf2jBdKigKTVALyuXZZaEVaZyO0kU /xOq5mHVpivlcQTTVggBQCw28HhecwR8JnKStRBK10v5QAHWcwHQpgH9V3eVEgA8xSrj020voQAp xnUwUH/2ZwI7EAEMAAM7gE8XgA88QAAGUgInEAA6EAA3QHuqAADrJwAXAGvXFibVQAHVVX/GxwN3 J4RM14P9pwNX2Ak1oIVb2IW8AAADg4AqEHyqoADudg2McRtNCHxRuCfJoAE4ZAoaqF6BYRmrRHN7 cw0X8QmKIlg7Ngg8EABwNS4peA0saBAWkAgY5R0usAkwkAKwYGvu4g7SkYPa0Ynz8AEU0FeikgxB qAsqkHWZyAM1AHOCAG/TZ108MAQmcAQyAIXGE/8KC9A7POAAdgQLAWAEgmABFgCGm3cBJ/AU2PIK KpKG1DcEQ5AMbriLgpABzbeJ07UTAZAB2rCH2rCNilBdRyAB1pU6qVECJiBoiKgiJaABx4EjNQAJ zMAJBZFlu6hjdiIenlgNgJRsbhUAVCgIbvgBRnADQ3AEB7CF86YDCBBrskV0GAABpqB7kiUIMGII 0pEAWzGRfVcEPWCLJkUR1AWSQVeNNAcBHJEMRrAbFEeOR9AD0wUEiEAIF+AQJdADskAYndgJCIAA MAJvxYAA3eiNmkAKjQB7MDCOFJEACQAKkncEGRCTMikEPRAJMMCRW2iTwmgEMHB3iocBnSFdErD/ VEhXiCnQAwlQA0AAbzxwARdAljK5FcQAA1jJKzzVTKDAcFn1VgcGkTQ3ETxAAzRQA352XRdZASgQ aRSwAiuQgjWABCVUDQ1YbeIAAKaVdHvyIilQAD6AAW6WgpVpmTu5Y8ZjiTyQAqJJAeFyBKZJAQ2g WHSmCCfAC0hQCK8Zm76WAjRwEzBAAynAfRVwG8FXhwTJADlYcApQAPmjCf3xARHQLEhAET4Am1u5 EpfpZ9GpE/3nmSqwm9ogBCuAjw2oGw0wBACQH3h5G67pA9OVfR9Am5dJZ42wmShwAv3nDjihD4qy GyQ4W5AZWMwAW3KBBEYAASdRKT92TGvjUErx/2lHoJImWQAFQJKaQh4hQR3NFBPrxQABoAAQoAM0 0JMZoABGMAR2Vn9jGXwligGtZ10pMD5byX1GIA5GIHI84GtIwAIUEAETqAEBcDyC0h85egL2lwGW eAQkeV3aMmaKo6G3Yxa6oZFB9qGeBhMjCmVJYQRJkATZFXwzUUj4wFbwsmP6BRP3VDAVmgwXmqGG cTsc6guBw58zwgtq6pomWpIukaLIsKJ0eliMAKMySqOdYAQ2iqM6ipw+6KNAqopDun3cd6RJuqRN +qQwEKVTGjLUYKVYqqVcOqFPcadgCqih9REqUKZrw5+smKaz2g080KZviqSCARVzSgscYafwlP+n 4IIR/sACWMlqdFEpebpZiHOmDOIfnxJc/oGB3mhGIioUzXQKp2ULz0prl4p1AGAB2VWNGYCcQgo3 g/qdzpCFbymg1iUDn3KqPBCQWtEJSKcI6gqnm8SsLJIK5tqQ1GpsAzOjQWkQ8xoQhJGtJsdanph0 3/oiXUEOmQEyJhcoDXkSjVCKhRIMsACyezWt61WK0MSU9AoLHBFui3AMqFAlgdKon0IdscVWxLp5 y7ZXxjZfPIVRTIl0HoGsZiIDNGACNdCvNJuPIdQIOMuxxTGy3dGzttogCztdFOCcwXAlRWu0AXdh SdMNQ+NHNyu1x8QcoCA3tkAYJ7soMdGswVD/cDoBEwWJb3m6svvpsg0yd5Mws91qs6OyWu5xUl5i p3Vrt9qBCxUxpns7Q0WbXyaDLUjwpLLJRP/6oaUAI2xLtf6BFiaXtYxrtu1ygsvyCooxuav5X4Gr iRAbEp07siKrpRT6IvKRdNshsi8BUebKojNSQ3nrTzO0Q6vriopmsdhStK/yKRpbC1P7Uua6uN6I gtFqGYMaEKp7va6YZr/qrVFxCVJrMs87K+VKHgt7vixHXwNBvNqrE82LvL+queCrHc77Dmobvb7L asTwvNUkq9tqq26nX7daXzkBtpNLEReGTpV1sXuxWrKrEaqauB7mMZllvTm3eklJr8jRCQfX/ySq urxVAsERfIO2C4INjEcE3GDty5Tbm7ELzESHBLBmC8HH0a12anIRWln58FeGZLIfpkaKtQ+za1XF G2VmUmo74q8zsjeHkg35o7Ym8rYW7BbWWz5KBbZMiSyhYCaKxhGCC0X/WhIHSb774MObaMFeZL3M +LCTtB24QAxJPDRhNL8ZIr66EUxR7B9Xu1XPa7YLvHmtRbosp7f7psE2dDUi6sFlmwyQAAkh52s5 mBlQ/MfQIbE3Rospe6vQQahytMUdDE0fohUUUZAFycWyq5AiG1gp5bZ841V4q8m6snEiiXSpk8jg CsNhRMqUAMcQfDyqHFIlSyFFgSjHRA3QAf/Ar+wWgXoY5mLAjqsJSXQo8QukbXYEgdh1d6eKzakA oBBkPOwIyJzMuVvF9KYbpNnCnXRQ5aF0BOW9ONIfYlxIn4i/LbStmLzM0YrH6HxL0YyC7fxAILxT pFwSyTSu4Uy3PJbBF4YOSjWmyaCKl6YIl3WDyKF2nwY/ZLR6YaF9vnbNkNcZthgL1QcSi8DQ0JYB C3BUywoTwkDRX9YWrWgKiEfSphABMiADimYJDLAA/IVRvwIXYHsLDH0LFODQiVQUy/DSP2bALI2L zpASO+0UlwBNHJaPuGTSWSMT48NBZVPADVPNH10DNCpyO2ACFIABGGBySWEBAhAByGkTaYj/0azz 1M2iaDRLZwWhAL8i0oVgnaxzEAwQASGnAwug0keABENAbkgQiBzFCCPK1KkUC2htBAIgqjzg1kgg AxGg04ZtAGOSNJOgbr0R2MlEA+wiMyGT2YrwhCqZYPcQonRNRjzF0aF2X6I92gtV2qShVEjt1esM 1tblZoE41m0YhWed1mvNA2391iMh15oCQTtE21Kd15ew15PQ121oZYE92Glo2IKQ2Ivd2MUgLpCd SFj4EpRt2UaK2W+92Z29AJ9dEKFNMXzkylotoKh9WN6x2uGp3K9tIMsa3QdEOzSLa17MKduNT8Jg FKJEZCl1kDumO2FtnmNdizVQAT1AA2k9/xYnYAEX8NYtgBPz1l0AgJZV4hnfqQm08wzZh1A+wNcY nuE08LKD+Cs8oIxWwgA5aeI5ydgEWQLWJXILun3VjCULcWi60XeFQIWakNPotHbjh1C/INqsUQwV UACuB4xk7ANjjdoafmhGcAGi8OEh3gI5nRQqUOI9MJQ+kisoHi+py+IQPuVAvSE1jgw3joFZedSO eyHRgIFb0wlD8AESgI6FYJkScAMRwH2MUAIGYAEG4N7PIQDYdqNLKdvicCM5twqDUAMfNZfQkOiK ji1EFtolkOOMwN5CKdI5oACRRn1KCAM+4OhprQB8OQQB2ekIlgwLsOSartk5nTQXyWk9QP/VUc1h JQBnFWDrCSAPiIABa4coi87oRuDry80LOI3mJbB2ly6T93UZAv4qmm42UKNs8EHVXpzsu6doujso zTQ0CrFpB5VM7HIDHwCvC2AKNL4sj70BNoAAbi0DPDLYjO2rNkQTcfUBGmBJKmAD0EQDd/7gtKaM t0CeXCwEgpADptB3GYAC/Ufra80AGJAAiaTEh3CnRmAABsMDNy0DUKMDjE0Axj4pQP0gFVABQPAC CkDyFpI1DCDlXBwBEVDpPABxNkDe5R3zCjDzPZDxp5ILfArNCa9oMWU8P+2B2rF7tIbfSoItZivd jIHfLXKY8Pp9IveaYo6UjFCVCSYKBY//RaaQA7K5Q2DhfBzhAqpgACInGVjWLWf+ezFfHkKQARiw 8Vyndt1HAbQ+FrqZYFKRJxfwfU/VAlq99AhwWCmR9cqr84SXAPTSCjnALO9WDDhnA2bRAu5w+Wye 8ff1SdpERnb/DIGl+Zvv9yMD3KMvMn017+CQFIugAUYgAYGIABAdiHdnnQyQAQhQ5sgZC5y9AAow QaIw9xnULCyrAxoQ/MNvCwvA96iD5/MuAykw2MtQCGuHDNCmGTtGsd0Z2fXlh0YNmGN+BBYgC6l/ PNCgAAhQgEI1CZ0BCAxHRxISJUcfPDQ8MTE8PAwqEzwflUcUFI9HFzwIFhcRSEgtjww6/zwqg6pH lIkMryo8iJqsj7YfKgyNjx+OqrqVuIKDh4myjI6RDLyWtrXPlDEfJSq5lJQqGSUwMIMxrIe/iAwZ CAahqilIjjAbAJYfAKeDt8u5vbIaGhlGgwzGr14Re8aq1zRrxoTB6HckBqYFAEZEgCHogwIFBWDU 0KAqmq9INWjQMLBggSxzoUhV+xejHYBvvwAKLJSiAkYY0SrBOFEyAyUMNULyIJnhCEpRRyrqMOAS wA56+JJG+jCLVj1ULDU1imkr4EBnOaktuyashKyOmnrFoFYtIS6zZ6naOluRQYlhq2gMkWYEgpFK jKadrfdB2dZGMAfBKzzs0FxEjdgaa/+lwqziQQYiIqGI6GKBAhtXIaN6RAUFE0E46JhndAKSf7B0 xYCwdRU8gZ9TSMAoS23LEwQm+PyAAZMJHqqLzpVVl59fIzc6SlOlIpE0y7Uowc6FuGFiRLcbZ+8d ua3bymePOD6265E1TbGsziUt6BoqVqvAn23bnh5h7o484os/ctHylSbIuDcWfPLNl1RBxqSSHniJ DFJde4Px8o8w7Q1IIEGqrMcKYgo6U02DzDxoXyr4qQIYdWqhWBiHHaa3IYjqZTdigLksWJqBt5AH UHya+DieM/WVoqOLpPEnTYMzcnhLYv8sh1YrQkJCZJEoIjlekvlZUppagGUYpZTRrFL/pTNXVkim lo8l1WWR2Q1jIHgwNmIMWlECyAuVZQIZJGSunIgklFnCeeiczNW5pGJNXvhkhtpVwt2UXMWZ3YsG Kbqof1YmqeSdeI6p5561nHlpmpneOeibkcQ5FqiPiWrnhGKaOimfG/rJalKBpjdflpFsKedg4bAX ICqVVWgsIuBYUl+EpUKVnqSuVnrPZB6qABNl4HS0o3uVleAsm9DyYK6KK0IrWoW6BsjrP9sKaKC3 EFYTLn7I8NjsfmzKVcK605LrrrX7xTihhsIEYy91+IKrrrgJMvvvj3NZlhZMbMHFnF1nfaOul5VQ o9/EDZGm68gdVUfvK8vWVpq8loKT/yFk6lUzMJLYNWRzo+CZbEw4KVvoG8usuPyyLgLK7G1vuEio MdTfdFwrdiLv3GjJ+g7tjZjY9ozKjD0yjQzEvtQ88jHk5awzzxlfMyIxjcGHHq28qOiKuIeYq7Kp gp11VyUvS3O0YtUVKOHaFTKiHl5wlSa2g3bujV84fud5nSaDE86hbwPiovjiZjXu+F3EmIjdcpTo DYmdOfqt8oWBy9L50tKQCGl1tZBeOnuP1y0Lesf8XtBcqZSwUQDVAOACAqAOvHe7tfQtt9Ht7QkJ 2Rv6RhoqGOLCyily23efevDNGr3l7T6C+fWSBtj4hi9Xgth0SS+rtvG82JK8ierL2P/0JkM69L1o ZVhiBWyEsSHEfA98t5Aa/yZzn8i9xxYTHNIRFFCDAAwCBgqAHjS8tCIJ5UgHGPgb7Vj3Cu4FQ0/H iJpccPEICuyscUOS0LmExbaPHe8+tnNMrhI3qa60sH7eiyHvKIPB69knEhAannxA5Tr3XA5Cs+vU co4YtQY+KVVLpGETcdgVHUoxLb9jRgwqkzyMDMIIMLAMHDVSA5Kpq2vqKUEGFCCvJAzhBEYIkCgG EIESLMUIzJlSL+hRDfl9oAZIGMINeXABJHyAAnGshgJQgMgj/BGRIRuPP2YhtDw6ZkDV8NayiNGW ZRyLTN96WisOaYTffQYGH9gJAlL/wQ2NcARk3qDVg4aWCqoMrBaoVGWcqFEYuvxpkYx0JNTSGA2d /Y8uY5mMmyxlsg1mhBu15AEge6kRShhhCEfIwAnuUh9wbtBwRkjCDcY5jQxkIAeF1EEGLMm2Ea0r XxXhgQbOOZ8LwCAF4NQkChzwiHmC8hL3jEDehjmN+jCkb9MpViM/oM5NHDQF2zvGjv6JDUFgQp+i MAAvbrmQEKpgjtzo4N2qcguKVvQZfStBRlN5HexQI6QiZcQ/C5ILmgZqm9akYlvGaCNrDEIBPAAA AI4AyhPQYxA1MFcGZEADCqjTPUYAgBHGCgPDASAENzjnOmyBBPz4xJUo2l3leCAD//ddgx+ReGgI kkCJtNpiBiBEwgBsSBpRQOAiqECCES6CgBN0KigBCEAGGuFVnvCjH5CA414BYCVEFPWk+xRFGgHw GmtwspdBiQ9aoqU3agnMfhUqFoauqkAECRNxc2WqP1YiLKos1a7Xk8pZoAoCEIhzGTUA1QNsMYRF 8MAnkMCJLIww2UbcoAJJOOdejGGEAVziFGuyiphKUdRZDAG4HPWHdAcxAkok4ViYVEB3JcqDsQ4B CQhALANOcIKLbKCOjYDBA3YQWR1sFwlFySMrFsKPEUQHQvRQRgQiQAEdqBUulQCBP5bBSZEI+CkB ZN2xrgGmsewiKY00HC0csyE2tf+iI8pQTNyuF5Demsmu8JKKKzFAoRzEoo6QEgJzNwRdHnSDOQZQ C0OTMoTt2iIHlyidK1ukYheV9xHnxbEB1PsKWeTAAdjFGDcKcAJ8PoIbpM0vBtyTgyKxoBcJ+JgK DjwhsyzEAPd0wNfgJYwJ14K0I6sEDja8X9v4Fl0FKkUwqMUcFrz5i7ItU4i0A9c900IY/imT8XQ8 5VL1L9A26vIReBwMH/MAyOARMpaJbIsjJyXJjVgyA5pcRCjbUDuDsbSVb5XlQG85KRRx5ZfDHJ8x l5m+aMavAtaMijY3Gs5ypvMq7GwEPH9Z155lgJ8fAejSfWDQOrYqkzCWnkRvz2H/QEyKozuFYm9J OnWMEWnKUIXpVA2NxjUeNyJ+CmpaQLEGLyAFD2yQAwWooAb8XQA3jsNtYOkAMEfmARJMEusUoOAE 9lxHyfBJgYL8IygvkMUuEoMVQUSgBgCQgQxSYJaldAMAkGzrIByQAmepAAlxGQ8KelAEgCdCBc5O ZEuoEpCXtKRnBZm4Dq7tHcclTdsUvoAOdl4Es7SgBTgguAIikXCFm6AHw2tRupC0aCB+bDRSUeXm OsKYyTS9NiXft6HS+AsWIWwta6I7io9QAwyMYBAuyEEtqQocbhwDExFgAAxWc4oMhAAAMEBCDh7e C4tvfZ+IMZd3wRiUNXvngNk+/wKFKTDh4xgSAUWBPFIG0YKaV60ESNABDDCQA+/yYDVEJ04iPgBl aNUyl0R/BQVUYILF60CEC6bhEVrgjSpnmwE0kDoDbqABdY1gBB4IvBGgCBwCwIAGDaia2BFEsLKL L/jmyigsMq8yZsQCP6fic1HxnvfgQtE2DoQEjq1yf+kIi2IUIACJpwCMVwkFcADJNXn2EyDr1wgY AACbVws6EBT84nxPlzKvs38R1n8jkh46QAEPaHv2BB0TqADBwF8nEBQZ8GZw1ABEQAQBqAI0QIA6 IG5YJXk6sAAyFxjwEndPMhYYNhgc2IHiclXq4gqLVjPB92gMGAkkIiioEFSG0/+D8wcQGhhhdrcj 1QFUrTA/WegfRXgkipaEqpVNT8ICDUhmEXhmQSFv5kNUU/E62jQ/Q+gqoDKCkFcDSchfRpBcy/AB RgB+DZB4TogufEcBObBPBGEfRJULWxheCaQl+QEiPLRF3WMp/pYTPICGsoUuV9EiWKJEcciFBySJ ooENPwdc8zGEi/h/2YGGZCiGu8BOWwIkBvd+CLJK2SY67qGKzFCHUzR+jwCLwaAvy9EetChi/oGL uXhpK8GL8aE19fCFrZhrr0iManOMjkCLtXglzDgucXEPiROFa7OK1IgLa7GFAyM9ZTSJ7pJjvdU5 gKFDQTOLAdFl09B+r1NpDfH/YiNSHd4yMOrIju0YJqTRg+8ij8xSEPuGjPdICZnjH6JGZa2jhejI TOqyjpPBiu9oFWw3MN0DRPCgU9t4j384VEYkb7vwPWuEjumYCBo5F6yIjoTjPgSpJYvjIrclOJUS i1SxktvIiTojGKcYhaDoMN4AkFMIhOYik8aoby42aWdSjNDiCPigLkJpLpGDFu93lPDSCEpZkza5 kakkdg/kkQY0lef3k9GAlQHRLEjXO26YQA2hlIbDlBRULGZJkwPpMZRGiQBjjVLWQpYwjnPRU7AQ C25HDyD5NxQyGImjSrwojRpSH1diIdZoQITZJMFiOCAZKxTUEYMziaU4Nnw5/zR+yRiWCYal0ZU8 STjdMyadOQ3sBJqGqC7/QJpUaCnuNpDLwRh76W6xkpF+6RXjZzQIiT4BgZSGaQtB+ZC3WQphh0Vx YSl6MpyUuY9i1yJbyJpmsZnw0ZnP2WWaUguzwiJ0SSHCSSSUeY/H2ZrJCRfgKZsUNJ7kSSrSWRps x2e8KQ3Y6ZfaWZ3raZPFKRDvOY609Z3z2Zz2UgKceJ8Lk5/oiZTqeZ3RCKBesTBGczPKGZLDI55u CaERep5QkWPF6J/sWaAC4YpLlaClEJL0eZghCqH5IaH7WZ1Rg6I2aYmr6Uq9SaCMaKCUYiGuyZiq GQyy+RiIGRAdAJE8NDjT+f9u+tea0nChb7iit+WayNJ2SNqcn/eZ2USUjNli+nkEsScsPlqlGER3 GeofCkAd1piRXOpb6CZytAmdYjqmzuIi/LcfapqRnyYVLZKbvTkZbHor8LdhHKqgMCopPjOLDyoE OoWS/jOdWhMTVMqL/QZJK9pPMDFlbKKgZWcqjwqpChAClREZKoNzzDKdAlB9auJbVapp9sF4YCIL NgiqglMCEjADjXohpYqVWbkWf1OpZYo+NtIks4peRWIrsvqnE/MIGSAAGaADWNobtnEWD8aoZHpz 3DADihB5tKkPCSBki0kMzHSsyPohKSZG63FqbXWt2CpjRaigIVABQAAECHX/IQsBSIFEmwpwAoq5 mEggkLyDBBeQAEdQfck6M1UajdlRA6uBpWllg0dgATpwBCDFdwMDA77arcDqnLRpLrZ5JwLpW9Pm b8r6p8nib0lCmIXaRAowrdVKgTyQAiClEb9wFjvAkwOXARCAS6WxEynIAxW2F+oSFJgwFjNwAM8l AALQmNO5rlJxogawheVoZIdYC6KQACaQXHKyWuhTAwhgBDi7rx8ge0R7AjuwjR9wtQvyCKARR+yU tvfltXUUataZthOIADc7FxObJDtgBCeQHjYAtDAgAXMbRzXAAEfrWwyKD9IjDMoota2ZOth0oppK mYL6osWIie6zQdMqALaa/0sIRUe/YAPydVH85QLVelDDgwAIYAw+sTmUMHw1VAAzC7VRexdGhlBY lbdVGwwGIAAn4LrRKq0IAAEUYEmRhwQRYAIBkLFh66JLwRQH1Q0HR0F8JBgCYCi2oLtFsY7koArS 6zHDiwukuxoGwBQR64dVwgqFSwvVqrEFkE7awLwIFnkJU5+0iQ1bckAgOSGYm76i467v+jHB0ELU MKtDowO8W63WWgkIJQsBUCQ24AJhpQqyqyUfUHOlIbsb8AEI5h0aOXx/OAMPNwi9W1/Z20sX3BuE WQLFiwDPE7qIQLZJ4byiIAA0oBqJFIZmwQ/cALwqEACW0AguEBkl8L09Av+RlZBc6/hcYccB6Nt2 1CAAlgKIcTQLkTW8j/CmJ+a3GisLFLgBFDAVloScP2nC0sNb+SgmO9OVLBI5R9rAmjoxe7KZDGwQ UeM+5PMxMONqMQwsssBZmKFSU1Fzw6MCOuAQVCG5ZhEBOhMDp2AMGWsWjlUaQRFH9bAh5qLF7koP QOa4iicKSHAaOGHIvSE4aZw4gGjBjNAKNiC5ArBGlVw6YLszGeBbp5GafUx5o/wIXxwQvtANJzbC N5sIFAhe1cFPw0NhrXOVZoHLk9o/qcM7Zeoxd+zH7KkjD9lCTSNDSSt1+7C0upAC+IHEC3zIpHEB nFAYKoBLKqMRmSAgH2D/AiawAxSGExxlHxxhFgRAQVblMYT5CLc8mfQAVbKQxmUlMlg0K3JcYQQw VupAFdMbADdgAxwdGE0cNYrJC2+aR7f3vKexAwVqDBqgJ9UxeMR8wVIRAwoAecWrxS5wuEYmARbx phohz5YkJtIssoLxx9rEk1i7Yka0JiztNbWCj5u5lO6zABmgATeAzmaLcwcQAGNFOIPwDrIAz8cr sfScHnp4mPqcAjKASS9lABdsT1TNCg4QH0FxAMhKaRuS0I9kkxJQTjVQYRnADU1mAjXH1dYyCJjg ABb9IkYgWRZgAbZAXQJwAQJ7Ih+81zXAEKjw1+cl2MC8IVRd1RSA2Emb/9VaHQAtNNOQrcVhfQQH lUsa0Yd+Tc8Vktb1KT+4bD5U+CzcvJyw1UyhiyQrytunoo4ixgDQgU5ZjXvaQVU5hgAYAAE6MI4o wEllrRUl0wvVYAQIEAB6lAFF0AOs0APHzQ10jT4KtJwB6NwQAJO8agQocGoz0LiAPQSCTRYG2oMk OxU9GJpwlN6p9Ai64d6YPYq7egy83QM9QAFC0AMwCQOkPYExbW67NwzGwEk8EN8wAMuD4XZ6kn6G ct1C6KXmvY9edMBZ60P7uIBbfOLMcdxHkNwPt9x/kR7qHd2AMd19yOHXjcvazd329N3hPd4Onjrn 3ULp/dzsLQHuDd/yDf8DgQ1SE07hWwoLpcjfMODfhhLgnISFi7kzRV4JCK7gDK4uDl5g8Dsdw1IY MsYDFo7hGo4wIncd2B0fIM7lXW7gwu3AJy5c41DimytKLbRGSQFDap4JfPadsCy7Vy5U36Awcy5U SEoPRlABKDAICWbHvI0RNXDU7zq8gg4Mf3k8+/Y6bz5SjW7bt02sxXoiPkPSMuxFy5q8zYrdEb7c UTTq+l2Ka9HoV/noqtp+/93qdsylS83UzSrDBRF/EBsqupAKsqF4kWcAHXfoKY4qs2wMHT7nVxlc Y5UEfMiTfZ7shvPNTd3sg36JUo7rvD0YK4nP6YfLvT4hbQEilqHmHjH/7r/d1J+uC91D4W7CqBR6 7SLr4dgSXKlUIETO1R7Bm/nukRl475PZQwrs7MFAAzAgAztIKR6MlKHYCgGCyydTkazd3/dM5Pv4 J7E+NYIsPpdI2AjilBxfp1cJlsWUEKvw3waiMeSp4sRNRS3k7C1/KxKf6zhEQTPfNWUyOzgP7i+K 8uSs8uJi796DnUcS00DvMGhIW3VC9AVzmLsn6LgtUubhieAxLRaKQYAOMxRfJlkPikYEy0nivx5v RozYyOeKH1JPJlSf9oIOLIDR9m5P6nD/QyJbTamCzY181EUo9ddJ9VZCLhWh91ibwFWrL8CyDKij IwjC9aBCGh2C9Pko//bBPiDkUlSwpd8Nr2NRc/nug6j8N/id33QCgvRNKfrvJy+9Y/qnP/md/vP6 Ahu4uVqbbx5qvik/+fGWX+eJf/uUshLg4Z+jmMCWWVQsAf0QC4bGzCL8npH6JjJEL/UkJeeCrhb8 05q8Yx2rSf0GkZg43Kxqf+42qZOtvvEun48jQpu03gveJvqRLCDTLwiAwMDwEfMhqMLDU1JydJR4 JMgQo6ICGcOgyNh49NEY48hA+TFq6PhRMupYiDrZSFjC88Hj2CjKyXPpOKvCAEloeJiomcjTu9s7 SAp5M5Cio7D5KNjqO5rp+ak7e6RCWhpLnBgTw1oZKwtOS9m9/V2LrP8ciqgYvT1dmWy96NkYXkva y1S4cYsImUNnTR27Te54QcoHad6+frPu4SN1jZ+2Td1GGUNHjKDBfghnbRPVztixap0iCqunklvA RLIYDKGQooaCGjV0PTRYiROmicT61RDCzdu3cDyApDhwY9TNFCk+7NSxjRulaCpXCpTHbpi9QdSA ZXzk8x/ArjRjELN27m3WrVx9OiRZDCU9n4IIlR2qKW3WpAC1vXUbl2bJTVrrFr0LLm9YipDUzTwH CQaiEjwpAvtANxbgaP10IOUhyqNhHjCcFoBBCAYMnlZrYNVBQTYMCkaOZJBdI8MjXjpMdTq0uZ7o QUHPjaa10VFHYKv/jxSS9UtxwblBGRvjpiD8EdzHKb303Bc0ScDDKPebzvZRoVjXtcvapANJ90Yz ZZJMJc9em3wHGWYMaKZIZ7p8FpohGUHHg2nSwbdaaym8FttsNdR2W26y8eYbcMIdU5yBAQb2Vl/N eXQWRdugtlZ19WV3znYc7cefOuFBQ15EEtXzmXqmsNePe9IVxtQs8/2C0Cn3NZIfjv1BFo95geVI SymufHIgO+LpAkMKNCiwjiej0aSDAQt8QMERJZjnnC4UUFAAJx/AQB8MWyoQy5xhigmNATAUUIMB EUQwywfFccKlPLKItVyZ1l1yTTquNPKmYkuhYqcsC2QQQwMUvALL/wcSnCRlkTsqgFubDACqgBGa FBoBAy0cqkNQlC7CiKUtuTmPasRwCpdfiZKT2KF0YZllQH75+OiA7uSS2iyyFbBjP7mJCUN4QbmA gAARLMICCzrokMECCwjgZiKVCHsnniY5GYNu2PI5SptUqaDnETAMwoAAAijZZkfb0JDbEAC46JE8 EhQwim7k7jQnBdmU0K0BpkpgTAQyyNAmTeoKgDAMiPGgQAEpwGDEsr58F8OO3VDAGrcZNwKuAB98 DHIl6a5LA68sSKJRu+9+Yy80fVocg5i4JCIBuAgcEcGyAMPcy3QVTcafO7EE1ZG/symwyDa57WAC BRhgUIkRJ1ggLv8SvOpw3wIGUGROMabMuU9k9QIX3jln71CmAAALbFLVhBlgABJDsAzAizQh97Bu NcCwSHg10DDETbOkjYERAhhhRC9xyxABVuDYLQts1oQnW8tWe+0tN0PcifacoW9jAQ+1fkwJBTqo 2zivJQxiUlao6dLL5YDje5NsuY8y+ttwV03X1bR8TVh5j9rjEUJgE8JaKBL44IMmFNRQQQ80rE1J Bm9fEIHci1AwSCMnYHo8QwHxDak7wcUHNFlfBSrQmAvIzwIXuAA6ZFCJbsTgBCcAQA+MoIATBBAY lHgNbJBXgvNtrgc9oNkRetA/BWbAEPRDQgtARhEj/MIIidnQfWb/Zwh0SEACEexBDNjnvvfJqhG9 i8AHWtCCUAgvA26L3DXyBx03BUQozpvN+eTEk0LQIBYXOMcH6NcYliCPex1xS0Si1bUx4mIr3UhA DYbQjbVlgBFbXI48MmAACxjKfiXAnywwmLzlgaIRSEAC5hiBAWLYcBYYOAUPaLAxrajgU3nsS0gi SAojlBACLhDQ5OSBgfWcQgIYYGIGMlDHG7iLK3v8WJv6QcN8dYozylhHUAAmCw3skG1GQGVPHBWt Iu5MBvIQABNjNYp9IG8jqwSFG9+oy1A6oo6jiAAnFlCqakqyazm8pFYAZDBlksKMk8BkAjRwg1CM AptHGJMEYBAB/4GF4m7WEVcmZICE1CFBAQTQRf/esQkK+KACQHhBLM55A1WmwAYLSAQkrQEaFdyN ATZAAALIZx1MBi4iiUTRkELxgk1cQhYpYEQyPIGn/jGOG1NzxETGs88P9EAIKyRfDc6xwnXAYxQx MAJVbKCCE6BSAe881OjoUVFxfUwQ+vEEAfRRghxsCBsunaIKEhCNhfYjaKjwHScMEI5wfc0h+cBo K0RhRnVmBHlmjOg3yzOsRgzKB0ZoYCgEgAAbXI+P8CyOAhDAFLBNkQc+SAEQOvGBBOhANjxIgQs0 ZoDceEOi64KEBeDW1giqIDwImGkGOsqYRAmioDxJQQJI4VgD5P+AcSGj6wXUJDBu7PWFaIqpZxXD KibSTadde5orNPuBAtC1rmDVhDCB0dd9XjSZUa1BNpIENsUu1qeP/UBkZfMB1/JgXXnVq7giGhBL ZlaS4BSGJpBXrBsS4ozoaE9L7ogAC3ygfi9ZJoT+SYkpQnQ1b/nAAiSbQwYgwQAXqIYDF7PZvwLg ASs8T5YgAQQRhKcAkETeXyegrlfyYE4DvlELaRsL/iomQkwEmKTQCxL1Noode0nUcVKQugUo4DM8 MEIO7Ls9/KrgXBqQ4V/96yGUzYmLGbDoF40oD/6gmCYnWa9apcGScHQCJZB4hCeLkmTjMNcXLgKF YKMBkiTJJZv/oHErMvLxFvJWxCRXwrKkvKhMKFo5y1QSc5K+N4pulGmnYZ7yQqrsUuVsbUWZXBgU fZKXd8wkzHZ+VDb1jA9uprgWC8EEX1jyJDMaLBlsLhIx7oENgpjU0nbyMqUF4QrsJClLTcqzPX6C EevsYtP3aVEipkGNcZBj1KTuhGROnWpV++MR6QUNWvicEE3DZZktpgioJzUOzD0kK74OBaXvAtFV u7i/xsZSWZU0HGvgGNnbUHZNEtLsT0tCV7qOczuqDTZeOEvYw7aTprpdmfQke9birjVRmCeJXIv6 Ib32crznTW8rb9uL88hRWe9j7lv7u0gAF3i0R01tU0ty3pGp/zdcGP5qTIN7F/3OSnhlYcZbEKYi lm5xmteNWF0/sSWpKIa1ZTKTk3GiINv73jm6wSy2Jorf92k5UWhiiUnE3C0TgWK1DwFQVejcSYjG c5nf29txDH3law60YY6jdDtpXZwMAcXN89sPne/c1wJRxM+xnvWhk7zog4FHqdMiwZ+kBTrH+biu T9EryX1asIOtyS0U7gpYvH1AXSs1WpLCJV8/PlFRFscqxOIim3/ZM3pDR3QcmedUOByxNW/yOLg8 ecpzOiSX33s4zn6Xr7gC8XZ69K9Qnb/Sm57LjB+j503/aZOQRhsf9wvTy0ZtEx+8Hizwoj9WwyJv L2Yu5CtG8v9Iw+3DHB/5rrgaXWKvi+Z/HC1SNsvo5QIdCSKm5fUgfp/HjvyUGGJZsU9E8xND/vKT GvfTB771BYkM/VUUhMEfg+EZ51YUPAV40SEa8wdsDDE09fF4h+ccQoJ7cvF4YUNqjGEcNgcSjAJ4 gTcvyXB2U+QKERhmjNEkKuJwUjaA0wFoHNiBanQsCzhsAdYd4PcBQyMJH6iCisEcvYeBaKGBzQQP lid8XIdo9aACacV2SLgPsMAV85eDDKAJssACfuFI3NAPjEUK2XOEvkV9tfYi0dCE4LM98McIUggK HvF9VkgDNNAAWPgLiseF7pdnt+QLIZGEWrOEZuiEiAZ/bsL/hsVAhRxhhbNXLnW4C8rxhd0RhinX ZGQIiVymdVGkfp4GJE1oCdtDHwvIKZgyNA74DixAERGodY3oCLJhHC5jd2a0DRigABpwAg7ARAez KF+TDUQzL5e3hi1RAjxIirzAAlRRR6j4GJTBcCnQe6kAizeyXtsTWqDBJZ9gZXW4hqEYjCaGiKYY fsioilXnVs0oaxQHeQOih/nDZFaWiZ6oZNSIBGqUdrvWLolgBDeAQVpSSAPAAMLTD8cjc8NxAkbA ij+XK+TYcTyAAS5QA/cISI1gAovCHLv4gbkRAxY1kIrHEwFwLvG4CetiPxlQVak4HJ72hZoxer72 gaiRd+7Y/zWcSINSF4V2KEVaomjDsAgBl4wmCRo3l28qOWwtyQl6WGVM5gg7Ei+9cQQIMJB6kh41 4DgUMCIk0Xo1RjpJMAQDWQr7GAHCczf2p4DDwZSkMy8BAJU3gT8FmA6JwCcMIEM8sD+P0CYDYESg QTqlYxXQwDIwQEFMuYo1oAFmCZWlYAQEZki74QgZoAAo8JY8kJW9wQEUgARaZgBEKQhGaRLpUYYm F3p7eI2tlxbBqBqIKHhZOB+qWBQMx3hF+Xtt+CR6dn5MZgA74kF68ldN2S+D0GM3IRyC6Gg84AAO sA0lIEOklgNVwwAiuSAYUZJkaQoBsJtz8pNGuT1vGVpSef+co6IChRSPeWktMvSbwAGdPeYg+0MJ VKEnpLOYDkBDPHADA6kCMyCVWpZTDud7wucuTyKNL4mA+DkfvDKAx+MgqDJYmvIYzdGK4xiG6HYk TZaOKcYDszlhunEEt0mQufkB0dmbVvafsBCcw1mc23CcvKCc95aMzhkL0GkEaDmdlmIS1hkN2NmV oMGdg7BRLANVrDEb4xmi5qkC6HkE6okC7JkI79ky8imSXlSf+Xafnvhn++kL7DBGaehoijecAEOE 9Wegw4Ggb5c9nsmgMHISABiA4IYE26AAAAAAsnCbjImhH7BCnSgM2sEISZAEw3k7hrAIk0mi9VgQ pSALlYD/AihwjQEgSA8BaJLYCACAY6wBDUcwKhE1mZLAJyVwpqQQhRoSAAFQU8mpaAtDOjAQAknA qL1AQ5UgLwsiHLcUXuCGifaVhNUAdAHnUnS6hlfaMJpwF1aKCoDKksxkbGCYqM8oE+gAmylpJ2e6 DSAAAqOgABtQA4xJA9KiA5EXDrzKCCMwAmgxBJhghcQpE4sCC2WTCz83qLWmAgEgJKN3d49wA2HT hdtQKxE1BL7AJ3B5rXT0eDrgrZPJDbKxMCzDRCOQTqZ6O5KVPDu2rifneGOoidICkx+Hrbe6DUNj c7o6RWUDC+X6hegmClbDZcpAhLVkgdVAE5M5CwCAAzjg/6wPWxpmhAQgMbE5kAMOUAFJYADdaggF UAAnkAOQuljtUjYswgM8QUEngLIqQAGQxowLamVH4AAGswl6MgvWxJKRU6GJhAMWkAOawytIkABC UELCAzBIcEqCAgMAYEjjWrMscjuaQYlJYZnTxxEJ4ZLS0VZwMbHcV5OC4I3+QYhuR7R5iK6E8aDo N4lT9iulcJmJ0ANFUAMv0AIre5RGewILwIE1AAAysDJhhq2N4AApgAL7Y7Gy4QI/SwEXkItz+g2W e7mJo7kfw4yMyxSOULPMiBZIkBs8kJ26gAKPG7mTawNduxOZsAAwYAI9cChHYLERkiaUQKpQuQA6 cLsp0P8Lp6Qff8YDFwB03VemCqc8mzkYqMFyMjssUZgVzUuEG8i6XbEOtUaA3VeUqRm+u5ASD8EC G6sBNRBKHuABpsATbkMAk0cBEWAC1TCu57sPT3I89/ealmalcTI075s8c7K8QgEJ+YsLZpQDLYC7 6IAEQZsDAzCtNHEDGnAEGDACCazAKocpDCB+c4EJSJADWOHBVXG9jvIiBYYI3pvBG3t9eEFxyuMg XcPCmbDAV1oulsILw9lfvVAuOmwXPYzBMEyusXprSbEe/MEIMaADOoECdioQnjYYZZZ0w5Kvd7eN 4/QOvqaxoiFFtvRq8ArHiXiJREx+UfRbYHe+13p3bjL/itFYrLWqeFaBAAYAFianxcaBDF0cxGMM ISrYvZKAxn4setuYDNnACy3hdqXSCzm5DnPcvXW8D8TKPElxvxn8l4u5Cb1qjsozq8wZwX3DwAEX jfk1C2+sNzzAg7ZQGVJbxaaImZiiDJFshn3XXrPcdi9cCNmgFRDsdomgu0Ywwd37y0+iGjAMycMp espzzNw0p35sKcfTg5rcxLkczSpRzVhHZcEszPBLiA5BxSH2w2vZyi76yglhSdEszvchoMbyDrkc wepBzlQmz/N8HBpsz+1it7HagZ4Zfy8RFzV5iQFdj29RCcejF/4xzyFmxfjM0JITRYkB0UnSK/7c FxV9/84XzT1xvBB3gdAZrMHwvAjy3Gu458BBTJOpecwe2F5McdL3wYO6dmpOrBiOEMXmwdFNLL8w jLiYMoBP29Orx8/04HzMG3DOjMssXXPVPBxZs4GMm9NJuNNSfSTn9tP9LNSoaM6XedHd7NWAy9RV 7NQL/czc8G5F58hR7aIObca+EMHXCoPBaJqFYNFv7c8azQ5oh9epVhGlzNf4bIBmPAiBPSzT0Qmi OQ6ix9QDjdLVgnZUbG+QsNf5p59+bQuVbWdvogzkooWKhs4jlss6nF9Z8272UNo3YtvB9tiyxtdP YtZD+V6OJGasnQqE/doyYdQTDcqLDdO3Tdq5TXybyf+BlE3cJo3ZgKyFLdHZ5TfboC3P1KbXvm3a 3lzGqX3dQD3Ymm3YOBfbJK3YgSpvjT3apE3eur3IG8wljDB+xMzJj4waFFnJ/+iHUUzUxfoIqNCr mb2N5sHYo3x632pvaPGnZBxaEXutVmbcCcHWmrxMvbrggJzIof0rG2zfzMnNJe56lGCt4cxmfojV By5v/uwkre3VtZ3fp3fiPmhJjX0OXDLWFG4pUBrgxNZe92WIiU0WKbfSCWy38b3PPu5kS9xx/CPZ F563ccVmPj3bxncS0Cy4ny0KPY7QQC7bTnzaI83iC9cebsdpLwzQz4zOZPbd3aCZUr6LQd4PycCD D7f/h6F1bN7QfBuoZXOaeXnDFEu+yYdoy/tR1fnQ597wE/UrLaMw6BOYGGXjIoj+esa36NaW1eta 1Une52X158ohaTtofRyY6fXL6Z/mF4vugI0eWhEM6ZGgFKduGJ3i0+HDe/VwXgBhsaweF4VIbK/+ NbGufO+y2d2xat7Q61B0aP4U7IbQvKyeo5QhJExRZrq2yUnGU4XQHM8ubvqWP9PuT5IGw4T+H27X fupxZ+r36VuhhaFRu9Bu7uf+K8y02aiBCbig7958CqmOCSrQZhONFjXXHOMKC+onDhyUdOuKKSqn 34GKCSPVW0WygGLEkm3W0O0gHdGQwOqHGIUA6rTe/8qzJ3XyffEBX4YDj2kFfyUP/Xi+tvBz6vAb POvNvh/8nTz93sSXEPBDfCzkcM7dZAoi5XVilCky+AsxmIDmoOANr4CTAnVLLvEiKHZGjwndNC/8 8CAk+CaivSXvJdJupQiONB2GPQ4nX+8pvxF+MfZdz2yiZ42BkR5WSPZlH4M+Ae8gDiNPr2ugvt3d ofWMwvXLUWst8VwmoXWRQIKZXeJxJUZDI4OqUB7/LtVV3e2fwCRbgfITT7+Pn/fH/d+UT4I8KIO4 8F7njMVWenWn9wvZ0+xwn5qkX/pu0s2on/omGA2GHQqNm4Scn4kKCPqbva6Hv8E2lw/5E4pilh24 jv/0L/V8sOatl49RT/Z8SZLSD397n2/40DcfpZ/YmceZA+r7jCINLLb9r9f9rO8dn9/KIviJtxb5 Ag0pdcci6a/+0FK7/AUIDAwfMTyGMR9HioOIHx8qikclR4aVhB88go4fgzySk5SemJQxhQwqKgw8 m6GGoZSggoYMLDyQkYqrmIIqrpierZappavEkQyNqAyRk6Okpqm6jq2vsIuzLLW3kdKZp6KVuZWr ysSEwIvJy8xHozzEmdGs4688oEeqmdq4uY7e3+1cBTP0CFmhYuiQbUrF7tezePnmufLl6R00edPo TYyVj5YtfpT88aIIbBzBYYUIFTqWjKGiZiWJnVL/tSlROIH2runbh6vbyIA4xz1CiRCXwoK4YD6E KC1YvXsdefYU+dPhQHIGCa5Mt3CdJKAPZxLMOLFixUsllK3CWkJgDGvH2jFIC7LoqWm/ShJUlerc kVJvF/0SJOhltWIf0tI8ORdY4JyL5M7d1s/YXaBBOdnqu7KU0cGFDU+8lFge1saK3kKOzIkuP7uX 84pbxZeRK8+CKxEWPRqRYoJs0VFTmRbVL0cq2gKzGQ6f3BJeeyJSpMKfb720OaH8i1sRXk7rJtEj btzSo7beZ3taBh563VKJjlR/lxh9KE7gt3f3ngg8u3AqxVDccUPZx1w47M0VHTfTUYfJdbPhNxNg /9zhwop/X41XyoAEJoeOeBXBY0s+nvQSlCWRrfWRcO04Yxw86uFH1CEJHZgUNRYZEk04JqpHkHO6 6EiJhf44KGKEgxQEz1aCVfNfiPDsWGKPA02zjIq3CFekkQfFOAhKBzGZpJMZThSlLK5Q2cool8xi oisk+ghnK1cKxB911cF3In5KWhIYPnnZaZ4oiMRjEj4n0lPnLGS2yKU/evHZZzGf0cMNcO3o+U1z +ci5Hp3iEBlJnoWisxdyWVEqWKCXYtrmKW+uhxMoUFaCSgmjxJqePVaGJOQ03Dgjn0p23vdlkpUw qcJjyME1ZI6blYBric21A0sidf4CSXzBAkNql//igFcQpODKpxpykEAG5UG3uticTdJi6+tm1nbr LbHCndoXueigcu4jzta6WXK5moSeL4EVp9x6qP0FC4It0gUpKA0OS4x9lFR3LDLJ/rmsLwDbo1em kty6MD4Yq6accxFva8g9DX4rci4abxxmdx+3iMrDrzjylsKK2qfyyuyV5jJkjXA5M80yEnbzqDk3 K7JZJBfnIZwLi+xOwuGl6aGc8q7llSeT4MqtxYkJBJ0jxzYC2HLVMZfu1FtL4tXKX/sor6/rkP0S sBZfR3aSTSMC2FaPyD13W+68Y/dLPNpn0ipA7tL3V2Zzm2farqzdtEJv81ddKIszHqLdXZe4stb/ Z40DCd47zhZvJvNmmZPpo+LrUCZNbwJYfLaIGLJy7uR1C96dyr5LP0K+DLmLAWLKe+8BNhi8eeni DpyQJ8cezLRXGh9K2UEqXT7vG/sMnzgfnwSL9oG+niaJL68V0mDpujuyorWnmyHgaJucJo7lu0KF xDgHrIS07KciWPlKPoIyC8NqNyRp3S93bRoHYaj3u7OMThdvwt28TnE/ao2MGuGzVQXvp7kManAQ X9qXnu7zwUeMA366yZ8JFchASJHQfhDcH8Sw5D/xAHBzAoThuNRXPASSQ4E4jIcOg3gpFKZwRZ+4 oINcOIsBLrGDB7QJcnjojAbmr2AnHKL4/NYUFCMFqosykqEBTyLGWEUxHg80USAAADs= ------=_NextPart_000_0011_01C787E9.6CB290C0-- From simple-bounces@ietf.org Thu Apr 26 03:09:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgy6a-0002Pl-7V; Thu, 26 Apr 2007 03:09:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgy6Z-0002Pg-84 for simple@ietf.org; Thu, 26 Apr 2007 03:09:27 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgy6X-00078o-Mk for simple@ietf.org; Thu, 26 Apr 2007 03:09:27 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3Q798LF028852 for ; Thu, 26 Apr 2007 10:09:23 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 10:09:09 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 10:09:09 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 10:09:09 +0300 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3Q797L2007417; Thu, 26 Apr 2007 10:09:08 +0300 Received: from [172.21.41.217] (esdhcp041217.research.nokia.com [172.21.41.217]) by kusti.research.nokia.com (Postfix) with ESMTP id D8FC993B77; Thu, 26 Apr 2007 10:09:07 +0300 (EEST) Message-ID: <46305013.8040600@nokia.com> Date: Thu, 26 Apr 2007 10:09:07 +0300 From: Jari Urpalainen User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: ext Martin Hynar Subject: Re: [Simple] PUT of xml fragment into rls-services document References: <1177507220.3863.11.camel@localhost> In-Reply-To: <1177507220.3863.11.camel@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2007 07:09:09.0897 (UTC) FILETIME=[C953B790:01C787D1] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: IETF WG SIMPLE 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 ext Martin Hynar wrote: > Hello, > > I am facing one interesting problem which I cannot decide how to > solve. See the situation > > 1. I store rls-services document with XCAP PUT request. The content is > following > > > xmlns:rl="urn:ietf:params:xml:ns:resource-lists"> > > > > > > > > presence > > > > > 2. Now I want to insert new on 3rd position using following > requets > > PUT > /rls-services/.../index/~~/rls-services/service[@uri="sip:friends@example.com"] > /list/rl:entry[3]?xmlns(rl=urn:ietf:params:xml:ns:resource-lists) > > > > First, I'm assuming with "insert" you mean "add". In order to add a new entry onto this position instead of overwriting what your r-uri is doing, you need a request like: PUT /rls-services/.../index/~~/rls-services/service[@uri="sip:friends@example.com"] /list/rl:entry[3][@uri="sip:presentity_C @example.com" ]?xmlns(rl=urn:ietf:params:xml:ns:resource-lists) (and of course you must percent-encode the uri) and FYI you could simplify the r-uri, because the presentity uri is a good enough unique selector in this case: PUT /rls-services/.../index/~~/rls-services/service[@uri="sip:friends@example.com"] /list/*[3][@uri="sip:presentity_C @example.com" ] So after the insert is successful get(put(x)=x must be satisfied. Unfortunately, this still leaves room for interpretation because of whitespace, comment nodes etc. > > 3. What shall be the resulting document? > - Is the content of 2nd PUT correct? Is it possible to have 2 > parseable items (comment and regular element) on the same level? > - Is comment addressable with XCAP document/node selector? > You cannot have a sibling comment node of an element within the body (breaks get(put(x))=x rule). Also a comment node is not addressable with xcap semantics. Comment nodes may appear as child nodes of an element. So the end result (look at e.g. examples in chapter 8.2.3): presence Note that the new entry appears before the whitespace text node. And if you needed "pretty printing style" you must submit e.g. the whole . > > I will be happy for all suggestions. Thanks in advance, Martin Hynar br, jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 26 04:17:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgz9l-0006An-HQ; Thu, 26 Apr 2007 04:16:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgz9k-0006Ae-IM for simple@ietf.org; Thu, 26 Apr 2007 04:16:48 -0400 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgz9i-0004zt-1b for simple@ietf.org; Thu, 26 Apr 2007 04:16:48 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id l3Q8Gjf6161512 for ; Thu, 26 Apr 2007 08:16:45 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.8/8.13.8/NCO v8.3) with ESMTP id l3Q8GjrV4071550 for ; Thu, 26 Apr 2007 10:16:45 +0200 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 l3Q8Gi9N023971 for ; Thu, 26 Apr 2007 10:16:44 +0200 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 l3Q8GiXo023968; Thu, 26 Apr 2007 10:16:44 +0200 To: simple@ietf.org, "Miguel A. Garcia Martin" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 From: Avshalom Houri Message-ID: Date: Thu, 26 Apr 2007 11:16:42 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 26/04/2007 11:16:44, Serialize complete at 26/04/2007 11:16:44 X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Subject: [Simple] Review of draft-garcia-simple-presence-dictionary-04.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="===============0411092428==" Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============0411092428== Content-Type: multipart/alternative; boundary="=_alternative 002D7049C22572C9_=" This is a multipart message in MIME format. --=_alternative 002D7049C22572C9_= Content-Type: text/plain; charset="US-ASCII" I have reviewed the document and I think that it is a good suggestion and will help in reducing the amount of traffic for presence document. We may need to have a mechanism for enabling versioning or more flexible way to decide on dictionaries. Unlike SIP and SDP headers which are more or less stable, in presence things change all the time and there will be new schemas that will require new and/or updated dictionaries. There should be a way to associate a dictionary with a schema and/or a way that a client and a server will agree on a version of the dictionary. One typo in section 1. resources are scare (e.g., such as low bandwidth links with high >> scare -> scarce --Avshalom --=_alternative 002D7049C22572C9_= Content-Type: text/html; charset="US-ASCII"
I have reviewed the document and I think that it is a good suggestion and will
help in reducing the amount of traffic for presence document.

We may need to have a mechanism for enabling versioning or more flexible way
to decide on dictionaries.
Unlike SIP and SDP headers which are more or less stable, in presence things
change all the time and there will be new schemas that will require new
and/or updated dictionaries.

There should be a way to associate a dictionary with a schema and/or
a way that a client and a server will agree on a version of the
dictionary.

One typo in section 1.
resources are scare (e.g., such as low bandwidth links with high
>> scare -> scarce

--Avshalom


 --=_alternative 002D7049C22572C9_=-- --===============0411092428== 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 --===============0411092428==-- From simple-bounces@ietf.org Thu Apr 26 04:20:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgzCq-0007ny-2S; Thu, 26 Apr 2007 04:20:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgzCo-0007nj-JC for simple@ietf.org; Thu, 26 Apr 2007 04:19:58 -0400 Received: from mail.tieto.com ([194.110.47.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgzCm-0007ia-2R for simple@ietf.org; Thu, 26 Apr 2007 04:19:58 -0400 Received: from viper.eu.tieto.com ([194.110.47.167]) by mail.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 11:19:52 +0300 Received: from sagaris.eu.tieto.com ([131.207.197.143]) by viper.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 11:19:54 +0300 Received: from 10.15.1.83 ([10.15.1.83]) by sagaris.eu.tieto.com ([131.207.197.143]) via Exchange Front-End Server email2.tietoenator.com ([192.176.143.12]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 Apr 2007 08:19:54 +0000 Received: from localhost by email2.tietoenator.com; 26 Apr 2007 10:20:07 +0200 Subject: Re: [Simple] PUT of xml fragment into rls-services document From: Martin Hynar To: Jari Urpalainen In-Reply-To: <46305013.8040600@nokia.com> References: <1177507220.3863.11.camel@localhost> <46305013.8040600@nokia.com> Date: Thu, 26 Apr 2007 10:20:07 +0200 Message-Id: <1177575607.3543.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-1.fc6) X-OriginalArrivalTime: 26 Apr 2007 08:19:54.0694 (UTC) FILETIME=[AB6C5660:01C787DB] X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 Cc: IETF WG SIMPLE 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="===============1335090628==" Errors-To: simple-bounces@ietf.org --===============1335090628== Content-Type: multipart/alternative; boundary="=-zgGH8FVOg2xWyjb3Gtsz" --=-zgGH8FVOg2xWyjb3Gtsz Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello, thanks much for explanation. The result is exactly as I have expected, also the handling of comments/whitespaces. However, it might be helpful to mention this also in simple-xcap spec, because this "free room" with comments and whitespace interpretation might lead to client/server interoperability issues. E.g. client might suppose that if comment is not addressable the it might be added using the way in my example together with some regular element and the subsequent get will then retrieve only that element. If I consider also the whitespace, then also putting content like " " (note the space in the beginning) would lead to IOP problems. br, Martin On Thu, 2007-04-26 at 10:09 +0300, Jari Urpalainen wrote: > ext Martin Hynar wrote: > > Hello, > > > > I am facing one interesting problem which I cannot decide how to > > solve. See the situation > > > > 1. I store rls-services document with XCAP PUT request. The content is > > following > > > > > > > xmlns:rl="urn:ietf:params:xml:ns:resource-lists"> > > > > > > > > > > > > > > > > presence > > > > > > > > > > 2. Now I want to insert new on 3rd position using following > > requets > > > > PUT > > /rls-services/.../index/~~/rls-services/service[@uri="sip:friends@example.com"] > > /list/rl:entry[3]?xmlns(rl=urn:ietf:params:xml:ns:resource-lists) > > > > > > > > > First, I'm assuming with "insert" you mean "add". In order to add a new > entry onto this position instead of overwriting uri="sip:presentity_D@example.com > " /> what your > r-uri is doing, you need a request like: > > PUT > /rls-services/.../index/~~/rls-services/service[@uri="sip:friends@example.com"] > /list/rl:entry[3][@uri="sip:presentity_C > @example.com" > ]?xmlns(rl=urn:ietf:params:xml:ns:resource-lists) > > (and of course you must percent-encode the uri) > > and FYI you could simplify the r-uri, because the presentity uri is a > good enough unique selector in this case: > > PUT > /rls-services/.../index/~~/rls-services/service[@uri="sip:friends@example.com"] > /list/*[3][@uri="sip:presentity_C > @example.com" > ] > > So after the insert is successful get(put(x)=x must be satisfied. > Unfortunately, this still leaves room for interpretation because of > whitespace, comment nodes etc. > > > > 3. What shall be the resulting document? > > - Is the content of 2nd PUT correct? Is it possible to have 2 > > parseable items (comment and regular element) on the same level? > > - Is comment addressable with XCAP document/node selector? > > > You cannot have a sibling comment node of an element within the body > (breaks get(put(x))=x rule). Also a comment node is not addressable with > xcap semantics. Comment nodes may appear as child nodes of an element. > > So the end result (look at e.g. examples in chapter 8.2.3): > > > xmlns:rl="urn:ietf:params:xml:ns:resource-lists"> > > > > uri="sip:presentity_C@example.com > " /> > > > > presence > > > > > Note that the new entry appears before the whitespace text node. And if > you needed "pretty printing style" you must submit e.g. the whole . > > > > I will be happy for all suggestions. Thanks in advance, Martin Hynar > br, jari > +-------------------------------------+ Martin Hynar Software Specialist TietoEnator Czech Software Center Phone: +420 597 459 713 Mobile: +420 724 432 817 E-mail: Martin.Hynar@TietoEnator.com Vystavni 292/13 CZ-709 16 Ostrava www.tietoenator.com Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorized use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You. --=-zgGH8FVOg2xWyjb3Gtsz Content-Type: text/html; charset=utf-8 Hello,

thanks much for explanation. The result is exactly as I have expected, also the handling of comments/whitespaces. However, it might be helpful to mention this also in simple-xcap spec, because this "free room" with comments and whitespace interpretation might lead to client/server interoperability issues. E.g. client might suppose that if comment is not addressable the it might be added using the way in my example together with some regular element and the subsequent get will then retrieve only that element. If I consider also the whitespace, then also putting content like " <el/>" (note the space in the beginning) would lead to IOP problems.

br, Martin


On Thu, 2007-04-26 at 10:09 +0300, Jari Urpalainen wrote: 
ext Martin Hynar wrote:
> Hello,
>
> I am facing one interesting problem which I cannot decide how to 
> solve. See the situation
>
> 1. I store rls-services document with XCAP PUT request. The content is 
> following
>
> <?xml version="1.0" encoding="UTF-8"?>
> <rls-services xmlns="urn:ietf:params:xml:ns:rls-services" 
> xmlns:rl="urn:ietf:params:xml:ns:resource-lists">
> <service uri="sip:friends@example.com 
> <mailto:friends__notedeleteselement0664_0@example.com>">
> <list name="friends">
> <rl:entry uri="sip:presentity_A@example.com 
> <mailto:presentity_notedeleteselement0664_1@example.com>" />
> <rl:entry uri="sip:presentity_B@example.com 
> <mailto:presentity_notedeleteselement0664_10@example.com>" />
> <rl:entry uri="sip:presentity_D@example.com 
> <mailto:presentity_notedeleteselement0664_15@example.com>" />
> </list>
> <packages>
> <package>presence</package>
> </packages>
> </service>
> </rls-services>
>
> 2. Now I want to insert new <entry> on 3rd position using following 
> requets
>
> PUT 
> /rls-services/.../index/~~/rls-services/service[@uri="sip:friends@example.com"] 
> <mailto:friends__notedeleteselement0664_0@example.com>/list/rl:entry[3]?xmlns(rl=urn:ietf:params:xml:ns:resource-lists)
>
> <!--some comment -->
> <rl:entry uri="sip:presentity_C@example.com 
> <mailto:presentity_notedeleteselement0664_2@example.com>" />
>
First, I'm assuming with "insert" you mean "add".  In order to add a new 
entry onto this position instead of overwriting <rl:entry 
uri="sip:presentity_D@example.com 
<mailto:presentity_notedeleteselement0664_15@example.com>" /> what your 
r-uri is doing, you need a request like:

PUT 
/rls-services/.../index/~~/rls-services/service[@uri="sip:friends@example.com"] 
<mailto:friends__notedeleteselement0664_0@example.com>/list/rl:entry[3][@uri="sip:presentity_C 
<mailto:presentity_notedeleteselement0664_2@example.com>@example.com" 
<mailto:friends__notedeleteselement0664_0@example.com>]?xmlns(rl=urn:ietf:params:xml:ns:resource-lists)

(and of course you must percent-encode the uri)

and FYI you could simplify the r-uri, because the presentity uri is a 
good enough unique selector in this case:

PUT 
/rls-services/.../index/~~/rls-services/service[@uri="sip:friends@example.com"] 
<mailto:friends__notedeleteselement0664_0@example.com>/list/*[3][@uri="sip:presentity_C 
<mailto:presentity_notedeleteselement0664_2@example.com>@example.com" 
<mailto:friends__notedeleteselement0664_0@example.com>]

So after the insert is successful get(put(x)=x must be satisfied. 
Unfortunately, this still leaves room for interpretation because of 
whitespace, comment nodes etc.
>
> 3. What shall be the resulting document?
>   - Is the content of 2nd PUT correct? Is it possible to have 2 
> parseable items (comment and regular element) on the same level?
>   - Is comment addressable with XCAP document/node selector?
>
You cannot have a sibling comment node of an element within the body 
(breaks get(put(x))=x rule). Also a comment node is not addressable with 
xcap semantics. Comment nodes may appear as child nodes of an element.

So the end result (look at e.g. examples in chapter 8.2.3):

<?xml version="1.0" encoding="UTF-8"?>
<rls-services xmlns="urn:ietf:params:xml:ns:rls-services" 
xmlns:rl="urn:ietf:params:xml:ns:resource-lists">
<service uri="sip:friends@example.com 
<mailto:friends__notedeleteselement0664_0@example.com>">
<list name="friends">
<rl:entry uri="sip:presentity_A@example.com 
<mailto:presentity_notedeleteselement0664_1@example.com>" />
<rl:entry uri="sip:presentity_B@example.com 
<mailto:presentity_notedeleteselement0664_10@example.com>" /><rl:entry 
uri="sip:presentity_C@example.com 
<mailto:presentity_notedeleteselement0664_10@example.com>" />
<rl:entry uri="sip:presentity_D@example.com 
<mailto:presentity_notedeleteselement0664_15@example.com>" />
</list>
<packages>
<package>presence</package>
</packages>
</service>
</rls-services>

Note that the new entry appears before the whitespace text node. And if 
you needed "pretty printing style" you must submit e.g. the whole <list>.
>
> I will be happy for all suggestions. Thanks in advance, Martin Hynar
br, jari
+-------------------------------------+
  Martin Hynar
  Software Specialist

  TietoEnator
  Czech Software Center
  Phone: +420 597 459 713
  Mobile: +420 724 432 817
  E-mail: Martin.Hynar@TietoEnator.com

  Vystavni 292/13
  CZ-709 16 Ostrava

www.tietoenator.com


Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorized use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You.
--=-zgGH8FVOg2xWyjb3Gtsz-- --===============1335090628== 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 --===============1335090628==-- From simple-bounces@ietf.org Thu Apr 26 07:06:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh1o1-0005NE-E5; Thu, 26 Apr 2007 07:06:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh1o0-0005N8-2k for simple@ietf.org; Thu, 26 Apr 2007 07:06:32 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh1ny-0004FJ-Kb for simple@ietf.org; Thu, 26 Apr 2007 07:06:32 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3QB68Rt018859 for ; Thu, 26 Apr 2007 14:06:28 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 14:06:25 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 14:06:25 +0300 Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3QB6NcC014312; Thu, 26 Apr 2007 14:06:23 +0300 Received: from [172.21.41.217] (esdhcp041217.research.nokia.com [172.21.41.217]) by kusti.research.nokia.com (Postfix) with ESMTP id 6C1F493B77; Thu, 26 Apr 2007 14:06:23 +0300 (EEST) Subject: Re: [Simple] PUT of xml fragment into rls-services document From: Jari Urpalainen To: ext Martin Hynar In-Reply-To: <1177575607.3543.5.camel@localhost> References: <1177507220.3863.11.camel@localhost> <46305013.8040600@nokia.com> <1177575607.3543.5.camel@localhost> Content-Type: text/plain Date: Thu, 26 Apr 2007 14:06:23 +0300 Message-Id: <1177585583.2368.11.camel@esdhcp041217.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2007 11:06:25.0140 (UTC) FILETIME=[EE316B40:01C787F2] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: IETF WG SIMPLE X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Thu, 2007-04-26 at 10:20 +0200, ext Martin Hynar wrote: > Hello, > > thanks much for explanation. The result is exactly as I have expected, > also the handling of comments/whitespaces. However, it might be > helpful to mention this also in simple-xcap spec, because this "free > room" with comments and whitespace interpretation might lead to > client/server interoperability issues. E.g. client might suppose that > if comment is not addressable the it might be added using the way in > my example together with some regular element and the subsequent get > will then retrieve only that element. If I consider also the > whitespace, then also putting content like " " (note the space in > the beginning) would lead to IOP problems. > > br, Martin > I think the spec already explicitly states what's allowed and what's not, so there should be no room for interpretations from that point of view (at least for the items you mention). I fully agree though that there will be interoperability difficulties, because some parts of the stuff aren't necessarily that trivial to implement, but they are more or less deployment issues. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 26 07:22:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh22v-0007ER-Ms; Thu, 26 Apr 2007 07:21:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh22t-0007E9-Db; Thu, 26 Apr 2007 07:21:55 -0400 Received: from mail.unina.it ([192.132.34.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh22p-0006Lr-F9; Thu, 26 Apr 2007 07:21:55 -0400 Received: from [143.225.229.193] ([143.225.229.193]) by mail.unina.it (8.13.7/8.13.7) with ESMTP id l3QBOFet002667; Thu, 26 Apr 2007 13:24:16 +0200 Message-ID: <46308B11.4090407@unina.it> Date: Thu, 26 Apr 2007 13:20:49 +0200 From: Lorenzo Miniero User-Agent: Mozilla Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: SIMPLE Mailing List Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.unina.it id l3QBOFet002667 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: XCON Mailing List Subject: [Simple] Open source MSRP implementation X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Dear all, just a brief post to notify all the interested readers that we at=20 University of Naples recently released a prototype, open source,=20 implementation of the Message Session Relay Protocol (MSRP) written in C. The library has only been released a few days ago, and so at the moment=20 only provides some very basic functionality, such as: * endpoint-to-endpoint sessions; * "switching"-mode (to enable conference rooms), where each conference=20 room is seen as an endpoint by all participants. Only text can be sent, i.e. no MIME encoding of data, CPIM and the like. Chunking is envisaged but not working yet. Besides, no relaying=20 functionality is provided, though we're working on it. We're currently using this library to provide some chatroom=20 functionality in Confiance, our prototype implementation of the XCON=20 framework (which is why I'm forwarding this mail to the XCON mailing=20 list too), and though still very basic, the library does its work. If you're interested in having a look at the library you can get it on=20 its Sourceforge project page: http://sourceforge.net/projects/libmsrp/ which also contains a couple of sample applications to test the=20 currently provided functionality. In a few days we'll update the Confiance project as well=20 (http://confiance.sf.net/), which will envisage the integration of the=20 MSRP functionality in both client and server sides. MSRP sessions in the=20 framework are negotiated within SIP/SDP as described in the draft. We'd really appreciate some feedback upon the current status of the=20 work, and suggestions on future work to be done of course. Regards, Lorenzo --=20 Lorenzo Miniero, Junior Researcher Dipartimento di Informatica e Sistemistica Universit=C3=A0 degli Studi di Napoli "Federico II" Via Claudio 21 -- 80125 Napoli (Italy) Phone: +390817683821 - Fax: +390817683816 Email: lorenzo.miniero@unina.it _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Apr 27 06:23:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhNbf-0006ge-Li; Fri, 27 Apr 2007 06:23:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhNbe-0006gU-4Z for simple@ietf.org; Fri, 27 Apr 2007 06:23:14 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhNbd-00030Q-IR for simple@ietf.org; Fri, 27 Apr 2007 06:23:14 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3RAN3Wg004611; Fri, 27 Apr 2007 13:23:11 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 13:23:04 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 13:23:04 +0300 Received: from [172.21.59.57] ([172.21.59.57]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 13:23:04 +0300 Message-ID: <4631CF08.2010104@nsn.com> Date: Fri, 27 Apr 2007 13:23:04 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Avshalom Houri Subject: Re: [Simple] Review of draft-garcia-simple-presence-dictionary-04.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2007 10:23:04.0905 (UTC) FILETIME=[0ABECB90:01C788B6] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Hi Avshalom: Thanks for the review. With respect the question on versioning, I would like to point out that the fundamental assumption behind SigComp is that, if there is a dictionary, it is unique, stable, and will not be updated in the future. At least, this was the idea behind the SIP dictionary, and here, the text in RFC 3485: The dictionary is not intended to evolve as SIP or SDP evolve. It is defined once, and stays as is forever. This solves the problems of updating, upgrading and finding out the dictionary that is supported at the remote end when several versions of the same dictionary coexist. The bigger problem with versions of the dictionary is that they constitute separate state. So, version 1 of the dictionary is a standalone dictionary. If you create version 2, then it is a separate dictionary, and the endpoint would have to implement both to have maximum interoperability. Since each dictionary requires storage and RAM memory, you may end up exhausting the resources in the endpoint. It would be possible, though, to create addenda to the existing dictionary, if the need arises. So each addendum would be a separate state that is advertise separately. I think this is the way to go forward (again, if the need arises). As you may have noticed, each dictionary is associated with a state identifier. This is as much as is needed to refer or find out the dictionary, so in my opinion, this is as much as it is needed between the two points to find out that the dictionary is available at the remote endpoint and start using it. I think the state identifier is a hash of the contents of the state (dictionary). /Miguel Avshalom Houri wrote: > > I have reviewed the document and I think that it is a good suggestion > and will > help in reducing the amount of traffic for presence document. > > We may need to have a mechanism for enabling versioning or more flexible > way > to decide on dictionaries. > Unlike SIP and SDP headers which are more or less stable, in presence > things > change all the time and there will be new schemas that will require new > and/or updated dictionaries. > > There should be a way to associate a dictionary with a schema and/or > a way that a client and a server will agree on a version of the > dictionary. > > One typo in section 1. > resources are scare (e.g., such as low bandwidth links with high > >> scare -> scarce > > --Avshalom > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- Please note my new e-mail address: miguel.garcia at nsn.com Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Apr 28 13:37:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhqr2-00032a-NA; Sat, 28 Apr 2007 13:37:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhqr0-00032Q-Ur for simple@ietf.org; Sat, 28 Apr 2007 13:37:02 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hhqr0-0005FT-3V for simple@ietf.org; Sat, 28 Apr 2007 13:37:02 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3SHaolb024752; Sat, 28 Apr 2007 20:36:59 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Apr 2007 20:36:46 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Apr 2007 12:36:44 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Simple] Review of draft-garcia-simple-presence-dictionary-04.txt Date: Sat, 28 Apr 2007 12:36:44 -0500 Message-ID: <6231925C3635AF47B2B149033DD9186502F64125@daebe103.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Review of draft-garcia-simple-presence-dictionary-04.txt Thread-Index: AceH21Bxk5yEy2aWTlWvMPXecF27UABBEX9w References: From: To: , , X-OriginalArrivalTime: 28 Apr 2007 17:36:44.0335 (UTC) FILETIME=[C9F27BF0:01C789BB] X-Nokia-AV: Clean X-Spam-Score: 0.3 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 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: , Content-Type: multipart/mixed; boundary="===============0493300213==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0493300213== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C789BB.C9DB7D41" This is a multi-part message in MIME format. ------_=_NextPart_001_01C789BB.C9DB7D41 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Miguel, =20 I have also reviewed the document. Regarding Avshalom's comment, I think the draft in its current form provides a good catch of nowadays PIDF and its extensions. Future extensions may be minor or proprietary, so I personally don't see a need to introduce versioning and its client-server negotiation. Certainly this document has to wait until all dependencies reach stability. =20 Some further minor comments as follow: =20 Section 1: change: "The Session Initiation Protocol (SIP) [4] is extended by the SIP-events framework [5] to provide, e.g., subscriptions and notifications to presence information. The presence information is typically carried in Extensible Markup Language (XML) [22] documents that are compliant with a given XML schema [23]. For example, the Presence Information Data Format (PIDF) [8] defines the format for the basic document that supplies presence information. " =20 with: "The Session Initiation Protocol (SIP) [4] is extended by the SIP-events framework [5] to provide subscriptions and notifications of events. One example of such event notification mechanism is presence. The presence information is typically carried in Extensible Markup Language (XML) [22] documents that are compliant with a given XML schema [23]. The Presence Information Data Format (PIDF) [8] defines the format for the basic document that supplies presence information." =20 Section 1: "Typically, PIDF is used in combination with other extensions to provide a richer user experience, among others: the Presence Data Model [10], Rich Presence Extensions to PIDF (RPID) [11], Contact Information in PIDF (CIPID) [12], or Timed Presence Extensions to PIDF [13]." I would remove reference [13] from here and add at least [19] and [20] (considering what the "typical" extensions are enhancing user experience...) =20 Section 1: "Sigcomp endpoints will initially announce the availability of one or both dictionaries until the other end acknowledges that it has received the announcement." Do sigcomp endpoints really announce the availability of RFC3485 dictionary? According to RFC 3485: "The static dictionary is unique and MUST be available in all SigComp implementations for SIP/SDP" =20 Appendix A (and Section 4 accordingly): - timestamp could be upgraded to priority 1, - "close" should be "closed" - "deviceId"should be "deviceID" - "country" seems to be missing from PIDF-LO [16] - "version=3D" is also included in winfo [17] (reference is missing) Cheers, Krisztian ________________________________ From: ext Avshalom Houri [mailto:AVSHALOM@il.ibm.com]=20 Sent: Thursday, April 26, 2007 1:17 AM To: simple@ietf.org; Garcia Miguel (NSN - FI/Helsinki) Subject: [Simple] Review of draft-garcia-simple-presence-dictionary-04.txt =09 =09 =09 I have reviewed the document and I think that it is a good suggestion and will=20 help in reducing the amount of traffic for presence document.=20 =09 We may need to have a mechanism for enabling versioning or more flexible way=20 to decide on dictionaries.=20 Unlike SIP and SDP headers which are more or less stable, in presence things=20 change all the time and there will be new schemas that will require new=20 and/or updated dictionaries.=20 =09 There should be a way to associate a dictionary with a schema and/or=20 a way that a client and a server will agree on a version of the=20 dictionary.=20 =09 One typo in section 1.=20 resources are scare (e.g., such as low bandwidth links with high >> scare -> scarce=20 =09 --Avshalom =09 =09 =09 ------_=_NextPart_001_01C789BB.C9DB7D41 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Miguel,
 
I=20 have also reviewed the document. Regarding Avshalom's comment, I think = the draft=20 in its current form provides a good catch of nowadays PIDF and its = extensions.=20 Future extensions may be minor or proprietary, so I personally don't see = a need=20 to introduce versioning and its client-server negotiation. Certainly = this=20 document has to wait until all dependencies reach = stability.
 
Some further minor comments as=20 follow:
 
Section 1: change:
 "The Session Initiation Protocol (SIP) = [4] is=20 extended by the SIP-events framework [5] to provide, e.g., subscriptions = and=20 notifications to presence information.  The presence information is = typically carried in Extensible Markup Language (XML) [22] documents = that are=20 compliant with a given XML schema [23]. For example, the Presence = Information=20 Data Format (PIDF) [8] defines the format for the basic document that = supplies=20 presence information. "
 
with:
 "The Session Initiation Protocol (SIP) = [4] is=20 extended by the SIP-events framework [5] to provide subscriptions and=20 notifications of events. One example of such event notification = mechanism=20 is presence. The  presence information is typically = carried in=20 Extensible Markup Language (XML) [22] documents that are compliant with = a given=20 XML schema [23]. The Presence Information Data Format (PIDF) [8] defines = the=20 format for the basic document that supplies presence=20 information."
 
Section 1:
"Typically, PIDF is used in combination with = other=20 extensions to provide a richer user experience, among others: the = Presence Data=20 Model [10], Rich Presence Extensions to PIDF (RPID) [11], Contact = Information in=20 PIDF (CIPID) [12], or Timed Presence Extensions to PIDF=20 [13]."
I=20 would remove reference [13] from here and add at least [19] and [20]=20 (considering what the "typical" extensions are enhancing user=20 experience...)
 
Section 1:
"Sigcomp endpoints will initially announce = the=20 availability of one or both dictionaries until the other end = acknowledges that=20 it has received the announcement."
Do sigcomp endpoints really announce the = availability=20 of RFC3485 dictionary? According to RFC 3485: "The static dictionary is = unique and MUST=20 be available in all SigComp implementations for = SIP/SDP"
 
Appendix A (and Section 4=20 accordingly):
-=20 timestamp could be upgraded to priority 1,
-=20 "close" should be "closed"
-=20 "deviceId"should be "deviceID"
-=20 "country" seems to be missing from PIDF-LO [16]
-=20 "version=3D" is also included in winfo [17] (reference is=20 missing)

Cheers,
Krisztian

From: ext Avshalom Houri=20 [mailto:AVSHALOM@il.ibm.com]
Sent: Thursday, April 26, 2007 = 1:17=20 AM
To: simple@ietf.org; Garcia Miguel (NSN -=20 FI/Helsinki)
Subject: [Simple] Review of=20 draft-garcia-simple-presence-dictionary-04.txt


I have = reviewed the document=20 and I think that it is a good suggestion and will
help in reducing the amount of traffic = for presence=20 document.

We may = need to have a=20 mechanism for enabling versioning or more flexible way =
to decide on dictionaries. =
Unlike SIP and SDP headers which are = more or less=20 stable, in presence things
change=20 all the time and there will be new schemas that will require = new=20
and/or updated = dictionaries.=20

There should be a way to = associate a=20 dictionary with a schema and/or
a=20 way that a client and a server will agree on a version of the =
dictionary.

One typo in section 1.
resources are scare (e.g., such as low bandwidth links with = high=20
>> scare -> = scarce=20

--Avshalom


 ------_=_NextPart_001_01C789BB.C9DB7D41-- --===============0493300213== 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 --===============0493300213==-- From Dillionurn@atlanticocorretora.com.br Sat Apr 28 20:30:48 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhxJQ-0006yV-3h for simple-archive@lists.ietf.org; Sat, 28 Apr 2007 20:30:48 -0400 Received: from [151.63.87.84] (helo=[151.63.86.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HhxJO-0003pX-5s for simple-archive@lists.ietf.org; Sat, 28 Apr 2007 20:30:47 -0400 Received: from a-l1lmm9gialcna ([150.144.190.57]:4688 "EHLO a-l1lmm9gialcna" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [151.63.86.138] with ESMTP id S22GMZTIORCPEBNK (ORCPT ); Sun, 29 Apr 2007 02:31:17 +0200 Date: Sun, 29 Apr 2007 02:30:55 +0200 From: "Blazej Dillion" Reply-To: "Blazej Dillion" Message-ID: <196913013631.391602889753@atlanticocorretora.com.br> To: Subject: I parked the car and started up the alley. MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Spam-Score: 0.9 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 ANLEGER UHR BJ5N.F!!! DIE RALLYE IST GESTARTET Firma: BOERSE INVEST BETEI WKN : 797639 ISIN : CH0012802093 Markt: Frankfurt Kürzel : BJ5N.F Preis: 1.90 5-Tag Prognose: 3.00 KAUFEN KAUFEN KAUFEN! BJ5N.F ESGESCHAFT FIN UNTER PARI! From simple-bounces@ietf.org Mon Apr 30 06:35:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiTDb-0002TF-Dt; Mon, 30 Apr 2007 06:34:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiTDZ-0002TA-Tn for simple@ietf.org; Mon, 30 Apr 2007 06:34:53 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiTDY-00041n-6V for simple@ietf.org; Mon, 30 Apr 2007 06:34:53 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3UAYdHJ010904; Mon, 30 Apr 2007 13:34:49 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 13:34:43 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 13:34:43 +0300 Received: from [172.21.59.57] ([172.21.59.57]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 13:34:42 +0300 Message-ID: <4635C642.8000501@nsn.com> Date: Mon, 30 Apr 2007 13:34:42 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Kiss Krisztian (Nokia-SIR/PaloAlto)" Subject: Re: [Simple] Review of draft-garcia-simple-presence-dictionary-04.txt References: <6231925C3635AF47B2B149033DD9186502F64125@daebe103.NOE.Nokia.com> In-Reply-To: <6231925C3635AF47B2B149033DD9186502F64125@daebe103.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Apr 2007 10:34:42.0744 (UTC) FILETIME=[29EDD380:01C78B13] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: Avshalom Houri , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Krisztian: Thanks for your review. I have implemented most of your suggestions in my working draft. As for your question: > Section 1: > "Sigcomp endpoints will initially announce the availability of one or > both dictionaries until the other end acknowledges that it has received > the announcement." > Do sigcomp endpoints really announce the availability of RFC3485 > dictionary? According to RFC 3485: "The static dictionary is unique and > MUST be available in all SigComp implementations for SIP/SDP" I believe the text is correct, because I got it from the ROCH mailing list. Some ROHC people reviewed the draft and wanted to clarify the fuzzy wording we previously had inthere. So, according to the Sigcomp experts the endpoint initially needs to announce the presence dictionary but it can stop when the other endpoint acknowledges that is has received the announcement. The SigComp END-MESSAGE "returned parameters" are used to announce the availability of the presence dictionary and "requested feedback item" is used to ask for acknowledgement from remote endpoint. So, after the requested feedback item has been returned to the endpoint there is no need to continue to announce the presence dictionary or other SigComp parameters using the returned parameters as "the endpoint is already satisfied all necessary information has reached the endpoint receiving the message" (quote from 3320). With respect the text that you quote from RFC 3485, I don't think it is related to the issue you mentioned. Basically, the text was trying to say that if you implement SigComp for SIP, you have to implement the SIP/SDP dictionary as well. It says nothing about the initialization phase. Now, with respect your proposed changes: > - timestamp could be upgraded to priority 1, We used the rule that any string that gets priority 1 means that you will always find that string in any presence document, or the likelyhood to find the string is very high. That's the reason why there is only a few strings with priority 1. I thought that "timestamp" is an optional element in PIDF and the data model, so there will be implementations that will not use it at all. I believe this is enough to write any other priority than 1. So, priority 2 (the current one) seems to be appropriate: it is very likely to find this string in a presence document. > - "close" should be "closed" Oops, yes, it should be closed. Fixed. > - "deviceId"should be "deviceID" Yes. Fixed. > - "country" seems to be missing from PIDF-LO [16] Yes. Added to the strings > - "version=" is also included in winfo [17] (reference is missing) As you can see, there are two similar entries for version. One is "version" and the other is "version=" (notice the '='). The former, which is listed at the end of the string collection, is used by reference [21] as an element. The latter, listed at the beginning of the string collection, is used by many documents (including winfo) as an attribute. So I should add reference [17] to this last one, but as I indicated, there are so many documents that use "version=" that I just don't list any document. Therefore, I see no action with this respect. BR, Miguel Kiss Krisztian (Nokia-SIR/PaloAlto) wrote: > Hi Miguel, > > I have also reviewed the document. Regarding Avshalom's comment, I think > the draft in its current form provides a good catch of nowadays PIDF and > its extensions. Future extensions may be minor or proprietary, so I > personally don't see a need to introduce versioning and its > client-server negotiation. Certainly this document has to wait until all > dependencies reach stability. > > Some further minor comments as follow: > > Section 1: change: > "The Session Initiation Protocol (SIP) [4] is extended by the > SIP-events framework [5] to provide, e.g., subscriptions and > notifications to presence information. The presence information is > typically carried in Extensible Markup Language (XML) [22] documents > that are compliant with a given XML schema [23]. For example, the > Presence Information Data Format (PIDF) [8] defines the format for the > basic document that supplies presence information. " > > with: > "The Session Initiation Protocol (SIP) [4] is extended by the > SIP-events framework [5] to provide subscriptions and notifications of > events. One example of such event notification mechanism is presence. > The presence information is typically carried in Extensible Markup > Language (XML) [22] documents that are compliant with a given XML schema > [23]. The Presence Information Data Format (PIDF) [8] defines the format > for the basic document that supplies presence information." > > Section 1: > "Typically, PIDF is used in combination with other extensions to provide > a richer user experience, among others: the Presence Data Model [10], > Rich Presence Extensions to PIDF (RPID) [11], Contact Information in > PIDF (CIPID) [12], or Timed Presence Extensions to PIDF [13]." > I would remove reference [13] from here and add at least [19] and [20] > (considering what the "typical" extensions are enhancing user experience...) > > Section 1: > "Sigcomp endpoints will initially announce the availability of one or > both dictionaries until the other end acknowledges that it has received > the announcement." > Do sigcomp endpoints really announce the availability of RFC3485 > dictionary? According to RFC 3485: "The static dictionary is unique and > MUST be available in all SigComp implementations for SIP/SDP" > > Appendix A (and Section 4 accordingly): > - timestamp could be upgraded to priority 1, > - "close" should be "closed" > - "deviceId"should be "deviceID" > - "country" seems to be missing from PIDF-LO [16] > - "version=" is also included in winfo [17] (reference is missing) > > Cheers, > Krisztian > > ------------------------------------------------------------------------ > *From:* ext Avshalom Houri [mailto:AVSHALOM@il.ibm.com] > *Sent:* Thursday, April 26, 2007 1:17 AM > *To:* simple@ietf.org; Garcia Miguel (NSN - FI/Helsinki) > *Subject:* [Simple] Review of > draft-garcia-simple-presence-dictionary-04.txt > > > I have reviewed the document and I think that it is a good > suggestion and will > help in reducing the amount of traffic for presence document. > > We may need to have a mechanism for enabling versioning or more > flexible way > to decide on dictionaries. > Unlike SIP and SDP headers which are more or less stable, in > presence things > change all the time and there will be new schemas that will require new > and/or updated dictionaries. > > There should be a way to associate a dictionary with a schema and/or > a way that a client and a server will agree on a version of the > dictionary. > > One typo in section 1. > resources are scare (e.g., such as low bandwidth links with high > >> scare -> scarce > > --Avshalom > > -- Please note my new e-mail address: miguel.garcia at nsn.com Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From Jahshanxfzy@asiansensor.com Mon Apr 30 16:17:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HicJ8-0000b8-GD for simple-archive@lists.ietf.org; Mon, 30 Apr 2007 16:17:14 -0400 Received: from aafy28.neoplus.adsl.tpnet.pl ([83.4.154.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HicJ5-0002Xm-RZ for simple-archive@lists.ietf.org; Mon, 30 Apr 2007 16:17:14 -0400 Received: from komputerek ([163.195.78.42] helo=komputerek) by aafy28.neoplus.adsl.tpnet.pl ( sendmail 8.13.3/8.13.1) with esmtpa id 1UfxNu-000TAL-OT for simple-archive@lists.ietf.org; Mon, 30 Apr 2007 22:17:24 +0200 Message-ID: <000801c78b64$79b60170$1c9a0453@komputerek> From: "ashur Jahshan" To: Subject: Another way of putting the point is that the price you pay for the possibility of confirming your authority is the outside chance of being discredited. Date: Mon, 30 Apr 2007 22:16:45 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C78B75.3D3ED170" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.8 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ------=_NextPart_000_0008_01C78B75.3D3ED170 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable It had been a surprise to learn that among Bashere's nine thousand Saldaean horse all of the nobles had brought their wives, and most of the other officers as well. ------=_NextPart_000_0008_01C78B75.3D3ED170 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
It had been a surprise to learn that among = Bashere's=20 nine thousand Saldaean horse all of the nobles had brought their wives, = and most=20 of the other officers as well.
------=_NextPart_000_0008_01C78B75.3D3ED170--