From simple-bounces@ietf.org Tue Feb 1 02:27:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20706; Tue, 1 Feb 2005 02:27:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvsjr-0000Wy-Fb; Tue, 01 Feb 2005 02:46:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvsPV-0007fX-Q8; Tue, 01 Feb 2005 02:25:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvsOb-0007B4-6m for simple@megatron.ietf.org; Tue, 01 Feb 2005 02:24:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20245 for ; Tue, 1 Feb 2005 02:24:20 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvsgh-0000T7-SK for simple@ietf.org; Tue, 01 Feb 2005 02:43:04 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j117OHc21288; Tue, 1 Feb 2005 09:24:17 +0200 (EET) X-Scanned: Tue, 1 Feb 2005 09:34:35 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j117YZVT005410; Tue, 1 Feb 2005 09:34:35 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00dmH5op; Tue, 01 Feb 2005 09:34:31 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j117Nqx29666; Tue, 1 Feb 2005 09:23:52 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 1 Feb 2005 09:23:43 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 1 Feb 2005 09:23:43 +0200 Received: from 172.21.50.105 ([172.21.50.105]) by esebe105.NOE.Nokia.com ([172.21.143.53]) with Microsoft Exchange Server HTTP-DAV ; Tue, 1 Feb 2005 07:23:42 +0000 Received: from xitami.research.nokia.com by esebe105.ntc.nokia.com; 01 Feb 2005 09:23:42 +0200 Subject: Re: [Simple] Namespaces and XCAP From: jari urpalainen To: ext Jonathan Rosenberg In-Reply-To: <41FE9B4C.1070106@cisco.com> References: <41FE9B4C.1070106@cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 01 Feb 2005 09:23:42 +0200 Message-Id: <1107242622.26454.54.camel@xitami.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-OriginalArrivalTime: 01 Feb 2005 07:23:43.0475 (UTC) FILETIME=[F5C4A430:01C5082E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Content-Transfer-Encoding: 7bit On Mon, 2005-01-31 at 15:55 -0500, ext Jonathan Rosenberg wrote: > Folks, > > One of the issues that has come up during the last call period for xcap > was the way namespaces are used during the URI matching operation. The > way it works today is that the namespace contexts for evaluating the > xcap URI are constructed as you traverse through the document. The > namespace prefixes in the URI therefore need to be defined using > namepsace bindings defined in the document itself. > > This has two major drawbacks that have been pointed out: > > 1. it requires the XCAP client to have the document in hand ahead of > time, just to know the namespace bindings > > 2. it prohibits the usage of existing off-the-shelf xpath libraries to > support xcap. These libraries require namespace bindings to be provided > PRIOR to the evaluation of an expression against a document. > > We have in the past agreed that an xcap client must be able to perform > operations like insertion of a buddy into a buddy list, without having > the full buddy list document stored locally. The current matching rules > make that impossible. That would seem to be a fairly significant > limitation and therefore one that we need to address. > > The alternatives are fairly limited. They are, as far as I can tell: > > 1. Server defined namespace bindings > > The server can define bindings between namespace prefixes and namespace > URIs in a separate document in the global tree. This requires the xcap > server to track namespaces used in each instance document. When a new > element, attribute or document is added, the server needs to scan those > for new namespaces, and add bindings for them to the global document. > Similarly, when an element, document or attribute is removed, the server > would have to do reference checking to see if that namespace is still in > use. If not, it would then remove the binding. > > The binding document can be simple. For example, xpointer expressions > would suffice: > > xmlns(prefix1="http://namespace-uri-1") > xmlns(prefix2="http://namespace-2-uri") > > A client would still need to have this namespace document in hand at all > times. It is relatively small. However, the xcap client would need to > know if it should change. > > 2. Client defined namespace bindings: separate document > > Instead of having the server define bindings, each user has a document > (in the user tree somewhere) that defines the bindings. The client > themself creates this document. Thus, the client need only create > bindings for the namespaces it plans on using in queries. > > We still have the problem that, if multiple clients for the same user > write this document, it needs to be kept up to date on the other clients > (i.e., would require the config package). > > Furthermore, it assumes that the user that performs a query is the same > as the user that "owns" the document. This need not be the case. For > example, my friends might be allowed to read entries off of my buddy list. > > 3. Implied namespace prefixes > > Instead of the namespace bindings being obtained from a document, they > could be well-known and constructed by algorithm. For example, an MD5 > hash of the namespace URI. > > This approach has the benefit that no synchronization on a document is > required. However, whenever the server processes a query against a > document, it will need to obtain all of the namespace URIs in use in > that document, and then hash them to obtain the namespace prefixes > allowed in the queries. Thus, the work on the server is similar to > proposal (1). > > It would also result in extremely UGLY URIs, and long ones too. > > 4. Allow the namespace URI instead of a namespace prefix > > In this approach, instead of hashing the namespace URI to obtain the > namespace prefix, we simply allow the namespace URI itself to BE a valid > prefix. This has none of the drawbacks of approach (3), except that it > makes the URIs really, really, really long. Its also definitely a hack > and something that is bending the rules a bit on XML namespaces. > > 5. Allow namespace bindings to be definde in the XCAP URI itself > > In this approach, bindings between namespace prefixes and namespace URI > are present in the xcap URI itself. The xpointer xmlns specification > (http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325/) provides a way to > define these. As an example of how this might work: > > http://xcap.example.com/services/resource-lists/users/bill/fr.xml/~~/ > xmlns(foo="http://foo.example.com")/ > resource-lists/list%5b@name=%22friends%22%5d/entry/foo:street-address > > > In other words, right after the ~~ delimiter, the next path segment is > actually a namespace definition, binding the namespace prefix "foo" to > the URI "http://foo.example.com". That prefix is then used later on in > the URI. > > The only question is where in the URI to place these definitions. Again, > we only have so many choices that I can see: > > CHOICE A: immediately after the ~~/, in the next path segment, which > would contain all such definitions as xmlns xpointer expressions. > > CHOICE B: anywhere in the URI, as a separate path segment > > CHOICE C: as part of a path segment that corresponds to an element, > attribute or document > > > I think the easiest thing is probably A. > > The main drawback to this approach is that its inclusion in a path > segment at all is a stretch to the definition of a path, but > conceptually you are navigating into a namespace, and within that > namespace, to elements and attributes. > > It also leads to somewhat long-ish URI. > > I would further propose that application usages define a default > namespace for the xcap URI evaluation, so as to avoid defining those in > each and every URI. > > > > > So, which to use? Considering the issues involved, I think the best > option is 5(A). > > Comments? > > Thanks, > Jonathan R. > > In principle I am in favor of 5A. However, I have a difficulty understanding why we should use a different syntax than what xpointer spec has ? http://www.w3.org/TR/WD-xptr xmlns(x=http://example.com/foo) xpointer(//x:a) Furthermore, there seems to be a tendency to use fragment identifiers, so I would propose to use them. This leads to another issue that has to be addressed as well, i.e. the namespaces in the request body. Do we still use the namespace context from the document or do we use definitions from the xpointer context or do we use the body context when appending new data ? Some interesting cases arise when we want to e.g. append a new node like this xmlns(x=http://example.com/foo) xpointer(/x:root/x:a) where body equals Given the document root had the same prefixed namespace definition how should the xcap server append this ? Character encodings should also be addressed somehow as we are heading towards better "blind" updates, i.e. if the document uses e.g. UTF-8 encoding and the client uses charset=iso-xxx, what would be the result of an append operation ? Probably there might be some other implications as well... br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 1 02:58:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23738; Tue, 1 Feb 2005 02:58:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvtE0-0001Bm-Qw; Tue, 01 Feb 2005 03:17:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvsnn-0006bY-S7; Tue, 01 Feb 2005 02:50:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvshy-0006Ge-1c for simple@megatron.ietf.org; Tue, 01 Feb 2005 02:44:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23001 for ; Tue, 1 Feb 2005 02:44:20 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvt04-0000wM-0W for simple@ietf.org; Tue, 01 Feb 2005 03:03:05 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 31 Jan 2005 23:50:53 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j117hlNt023387; Mon, 31 Jan 2005 23:43:47 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-35.cisco.com [10.86.242.35]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHK58770; Mon, 31 Jan 2005 23:43:46 -0800 (PST) Message-ID: <41FF3331.8010008@cisco.com> Date: Tue, 01 Feb 2005 02:43:45 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari urpalainen Subject: Re: [Simple] Namespaces and XCAP References: <41FE9B4C.1070106@cisco.com> <1107242622.26454.54.camel@xitami.research.nokia.com> In-Reply-To: <1107242622.26454.54.camel@xitami.research.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit inline. jari urpalainen wrote: >>So, which to use? Considering the issues involved, I think the best >>option is 5(A). >> >>Comments? >> >>Thanks, >>Jonathan R. >> >> > > > In principle I am in favor of 5A. However, I have a difficulty > understanding why we should use a different syntax than what xpointer > spec has ? Why is it different? I was proposing to use the xmlns xpointer expression exactly as defined. > > http://www.w3.org/TR/WD-xptr > > xmlns(x=http://example.com/foo) xpointer(//x:a) Oh, so you are saying ditch the whole xpath thing in favor of xpointers for element naming? My read of xpointer was that it was primarily aimed at solving a broader problem even than path, namely being able to identify points and text ranges within an xml document. We don't need or want that. I also don't know how to map this easily into URI's, whereas xpath is easily mapped. Since the ONLY thing xpointer() would give us is syntax, what is gained?? > > Furthermore, there seems to be a tendency to use fragment identifiers, > so I would propose to use them. URL fragment identifiers? AS in #fragment-id? As an alternative to the ~~ approach in the URI? > > This leads to another issue that has to be addressed as well, i.e. the > namespaces in the request body. Do we still use the namespace context > from the document or do we use definitions from the xpointer context or > do we use the body context when appending new data ? Document. The body is either the document itself or a piece of it, in which case the namespace bindings have to be from the document. > > Some interesting cases arise when we want to e.g. append a new node like > this > > xmlns(x=http://example.com/foo) xpointer(/x:root/x:a) > > where body equals > > > > > > Given the document root had the same prefixed namespace definition how > should the xcap server append this ? What is the ambiguity? The URI provides the bindings for the URI evluation against the document. It resolves to no existing element. Great. The parent element is located (again using the URI namespace binding context), and the content of the request is inserted as its child. It happens to reset the default namespace. Perform a GET against that same URI. It now returns what was just selected. Everything is fine. If the element had redefined the default namespace to something else, the URI would no longer select the element just inserted, and the operation wouldn't meet the GET(PUT(X))==X property and be rejected. > > Character encodings should also be addressed somehow as we are heading > towards better "blind" updates, i.e. if the document uses e.g. UTF-8 > encoding and the client uses charset=iso-xxx, what would be the result > of an append operation ? Good question. This came up as a comment from others during last call. I have already added text to my working copy which says that this would be rejected. An error code has been defined for this too. Indeed, the current text mandates UTF-8 so anything but that in the charset is rejected. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 1 07:14:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22161; Tue, 1 Feb 2005 07:14:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvxDX-0007v3-CX; Tue, 01 Feb 2005 07:33:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvwmU-0003YY-4M; Tue, 01 Feb 2005 07:05:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvwmA-0003OU-35 for simple@megatron.ietf.org; Tue, 01 Feb 2005 07:04:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21225 for ; Tue, 1 Feb 2005 07:04:56 -0500 (EST) Received: from [61.95.224.109] (helo=blr.dgbmicro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvx4I-0007dP-TH for simple@ietf.org; Tue, 01 Feb 2005 07:23:43 -0500 Received: from suganya ([192.168.10.78]) (authenticated bits=0) by blr.dgbmicro.com (8.12.8/8.12.8) with ESMTP id j11C4YDx025693 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 1 Feb 2005 17:34:39 +0530 From: "Suganya" To: Date: Wed, 2 Feb 2005 05:34:25 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Found to be clean X-MailScanner-From: suganya@dgbmicro.com X-Spam-Score: 4.6 (++++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: [Simple] sip and dns X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 4.6 (++++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Hi, I have the following doubts and need some help. a) In order to contruct DNS query, I googled-up and found RFCs 1034 and 1035. But it doesn't talk of SIP. Can those guidelines be used for constructing the DNS for SIP related queries? b) Where to send the DNS query from UAC? c) Unlike RFC 3261 which clearly tells how to construct invite, ack, etc... messages, RFC 3263 specifies no syntax or query format to construct the DNS query. Regards, B.Suganya _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 1 07:45:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25309; Tue, 1 Feb 2005 07:45:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvxhl-0000Ss-7Z; Tue, 01 Feb 2005 08:04:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvxIO-0001EW-80; Tue, 01 Feb 2005 07:38:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvxBF-0008Fd-Od for simple@megatron.ietf.org; Tue, 01 Feb 2005 07:30:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24040 for ; Tue, 1 Feb 2005 07:30:51 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.193]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvxTO-0008P0-JT for simple@ietf.org; Tue, 01 Feb 2005 07:49:39 -0500 Received: by wproxy.gmail.com with SMTP id 55so1091044wri for ; Tue, 01 Feb 2005 04:30:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=oo/u6N2iX9nz8DxvyRde0dHcqp5wSjM9NpS3H70+98aJN1i91nvIHXpSmnq4xRPkCh8HXJ8La5lJAwb4SbSaV4kSyhWUVj7Tfqp1FKy//rv+EJZduhlN6S0pNlW/YmLLWlO/z4c/ngPHbC3JKCLi7q+VDs9tkz8FMHAGqQyHt5I= Received: by 10.54.54.78 with SMTP id c78mr44666wra; Tue, 01 Feb 2005 04:30:20 -0800 (PST) Received: by 10.54.54.6 with HTTP; Tue, 1 Feb 2005 04:30:20 -0800 (PST) Message-ID: Date: Tue, 1 Feb 2005 18:00:20 +0530 From: Sharath Chandra To: simple@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: [Simple] On Class X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sharath Chandra List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit How does existing Presence data model address the following issues ? 1) Unique identity for a user across the domains and networks. For a presence document to be complete it may need to handle alias for a user within the same network as well as across the domains and networks. Presence informations multiple application (not sip based sources) also needs to be handled. Is there a proposed architecture for such requirement 2) Categorizing the watchers into groups for a presentity to specify different levels of privacy and trust. Like Family, Friends, Colleagues etc. I believe once the grouping/class is available i can have more control on what data i can disclose to which class and i can make a authorization document using XCAP. Thanks, Sharath _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 1 08:53:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02697; Tue, 1 Feb 2005 08:53:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvylr-0002Gr-Hw; Tue, 01 Feb 2005 09:12:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvyRW-0004D1-QB; Tue, 01 Feb 2005 08:51:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvyLj-0003ZU-9H for simple@megatron.ietf.org; Tue, 01 Feb 2005 08:45:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01934 for ; Tue, 1 Feb 2005 08:45:44 -0500 (EST) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvydr-00024y-FU for simple@ietf.org; Tue, 01 Feb 2005 09:04:33 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j11Dja820604; Tue, 1 Feb 2005 15:45:36 +0200 (EET) X-Scanned: Tue, 1 Feb 2005 15:44:42 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j11DigTj012764; Tue, 1 Feb 2005 15:44:42 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00LEe70T; Tue, 01 Feb 2005 15:44:17 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j11Di7U27095; Tue, 1 Feb 2005 15:44:07 +0200 (EET) Received: from [192.168.1.186] ([10.162.252.142]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 1 Feb 2005 15:44:05 +0200 Message-ID: <41FF87A5.3060301@nokia.com> Date: Tue, 01 Feb 2005 15:44:05 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Paul Kyzivat Subject: Single tuple or many tuples (was: Re: [Simple] another try at data model compromise regarding unique service URI) References: <41F33C72.2070306@cisco.com> <41F778F5.8040004@nokia.com> <41FA2D02.3020008@cisco.com> <41FE4707.8030602@nokia.com> <41FE4F2C.8000806@cisco.com> <41FE5B74.3020105@nokia.com> <41FE6C99.6060708@cisco.com> In-Reply-To: <41FE6C99.6060708@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Feb 2005 13:44:05.0829 (UTC) FILETIME=[18F37F50:01C50864] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit ext Paul Kyzivat wrote: ...snip... > For devices with the real estate, it would be better to simply display > multiple icons for each buddy indicating what capabilities are currently > available. (Perhaps icons of phones and cameras can turn from red to > green.) I don't buy this. Think of a "doom" icon that can be either red, green, or indicate deathmatch. Capabilities are uninportant, it's the service that is composed of those capabilities that is important. And do you really think users will generally be happy to interpret that someone is available for push-to-talk by examining a set of three (or more) icons? ...snip... >> Even further, for some services, audio can be "on" while for others >> "off". Take for example, push-to-talk, voice, and video call in a >> single device. How can you describe a different stratus for each of >> these services using a single tuple? > > > I still don't understand your model of how the device works. > > You seem to have in mind a "video service" that includes both voice and > video, and a separate "audio service" that includes only audio. And then > either or both can be available. I gave an example of *three* different services. But fine, let's say you only have two: a videophone capable of both video and audio (together or separate) and a push-to-talk client (audio, half-duplex and floor control). Now, let's say video is unavailable, audio is available, and push-to-talk is unavailable. How would you represent that in a single tuple? > But how is this better (or even as good as) a single videophone service > that is capable of supporting both voice and video, or just voice, or > just video, depending on what is negotiated in a call? With such a > service, if I don't want to be available for video, I just disable it, > so it won't be offered or answered, and then video then isn't advertised > in the (single) presence tuple either. I'm not going to debate over details about voice and/or video. My attempt was to demonstrate that there are "services" that aren't going to be described only using a single, simple media attribute, like "voice" and "video", but will be composed of a set of capabilities, where this capability set then shares a status that will have more states available than simple on or off. However, stepping back for a moment. Seems there is still some fundamental desire here to restrict the presence data model to suit the "unique-URI" concept. But like Henning has pointed out many times before, there will be multiple tuples in a document. So inherently, the watcher is faced with having to make a selection. Henning has also pointed out that to determine uniqueness, the contact is a very poor key to use. Whether some of those tuples have the contact address is therefore immaterial (and depends exclusively on the uniqueness rules of the URI scheme). Also, we aren't going to forbid a dumb composer passing all of the received tuples to the watcher using the union composition. If we were to *mandate* that all SIP-enabled services are represented using a single tuple, where would you enforce this rule? And what would be the benefit compared to allowing more than a single tuple? Simply saying that it is possible in some instances to do things that way is not a good enough reason, if there are instances where it does not work. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From QVILIIZALIKN@msn.com Tue Feb 1 09:19:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07353; Tue, 1 Feb 2005 09:19:26 -0500 (EST) Received: from host16-102.pool80183.interbusiness.it ([80.183.102.16]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CvzAU-0002zO-9L; Tue, 01 Feb 2005 09:38:16 -0500 Received: from mensurable.webhost1.alterusa.com id CFB65664DE; Tue, 01 Feb 2005 07:19:42 -0700 Received: by intrusive.webhost4.starnetusa.net (Postfix, from userid 630) id CFB62814DE; Tue, 01 Feb 2005 19:14:42 +0500 Date: Tue, 01 Feb 2005 18:18:42 +0400 Message-Id: <28361130090241.CFB3248DE@goddard.starnetusa.net> From: "Cyrus Weeks" To: secdir-web-archive@ietf.org Cc: secretariat@ietf.org, secretary@ietf.org, sg@ietf.org, sic@ietf.org, sigtran@ietf.org, sigtran-admin@ietf.org, simple@ietf.org, simple-admin@ietf.org, simple-archive@ietf.org Subject: Everyone Need This Secdir-web-archive X-Spam-Score: 2.3 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 The L0west price of all med's is here. Viicodin - $199.95 Codeine - $189.95 V1a'gra - $199.95 Va|ium - $259.95 Cia|is - $189.95 Xa'nax - $233.95 and many m0reeee..... We are the bes't available nowadays http://uhviagra.info/in.php?aid=56 This is 1 tiime maillling. N0-removalll are requiired QoOvm6UUvXqmXCBDaOTF505BagSBHxszmPywjEZTAb8 From simple-bounces@ietf.org Tue Feb 1 10:11:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13439; Tue, 1 Feb 2005 10:11:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvzzK-0004a1-RT; Tue, 01 Feb 2005 10:30:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvzaj-0004MR-2y; Tue, 01 Feb 2005 10:05:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvzTk-0001Qk-Vj for simple@megatron.ietf.org; Tue, 01 Feb 2005 09:58:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11688 for ; Tue, 1 Feb 2005 09:58:07 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvzlu-0004Ce-4R for simple@ietf.org; Tue, 01 Feb 2005 10:16:55 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 01 Feb 2005 06:59:30 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j11EvXRO012572; Tue, 1 Feb 2005 06:57:34 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOT30756; Tue, 1 Feb 2005 09:57:32 -0500 (EST) Message-ID: <41FF98DC.8060605@cisco.com> Date: Tue, 01 Feb 2005 09:57:32 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: Single tuple or many tuples (was: Re: [Simple] another try at data model compromise regarding unique service URI) References: <41F33C72.2070306@cisco.com> <41F778F5.8040004@nokia.com> <41FA2D02.3020008@cisco.com> <41FE4707.8030602@nokia.com> <41FE4F2C.8000806@cisco.com> <41FE5B74.3020105@nokia.com> <41FE6C99.6060708@cisco.com> <41FF87A5.3060301@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: 7bit Aki Niemi wrote: > > > ext Paul Kyzivat wrote: > > ...snip... > >> For devices with the real estate, it would be better to simply display >> multiple icons for each buddy indicating what capabilities are >> currently available. (Perhaps icons of phones and cameras can turn >> from red to green.) > > I don't buy this. Think of a "doom" icon that can be either red, green, > or indicate deathmatch. Capabilities are uninportant, it's the service > that is composed of those capabilities that is important. I don't understand your point at all. It seems to me that either: - you have a separate tuple/service for Doom, with its own unique contact that I can call. In this case doom itself may have "doom" capability, and perhaps audio, video, etc. as well. you then have other contacts with differing sets of capabilities and different contact addresses. Perhaps one with basic voice. - you have a single multipurpose tuple/service. It has capabilities for voice, and maybe doom as well. - you have multiple tuples - one for doom, another for basic voice, but they share a contact address. The question is, how do I know what to expect when making a call in each case? E.g. if I make a voice-only call, do I talk to you, or do I hear the audio from a doom game I can't control? I guess it depends a bit on how you expect doom to work. Do you imagine it to consist of a game control protocol plus audio and video streams rendering the game? > And do you really think users will generally be happy to interpret that > someone is available for push-to-talk by examining a set of three (or > more) icons? I see a couple of alternatives here: - the user has a PTT application displaying presence. It is only interested in PTT, so it filters what it displays. All I get is a list of buddies with red or green status. - the user has a general purpose presence client, that can do PTT, regular voice, video, Doom, whatever. (The user has to both pick a buddy and then pick an action to do something.) In this case, it has three or more things to display regardless of how the RPID document is formatted. Either it has multiple capabilities for a single tuple, or it has multiple tuples each with (potentially multiple) capabilities. There are many ways of rendering each of these, but the fundamental complexity of what is to be rendered is pretty much the same. >> You seem to have in mind a "video service" that includes both voice >> and video, and a separate "audio service" that includes only audio. >> And then either or both can be available. > > > I gave an example of *three* different services. But fine, let's say you > only have two: a videophone capable of both video and audio (together or > separate) and a push-to-talk client (audio, half-duplex and floor > control). Now, let's say video is unavailable, audio is available, and > push-to-talk is unavailable. > > How would you represent that in a single tuple? I left out the PTT to keep things simple, since I don't think we have agreed in detail how to represent it as a capability. But lets try anyway. In the state you describe it, I would simply represent it as a tuple with audio=true, video=false, duplex=full, floor-control=false. What is so hard about that? >> But how is this better (or even as good as) a single videophone >> service that is capable of supporting both voice and video, or just >> voice, or just video, depending on what is negotiated in a call? With >> such a service, if I don't want to be available for video, I just >> disable it, so it won't be offered or answered, and then video then >> isn't advertised in the (single) presence tuple either. > > > I'm not going to debate over details about voice and/or video. My > attempt was to demonstrate that there are "services" that aren't going > to be described only using a single, simple media attribute, like > "voice" and "video", but will be composed of a set of capabilities, > where this capability set then shares a status that will have more > states available than simple on or off. Ahh. This may be hinting at the real issue. But it is only a hint, and I think you need to say a lot more to establish the use case. I've got a feeling that PTT is a bad example because its "differences" are more about limitations in the technology that intrinsic feature differences. I suspect Doom may be a better example. I have the idea that what you have in mind is that when I call the "Doom Service" I get audio and video that are slaved to the game, rather than a conversational adjunct to the game that allows me to converse with the other player(s) while playing. If so, then it is a lot like an IVR or a VM server. If so, then I agree with you that it *should* be represented as a separate tuple. But I also think it *should* have a separate contact, so that it is clear how to reach that particular service. I gather you have in mind that if I negotiate the doom control protocol I will get the doom service and the audio/video will be slaved to it, but if I don't negotiate the doom control protocol then I get the "conversational" service managing my voice/video. I don't see why I would be able to draw that conclusion from the RPID. > However, stepping back for a moment. > > Seems there is still some fundamental desire here to restrict the > presence data model to suit the "unique-URI" concept. > > But like Henning has pointed out many times before, there will be > multiple tuples in a document. So inherently, the watcher is faced with > having to make a selection. Henning has also pointed out that to > determine uniqueness, the contact is a very poor key to use. Whether > some of those tuples have the contact address is therefore immaterial > (and depends exclusively on the uniqueness rules of the URI scheme). > Also, we aren't going to forbid a dumb composer passing all of the > received tuples to the watcher using the union composition. In most cases I see no reason why the watcher has a need to determine uniqueness. All it has to do is present the alternatives to the user, let the user choose one, and send a request to the contact of the one chosen. The kind of request sent can either be determined by default based on capabilities advertised in the tuple and local capabilities, or can be adjusted based on explicit choices made by the user. > If we were to *mandate* that all SIP-enabled services are represented > using a single tuple, where would you enforce this rule? And what would > be the benefit compared to allowing more than a single tuple? I'm not sure this is something to mandate. I think it is more of a "best practices" kind of thing. It seems clear that people are going to do a bunch of weird things, and results will vary. About all we can do is give suggestions on how to get a good result. > Simply saying that it is possible in some instances to do things that > way is not a good enough reason, if there are instances where it does > not work. I think this might best be approached by restarting the work on presence use cases. Here is (a bad) one, based on what I think you have in mind. (Please feel free to provide a better way to handle this case.) Suppose your presence includes one tuple listing audio, video, and doom. My presence client doesn't understand doom or video, so it simply renders the tuple as available for voice. I pick it and make a voice call. Your Doom service slaves audio to the game, so I just hear a bunch of bleeps and gun fire. I am likely to be annoyed with you for having announced that you were available for voice when you were not. Or, your UA refused my call because I didn't offer doom control protocol. I'm still annoyed that you said you were available for voice but refused my call. (But at least this is within the realm of reasonable behaviors.) Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 1 11:04:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19964; Tue, 1 Feb 2005 11:04:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw0nv-00061K-HB; Tue, 01 Feb 2005 11:23:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw0UR-00051t-VZ; Tue, 01 Feb 2005 11:02:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw0IB-0002rT-3Z for simple@megatron.ietf.org; Tue, 01 Feb 2005 10:50:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18584 for ; Tue, 1 Feb 2005 10:50:13 -0500 (EST) Message-Id: <200502011550.KAA18584@ietf.org> Received: from winwebhosting.com ([67.15.20.8] helo=dx24.winwebhosting.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw0aL-0005eE-Ue for simple@ietf.org; Tue, 01 Feb 2005 11:09:02 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx24.winwebhosting.com with esmtpa (Exim 4.43) id 1Cw0Gg-0003qr-KO; Tue, 01 Feb 2005 08:48:43 -0700 From: "Brian Rosen" To: "'Paul Kyzivat'" , "'Aki Niemi'" Subject: RE: Single tuple or many tuples (was: Re: [Simple] another try atdata model compromise regarding unique service URI) Date: Tue, 1 Feb 2005 10:49:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcUIcEP9sx2X6kR8Rk+WPZd2y4VoYQAArVRQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <41FF98DC.8060605@cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx24.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Content-Transfer-Encoding: 7bit I've pretty much stayed out of this whole set of threads, but this one really had me wondering where everyone's head is again. We're getting wrapped around the axle of not having a definition of "service" again. Specifically, I believe that the Doom case you describe below is a Service called Doom that has a number of media streams it supports. It does NOT offer a voice SERVICE, the DOOM service includes game, audio and video media capability. Now the TUPLE might offer a voice SERVICE, in addition to Doom, possibly using the same hardware, possibly not. You don't care. PTT is a SERVICE. It supports voice, possibly video and has floor control. But there is nothing in the set of capabilities such as: audio=true, video=false, duplex=full, floor-control=false that could possibly indicates PTT isn't there. A dumb but straightforward audio conference phone could have exactly the same capabilities. The dumb conference phone could have that also. The "floor control=true" and "duplex=half" capabilities, in particular, are not peculiar to PTT. A cell phone with PTT today would have at least two services (voice and PTT). Today, those services are separate; even the voice path is separate in many implementations. And please keep in mind that I want to be able to offer a presence service with ONE contact, which I assumed was one tuple, but don't care if there are multiple tuples as long as they have the same contact URI. That represents the presence information of the presentity, full stop, including all of the services it might support. Brian > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Tuesday, February 01, 2005 9:58 AM > To: Aki Niemi > Cc: Simple WG > Subject: Re: Single tuple or many tuples (was: Re: [Simple] another try > atdata model compromise regarding unique service URI) > > > > Aki Niemi wrote: > > > > > > ext Paul Kyzivat wrote: > > > > ...snip... > > > >> For devices with the real estate, it would be better to simply display > >> multiple icons for each buddy indicating what capabilities are > >> currently available. (Perhaps icons of phones and cameras can turn > >> from red to green.) > > > > I don't buy this. Think of a "doom" icon that can be either red, green, > > or indicate deathmatch. Capabilities are uninportant, it's the service > > that is composed of those capabilities that is important. > > I don't understand your point at all. > > It seems to me that either: > > - you have a separate tuple/service for Doom, with its own unique > contact that I can call. In this case doom itself may have > "doom" capability, and perhaps audio, video, etc. as well. > > you then have other contacts with differing sets of capabilities > and different contact addresses. Perhaps one with basic voice. > > - you have a single multipurpose tuple/service. It has capabilities > for voice, and maybe doom as well. > > - you have multiple tuples - one for doom, another for basic voice, > but they share a contact address. > > The question is, how do I know what to expect when making a call in each > case? E.g. if I make a voice-only call, do I talk to you, or do I hear > the audio from a doom game I can't control? > > I guess it depends a bit on how you expect doom to work. Do you imagine > it to consist of a game control protocol plus audio and video streams > rendering the game? > > > And do you really think users will generally be happy to interpret that > > someone is available for push-to-talk by examining a set of three (or > > more) icons? > > I see a couple of alternatives here: > > - the user has a PTT application displaying presence. It is only > interested in PTT, so it filters what it displays. All I get is a > list of buddies with red or green status. > > - the user has a general purpose presence client, that can do PTT, > regular voice, video, Doom, whatever. (The user has to both pick > a buddy and then pick an action to do something.) > > In this case, it has three or more things to display regardless > of how the RPID document is formatted. Either it has multiple > capabilities for a single tuple, or it has multiple tuples each > with (potentially multiple) capabilities. There are many ways > of rendering each of these, but the fundamental complexity of > what is to be rendered is pretty much the same. > > >> You seem to have in mind a "video service" that includes both voice > >> and video, and a separate "audio service" that includes only audio. > >> And then either or both can be available. > > > > > > I gave an example of *three* different services. But fine, let's say you > > only have two: a videophone capable of both video and audio (together or > > separate) and a push-to-talk client (audio, half-duplex and floor > > control). Now, let's say video is unavailable, audio is available, and > > push-to-talk is unavailable. > > > > How would you represent that in a single tuple? > > I left out the PTT to keep things simple, since I don't think we have > agreed in detail how to represent it as a capability. But lets try anyway. > > In the state you describe it, I would simply represent it as a tuple > with audio=true, video=false, duplex=full, floor-control=false. What is > so hard about that? > > >> But how is this better (or even as good as) a single videophone > >> service that is capable of supporting both voice and video, or just > >> voice, or just video, depending on what is negotiated in a call? With > >> such a service, if I don't want to be available for video, I just > >> disable it, so it won't be offered or answered, and then video then > >> isn't advertised in the (single) presence tuple either. > > > > > > I'm not going to debate over details about voice and/or video. My > > attempt was to demonstrate that there are "services" that aren't going > > to be described only using a single, simple media attribute, like > > "voice" and "video", but will be composed of a set of capabilities, > > where this capability set then shares a status that will have more > > states available than simple on or off. > > Ahh. This may be hinting at the real issue. But it is only a hint, and I > think you need to say a lot more to establish the use case. I've got a > feeling that PTT is a bad example because its "differences" are more > about limitations in the technology that intrinsic feature differences. > > I suspect Doom may be a better example. I have the idea that what you > have in mind is that when I call the "Doom Service" I get audio and > video that are slaved to the game, rather than a conversational adjunct > to the game that allows me to converse with the other player(s) while > playing. If so, then it is a lot like an IVR or a VM server. If so, then > I agree with you that it *should* be represented as a separate tuple. > But I also think it *should* have a separate contact, so that it is > clear how to reach that particular service. > > I gather you have in mind that if I negotiate the doom control protocol > I will get the doom service and the audio/video will be slaved to it, > but if I don't negotiate the doom control protocol then I get the > "conversational" service managing my voice/video. I don't see why I > would be able to draw that conclusion from the RPID. > > > However, stepping back for a moment. > > > > Seems there is still some fundamental desire here to restrict the > > presence data model to suit the "unique-URI" concept. > > > > But like Henning has pointed out many times before, there will be > > multiple tuples in a document. So inherently, the watcher is faced with > > having to make a selection. Henning has also pointed out that to > > determine uniqueness, the contact is a very poor key to use. Whether > > some of those tuples have the contact address is therefore immaterial > > (and depends exclusively on the uniqueness rules of the URI scheme). > > Also, we aren't going to forbid a dumb composer passing all of the > > received tuples to the watcher using the union composition. > > In most cases I see no reason why the watcher has a need to determine > uniqueness. All it has to do is present the alternatives to the user, > let the user choose one, and send a request to the contact of the one > chosen. The kind of request sent can either be determined by default > based on capabilities advertised in the tuple and local capabilities, or > can be adjusted based on explicit choices made by the user. > > > If we were to *mandate* that all SIP-enabled services are represented > > using a single tuple, where would you enforce this rule? And what would > > be the benefit compared to allowing more than a single tuple? > > I'm not sure this is something to mandate. I think it is more of a "best > practices" kind of thing. It seems clear that people are going to do a > bunch of weird things, and results will vary. About all we can do is > give suggestions on how to get a good result. > > > Simply saying that it is possible in some instances to do things that > > way is not a good enough reason, if there are instances where it does > > not work. > > I think this might best be approached by restarting the work on presence > use cases. > > Here is (a bad) one, based on what I think you have in mind. (Please > feel free to provide a better way to handle this case.) > > Suppose your presence includes one tuple listing audio, video, and doom. > My presence client doesn't understand doom or video, so it simply > renders the tuple as available for voice. I pick it and make a voice > call. Your Doom service slaves audio to the game, so I just hear a bunch > of bleeps and gun fire. I am likely to be annoyed with you for having > announced that you were available for voice when you were not. > > Or, your UA refused my call because I didn't offer doom control > protocol. I'm still annoyed that you said you were available for voice > but refused my call. (But at least this is within the realm of > reasonable behaviors.) > > Paul > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From Hopkins@doneasy.com Tue Feb 1 11:22:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21909; Tue, 1 Feb 2005 11:22:58 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw160-0006Vn-Qe; Tue, 01 Feb 2005 11:41:48 -0500 Received: from m154.net81-66-128.noos.fr ([81.66.128.154]) by mx2.foretec.com with smtp (Exim 4.24) id 1Cw0nn-0007SN-4L; Tue, 01 Feb 2005 11:22:55 -0500 Received: from [155.8.120.194] by becalm%DIGITS.brawl.81.66.128.154 via HTTP; Tue, 01 Feb 2005 11:22:23 -0800 Reply-To: "l Reeves Limited" From: "l Reeves Limited" To: Subject: Match Found Date: Tue, 01 Feb 2005 11:22:23 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--8156894658sblv5321" Message-Id: X-Spam-Score: 14.6 (++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----8156894658sblv5321 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable 4 unfaithful wives have been matched for you in your area: 1) Melissa, 134 lbs, 5'8, 36c, 21 miles away, available Jan 31- Feb 7rd 2) Jennifer, 120 lbs, 5'6, 36d, 12 miles away, available Jan 30- Feb 5rd 3) Courtney, 124 lbs, 5'9, 34b, 12 miles away, available most nights (husb= and works midnights) 4) Rebecca, 127 lbs, 5'9, 36c, 10 miles away, available most week nights (= looking for side-fling) All 4 women are waiting to speak with you live & have photos. Webcam's are= available for all 4. http://godatetomorrow.com/d/10.php If you have found a lady or not to be paired up then continue. http://godatetomorrow.com/out/=20 ----8156894658sblv5321-- From simple-bounces@ietf.org Tue Feb 1 13:54:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06045; Tue, 1 Feb 2005 13:54:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw3Su-0001tu-2C; Tue, 01 Feb 2005 14:13:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw2uw-0001vh-TR; Tue, 01 Feb 2005 13:38:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw2rb-0001Ao-Vb for simple@megatron.ietf.org; Tue, 01 Feb 2005 13:35:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04357 for ; Tue, 1 Feb 2005 13:34:57 -0500 (EST) Received: from voyager.coretrek.no ([212.33.142.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw39f-0001Pn-4K for simple@ietf.org; Tue, 01 Feb 2005 13:53:48 -0500 Received: from localhost (localhost [127.0.0.1]) by voyager.coretrek.no (Postfix) with ESMTP id C46B2A9752; Tue, 1 Feb 2005 19:34:10 +0100 (CET) Received: from [192.168.1.59] (unknown [82.196.203.62]) by voyager.coretrek.no (Postfix) with ESMTP id 90E23A9741; Tue, 1 Feb 2005 19:34:07 +0100 (CET) In-Reply-To: <91C9464F6AFC0647A2D8069E25DBF496A8F570@EXC01B.cselt.it> References: <91C9464F6AFC0647A2D8069E25DBF496A8F570@EXC01B.cselt.it> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <21c9f0516f64065acb11c946f16094fb@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Presence data model: in Date: Tue, 1 Feb 2005 19:34:05 +0100 To: Goix Walter X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1) X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Cc: krisztian.kiss@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit On Jan 30, 2005, at 1:40 PM, Goix Walter wrote: > Krisztian, > > The examples in the presence data model draft identify as > an element under , but that's probably what you had in mind. > However, I don't clearly see the rationale for multiple > within a single . Multiple devices for the same presentity may > offer exactly the same service, but they probably would need no > element to get the ability to be merged into a single > at the server. In that case, if one device updates its > inserting a element (max 1 in PIDF ), then both > tuples will need to be separated again. Same if another property of a > single device is updated. I personally see more complications > than benefits allowing multiple per . Is there a > real requirement for such an optimization? Think of it as multiple PUAs publishing tuples about the same service, and placing the AoR as the contact. The compositor may decide to merge those tuples, it is nice, but maybe not useful, for the watcher to see that this service is available on multiple devices. /Hisham > > I agree that no namespace nor schema is defined for this extension. > Maybe the following declaration could be used: > > > > Walter > > -----Original Message----- > From: simple-bounces@ietf.org on behalf of krisztian.kiss@nokia.com > Sent: Fri 1/28/2005 10:54 AM > To: simple@ietf.org > Subject: [Simple] Presence data model: in > > > draft-ietf-simple-presence-data-model-01 allows to include a > or a list of s serving as correlation > identifier(s). > > Section 5.1.2 contains schema definition for including > , i.e.: > > > > I would assume that if appears under , another > schema definition would be required, something like: > > maxOccurs="unbounded"/> > > Should this extension be added to the draft? > > Thanks, > Krisztian > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia > S.p.A. > > ==================================================================== > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > MailAdmin@tilab.com. Thank you > ==================================================================== > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 1 14:02:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06796; Tue, 1 Feb 2005 14:02:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw3aI-000252-1W; Tue, 01 Feb 2005 14:21:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw3BZ-0005DL-IK; Tue, 01 Feb 2005 13:55:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw37i-0004AF-I2 for simple@megatron.ietf.org; Tue, 01 Feb 2005 13:51:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05808 for ; Tue, 1 Feb 2005 13:51:36 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw3Pv-0001nd-1o for simple@ietf.org; Tue, 01 Feb 2005 14:10:27 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 01 Feb 2005 10:58:16 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j11Iowl2000476; Tue, 1 Feb 2005 10:50:59 -0800 (PST) Received: from cisco.com ([161.44.79.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOT54189; Tue, 1 Feb 2005 13:51:02 -0500 (EST) Message-ID: <41FFCF96.90707@cisco.com> Date: Tue, 01 Feb 2005 13:51:02 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: Single tuple or many tuples (was: Re: [Simple] another try atdata model compromise regarding unique service URI) References: <3q2adl$17u3rq@sj-inbound-e.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Content-Transfer-Encoding: 7bit Cc: "'Aki Niemi'" , "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 Content-Transfer-Encoding: 7bit Brian - inline. Paul Brian Rosen wrote: > I've pretty much stayed out of this whole set of threads, but this one > really had me wondering where everyone's head is again. > > We're getting wrapped around the axle of not having a definition of > "service" again. Well, we had decided that a service is whatever a tuple describes. But functionally I agree it has still not really been resolved. > Specifically, I believe that the Doom case you describe below is a Service > called Doom that has a number of media streams it supports. It does NOT > offer a voice SERVICE, the DOOM service includes game, audio and video media > capability. I infer that you are using "service" to denote what kind of functionality is provided via the communication channel(s) described. So in this case there is an automaton executing the Doom game, providing a rendering of that via the output streams, and accepting input to it via the input streams. > Now the TUPLE might offer a voice SERVICE, in addition to Doom, possibly > using the same hardware, possibly not. You don't care. We currently have no definition of, or way to describe, services such as these. The closest we can get to this right now is via a few attributes: - automaton - attendant - message-taker If all of those are false, in absence of any extentions, I think you have a "conversational" service facilitating interactive conversation with a human being. Even with the limited range of "service"s that can be represented via those attributes, it is impossible to say in a single tuple that you have a conversational service and an automated message taking service, except in the negative - by saying nothing about what is provided. > PTT is a SERVICE. It supports voice, possibly video and has floor control. From what I have inferred above, I don't see how this can be considered a service. It says nothing about the content, and its not an automaton. It simply provides different ways to control the media in a conversational session - like a different codec does. > But there is nothing in the set of capabilities such as: audio=true, > video=false, duplex=full, floor-control=false that could possibly indicates > PTT isn't there. A dumb but straightforward audio conference phone could > have exactly the same capabilities. The dumb conference phone could have > that also. The "floor control=true" and "duplex=half" capabilities, in > particular, are not peculiar to PTT. A cell phone with PTT today would have > at least two services (voice and PTT). Today, those services are separate; > even the voice path is separate in many implementations. Why is this any different than audio vs video? I might want to have a conversation with you using any of those, and switch back and forth between them during the call. I think I know the answer, but its not an appealing one - the UA will simply not permit mixing the capabilities in a single call, or even switching among them serially within a call. Of course there are lots of technological excuses for this, but it makes no real sense from a user standpoint. I can at least imagine using PTT to talk to a VM "service" or auto attendant "service". This all suggests to me that PTT is not a service in the sense that Doom might me. The PTT case is, I think, just a matter of wanting a way to describe mutually exclusive combinations of capabilities. I believe we agreed some weeks ago that this was potentially still of interest, but postponed dealing with it. Until then, multiple tuples with the same contact provides a way at the expense of being ambiguous about what is intended. I have been trying for years now to understand what you "service" oriented people are talking about. It always seems like there is *something* there, but its elusive, and you don't all seem to have the same concept. I think there may be some opportunity to describe this as the behavior behind the media, encompassing VM, Attendant, Doom. > And please keep in mind that I want to be able to offer a presence service > with ONE contact, which I assumed was one tuple, but don't care if there are > multiple tuples as long as they have the same contact URI. That represents > the presence information of the presentity, full stop, including all of the > services it might support. You have been quiet for so long now that I thought you had got the correct religion, or fallen asleep, or something. :-) If you are going to offer a single tuple, and hide both a conversational voice service and Doom behind it, I don't see how you are going to avoid disappointing someone. Somebody is going to end up on their phone talking to a doom game. > Brian > > >>-----Original Message----- >>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf >>Of Paul Kyzivat >>Sent: Tuesday, February 01, 2005 9:58 AM >>To: Aki Niemi >>Cc: Simple WG >>Subject: Re: Single tuple or many tuples (was: Re: [Simple] another try >>atdata model compromise regarding unique service URI) >> >> >> >>Aki Niemi wrote: >> >>> >>>ext Paul Kyzivat wrote: >>> >>>...snip... >>> >>> >>>>For devices with the real estate, it would be better to simply display >>>>multiple icons for each buddy indicating what capabilities are >>>>currently available. (Perhaps icons of phones and cameras can turn >>>>from red to green.) >>> >>>I don't buy this. Think of a "doom" icon that can be either red, green, >>>or indicate deathmatch. Capabilities are uninportant, it's the service >>>that is composed of those capabilities that is important. >> >>I don't understand your point at all. >> >>It seems to me that either: >> >>- you have a separate tuple/service for Doom, with its own unique >> contact that I can call. In this case doom itself may have >> "doom" capability, and perhaps audio, video, etc. as well. >> >> you then have other contacts with differing sets of capabilities >> and different contact addresses. Perhaps one with basic voice. >> >>- you have a single multipurpose tuple/service. It has capabilities >> for voice, and maybe doom as well. >> >>- you have multiple tuples - one for doom, another for basic voice, >> but they share a contact address. >> >>The question is, how do I know what to expect when making a call in each >>case? E.g. if I make a voice-only call, do I talk to you, or do I hear >>the audio from a doom game I can't control? >> >>I guess it depends a bit on how you expect doom to work. Do you imagine >>it to consist of a game control protocol plus audio and video streams >>rendering the game? >> >> >>>And do you really think users will generally be happy to interpret that >>>someone is available for push-to-talk by examining a set of three (or >>>more) icons? >> >>I see a couple of alternatives here: >> >>- the user has a PTT application displaying presence. It is only >> interested in PTT, so it filters what it displays. All I get is a >> list of buddies with red or green status. >> >>- the user has a general purpose presence client, that can do PTT, >> regular voice, video, Doom, whatever. (The user has to both pick >> a buddy and then pick an action to do something.) >> >> In this case, it has three or more things to display regardless >> of how the RPID document is formatted. Either it has multiple >> capabilities for a single tuple, or it has multiple tuples each >> with (potentially multiple) capabilities. There are many ways >> of rendering each of these, but the fundamental complexity of >> what is to be rendered is pretty much the same. >> >> >>>>You seem to have in mind a "video service" that includes both voice >>>>and video, and a separate "audio service" that includes only audio. >>>>And then either or both can be available. >>> >>> >>>I gave an example of *three* different services. But fine, let's say you >>>only have two: a videophone capable of both video and audio (together or >>>separate) and a push-to-talk client (audio, half-duplex and floor >>>control). Now, let's say video is unavailable, audio is available, and >>>push-to-talk is unavailable. >>> >>>How would you represent that in a single tuple? >> >>I left out the PTT to keep things simple, since I don't think we have >>agreed in detail how to represent it as a capability. But lets try anyway. >> >>In the state you describe it, I would simply represent it as a tuple >>with audio=true, video=false, duplex=full, floor-control=false. What is >>so hard about that? >> >> >>>>But how is this better (or even as good as) a single videophone >>>>service that is capable of supporting both voice and video, or just >>>>voice, or just video, depending on what is negotiated in a call? With >>>>such a service, if I don't want to be available for video, I just >>>>disable it, so it won't be offered or answered, and then video then >>>>isn't advertised in the (single) presence tuple either. >>> >>> >>>I'm not going to debate over details about voice and/or video. My >>>attempt was to demonstrate that there are "services" that aren't going >>>to be described only using a single, simple media attribute, like >>>"voice" and "video", but will be composed of a set of capabilities, >>>where this capability set then shares a status that will have more >>>states available than simple on or off. >> >>Ahh. This may be hinting at the real issue. But it is only a hint, and I >>think you need to say a lot more to establish the use case. I've got a >>feeling that PTT is a bad example because its "differences" are more >>about limitations in the technology that intrinsic feature differences. >> >>I suspect Doom may be a better example. I have the idea that what you >>have in mind is that when I call the "Doom Service" I get audio and >>video that are slaved to the game, rather than a conversational adjunct >>to the game that allows me to converse with the other player(s) while >>playing. If so, then it is a lot like an IVR or a VM server. If so, then >>I agree with you that it *should* be represented as a separate tuple. >>But I also think it *should* have a separate contact, so that it is >>clear how to reach that particular service. >> >>I gather you have in mind that if I negotiate the doom control protocol >>I will get the doom service and the audio/video will be slaved to it, >>but if I don't negotiate the doom control protocol then I get the >>"conversational" service managing my voice/video. I don't see why I >>would be able to draw that conclusion from the RPID. >> >> >>>However, stepping back for a moment. >>> >>>Seems there is still some fundamental desire here to restrict the >>>presence data model to suit the "unique-URI" concept. >>> >>>But like Henning has pointed out many times before, there will be >>>multiple tuples in a document. So inherently, the watcher is faced with >>>having to make a selection. Henning has also pointed out that to >>>determine uniqueness, the contact is a very poor key to use. Whether >>>some of those tuples have the contact address is therefore immaterial >>>(and depends exclusively on the uniqueness rules of the URI scheme). >>>Also, we aren't going to forbid a dumb composer passing all of the >>>received tuples to the watcher using the union composition. >> >>In most cases I see no reason why the watcher has a need to determine >>uniqueness. All it has to do is present the alternatives to the user, >>let the user choose one, and send a request to the contact of the one >>chosen. The kind of request sent can either be determined by default >>based on capabilities advertised in the tuple and local capabilities, or >>can be adjusted based on explicit choices made by the user. >> >> >>>If we were to *mandate* that all SIP-enabled services are represented >>>using a single tuple, where would you enforce this rule? And what would >>>be the benefit compared to allowing more than a single tuple? >> >>I'm not sure this is something to mandate. I think it is more of a "best >>practices" kind of thing. It seems clear that people are going to do a >>bunch of weird things, and results will vary. About all we can do is >>give suggestions on how to get a good result. >> >> >>>Simply saying that it is possible in some instances to do things that >>>way is not a good enough reason, if there are instances where it does >>>not work. >> >>I think this might best be approached by restarting the work on presence >>use cases. >> >>Here is (a bad) one, based on what I think you have in mind. (Please >>feel free to provide a better way to handle this case.) >> >>Suppose your presence includes one tuple listing audio, video, and doom. >>My presence client doesn't understand doom or video, so it simply >>renders the tuple as available for voice. I pick it and make a voice >>call. Your Doom service slaves audio to the game, so I just hear a bunch >>of bleeps and gun fire. I am likely to be annoyed with you for having >>announced that you were available for voice when you were not. >> >>Or, your UA refused my call because I didn't offer doom control >>protocol. I'm still annoyed that you said you were available for voice >>but refused my call. (But at least this is within the realm of >>reasonable behaviors.) >> >> Paul >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 1 14:24:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09119; Tue, 1 Feb 2005 14:24:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw3vi-0002j2-KF; Tue, 01 Feb 2005 14:43:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw3T0-00012A-FF; Tue, 01 Feb 2005 14:13:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw3QF-0008TY-LG for simple@megatron.ietf.org; Tue, 01 Feb 2005 14:10:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07803 for ; Tue, 1 Feb 2005 14:10:42 -0500 (EST) Received: from dns2.xten.net ([64.69.76.5] helo=mail.xten.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw3iP-0002Nz-CN for simple@ietf.org; Tue, 01 Feb 2005 14:29:34 -0500 Received: from [24.85.92.32] by mail.xten.com (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.5.3)); Tue, 1 Feb 2005 11:14:14 -0800 From: "Nelson Hung" To: "'Jonathan Rosenberg'" Subject: RE: [Simple] Namespaces and XCAP Date: Tue, 1 Feb 2005 11:10:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <41FEDB61.6030102@cisco.com> Thread-Index: AcUH/fIcifLJeRVURW+xuX/YJArjtAAk7P+w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-ArGoMail-Authenticated: nelson@xten.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Inline > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Monday, January 31, 2005 5:29 PM > To: Nelson Hung > Cc: 'Simple WG' > Subject: Re: [Simple] Namespaces and XCAP > > This particular behavior in XPath 1.0 is IMHO a bug, and appears to > have been corrected in XPath 2.0. I believe that this behavior is intentional in XPath 1.0. I cannot speak for the member of XPath 1.0 working group but I guess the reason behind this behavior is that they dislike the fact that elements and attributes are not being treated uniformly => default namespace only apply to elements but not to attributes. > We are not normatively dependent on XPath, so we can do what we choose. > I would propose that the application usage specify the default > namespace. Otherwise, every single XCAP URI will need to contain a > xmlns() xpointer expression declaring the default namespace for the > documents, all of which are likely to use the target namespace as the > default. > > If we specify this, an xcap expression would be compatible with xpath > 2.0 I believe. XPath 2.0 does allow the host language to provide a default element/type namespace http://www.w3.org/TR/2004/WD-xpath20-20041029/#static_context [Definition: Default element/type namespace. This is a namespace URI or "none". The namespace URI, if present, is used for any unprefixed QName appearing in a position where an element or type name is expected.] The initial default element/type namespace may be provided by the host language. > > -Jonathan R. > > Nelson Hung wrote: > > > I agree that 5(A) is the best option. > > > > But one thing about default namespace, XPath Specification 1.0 > > explicitly disallows the use of default namespace in an XPath expression... > > > > > > http://www.w3.org/TR/xpath#node-tests > > > > > > "A QName in the node test is expanded into an expanded-name using > > the namespace declarations from the expression context. This is the > > same way expansion is done for element type names in start and > > end-tags except that the default namespace declared with xmlns is > > not used: if the QName does not have a prefix, then the namespace > > URI is null (this is the same way attribute names are expanded). It > > is an error if the QName has a prefix for which there is no namespace declaration in the expression context." > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 1 17:19:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08152; Tue, 1 Feb 2005 17:19:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw6fP-0002Qm-Qv; Tue, 01 Feb 2005 17:38:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw6FK-0000oA-Vf; Tue, 01 Feb 2005 17:11:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw60b-0005wf-Eu for simple@megatron.ietf.org; Tue, 01 Feb 2005 16:56:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03407 for ; Tue, 1 Feb 2005 16:56:28 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw6Ip-00012J-Re for simple@ietf.org; Tue, 01 Feb 2005 17:15:20 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 01 Feb 2005 14:03:08 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j11LttNt004746; Tue, 1 Feb 2005 13:55:55 -0800 (PST) Received: from [161.44.55.58] (dhcp-161-44-55-58.cisco.com [161.44.55.58]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHL09119; Tue, 1 Feb 2005 13:55:50 -0800 (PST) Message-ID: <41FFFAE6.4000802@cisco.com> Date: Tue, 01 Feb 2005 16:55:50 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nelson Hung Subject: Re: [Simple] Namespaces and XCAP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit inline. Nelson Hung wrote: > Inline > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>Sent: Monday, January 31, 2005 5:29 PM >>To: Nelson Hung >>Cc: 'Simple WG' >>Subject: Re: [Simple] Namespaces and XCAP >> >>This particular behavior in XPath 1.0 is IMHO a bug, and appears to >>have been corrected in XPath 2.0. > > > I believe that this behavior is intentional in XPath 1.0. > > I cannot speak for the member of XPath 1.0 working group but I guess the > reason behind this behavior is that they dislike the fact that elements and > attributes are not being treated uniformly => default namespace only apply > to elements but not to attributes. Sure, but thats a complaint in the way XML namespaces is done. In any cases, it doesn't matter. > > > >>We are not normatively dependent on XPath, so we can do what we choose. >>I would propose that the application usage specify the default >>namespace. Otherwise, every single XCAP URI will need to contain a >>xmlns() xpointer expression declaring the default namespace for the >>documents, all of which are likely to use the target namespace as the >>default. >> >>If we specify this, an xcap expression would be compatible with xpath >>2.0 I believe. > > > > XPath 2.0 does allow the host language to provide a default element/type > namespace > > http://www.w3.org/TR/2004/WD-xpath20-20041029/#static_context > > [Definition: Default element/type namespace. This is a namespace URI or > "none". The namespace URI, if present, is used for any unprefixed QName > appearing in a position where an element or type name is expected.] The > initial default element/type namespace may be provided by the host language. Right. So, my point is that we can choose if we want to specify the default namespace, or if the default namespace should be null as per Xpath 1.0. I see no benefit to the default being null, as this would require a namespace declaration for the default namespace for even the simplest document. As such, I would still propose that we specify in xcap that the application usage defines the default namespace. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From Green@hushmail.com Tue Feb 1 19:10:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19782; Tue, 1 Feb 2005 19:10:29 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw8OZ-0005IH-4G; Tue, 01 Feb 2005 19:29:24 -0500 Received: from adsl-68-253-33-17.dsl.ipltin.ameritech.net ([68.253.33.17]) by mx2.foretec.com with smtp (Exim 4.24) id 1Cw86H-0005vF-7e; Tue, 01 Feb 2005 19:10:29 -0500 Received: from [83.196.240.229] by princeton%DIGITS.deduce.68.253.33.17 via HTTP; Tue, 01 Feb 2005 19:09:54 -0800 Reply-To: "graffiti.net" From: "graffiti.net" To: Subject: Heyllooo, it's me Date: Tue, 01 Feb 2005 19:09:54 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--3040218448xbsg4586" Message-Id: X-Spam-Score: 2.4 (++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 ----3040218448xbsg4586 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable Would you like to keep me some company? My Husband doesn't love me anymore, I'm looking for some excitement withou= t breaking up our family. Safe way to contact me: http://godatetonight.com/d/1.php Sincerely Yours, Kayla i ----3040218448xbsg4586-- From taftkdswddernm@cypresscom.net Tue Feb 1 19:30:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21647; Tue, 1 Feb 2005 19:30:55 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw8iH-0005kb-Pv; Tue, 01 Feb 2005 19:49:50 -0500 Received: from c9068f28.virtua.com.br ([201.6.143.40]) by mx2.foretec.com with smtp (Exim 4.24) id 1Cw8Pv-0006Zj-Eb; Tue, 01 Feb 2005 19:30:47 -0500 Received: from BMOJA-WV55 (201.6.143.40) by 201.6.143.40; Tue, 01 Feb 2005 16:34:14 -0800 From: "Staint Jan Osp." To: simple@ietf.org, simple-admin@ietf.org, simple-archive@ietf.org, simple-web-archive@ietf.org, sip@ietf.org, sip-admin@ietf.org, sipping@ietf.org, sipping-admin@ietf.org, sipping-bounces@ietf.org Subject: Don't get ripped off by your phermacy! Date: Tue, 01 Feb 2005 16:34:14 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=0VO_02X1312NB_00D.064K73S0" X-Priority: 3 X-Mailer: ROU MX v0.9 Message-Id: X-Spam-Score: 5.4 (+++++) X-Spam-Flag: YES X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285 This is a multi-part message in MIME format. ------=0VO_02X1312NB_00D.064K73S0 Content-Type: multipart/alternative; boundary="----=0_00BW_07X9855QH_06S.462H76S0" ------=0_00BW_07X9855QH_06S.462H76S0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit http://yismei182.boprjdncmdhe.com/ Beer is proof that God loves us and wants us to be happy. Hatch a dream and then believe it. Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has. You can widen your life by yourself, but to deepen it you need a friend. Each encounter that becomes a friendship turns into a lifeline. One can never have too many, only too many to properly take care of. Yesterday is a dream, tomorrow but a vision. But today well lived makes every yesterday a dream of happiness, and every tomorrow a vision of hope. Look well, therefore to this day. Begin doing what you want to do now. We are not living in eternity. We have only this moment, sparkling like a star in our hand and melting like a snowflake. The problem with the world is that everyone is a few drinks behind. A book may lie dormant for fifty years or for two thousand years in a forgotten corner of a library, only to reveal, upon being opened, the marvels or the abysses that it contains, or the line that seems to have been written for me alone. In this respect the writer is not different from any other human being: whatever we say or do can have far-reaching consequences. I feel sorry for people who don't drink. When they wake up in the morning, that's as good as they're going to feel all day. Opportunity is missed by most people because it is dressed in overalls and looks like work. Time is never wasted when you're wasted all the time. Love is the beauty of the soul. Can miles truly separate you from friends... If you want to be with someone you love, aren't you already there? Beer is proof that God loves us and wants us to be happy. Take away love and our earth is a tomb. I'd rather have a bottle in front of me, than a frontal lobotomy. A happy person is not a person in a certain set of circumstances, but rather a person with a certain set of attitudes. A woman drove me to drink and I didn't even have the decency to thank her. Love is the immortal flow of energy that nourishes, extends and prese rves. Its eternal goal is life. A woman knows the face of the man she loves as a sailor knows the open sea. What the world really needs is more love and less paper work. Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. You can't wait for inspiration. You have to go after it with a club. The great thing about a computer notebook is that no matter how much you stuff into it, it doesn't get bigger or heavier. Who so loves believes the impossible. You can't wait for inspiration. You have to go after it with a club. Books are the shoes with which we tread the footsteps of great minds. Always remember that I have taken more out of alcohol than alcohol has taken out of me. Love is life. And if you miss love, you miss life. Love takes up where knowledge leaves off. Love is composed of a single soul inhabiting two bodies. Nothing splendid has ever been achieved except by those who dared believe that something inside them was superior to circumstances. The best proof of love is trust. Love is the beauty of the soul. Can miles truly separate you from friends... If you want to be with someone you love, aren't you already there? An intelligent man is sometimes forced to be drunk to spend time with his fools. The only time you run out of chances is when you stop taking them. Who so loves believes the impossible. A book may lie dormant for fifty years or for two thousand years in a forgotten corner of a library, only to reveal, upon being opened, the marvels or the abysses that it contains, or the line that seems to have been written for me alone. In this respect the writer is not different from any other human being: whatever we say or do can have far-reaching consequences. The quality of the moment is more important than the number of our days. Drinking provides a beautiful excuse to pursue the one activity that truly gives me pleasure -- hooking up with fat, hairy girl s. The problem with the world is that everyone is a few drinks behind. Compassion alone stands apart from the continuous traffic between good and evil proceeding within us. Life's challenges are not supposed to paralyze you, they're supposed to help you discover who you are. Treat everyone with politeness, even those who are rude to you. Not because they are nice, but because you are. The best proof of love is trust. I'd rather have a bottle in front of me than a ... brain operation. Nothing splendid has ever been achieved except by those who dared believe that something inside them was superior to circumstances. Without question, the greatest invention in the history of mankind is beer. Oh, I grant you that the wheel was also a fine invention, but the wheel does not go nearly as well with pizza. Always do sober what you said you'd do drunk. That will teach you to keep your mouth shut. The man who says I told you so is making an excuse for not expressing his position clearly in the first place. No matter what looms ahead, if you can eat today, enjoy today, mix good cheer with friends today enjoy it and bless God for it. Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has. Try not to become a man of success but rather to become a man of value. I'd rather have a bottle in front of me, than a frontal lobotomy. 24 hours in a day, 24 beers in a case. Coincidence? Solitude, if rightly used, becomes not only a privilege but a necessity. Only a superficial soul fears to fraternize with itself. An intelligent man is sometimes forced to be drunk to spend time with his fools. What contemptible scoundrel has stolen the cork to my lunch? Try not to become a man of success but rather to become a man of value. The Babylon project was our last, best hope for peace. .. It failed. .. But in the year of the Shadow war it became something greater: our last, best hope .. for victory. The year is 2260, the place: Babylon 5.Memory is a child walking along a seashore. You never can tell what small pebble it will pick up and store away among its treasured things. When love is not madness, it is not love. No elected body is the country, we are the country. You and me. Us. It can only stay that way as long as we care to keep it so. When you're in love you never really know whether your elation comes from the qualities of the one you love, or if it attributes them to her; whether the light which surrounds her like a halo comes from you, from her, or from the meeting of your sparks. The man who says I told you so is making an excuse for not expressing his position clearly in the first place. Love takes off masks that we fear we cannot live without and know we cannot live within. You can't be a real country unless you have a beer and an airline. It helps if you have some kind of a football team, or some nuclear weapons, but at the very least you need a beer. No dictator, no invader, can hold an imprisoned population by force of arms forever. There is no greater power in the universe than the need for freedom. Against that power, governments and tyrants and armies cannot stand. Love does not begin and end the way we seem to think it does. Love is a battle, love is a war; love is a growing up. Autumn is the time when seasons merge because of bare necessity. Hatch a dream and then believe it. Compassion alone stands apart from the continuous traffic between good and evil proceeding within us. Begin doing what you want to do now. We are not living in eternity. We have only this moment, sparkling like a star in our hand and melting like a snowflake. Reduce the complexity of life by eliminating the needless wants of life, and the labors of life reduce themselves. A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a shp, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. Memory is a child walking along a seashore. You never can tell what small pebble it will pick up and store away among its treasured things. The ultimate measure of a man is not where he stands in moments of comfort and convenience, but where he stands in times of challenge and controversy. No elected body is the country, we are the country. You and me. Us. It can only stay that way as long as we care to keep it so. Love is the immortal flow of energy that nourishes, extends and preserves. Its eternal goal is life. Drinking provides a beautiful excuse to pursue the one activity that truly gives me pleasure -- hooking up with fat, hairy girls. Beer is proof that God loves us and wants us to be happy. A woman knows the face of the man she loves as a sailor knows the open sea. Books are the shoes with which we tread the footsteps of great minds. What contemptible scoundrel has stolen the cork to my lunch? Distance between two hearts is not an obstacle; rather a great reminder of just how strong true love can be. 24 hours in a day, 24 beers in a case. Coincidence? ------=0_00BW_07X9855QH_06S.462H76S0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 3D"" Beer is proof that God loves us and wants us to be happ= y. Hatch a dream and then believe it. Never doubt that a small group of th= oughtful, committed citizens can change the world. Indeed, it is the only = thing that ever has. You can widen your life by yourself, but to deepen it= you need a friend. Each encounter that becomes a friendship turns into a = lifeline. One can never have too many, only too many to properly take care= of. Yesterday is a dream, tomorrow but a vision. But today well lived mak= es every yesterday a dream of happiness, and every tomorrow a vision of ho= pe. Look well, therefore to this day. Begin doing what you want to do now.= We are not living in eternity. We have only this moment, sparkling like a= star in our hand and melting like a snowflake. The problem with the world= is that everyone is a few drinks behind. A book may lie dormant for fifty= years or for two thousand years in a forgotten corner of a library, only = to reveal, upon being opened, the marvels or the abysses that it contains,= or the line that seems to have been written for me alone. In this respect= the writer is not different from any other human being: whatever we say o= r do can have far-reaching consequences. I feel sorry for people who don't= drink. When they wake up in the morning, that's as good as they're going = to feel all day. Opportunity is missed by most people because it is dresse= d in overalls and looks like work. Time is never wasted when you're wasted= all the time. Love is the beauty of the soul. Can miles truly separate yo= u from friends... If you want to be with someone you love, aren't you alre= ady there? Beer is proof that God loves us and wants us to be happy. Take = away love and our earth is a tomb. I'd rather have a bottle in front of me= , than a frontal lobotomy. A happy person is not a person in a certain set= of circumstances, but rather a person with a certain set of attitudes. A = woman drove me to drink and I didn't even have the decency to thank her. L= ove is the immortal flow of energy that nourishes, extends and preserves. = Its eternal goal is life. A woman knows the face of the man she loves as a= sailor knows the open sea. What the world really needs is more love and l= ess paper work. Programming today is a race between software engineers str= iving to build bigger and better idiot-proof programs, and the Universe tr= ying to produce bigger and better idiots. So far, the Universe is winning.= You can't wait for inspiration. You have to go after it with a club. The = great thing about a computer notebook is that no matter how much you stuff= into it, it doesn't get bigger or heavier. Who so loves believes the impo= ssible. You can't wait for inspiration. You have to go after it with a clu= b. Books are the shoes with which we tread the footsteps of great minds. A= lways remember that I have taken more out of alcohol than alcohol has take= n out of me. Love is life. And if you miss love, you miss life. Love takes= up where knowledge leaves off. Love is composed of a single soul inhabiti= ng two bodies. Nothing splendid has ever been achieved except by those who= dared believe that something inside them was superior to circumstances. T= he best proof of love is trust. Love is the beauty of the soul. Can miles = truly separate you from friends... If you want to be with someone you love= , aren't you already there? An intelligent man is sometimes forced to be d= runk to spend time with his fools. The only time you run out of chances is= when you stop taking them. Who so loves believes the impossible. A book m= ay lie dormant for fifty years or for two thousand years in a forgotten co= rner of a library, only to reveal, upon being opened, the marvels or the a= bysses that it contains, or the line that seems to have been written for m= e alone. In this respect the writer is not different from any other human = being: whatever we say or do can have far-reaching consequences. The quali= ty of the moment is more important than the number of our days. Drinking p= rovides a beautiful excuse to pursue the one activity that truly gives me = pleasure -- hooking up with fat, hairy girls. The problem with the world i= s that everyone is a few drinks behind. Compassion alone stands apart from= the continuous traffic between good and evil proceeding within us. Life's= challenges are not supposed to paralyze you, they're supposed to help you= discover who you are. Treat everyone with politeness, even those who are = rude to you. Not because they are nice, but because you are. The best proo= f of love is trust. I'd rather have a bottle in front of me than a ... bra= in operation. Nothing splendid has ever been achieved except by those who = dared believe that something inside them was superior to circumstances. Wi= thout question, the greatest invention in the history of mankind is beer. = Oh, I grant you that the wheel was also a fine invention, but the wheel do= es not go nearly as well with pizza. Always do sober what you said you'd d= o drunk. That will teach you to keep your mouth shut. The man who says I t= old you so is making an excuse for not expressing his position clearly in = the first place. No matter what looms ahead, if you can eat today, enjoy t= oday, mix good cheer with friends today enjoy it and bless God for it. Nev= er doubt that a small group of thoughtful, committed citizens can change t= he world. Indeed, it is the only thing that ever has. Try not to become a = man of success but rather to become a man of value. I'd rather have a bott= le in front of me, than a frontal lobotomy. 24 hours in a day, 24 beers in= a case. Coincidence? Solitude, if rightly used, becomes not only a privil= ege but a necessity. Only a superficial soul fears to fraternize with itse= lf. An intelligent man is sometimes forced to be drunk to spend time with = his fools. What contemptible scoundrel has stolen the cork to my lunch? Tr= y not to become a man of success but rather to become a man of value. The = Babylon project was our last, best hope for peace. .. It failed. .. But in= the year of the Shadow war it became something greater: our last, best ho= pe .. for victory. The year is 2260, the place: Babylon 5.Memory is a chil= d walking along a seashore. You never can tell what small pebble it will p= ick up and store away among its treasured things. When love is not madness= , it is not love. No elected body is the country, we are the country. You = and me. Us. It can only stay that way as long as we care to keep it so. Wh= en you're in love you never really know whether your elation comes from th= e qualities of the one you love, or if it attributes them to her; whether = the light which surrounds her like a halo comes from you, from her, or fro= m the meeting of your sparks. The man who says I told you so is making an = excuse for not expressing his position clearly in the first place. Love ta= kes off masks that we fear we cannot live without and know we cannot live = within. You can't be a real country unless you have a beer and an airline.= It helps if you have some kind of a football team, or some nuclear weapon= s, but at the very least you need a beer. No dictator, no invader, can hol= d an imprisoned population by force of arms forever. There is no greater p= ower in the universe than the need for freedom. Against that power, govern= ments and tyrants and armies cannot stand. Love does not begin and end the= way we seem to think it does. Love is a battle, love is a war; love is a = growing up. Autumn is the time when seasons merge because of bare necessit= y. Hatch a dream and then believe it. Compassion alone stands apart from t= he continuous traffic between good and evil proceeding within us. Begin do= ing what you want to do now. We are not living in eternity. We have only t= his moment, sparkling like a star in our hand and melting like a snowflake= Reduce the complexity of life by eliminating the needless wants of life,= and the labors of life reduce themselves. A human being should be able to= change a diaper, plan an invasion, butcher a hog, conn a shp, design a bu= ilding, write a sonnet, balance accounts, build a wall, set a bone, comfor= t the dying, take orders, give orders, cooperate, act alone, solve equatio= ns, analyze a new problem, pitch manure, program a computer, cook a tasty = meal, fight efficiently, die gallantly. Specialization is for insects. Mem= ory is a child walking along a seashore. You never can tell what small peb= ble it will pick up and store away among its treasured things. The ultimat= e measure of a man is not where he stands in moments of comfort and conven= ience, but where he stands in times of challenge and controversy. No elect= ed body is the country, we are the country. You and me. Us. It can only st= ay that way as long as we care to keep it so. Love is the immortal flow of= energy that nourishes, extends and preserves. Its eternal goal is life. D= rinking provides a beautiful excuse to pursue the one activity that truly = gives me pleasure -- hooking up with fat, hairy girls. Beer is proof that = God loves us and wants us to be happy. A woman knows the face of the man s= he loves as a sailor knows the open sea. Books are the shoes with which we= tread the footsteps of great minds. What contemptible scoundrel has stole= n the cork to my lunch? Distance between two hearts is not an obstacle; ra= ther a great reminder of just how strong true love can be. 24 hours in a d= ay, 24 beers in a case. Coincidence?=20 ------=0_00BW_07X9855QH_06S.462H76S0-- ------=0VO_02X1312NB_00D.064K73S0 Content-Type: image/jpeg; name="kfanjcr.jpg" Content-Transfer-Encoding: base64 Content-ID: <946226c4d3c0$2180fea0$319aa2c0@RVGSVLYNI> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAACQAA/+4AIUFkb2JlAGTAAAAAAQMA EAMCAwYAAAtUAAAZrAAANLH/2wCEABQRERoTGioZGSo1KCEoNTEpKCgpMUE4ODg4OEFERERERERE REREREREREREREREREREREREREREREREREREREQBFhoaIh0iKRoaKTkpIik5RDktLTlEREREOERE RERERERERERERERERERERERERERERERERERERERERERERERERP/CABEIAQUBkAMBIgACEQEDEQH/ xADOAAABBQEBAAAAAAAAAAAAAAADAAECBAUGBwEAAwEBAQAAAAAAAAAAAAAAAAECAwQFEAACAgIB BAEDBQEAAwEBAAABAgADEQQFECESEzEgFCUwMhUGFiJBMzRANREAAgECAwMIBAsHAwUBAQAAAQIR AAMhMRJBURMQIGFxgSIyBJGhQqIw8LHB0VKS4iMzQ+FicoLC0hTxsgVTY3MkNEAVEgABAgMGBQQB BQEAAAAAAAAAAREhMUEQIDBAgbFRoQISQvBhcSLBkeEyUmKi/9oADAMBAAIRAxEAAADkXZMdJBKZ Nuax+qe1lqHWxZOT8b0/KaRWezWBOmaSi4ndpMISKaJ6P5f2Evp5xoDJPJx507GPI1h9tPjXDro8 1MXSvytcfX2/PO3citcWdV1o+ZzQ7hcxXDsJ8HYH2Y+YOT0M8A7XAM6ebSe4qtdBT0ObpvQadTWy NzlWtQErEMOX0cI040W5jdXNBOrzU4FZNphahsZOmn3V3nejDOfQxE7EqZgNGruhmJhBZi9QLdsS FF6sAsuOuM8rmeBhpxTanoDI9hC8gYoxz1czey2t2KcMNd6GKtI0eS6rLVD18HWSvyqaMXk8x3mD rnzTkF0c5DR3U8YNyjUivUnDou88r9UQqNvCDWDnWwJpclqgdVagbobWYGjXxbQaEq1ENV6tQN+g BBfWLqhOObvBNJB59Q6CHJ3c70lK44jG9ZmqNsw6mpYqVIujoY3YaZ4t4kou9OBnOTkdQ1Tl2ZSj TF5voMHo5ws61yf2Dx72FCrWeTDqVzdgNmfNwDpwZow36OWg3mw64b8Y5ob0ccAdDQ0efDShRsBe Lz7h0iSDEz71Tm6asSiz0IQBAKwk0LK1c2qn1nCa7jaOF8rtTrGuHhIDKoCwioZG3WucCO9ZuOd9 Qwd7TNJK8wyrvRUNoIIyo02tpJQ0lRZeVFMvBrmCwlCSapXWJJISSDnM+YOTrJNg56WBjNcggwGW cw8m6N4iV6diB4kkqwHNypnRHZNXsxc5EsOK5LhLjN6LL1NsklDbGtcrWaEA/HUo2anSdC0Ulx1H zH07zHtmw+vY0WBX7WMupWw3pH6fn64eioZPOtJIOSVl+DupivMPOJeEMCkMExpjqNbQRKEIq+Xt NpGFsqoPYNl7+TmcZHJWCHSB9Dh7muaSW2NGwKVrnw9BhdCno5/Rw5TS53HzL03geyb9LuudDJME uqzj3tZAOU1ky51uVq8dJJZPlNKL8PaWbvWYKGsw8WM5LSuVQQZMyEmSFCUBxrWQNy2qtsUlIjgB C09EDpOX6bTOSCtMjVCpqtnbT2UdMSkKhpBENgKq0kzqDtSUUKSZMdMgdJBzGjRvcPaiDckjO9Tm jKEuLFqyysIqE7RHIE4AMDhqukJCcSQkJXFcklRR3eb6O4hn280kpasA0Y5J0X4LNa0tHA3mqtE9 Tm2aDJvR1at3r54RLkXGoqBGXFJgZ8nRueYM0/M9G5PMK50JxdxLI2AWsiKSoJYSmjPBJsAoR1LI 9BvQJAkzIkZ6ZvVtU2s/pc7V0mvn6icZLa6CjW13Zjy1kLOvzTMuj0IMdMjWsvpDQI+kBY6YCFtN AR0FYpUHMEETz+5BNEZrmVoVNlAkRUz93IogUNibUovDYBQjFfp6QEnGdSSUZaZtXaxSKcL9GAmz obYaqxbgX3o1B7SxLKNN8jWHIkZKnjALDEx9ppnUM6ImcHdkm7xQcmbmdbj7dFgNLk+azfRlyNKV ZjEjjHWpklGkIkUwiDAtwZQkSBLiTsG5rbFK5rlMcltlk1Nge2GOPYMGGPoIBgm3GDD1LjDcQwWy jiW1LaqvzaWcu08VWkdgtNXcM7RRrnyq/Tv8ncQoz46QmcyVbRrOi8akUVsTzc4xL2WUdw2pZyDK yU4K4mJS0ztkBHXM1qgak7AWlnQXEZBcDITiKhOgkWZy0gs4uOOU1NRcJJkiSZxJ2cPOW1Y4dFQ4 iYdFicCwlJ3CBoDZdLTMKzUOzMXUqXlU5xdxKLZFyS3xV3bPsC5uuk5Qm1WPTOLbasO4MqtZnMKU LhlnU1ql91oRGRckLUhokUJJb0blURUJBcUWCvaz7dzhTO/N0Z1TYy8tXLWLloZ4TQ8JRCB6ZWXC VTCYkXYVhiqW5vRo06IbVLfDp9/m93OrWhnS0xM2crz0nzEGm+Whaj5SRrLJQrV/GTnZfFSe02Mg 2VjINpYqFtrEQbhOfsDmxIR1CztOnF5TuXDoU3kkneaVetfptlPk26NBqruS1BzaDXuVyqFDUzts tPquH6VLcrsF8lGYRrzrUa0gV2iyNmoCNXaozrznZtUzOj1WYL9OEAvSoTHeelBu/VqHU2bOZadb cEn6w6aU1lmS5+ickkPJISAkzPSWhYCk1aKlCFWSVVc9LabF5JXu7SWnEFJXzpJAkkCSQJJAkkCS QJJAkkCSQJJAiJD/AP/aAAgBAgABBQDoWxGOYjTIgIP1GZmZmZmYDMmZmZmZme8JxPLvnMUd7DFY iK2R9B/V+ZYQIATPgK0sExEOJmFgsyCP1gxUuQYDD8AGPnGRB3gJEOZX2H6zDI6CKe7joOhOIrT2 RW8umO2RAhIgBM8GhVh0II6s2ID1BUQtnpnoYDAJX0b5rTyLsFWa3x5PkW4YVAMyrYvTEA+kQMBC Q0IxBMyroe8RlJfwzNcgCu4lyEybFwoRJaQzdcTH0iHvAJnArM8hA+ILcQv5HInkJ5CZmfrP0gdo IIvwT3JwQxhJyGyCcnEQdsdXQoZnriGZ6Z7CCYzEU48TPGeM8ZiGo5WsD68dMzMP0CCCJMTBmJgw gjoAYy4H0FCOmIe3Q/QOijET5z2zPKeXbyzAonYRyWPV3Ll4TCZn6RBFEzF7/qt3B+owQCY7DvEn bHads/8AgkT4+p/HJjD9ARe8z3U4nmJ5ieYnmJ5iewTzE8xPMTzE8xPIQxh26iYgHTMQxsZHx2mR ntMiHE7Q4hImRMiEiZGTD8H6B8Q9E6J+r//aAAgBAwABBQDoFzFGI6wAmFSPqAyQoJFYgrECiCsR lAhRZ6xnwGDWIUAhUeMC5mO3xG+KxD3jLg/TkzJmTMmZPXMyZmZ6EYlYMJxPmFYhmYw8hjECkwgg /rOFcIMAiYhIi4ziGEAwYxYO/wCspwehnYBeh6CEZnrGXXx/VVZiEGYniTFXxhOTiBehhMsOepg6 HpiZnx1zMzPTMz0IzAuITDPGW/QOhhE7zHQdDO8DTP0iGEz5NoxPEzxM8Z4zEwZ4mY+kw9B9P/iG Zj/MxCJiYgGOjHv1Vg3TEMB6DoIYYYI7AnImZmZmYHELZ+vMInj0H0GGGOZkTyGMiZEBB6ZgOfpB B6Y6Yg+g9GOY3x45PjPGePdVxCei9voVfGV/GPo+Op6McTExk+tZ4LPATwE8RConaATEx1Q4OfpH Q9D8ntB89vElZlfI/DlSD3gEP0LmCIf0MR+0MscJPukn3ST7pJ9yk+5Se+ufcVz7iue+ue+ue+uC 5CRFPf6xLB28SBsYCkrjyXyyohZISsBWMVMZlMDIJ5JhmUwFS4g+fpPQR4fi34/THz//2gAIAQEA AQUA6iCLSWjazVDUBZKQE2FsxNy/0Nu7jXsCZnPXPUCJC017317NS4bFXxCQAvK6rTb5HX0ztbtO mjb+uo2+R19KbO5Tq11cjRa9nJ69Vu3v0aS37tOvU3I661MwULzWmwG5S11O5TdYnI67328jRTav Jaz0jkNc0V7lNlOpu07q2cnro9fI69ltO7TsP9FFBsajjgh19INPDBuU5q3yz8h47FSaxZrdVqx4 kdD1EHaKY5gbE/qu55L8zm1d9Hi7Kn1OQ8t/Z2dv7rjHNutbus3IbF+4djiuSYum9aW5Hk3+92m2 ms4u/wBmtK2La2jRbt6im2vkNTaOttA2VDb2WPIa7BtJXs+3G044/jLW0tz+vtheb11GvwWv4VdM QdjrKGbWTzgjLHr7P/8AaSAKahhtfI2tM5ZSJjqIvaAkQ/8AUM/rlhXeTZCuRmLxlVb18albHiaZ bxldqVcbXWW4mnNPGJSL+Josg45Az8VSzPxldldNIrSjQShrtFLLLeNqsdeNr8F4qtYeLq8142vx HE1rLONrcWcZVYx1lsr1dca69FAmrrF2opCCo+MU+UbsLGAXX2w23ae1K9gO1lKuu/qZh/56YgER TPHAcTy8x/Xf/wCjy2wNROle5uNv6+xsnf8A5pE1z/YETpRyV22G5xTR9/bVf/Po7aG8m/TubLa4 0+YXZerlr7dV+UDNRfsNymzsJq1Pyd9VDcm7bKb72zU5F9fQ++89npjpW2DrXZlbdq8mVYWW7lYm z5W1svqK2+yUr2AhXttr22FKtBBEzAwMsSZweKu9W5/YQXu6WccrXU6SU3fxVBQUq6xeLWqfxGuK 79NL7V44VFFTUq2OPr2rauNSu2rj66tQ8ZWBTxy1bF1SXoeIRq10a12BoVi0aQo1OL49ePo6WVNU ZRUbXo1FqBda5/IBY33OwqUdqLDWOW0isorLom2tVdW+thrsSwXayuNziXEupasgGUUta1HBrjd0 m1YzGHvK7DU25vvumWMUXX2b9nS/kNnYeq66neS5qOI2Lr35BNy/Xuq29+/W17DZUtt9+9tbdt2n tWbGlq7e15bFXJ7J1XbYr0tnY29fjty3Y0Wt22utXmdgceKrFI5TYVa1ZE6O6vNvRNM1HFdijIbV DEVGqBbrgawq+UTDLvUNTZxlROubjTZr7TMUcsCmZvcet0TgQzU6lWodO9A/PAJUc4PQfHR9DWd2 qRm9SF/tafD1J5ipA7cfquwAUNxWtZd9vV671pFXp1d9QuolhqQo1FT12VJZNluNFtezoJVqnjQ9 epXVdTfVsL0fjxPXkfx1KMpxEcYrIENglj5B8qzdyL0yzZs27NbWFNOxrB5RV4ytcdLBmKksT2Qa VdU5ZW23sBUzE+Ot28lyXblj0VXD73T2KHVr9ttTk0fUUXqNp92/jX3hs6i6d9n3C21WaXD/APw7 5qHJ6oa7YTY27iq+I11ublOf801N/d0dmq+zZGqjnjdvpYMrdSay0HeAEQORBbHvFYa5mG2TOBpW zYb488sgxAcdDPLEaxg9jWOr+KV26vtLaLhdbQv2zZw+3WetutXcz3JW2taao3INXAwP6NOtXQ36 CPldiyEBoylYrzzEJEYhi/xfR4iq56LNHbuusWsKFfEFhEBhMtaO4jLkeIIsIWK2ZS5pKb1dn0be yazq6gpHTdpCjR5pdg9Pify+lP5fSn8vpT+X0pRu6+wZbalKjlNM/VW2G2bQ7qcBLFaNrZhqYRlY T2FI20oG3s+yU0kypAGpRsKjJAwI9gEa0CWXZhtyVyQvY+hCU1hkaamNx1Tdfiabm7rtbVWpXvbp 3Rx1Is3Oln7dUUJQBSR40zxpmNa1uB5i2yz+w7jb2xY9W6v9c5T72j6LbSLFr7+PZ18YlpENjENY 7EpaxOpkrqKsCAAqRNclk8YTiWXBZZu+RUPbFTxlfeIkSuKsAljBetn7NEg09N/YF2wtV52OM4uv j16WftprezUr/se4i3f2S6mvQ5ltvd/sehVsattz1oS2rr73B2cfqptnUvptW5OoqxDgQuojZeGl pWxrl9IYUpkFf+mSeuGsyi8VS3cRRfycuttvlYek6162gd5q19lWKIoltgrFrM56fM0CtY2dmrVr r5Tc3H5PjbNTj9fdq1eQP9i0letxYss/bRdZTqJwPJOvM6t2qupyNXHcpynOtyiiuu6zQsW2+z+0 6Fq69tQs/rG5ZVZ1VPJTUhja7KKFFsaplDAQgqFLQLiYhXMxgMgjaqmDVUQ0LGpEsoxNTZZmrXxA gOJ7yS3eN4gddlHQ621XtLtcTqbc3+P2OMq43UXZts16rT0cZVeD3hrUgrX/AGbj9ncZ9HlHavhe S2hyfDbCJscc2rx/2XIz7LkZxOm9S9aLXodqwwWsiPWrzxZJdqtXBGGJ3iHMBxCcgGEQ4EKiMoli zj9cNYBBLASNM+suPJtq/wAPpu0a7GNW3WNzV5BtjR4inUf/APCES5KK/UA2YJmEZAUo2BGHYMck YhGIO57tGyATmBsyztNOsJWBBAJjE2NiVV4LMFHtM9pntM9hnsM9hnsM9hnmZ5meZjXBZ92gg2Ua eU8pmZmZmZ+inVv1mJgMB6EGbagOO8evyip4QtklTApEJnjmMMyx/XFt9pTsBBBNi0iNrIEY+sW/ Mu5Wqqfy9Zerka7Ep3PY9W+lll++tNlfLU2Lr8tVe0vuM9hYl+/kZxlrE4M7xH8x3mTMmZMziCU8 gjEYMIinEBnzN1SCDmHtGfBVh5LmeWYxGQJnE2T7F0aSbwIoxF6NSHlh8FWv7+y35v8AL16fh7H+ 386286qdw2rq/v3P/fWVRKvAO/xf/wBMxy3/AJVCx1dca6dOKtyle35P7bPuYxwNXdusuVgrisGV WPTEtVx0WOgdWq9LMSY4Ag7OD3AwI+MucS15xSlrB2iwQdNtgteqrVy35l3FVWz+IrDjh0Ev0VtL cLWy18LXSRwtKrrcZVrkjI2EKM5lWtZcdfVWgRrXE91k9rie14pZX91k91kzYZTSKgsxGUqadzBA nxF7zco9iqSIwzMZA/5gtBhcmYMZGMNGZoV+IAiwCDpsUPssdNFDKGHqM9RnqM9ZnrM9ZnrM9Zng Z4GGvIGhWCEIniZ4zxmJiYmJj6F6HvGUGa1/kAYGxCczaogYiVgMfETwBgQCNgRjGmuviogggjsE GuRZPBQbrCkJJ/TCCeAhUCewL+khghPRgQa7Q6+UBh7zboNZqPbtAYTGjRF8mUYgEEHTcOVrrfxr R1mx+7a2rqrNjfsz99t4v2bfYu8PT99tktyd7Lp71ljPyF0DAhBC4Ea2NdNq4kBDjwMof3V4MwZg zBncRWDBLMwPPIGeWA1mJTd6mUwGAx0Di2k0sr5g6GNNdIIsEEzFY33r/wAAnE2P3b6+M19da7BY BLfZepfFtSsHVmtqDmqeJrt0LfGo2xro1sLkzW1zY3TjtdqpXXaHCE7cbJGprXpclgss1950lO4j gOIz5ltreS2nGhtlwrQNAZbWLBcjUlGyITD3lY8QsAg6bN3qr0qPt0XMAxNhDCAwp16qB/H6uaqK qZXr1VN9jrljrVM9mnRaworCLrVolqmseamFlEoQWlXQA+ZmLZ42zxtgrsE8LZ4Wz1OwRAgoEVe1 ZYQeyCvMGvmV0LWUs8grRWmZbWHFlbUFHDAysZYRRBAZmKotsVfKFgIGzCQAzVZ8qp5VTyqnlXPK uZrma5lJlJlI1dLz1a9cD5IImVmRO07TtO30Cs1MgyE7QEGJ2njmeEX/AIKtEeK0Mtq8hahoK2Ai pcBRB0zHfAqYCe2AliSXOyxz+mzBYflR7Ci+K/o2aWRVlYoixZmCYgPiVMRopnzNmoOKFPtURR0z GbE/k6nsrtgszKyXgwo2P3ck4aalq1hHGqLa0pT01LstWmwy6yCqldb12KqDiFCAv4hFnqOVQIMz xE8Fmhse6tb0ae9PPwWFVEq3arXVjlag0fQzPFkKd4sAmMdCMgMRFaK8DRu4rTxuUQQwticruGtH E1eTes691LQf8qMLNj92zr323WcdbXKtDYLfxuwU+32msOps1Oupt+vx37al0bscfW9Ko3lKQc9l GST8w2oJ7q5rU1a8WmpXUIdn3Vw21kV61FDUh3KUgw14mxR5BRiLAZnq65iPFaK0zCvdZmFsTYvF a3sbGcRP/ZxlqsFvXAtWW1+YNbCeDTwaeDTwaeDTwaeDTxMKEipLKSp7YYnBmDDWDPUs9Kz0rPSs 9KT0pBUq9Fr8RiOMy9fFw0VoGEDAzMJjnBSzIVoGmYDC0sswL3NhsWWCOSrU14lDi1QJyHK/ZWf6 Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6KafM/dXYhE YTbSHMVCYK4BiDvPGWLMmspZFeBoXjWYj2F40cSwS4YPEbwqlNdZhAE5DWW/bWoWPvVpr2byVVV8 br1WHe1/tr9jWrqqGhQBXrJ9qusn22tQNi/YelH2tNDs7mpSH260o2rdXWG5vazUDX0kto0NKlpp cfW63cfVTTt6dVa8lr10bHJa6a71010cmRCI02RlIogmIIIy5lwi2msrbiC6GzAa32FVjrGEtEuG SiduO2PbWLwZzF76+2d9wNjZ+4N+y1617tlVWztPsm/Za8Dk7Vf74msbp9a2FHs2/aTylnsHIXFL dz3PdvG+y7aa1ats1FuSvKW8nbYPvrfDYvbYs2N47DbO4dk8dd7t4wwza/YIsEHQQyyX5mv5+P8A 1hs5r9eBiWRpbjD/AL1xOP8AL3PibH2vl+Pn4+fj5+Pn4+fj5+Pn4+fj5+Pn4+fj5+Pn4+fj5+Pn 4+fj5+Pn4+fj5+Pn4+U/Z+f/2gAIAQICBj8AuNmmzKWRsiOmQdLjLbAcbKd2C6n8Tu6bIISUii2R tbEWxT2GTT1+Zr8WdWg3b/0J09SM/u53pOie43THh8/vhQQjbAWzupUTth7cdSLys6u5eAidTIgn Wq9Lp7/gRvKGlf1FTpr/AKQVU1xWFeyBJB1tnkV7hRE4kaI4jzdlFYcjZG4y4qotkiRKyGVa8i5J rJDEbHuuuG+DHIQxvpLFfMPcXB1xVKFChQoUKFChQoUP/9oACAEDAgY/ALjkCN5iMEQjOInM0XkJ z1EaoqPJzb5YTTma8hVpQ7rrCqRybLdW7HHgMtx0tiMo+ThMa+mK+ImVhbETMOgmLHDZBMCFyFxs FM29jEKZVzVydGHfJtY2Xja1RWE+eQnMVUm9/wC1jYfcsCe5PcnuT3J7k9ye5PcnuT3J7jIu+Knd JyE/XsPQ6mrIl6gdPMV+PAhA6m0EVUlQZtdRWRuHM+v9kbFpqeJ4nieJ4nieJ4nieJ4nif/aAAgB AQEGPwDm4UCMJMfE0C2DRlQfIkaT07R8/p5DcGIK/H49NET3c+2OTHn4VjS3reDKaW6uTiR9HZyS cAKwckE6dWltM/xRp9dKt99Jbw4E/JXEvNpUmJgnHsmrbF8LpC2zBxJ+TtpeO+nV4cCcuoGuLebS kxME59U0LYaHOIV1ZCerUBPZXAYsLhyXhvj1d3EdIoNfbSGMDAn5Jrj3Gi2Y70E55ZUl4v8Ah3CF RoOJPZ0baLHIY0G1kKTAYo4Wf4iseuj5cN+IBq0wcuvKntI0vbwcQcPj0UfLK83RmsH5Yj11wGJ4 katKozGP5QabzCuDbXxGDh2Z+qv8rX+F9aDvjLPPor/IVvwoLaschn00XsNqUGDgRj20yFiWXxaV ZtPXpBjtoWVeXZdaiDiM8DEGnt221NbMPgcD15c0JvoEmdnx9VKzDwj4/wCvxGGQ2VI2VwnziQd9 FZgb6IGQqc/g38qxy769W349PJdFvxRs3SJ9U0hdgEAVP5vpmrulS6oOEhEZjrI2zlsq2GxZbiqe wGrXlm8C3FuWz0E040lxbXhrEeLfiR00FY95HVT2V5cIZvapG8AbasPt4Z/rrhAF0tJpwjxNtxI/ 1FPYfxW2VfX8RS+X/SLrdTo2EeumJ+q3yVwAQqapJkz2CPnqEIDC2olhOGHSK8zdczB1NAiYnZJ+ Wk85pOvWXZ8MQ3bPq20LtoaibQIxia8wQe80m4u4zR8pJ0FeP2aJj7UUnlk8V06QOicaNoAol0So aMx1EjfT2rh0srM1yc+2k87YaDbgoy/Val05HvMd5PNFz6vz0C2zEdPx3cxQPZVmb5Kx241141NS M6g4HnYVhyIo9oMPdJ+atLGJqK4iIurfpE1IAAzhRFEBV0kzGkZ76AYAsuRIyqQABtgRJpoVdLYk aRnRVAqznpAFAhEna2kTWoACcWgRJ6d9EhVhvENIxoI4BgyJGVaDiKJQALuAgULoADbWjH00W0r3 vF3R3uvfRRgCp2RhQIABGAMYxuosFXvCG7ox660EDTlGyN1YKojw90YdW6lMDUuTRjQuMqs37yg0 bdwBlPskYVpGXLjUigMMKw5TNPuc6fRlUdXKZFSMxUHnSKxzFWv5/wDY1M23ZPLesKqMiBCqs+mJ 2yLZMnaNmwmvNW7Y1heFAe4VVZXZg2fQOurt+8pU2XNt1BnvYZHDAz0UpucLSxC/h3w7id66R2wT 28jXPLWg1sEqGe5pLRnA0t6yKs37SFjduCzoJ0lWM9e6rdi/bC8XUEZH1YqJx7qx2TTi1wgqErN6 8LZYjculsOuKF63gDIIOwigw4cYybtzh/wBLT6quWoXVbXXNu4HQj+KB8lf5i2V4ekuQbvegZx3I 9JFWrdhNdy8vEUE6QE3sYPqBo27vdHA1aFcss688QuOzKmvXPCgkxQ81csgWYDGLkuFO3TpA7NVD y1i2H1WheDl9IgmPqk/HKr9l10XbSz3W1CGBIIMKfVXl790F0YAXbhbFZ9o7xvxw6aHlrS64XVce cEB8OzEtuwwx+BxqBTcPcYrDAilnbHMINY8uNSOSRyWn2ao9OHz0zXD3Rgi7z+zlPmLdx7bsAraN OMZYMreqrt9SS17RqnLuiBFXbbgst5uIwOw9EZZVr/yna2DGDW4w2agoPvdfIwsXLlpHMlEKxJzj UpK/ykVatLKrZdbqwc2G+ZmZxq3eYnVaLFYyxEY03AuPaDEuVTQRJ/iVo7MK77kqMS9xvlOVJ5gM y3FEK6aTgf4gw7YmnvF3d7ihGLach1KPo6K/wwW4elkkxqhp6I27qtlGZHtJw0uLGrT0yCp9HVR8 0Xd7hTh97TETOQUfR0UbdwalYQQaFh7txrIj8MlYgbJC64/mr/KEhuHwtPs6Zn441dvSdV5QjboA jDDpr/FsgOApRRcOB/igfIKFoYtm7fWPxwHRy6XEHkCit9d4xXdFFvAm8mgcSY21BrjWxKnOgwMH ZQuNl0VgjR1VAwPTUGiUxG6oYQeQKokndRNy4dW62MvT+yg2oMhmGyy39NY8gcZqZE0HuRqAjDLk LASQCY30fOnzGhoZtAVNCx7JkaveFeTCnhcdbjXBpB8KgiJ9XXjNDyrubiNbNwFwoIIaPZVRHZV6 4kahdaJAP6g2GRS+VS4Utm0XMKpM6o2g/OOivMWWJvC1bF1JADEwcO6AD6KHmU4mthqGFgWurFtc dMz0bKR2ADMoJAMiSN+2r3lxdKIi2yoVVnHPxKfn7K87aduItqFS7AGqcxhhK9FJ5lbpaOGDbKrp hoEeHVt+tRsWXu8RVBZLS24E7Sbg/qrzZY9+xIRiF1ZbdMpPVhTeaN5i4sl40ppnTP1Z96Oil88L xL6bblCiaDqj93Vt+tVh+KXFy6lp0ZViG2iACI6SauJ5d7xNs6XFtbOlT13AD6z6K/yDGvicIuRg omNRAMYdcUs+ZJ1AwGW3jh7MKMs/ao+SInzurQGjulT+rugDMb8KCs2pgMWMCfRhyxcAI6a4i+D5 KB6Y5JNYW56omtJXSu2ayqK0nKigMKcQBRBxEmK0kMBsruyR08uWNYkx0UBAE7emtLLpntFC3ta5 I7Afprq53Ea0hf6xRZ9MUrsoLLOliMROcHZNcTSNYGnVGMbp3UbWhdBMldIgnPLrriaRrjTqjGN0 7qNwKNZEFoxI661tZtls9RRZ9MVAwAp791RcZwoIcBgNO6RXB0Lw8tGkafRlR4qg21GogrIAXHLo pbzIlwMJVnQHA9Ymj5UKga4utkCYMowxwg9tcMqCkadMYRujdXCZFNuANBA0wMsMsKGtQ2khlkTB GRHTRPmDY4oieJo1dGeNHhvaFqYbSy6ZO/ZJr/1uBxP+3o1erGn8ySS7CJb2VGwbhtrVadXWYlCC PVyljgN9aWgiIMVIBEdPNiiTiDUBMN80CfETpAFLb3Csagc1YgwWmdlBlJIzNG4uS+Hq/wBaM864 9om241Qr+buLcBH/AGu8OzLsryNy5cKcQ/isG0z3duyrS+SuNdtEPx/xGuKPq4ktBnceyr3+X5hl YXboUcZlIAOGkAgnqx6BXlOKzo7+YRCw7rMh1RPWN9JwmuC07gX31s7KvRJOnpKirK+QutdVieMv EN1Qu+SW0ndjjup/KHVce4Z8qzYzqPhJP1Djj7NeXs62Ns6uNda4Vlo2vDFF7OiRUWbiMhRpti+9 /vbDqZe71aqdvNXm/wAoo+q3xWUg493hgjDrXpyqx/40+Sk4z8NOC0tr0e19bCPSKu2rNxn8o1sR cFwtpefZeScsczFf/wAwki6h/Evj/pbGH7zZdGJoKNmGONeb4LKuFmdaFvZ6GX56tm8yki9bJZV0 iO1m+Wmt6lvMQdKW++07I0zGMY4VZ/486n8xcX8XSRqW2M8SQJ9nE440ri01ny17TbcMUhXGCnus 2YwM8uFYTB5cOWTXdHprvmTu2UWb2RIrCtPOJgEbKMmAdgo7aLNgorVHooiyuqM8QPlioa3B6x9P MR3EtbOpMTgfjvoKxAZp0rtMbqI8tYbS7FyWaMWxJ73zYT0Y1N20yicx3u3Ls66gHH4F2QQ1w6nM kknt9QyGz4GKx2cnRy4VNYUXYya1WjBr8RsPRUgYmoqDztI9VRuy5JAic99RcienmC1bE3XyHRtP x/YdTnXcPiY/NynzCvw3QE6iTpy9ro+gZxTO/dtPcFqwSMWMfT6Jg8z8639sV+db+2K/Ot/bFfnW /tiotXFc7lYHkL3CFUZk5UALyY5d4c4ioHJDVK1jWFd4VnWlcak0BlUIzR6qxYt11B5mFZxWFSwk nfUgR1ViKxUcxr/e0t4VcREbug9PKbt46VFC95uU8tP4Plx47p2E7h0/ZxxKHzZHGC6rVhfDaUZT 07h2nZHIeo0129bNwh1QDVpzDH5qkeTeP42/tr/47n22/tr/AOO59tv7ahNXl7gPd1NqWeuAV68f oPkvOfmr4WOZjYenaDt+Vf8AjrByPfOyfoUYn9lN5S0Pyh/67Ri8eIHpfxDpw21w3P4tqAeldh+Y /t5rBanliSKwPqrTEGomBWJqeSaB5c67uPVUtlyYfAHqNKQAM8FyGJ3cvmPM3hrt+V0patHwlyYk 78RJ3iBQVfxPPOAzufBYU7umD2eyKMd662Ny42bH6PieU9RpwgLHiJgBPsvQX/GJgAe19FWna0A1 wsCpkRpI+mrvlCgAt6+9OelgtPeIAuWxqVvmry3m1P4gBWf/ABnCeyB2UWbG/wCZ9Itzietz7o6a tebQkXVIa50E5fZyPTVv/kbI7jki4g2N7a9viX7tLcQyrCQfgMK72ValzqTnWFTy6TlUkioQSa7x w3CtS9orDA/V5JOfwLeXEzbJ8W2ccMcvmijdvNpQZmifL3vLqCe6jag0bMxnTcQ63e6Lt519mdww nP8A0p710xb80itbfq2Hp+frrQ7Mp/eRh800HXIiRyHqNObbFSbiYqY9l6DDzOBE+N68tbvvreXO qSdq768xdvTpLXV7onHXPzV/i+TRtLYsTmQPUBvJPopbcz5by6zcce1jJj+JjpXog76b/kvNA8K2 wgKJ73sr1KPmoo6uVYQQVGXpp/Lk/gXTAZvZPst2ZHoJp/8Aj7oMqWK9EeIfRzAdhru+upGNGcCK xGHJAqBhyY8kVHJlyyMCKCN4qjl0p6anbzeNZALDxAASw6+jdWpcxmpzHx2HbR4ttST7QwPpFE2L puWG7hsXMZ1YQsfNBq3e8sWtW7HduJrZgXgFlWScBME7dg20GdFYjIsoMcpA3U1vhHUbiNErkFbp 6aUHMAVaby6atOqcRhlvos3l0LEySUtYk1w7umzaOYUKJ7Ez7aXynkrZNod645Il39OQoeX8tbW4 4IlWEgnaca/+S19hPpr/AOS19hPpo3/MKq33ADBRkq5D6ewbOZwrogHBTsrCu9WUGscRWtfDu3ck 10b+Wag1IqeYbh9nAdvLhRDDA40TkDWhM+brWUeCNS9R+SZ66AR1f+MR8me31ddWfMIEfhzKaoXH CcejrI6aN5AVdsSoclQejKe0ej/8Wxga0ySNk7OayHZyCo5MeSK31G3kyodOPNKJiak4tUn4TEgV nWDD4MFSCu0TzlO/5qio5enkwipro5NIzOA5oUYTRO7KtbGAM+WQCyg6dQKqs9bsoPZNcJUcvHh7 gPvMNW/uzVy4QVFvxA6T/tLCcMpmuGyMjEFhr04xE+Fm30ECsASyq5iCVmds7DmBXBCM7xMLpH+5 lnsmpAbVJAQQSYzxUlduJ1YZHGgoBEnTMownd3GaO3kwwFdBMTUVjumihyiRyZUGXEESDWVZGsjW RqThyQ4K9eVYc1WjDGp5J2cmOysOQ4181SKUnZJ5veqDkKIY9xfZ38jaPFpOnrirWWng9yeyfVFW v8fTHEbVp38N/juq3Z2Ncuu38KXGP+7T66a+SpNm5qGllb8M4GdJPsznuFWf/Je/rqz1XPkFW/aL 29BtzBiTkTAxxwkE7MqW53m0OtopcA1KSREGJwkGCSI3EUaC7Mz1VO7kgYmv3jny2kV9YNoFhh3S NMZYiccD9XrpLervm7dVl26RxI+Ra4E4fmT+5ER9v1chIxoK2IOyMq0DrjdyYYruqVPMg5VpbbUA 0DursqDUipYV0cmFMx2COcWOQrWPEcTywCVUnUVAVlnfDqwHZFC4rurxGruE+8p04Yd2KaLjjVIe NA1T1Jh1iCd+VAhmQgaO7pxXcdQYULZdygMhWW20faQn11qtuytvC2/7IH8sTtk0VDMC3iMJj1ro 0e7mSc6BBLacVnSAOpVCrPTE1FSeqsK7ow3nKt7b+TBZ7a8Hr/ZXg9f7KnR6/wBlNc0Es0DFtg2D CvB6/wBleD1/so6UCk+18RW8nM8upcDWm4I6eZh4hlRJ2EzNY0I2GpNYVA5caPSecqJGkGWruv6q g/Bwa1AY/DxUVoY95fWOZrXtrKss6x5wHNLHIVrWccdR+M0DUDM1j8Hjjy970/DalzFSOWK1Lka6 ecBztH1qiB6a7wkdlDqoqgWFXXBBJbfBkR6DmKJsaSqhPEpOpnyA7wjNd+eVSNOrXw9Gjb18SI6f Vsrh2ioKgFiwLYnZmvxig7DvklNA+sJ9WE9VFgqlAYJCEgRmJ1zhtISKLoFXToGkqWJLR++g2/PS rdjvyFKjTBWZBEtuOINNdTTwlJ7uk6mCnEg6vR3TUjEHKp5hAzrPGs/VS3FODANHWJ31mKzFZ+qs x6K31I5mPJ+6eZBrDLnaudGxcK6ak50OqkvfUMN/C2HyweyltT3Um63yIOz+ihdM6OMXnSfDjjll 00OGGNy43GMAHuiNMyy/u7cxlSXV/Lb8T3dJP+33jQUu+iXPdZ1UCZBDKwXHaDjNXC2LMbWJn92D gQenOg9tTOk2lH/TuExJ39Z/qpWUHg2wLJMCJMbdU7VnunLPOuEc7ZKdns+6R2jm628K5dJ/Z8vb y2wbfDKWtFzLvN3dxxiGxP1uukQoYW7cctIiG1xtn2hswoqPAIun+MjRHox6+QxnWpgQPaO+joyG Z30JxFbjU8nzCu8a0Ns8PSOZBro5kVHNLbdnXWt/GfVWo51JzoNUHEGiLSKgOelQPkrVwrc5zoX6 KPDRVnPSAJouiKrHMqoBNa+Emr62gT8lC4UUuMmKiR21re2jMcJZQTXDCqE+rAj0VotqEXOFED1V JyrAj01iRUkwu/f1fT6KABHpruth2V4/UPorx+ofRXj9Q+iiQ2eeA+ivH6h9FeP1D6Kh3wPRUDKs eTA1sFSxn+EVgI6TnWrNht5sGv3fgQzeFMe2tTejknZWNZeisj8e2sj8e2sjWRrI1kayNZGsqyrv KD1ipCKD0AVkBWI+Cg8/o5sV0c+BnQG7l0LkM6A+E6a7x7xGFDDvbaiSev4LA41pOfwunYMedw1a WmBu9NY8kLntO6tK0OqlsnJpd/4V+kx2TR4Y0pcRioGEOs+v+2lu2gA5WGgROod2d/fA9NKbUAnU rMM2gHM7aKgKuEjSEBy2R359UVau3QHNxH1BlBgqVG0YH6wymkBAbVa4sMF0hjGQjSPjNM1osLgX ZwoxwP5eP2sO2mTy4CiVW6iiBBgzHq6pq6igBQ+AGQ7i1AzNTOO+o9P0/srdU8mQq2LikM1tXkx3 spyyzGcZ9cL3fE72+1dX9taNPe1aPd1T1R68KyFSQK4ayCcjWls/lrAVqGdQwx58c1jvj5+bw08T eocmh+8Nh2/toTcAnZ/rWleQdVNCnS2lQ/dgJtwOM4t7MZVwrQLLIKP3F07wQNOeOS7aDaQulQkO RB6Rp1ZbJiha0+DV3yVhpnLGfSBU8JgpIaDozAIz4hwx+rNDuawNZ7hXNyCfEy5RAw6ZpQ9snSht DSVmMIJl49DeijYdAF0xJAGWWVx/kHXTXwhD6vASslYAO3TOEjH0TVx7qldTagpInBVGwkbN9asp 2isDht6eSTyYsB214h6aX8TUEXhpqK4Lhuichnu65DcTBWZ1WViWmen2jtwpr5IEKEXvZ7Sfm9Ne IemoLCOuuIG1RktcR8PqjdyYGp2/AY8yeZJos2Z5AN9cJxJGVAGRFYVhmKyNZGsjWRrI1kayNZGs jUQahgY2GpAmpNZcmIrKsqyrKsqyrAc08+R8B0csjMUtxcNQDCp28gt6NUrqnVG/oO6vyvf+7X5X v/dr8r3/ALtfle/92vyvf+7X5Xv/AHa/K9/7tfle/wDdr8r3/u1+V7/3a/K9/wC7X5Xv/dr8r3/u 1+V7/wB2vyvf+7X5Xv8A3a/K9/7tfle/92vyvf8Au1+V7/3a/K9/7tfle/8Adr8r3/u0trh6dU46 pyE7uZq5M+d0c7o5vBuiUJ7p3VK4VEE13/ClrWQNsE4Vb1WSiM6ie9BB69+8GiFtppBw75Ldo1z6 hVspbUG4momWw6u98s09y+JtoMes5U1sZAyvUcqtsiISyBmLOQZjYNY+SlLIOHwg7tqOoHqn+mku hFZyxBLvpw+0tLdCIXLMDreBHR3xS2jgGOz5qZFtgBWgHU2Mb8dvRHXVuxaUKGCk4nbnmTlVt7I/ DZtDYnMGPXTIqjQCO6Z+mfXXAICIBh3jiY2kk+qgWQLOTIxKn0zStaC3LhnWrMQR1AEeunbzCwNf DQScG/ZV5Lw76sEVpOBOA9cVbkTc4ircMnbjFXpThhI4bS3e9JM9lcO2IWFwpltogURjr7/o1/00 qWhCgZfynmH4GDl8nMgZc/A99cG+ntrvYGldM9AHWJalVVVVV+JAnxdpPqosyKGJksNXzsR6qRWA hBpEUbVs6ZOosshvTOVKbkSo0ztPXSKwEIukRupXAWUXhxsI6caFpkQoCWA72E9TChZZFZASwnVt 6mFB07pBkRsos1tJJljBx9eE7YiuKFQOF0z3svtVoc64YOC8kgjtriNbTUTJPe/uo3XRCSIOePrw 7IpbcBUXJV6esk+ugQi6lyaDPqMHtFBFbTBLErILE76cQo4mnURPs5RjQtmDD8STMz6aNxoBbdWt 0XV9Yatn80eqi7ous+0NX90eqkbSq+LBBA8J5hjn48uMadld2K/FnT+7l9NdzLmjkHD3d6d3x9fR XTX4/D1R7emY7a/R9yv0fcr9H3K/R9yv0fcr9H3K/R9yv0fcr9H3K/R9yv0fcr9H3K/R9yv0fcr9 H3K/R9yv0fcr9H3K/R9yv0fcr9H3K/R9yv0fcocLha9mnTPqr//Z ------=0VO_02X1312NB_00D.064K73S0-- From Lindsay@nuukiemail.com Tue Feb 1 21:59:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05631; Tue, 1 Feb 2005 21:59:52 -0500 (EST) Message-Id: <200502020259.VAA05631@ietf.org> Received: from c-24-23-115-167.client.comcast.net ([24.23.115.167]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CwB2V-0000kt-TC; Tue, 01 Feb 2005 22:18:49 -0500 Received: from [58.200.50.98] by campbell%DIGITS.chivalry.24.23.115.167 via HTTP; Tue, 01 Feb 2005 21:59:25 -0800 Reply-To: "a Miranda Inc." From: "a Miranda Inc." To: Subject: Four beautiful matches Date: Tue, 01 Feb 2005 21:59:25 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--4494588404xhxa0433" X-Spam-Score: 3.6 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ----4494588404xhxa0433 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable 4 Cheating House Wife have been matched for you in your area: 1: Rebecca, 128 lbs, 5'5, 36c, 10 miles away, available most nights (husba= nd works midnights) 2: Tiffany, 131 lbs, 5'7, 36d, 19 miles away, available most nights (husba= nd works midnights) 3: Rebecca, 134 lbs, 5'8, 34b, 19 miles away, available most week nights (= looking for side-fling) 4: Alyssa, 120 lbs, 5'5, 36c, 8 miles away, available Jan29-31th All 4 women are waiting to speak with you live & have photos. Webcam's are= available for all 4. http://godatetomorrow.com/d/10.php If you have found a lady or not to be paired up then continue. http://godatetomorrow.com/out/=20 ----4494588404xhxa0433-- From simple-bounces@ietf.org Wed Feb 2 02:21:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28425; Wed, 2 Feb 2005 02:21:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwF7a-0006My-7s; Wed, 02 Feb 2005 02:40:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwEmp-0007gj-LK; Wed, 02 Feb 2005 02:18:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwEj6-00069R-F7 for simple@megatron.ietf.org; Wed, 02 Feb 2005 02:15:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22350 for ; Wed, 2 Feb 2005 02:14:58 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwF1P-00069u-Vh for simple@ietf.org; Wed, 02 Feb 2005 02:33:56 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 01 Feb 2005 23:14:50 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j127EQ82006555; Tue, 1 Feb 2005 23:14:26 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-107.cisco.com [10.86.240.107]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHL44198; Tue, 1 Feb 2005 23:14:25 -0800 (PST) Message-ID: <42007DD0.4050802@cisco.com> Date: Wed, 02 Feb 2005 02:14:24 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat References: <41F33C72.2070306@cisco.com> <41F778F5.8040004@nokia.com> <41FA2D02.3020008@cisco.com> <41FE4707.8030602@nokia.com> <41FE4F2C.8000806@cisco.com> <41FE5B74.3020105@nokia.com> <41FE6C99.6060708@cisco.com> <41FF87A5.3060301@nokia.com> <41FF98DC.8060605@cisco.com> In-Reply-To: <41FF98DC.8060605@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: Aki Niemi , Simple WG Subject: [Simple] Re: Single tuple or many tuples X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: > Here is (a bad) one, based on what I think you have in mind. (Please > feel free to provide a better way to handle this case.) > > Suppose your presence includes one tuple listing audio, video, and doom. > My presence client doesn't understand doom or video, so it simply > renders the tuple as available for voice. I pick it and make a voice > call. Your Doom service slaves audio to the game, so I just hear a bunch > of bleeps and gun fire. I am likely to be annoyed with you for having > announced that you were available for voice when you were not. > > Or, your UA refused my call because I didn't offer doom control > protocol. I'm still annoyed that you said you were available for voice > but refused my call. (But at least this is within the realm of > reasonable behaviors.) We've touched on this kind of case before. Its another example of a case where there is a mandatory feature or media stream that needs to be used by the watcher in order to connect. If you want this, I think it is far preferable to explicitly state that. That makes it more than just a capability, so its not just a prescaps issue. We ran into this previously for PTT, where folks wanted a way to say that you HAD to use this floor control protocol. I recall advocating that a non-SIP URI might even be the best way to handle these things since they are arguably not really SIP proper. However, I think Aki's case is different still. The example he has been giving is "I'm available for IM, not for audio". This is not saying that a watcher has to use both IM and audio, and thus seems different from the doom case. I think what it means is that the actual status of communications is no longer readily expressed as OPEN/CLOSED. Rather, it is effectively a boolean function over a set of session characteristics. In other words, whether I am available depends on the details of the session. Here, I'm available if we have IM only, but not if we have audio. One can imagine complex boolean functions which are not readily decomposed in a way that makes them amenable to representation using a number of separate tuples each just with a simple OPEN/CLOSED. For example, what if I want to say that I'm available if you have audio AND video, but not if you use audio alone or video alone. Admittedly this is a stretch, but this seems harder to do using separate tuples. Worse case with N variables you could require 2^^N tuples. Yuck. I would suggest that another approach would be to define an alternative status indication that actually contains the boolean function: (AND (EQUAL audio TRUE) (EQUAL video true)) where I am using rfc2533-style syntax for boolean expressions. As Paul suggested, I think the status here would still be OPEN, but this more complicated status would provide more complex information about availability. To be clear - I don't think any of this impacts the compromise position we have reached around the data model; rather this discussion is follow on to help us sort out what multiple tuples might mean in different cases. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 2 02:27:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04521; Wed, 2 Feb 2005 02:27:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwFDB-0006V4-N3; Wed, 02 Feb 2005 02:46:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwEtx-0002d1-MO; Wed, 02 Feb 2005 02:26:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwEnM-0007nl-UA for simple@megatron.ietf.org; Wed, 02 Feb 2005 02:19:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26560 for ; Wed, 2 Feb 2005 02:19:23 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwF5f-0006Ht-BF for simple@ietf.org; Wed, 02 Feb 2005 02:38:20 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 01 Feb 2005 23:21:24 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j127Io82007981; Tue, 1 Feb 2005 23:18:50 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-107.cisco.com [10.86.240.107]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHL44326; Tue, 1 Feb 2005 23:18:48 -0800 (PST) Message-ID: <42007ED7.9030900@cisco.com> Date: Wed, 02 Feb 2005 02:18:47 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] another try at data model compromise regarding unique service URI References: <41F33C72.2070306@cisco.com> <41F6D408.6080700@cisco.com> <41FA2C65.4040305@cisco.com> <41FAB375.3070108@cisco.com> In-Reply-To: <41FAB375.3070108@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: >>> How is it that the compositor knows the GRUUs are all bound to the >>> same AOR? It knows they are bound to the same domain, but AFAIK >>> nothing more. >> >> >> I was assuming a compositor that had access to registration data. > > > The public registration data (available via reg package), or the > complete set of private registration data. Either, possibly. I happen to think that it is more likely that there will be a tight coupling between providers of the registrars and presence servers, so the private registration data can be provided through proprietary interfaces. If this is not the case then reg-event needs to be used. > > The current reg package doesn't give info on GRUUs, so you wouldn't be > able to figure this out from that. True. Thats a known bug which we would need to fix in order to ultimately do this. > >>>> GRUU PUA, union compositor: This produces a document that exposes >>>> the GRUU to the watcher. Still works fine, though it may not have >>>> been desireable to expose the GRUU to the watcher. >>>> >>>> GRUU-less PUA, smart compositor: The compositor can correlate the >>>> tuples together because they each use the AOR as the . >>>> However, because there is no GRUU, it can't as easily correlate each >>>> tuple with a registration that might exist for the UA that generated >>>> the PUBLISH. Such correlation would need to be supported through >>>> other tuple data. >>> >>> >>> Hmm. You mention the compositor correlating PUBLISH data from PUAs >>> with registration data. This is the first mention I have seen of that. >> >> >> Oh? The whole model we have is based on multiple sources of data... > > > Sure it has always been a potential. But we had never gotten into such > specifics. If it becomes *necessary* to access registration data to make > a compositor, then we had better make that very clear. I don't think its ever NECESSARY, but it sure would be nice. As an example, I have heard complaints that it seems redundant that when a client device turns on, it would have to *both* REGISTER and PUBLISH to indicate availability. If a presence server had direct access to registration data, the extra PUBLISH could be avoided. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 2 02:35:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10050; Wed, 2 Feb 2005 02:35:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwFLa-0006gf-Kf; Wed, 02 Feb 2005 02:54:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwEzB-00054i-1d; Wed, 02 Feb 2005 02:31:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwEvc-0003ZI-JT for simple@megatron.ietf.org; Wed, 02 Feb 2005 02:27:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05318 for ; Wed, 2 Feb 2005 02:27:54 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwFDw-0006VN-9L for simple@ietf.org; Wed, 02 Feb 2005 02:46:52 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 01 Feb 2005 23:27:47 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j127RM82010420; Tue, 1 Feb 2005 23:27:23 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-107.cisco.com [10.86.240.107]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHL44672; Tue, 1 Feb 2005 23:27:21 -0800 (PST) Message-ID: <420080D8.1060502@cisco.com> Date: Wed, 02 Feb 2005 02:27:20 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: krisztian.kiss@nokia.com Subject: Re: [Simple] Presence data model: in References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, Walter.Goix@TILAB.COM X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit inline. krisztian.kiss@nokia.com wrote: > Hi Walter, > > >> -----Original Message----- From: ext Goix Walter >> [mailto:Walter.Goix@TILAB.COM] Sent: Sunday, January 30, 2005 4:41 >> AM To: Kiss Krisztian (Nokia-TP/SanDiego); simple@ietf.org Subject: >> RE: [Simple] Presence data model: in >> >> >> Krisztian, >> >> The examples in the presence data model draft identify >> as an element under , but that's probably what you had in >> mind. > > > Right. The intention is that this would be defined in RPID, actually. > > >> However, I don't clearly see the rationale for multiple >> within a single . Multiple devices for the same presentity >> may offer exactly the same service, but they probably would need no >> element to get the ability to be merged into a single >> at the server. In that case, if one device updates its >> inserting a element (max 1 in PIDF ), then >> both tuples will need to be separated again. Same if another >> property of a single device is updated. I personally see >> more complications than benefits allowing multiple per >> . Is there a real requirement for such an optimization? > > > Actually the intention of my previous e-mail was not to debate > whether you can have multiple s under or not, (the > current draft allows more than one at the moment, I think) but I > agree with your analysis and would restrict the number of > elements to be one under . > I disagree. It was an explicit design choice to allow this, to support cases where a service runs on multiple devices. That is explicitly defined in the data model UML diagram. In such a case, the for the service would be the AOR. A compositor would construct such a document by taking individual elements from each component UA, throwing away their elements, but combining their s. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 2 05:17:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25832; Wed, 2 Feb 2005 05:17:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwHsA-0002KE-Ir; Wed, 02 Feb 2005 05:36:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwHWG-00078j-J3; Wed, 02 Feb 2005 05:13:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwHRl-0005rY-4M for simple@megatron.ietf.org; Wed, 02 Feb 2005 05:09:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25180 for ; Wed, 2 Feb 2005 05:09:14 -0500 (EST) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwHk6-00028l-4r for simple@ietf.org; Wed, 02 Feb 2005 05:28:14 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j12A97O20610; Wed, 2 Feb 2005 12:09:07 +0200 (EET) X-Scanned: Wed, 2 Feb 2005 12:19:33 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j12AJXlI006979; Wed, 2 Feb 2005 12:19:33 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 000zH8Dg; Wed, 02 Feb 2005 12:19:29 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j12A8hx20947; Wed, 2 Feb 2005 12:08:43 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 2 Feb 2005 12:08:40 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 2 Feb 2005 12:08:41 +0200 Received: from 172.21.50.105 ([172.21.50.105]) by esebe105.NOE.Nokia.com ([172.21.143.53]) with Microsoft Exchange Server HTTP-DAV ; Wed, 2 Feb 2005 10:08:40 +0000 Received: from xitami.research.nokia.com by esebe105.ntc.nokia.com; 02 Feb 2005 12:08:39 +0200 Subject: Re: [Simple] Namespaces and XCAP From: jari urpalainen To: ext Jonathan Rosenberg In-Reply-To: <41FF3331.8010008@cisco.com> References: <41FE9B4C.1070106@cisco.com> <1107242622.26454.54.camel@xitami.research.nokia.com> <41FF3331.8010008@cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 02 Feb 2005 12:08:39 +0200 Message-Id: <1107338919.27837.34.camel@xitami.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-OriginalArrivalTime: 02 Feb 2005 10:08:41.0020 (UTC) FILETIME=[2B93E7C0:01C5090F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit On Tue, 2005-02-01 at 02:43 -0500, ext Jonathan Rosenberg wrote: > inline. > > jari urpalainen wrote: > > >>So, which to use? Considering the issues involved, I think the best > >>option is 5(A). > >> > >>Comments? > >> > >>Thanks, > >>Jonathan R. > >> > >> > > > > > > In principle I am in favor of 5A. However, I have a difficulty > > understanding why we should use a different syntax than what xpointer > > spec has ? > > Why is it different? I was proposing to use the xmlns xpointer > expression exactly as defined. > > > > > http://www.w3.org/TR/WD-xptr > > > > xmlns(x=http://example.com/foo) xpointer(//x:a) > > Oh, so you are saying ditch the whole xpath thing in favor of xpointers > for element naming? > yes definitely. > My read of xpointer was that it was primarily aimed at solving a broader > problem even than path, namely being able to identify points and text > ranges within an xml document. We don't need or want that. I also don't > know how to map this easily into URI's, whereas xpath is easily mapped. > Since the ONLY thing xpointer() would give us is syntax, what is gained?? > yes it does extend basic xpath with these ranges and points and of course I don't want to propose to use them just this xcap scoped restricted xpath. I just don't want yet another buggy uri selector as w3c has already found a proper model for selectors with xpointers. > > > > Furthermore, there seems to be a tendency to use fragment identifiers, > > so I would propose to use them. > > URL fragment identifiers? AS in #fragment-id? As an alternative to the > ~~ approach in the URI? > yes. this seems to be w3c preference (xlink, xinclude etc.) and I think we should really follow that. > > > > This leads to another issue that has to be addressed as well, i.e. the > > namespaces in the request body. Do we still use the namespace context > > from the document or do we use definitions from the xpointer context or > > do we use the body context when appending new data ? > > Document. The body is either the document itself or a piece of it, in > which case the namespace bindings have to be from the document. > so the document context should still be followed strictly. > > > > > Some interesting cases arise when we want to e.g. append a new node like > > this > > > > xmlns(x=http://example.com/foo) xpointer(/x:root/x:a) > > > > where body equals > > > > > > > > > > > > Given the document root had the same prefixed namespace definition how > > should the xcap server append this ? > > What is the ambiguity? The URI provides the bindings for the URI > evluation against the document. It resolves to no existing element. > Great. The parent element is located (again using the URI namespace > binding context), and the content of the request is inserted as its > child. It happens to reset the default namespace. Perform a GET against > that same URI. It now returns what was just selected. Everything is fine. > > If the element had redefined the default namespace to something else, > the URI would no longer select the element just inserted, and the > operation wouldn't meet the GET(PUT(X))==X property and be rejected. > my aim was to raise a question whether to allow a more xml-ish way of allowing e.g. the server to decide when to drop duplicate namespace definitions or change e.g. default namespace usage to a prefixed version etc. Granted, I don't have a clear view on this, but I am just afraid that we may miss some useful usecase given this tight schedule. > > > > > Character encodings should also be addressed somehow as we are heading > > towards better "blind" updates, i.e. if the document uses e.g. UTF-8 > > encoding and the client uses charset=iso-xxx, what would be the result > > of an append operation ? > > Good question. This came up as a comment from others during last call. I > have already added text to my working copy which says that this would be > rejected. An error code has been defined for this too. Indeed, the > current text mandates UTF-8 so anything but that in the charset is rejected. > Sorry I may have missed that thread, but I'll hope this means that the server has to support UTF-8 but may support UTF-16, ISOxxx, right ? > -Jonathan R. > br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 2 09:00:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04696; Wed, 2 Feb 2005 09:00:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwLLS-0007nr-Pa; Wed, 02 Feb 2005 09:19:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwKxE-0006Ws-L0; Wed, 02 Feb 2005 08:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwKu8-0005RW-99 for simple@megatron.ietf.org; Wed, 02 Feb 2005 08:50:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03673 for ; Wed, 2 Feb 2005 08:50:44 -0500 (EST) Message-Id: <200502021350.IAA03673@ietf.org> Received: from winwebhosting.com ([67.15.20.8] helo=dx24.winwebhosting.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwLCT-0007SM-UT for simple@ietf.org; Wed, 02 Feb 2005 09:09:47 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx24.winwebhosting.com with esmtpa (Exim 4.43) id 1CwKtZ-00059L-8s for simple@ietf.org; Wed, 02 Feb 2005 06:50:13 -0700 From: "Brian Rosen" To: Subject: FW: Single tuple or many tuples (was: Re: [Simple] another try atdata model compromise regarding unique service URI) Date: Wed, 2 Feb 2005 08:50:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcUIjt+eGvZvsYyIReSxGuVZPgvCUgAlgvuwAAJJQjA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx24.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-Spam-Score: 0.0 (/) X-Scan-Signature: db284e046c8702920c1c6125bc4d0b7a Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 07e9b4af03a165a413ec6e4d37ae537b Content-Transfer-Encoding: 7bit I don't think we have a prayer of making a Doom game with audio and video streams as well as the game stream work in presence without having a notion of service that has some kind of name which is used to describe the service. That service description can be text as long as it is unique enough that the watcher (client) can render some good enough UI and the watcher (human) understands what to do with it. So if someone defines "Doom" as being a service that has a game stream and optional audio and video streams, then you can build a watcher that understands what Doom is and render a very nice interface with, say, a Doom icon, and a basic watcher can show the name of the service and the media streams on it that a human can interpret it. I think we all agree that, at the very least, the presence of the Doom service is contained in one tuple. The only thing you really would like to understand about service is name and the fact that it can contain multiple streams and multiple capabilities. I don't think you can infer this notion of service from the aggregate of capabilities, and I don't want to try. You can DEFINE a service as having some fixed and optional capabilities with the watcher being able to discover which of them a particular presentity has available at a point in time. That we can do. So don't guess that audio and/or video with half duplex and floor control MEANS PTT, instead DEFINE PTT as a service that has audio, optional video, half duplex and floor control and let a tuple state that the presentity supports a PTT service and at the present time only has audio (not video) available. Then I can offer a Telephone service and Doom service, both of which support audio, and we won't get anyone confused. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, February 01, 2005 1:51 PM > To: Brian Rosen > Cc: 'Aki Niemi'; 'Simple WG' > Subject: Re: Single tuple or many tuples (was: Re: [Simple] another try > atdata model compromise regarding unique service URI) > > Brian - inline. > > Paul > > Brian Rosen wrote: > > I've pretty much stayed out of this whole set of threads, but this one > > really had me wondering where everyone's head is again. > > > > We're getting wrapped around the axle of not having a definition of > > "service" again. > > Well, we had decided that a service is whatever a tuple describes. > But functionally I agree it has still not really been resolved. > > > Specifically, I believe that the Doom case you describe below is a > Service > > called Doom that has a number of media streams it supports. It does NOT > > offer a voice SERVICE, the DOOM service includes game, audio and video > media > > capability. > > I infer that you are using "service" to denote what kind of > functionality is provided via the communication channel(s) described. > > So in this case there is an automaton executing the Doom game, providing > a rendering of that via the output streams, and accepting input to it > via the input streams. > > > Now the TUPLE might offer a voice SERVICE, in addition to Doom, possibly > > using the same hardware, possibly not. You don't care. > > We currently have no definition of, or way to describe, services such as > these. The closest we can get to this right now is via a few attributes: > > - automaton > - attendant > - message-taker > > If all of those are false, in absence of any extentions, I think you > have a "conversational" service facilitating interactive conversation > with a human being. > > Even with the limited range of "service"s that can be represented via > those attributes, it is impossible to say in a single tuple that you > have a conversational service and an automated message taking service, > except in the negative - by saying nothing about what is provided. > > > PTT is a SERVICE. It supports voice, possibly video and has floor > control. > > From what I have inferred above, I don't see how this can be considered > a service. It says nothing about the content, and its not an automaton. > It simply provides different ways to control the media in a > conversational session - like a different codec does. > > > But there is nothing in the set of capabilities such as: audio=true, > > video=false, duplex=full, floor-control=false that could possibly > indicates > > PTT isn't there. A dumb but straightforward audio conference phone > could > > have exactly the same capabilities. The dumb conference phone could > have > > that also. The "floor control=true" and "duplex=half" capabilities, in > > particular, are not peculiar to PTT. A cell phone with PTT today would > have > > at least two services (voice and PTT). Today, those services are > separate; > > even the voice path is separate in many implementations. > > Why is this any different than audio vs video? I might want to have a > conversation with you using any of those, and switch back and forth > between them during the call. I think I know the answer, but its not an > appealing one - the UA will simply not permit mixing the capabilities in > a single call, or even switching among them serially within a call. Of > course there are lots of technological excuses for this, but it makes no > real sense from a user standpoint. > > I can at least imagine using PTT to talk to a VM "service" or auto > attendant "service". This all suggests to me that PTT is not a service > in the sense that Doom might me. > > The PTT case is, I think, just a matter of wanting a way to describe > mutually exclusive combinations of capabilities. I believe we agreed > some weeks ago that this was potentially still of interest, but > postponed dealing with it. Until then, multiple tuples with the same > contact provides a way at the expense of being ambiguous about what is > intended. > > I have been trying for years now to understand what you "service" > oriented people are talking about. It always seems like there is > *something* there, but its elusive, and you don't all seem to have the > same concept. I think there may be some opportunity to describe this as > the behavior behind the media, encompassing VM, Attendant, Doom. > > > And please keep in mind that I want to be able to offer a presence > service > > with ONE contact, which I assumed was one tuple, but don't care if there > are > > multiple tuples as long as they have the same contact URI. That > represents > > the presence information of the presentity, full stop, including all of > the > > services it might support. > > You have been quiet for so long now that I thought you had got the > correct religion, or fallen asleep, or something. :-) > > If you are going to offer a single tuple, and hide both a conversational > voice service and Doom behind it, I don't see how you are going to avoid > disappointing someone. Somebody is going to end up on their phone > talking to a doom game. > > > Brian > > > > > >>-----Original Message----- > >>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > >>Of Paul Kyzivat > >>Sent: Tuesday, February 01, 2005 9:58 AM > >>To: Aki Niemi > >>Cc: Simple WG > >>Subject: Re: Single tuple or many tuples (was: Re: [Simple] another try > >>atdata model compromise regarding unique service URI) > >> > >> > >> > >>Aki Niemi wrote: > >> > >>> > >>>ext Paul Kyzivat wrote: > >>> > >>>...snip... > >>> > >>> > >>>>For devices with the real estate, it would be better to simply display > >>>>multiple icons for each buddy indicating what capabilities are > >>>>currently available. (Perhaps icons of phones and cameras can turn > >>>>from red to green.) > >>> > >>>I don't buy this. Think of a "doom" icon that can be either red, green, > >>>or indicate deathmatch. Capabilities are uninportant, it's the service > >>>that is composed of those capabilities that is important. > >> > >>I don't understand your point at all. > >> > >>It seems to me that either: > >> > >>- you have a separate tuple/service for Doom, with its own unique > >> contact that I can call. In this case doom itself may have > >> "doom" capability, and perhaps audio, video, etc. as well. > >> > >> you then have other contacts with differing sets of capabilities > >> and different contact addresses. Perhaps one with basic voice. > >> > >>- you have a single multipurpose tuple/service. It has capabilities > >> for voice, and maybe doom as well. > >> > >>- you have multiple tuples - one for doom, another for basic voice, > >> but they share a contact address. > >> > >>The question is, how do I know what to expect when making a call in each > >>case? E.g. if I make a voice-only call, do I talk to you, or do I hear > >>the audio from a doom game I can't control? > >> > >>I guess it depends a bit on how you expect doom to work. Do you imagine > >>it to consist of a game control protocol plus audio and video streams > >>rendering the game? > >> > >> > >>>And do you really think users will generally be happy to interpret that > >>>someone is available for push-to-talk by examining a set of three (or > >>>more) icons? > >> > >>I see a couple of alternatives here: > >> > >>- the user has a PTT application displaying presence. It is only > >> interested in PTT, so it filters what it displays. All I get is a > >> list of buddies with red or green status. > >> > >>- the user has a general purpose presence client, that can do PTT, > >> regular voice, video, Doom, whatever. (The user has to both pick > >> a buddy and then pick an action to do something.) > >> > >> In this case, it has three or more things to display regardless > >> of how the RPID document is formatted. Either it has multiple > >> capabilities for a single tuple, or it has multiple tuples each > >> with (potentially multiple) capabilities. There are many ways > >> of rendering each of these, but the fundamental complexity of > >> what is to be rendered is pretty much the same. > >> > >> > >>>>You seem to have in mind a "video service" that includes both voice > >>>>and video, and a separate "audio service" that includes only audio. > >>>>And then either or both can be available. > >>> > >>> > >>>I gave an example of *three* different services. But fine, let's say > you > >>>only have two: a videophone capable of both video and audio (together > or > >>>separate) and a push-to-talk client (audio, half-duplex and floor > >>>control). Now, let's say video is unavailable, audio is available, and > >>>push-to-talk is unavailable. > >>> > >>>How would you represent that in a single tuple? > >> > >>I left out the PTT to keep things simple, since I don't think we have > >>agreed in detail how to represent it as a capability. But lets try > anyway. > >> > >>In the state you describe it, I would simply represent it as a tuple > >>with audio=true, video=false, duplex=full, floor-control=false. What is > >>so hard about that? > >> > >> > >>>>But how is this better (or even as good as) a single videophone > >>>>service that is capable of supporting both voice and video, or just > >>>>voice, or just video, depending on what is negotiated in a call? With > >>>>such a service, if I don't want to be available for video, I just > >>>>disable it, so it won't be offered or answered, and then video then > >>>>isn't advertised in the (single) presence tuple either. > >>> > >>> > >>>I'm not going to debate over details about voice and/or video. My > >>>attempt was to demonstrate that there are "services" that aren't going > >>>to be described only using a single, simple media attribute, like > >>>"voice" and "video", but will be composed of a set of capabilities, > >>>where this capability set then shares a status that will have more > >>>states available than simple on or off. > >> > >>Ahh. This may be hinting at the real issue. But it is only a hint, and I > >>think you need to say a lot more to establish the use case. I've got a > >>feeling that PTT is a bad example because its "differences" are more > >>about limitations in the technology that intrinsic feature differences. > >> > >>I suspect Doom may be a better example. I have the idea that what you > >>have in mind is that when I call the "Doom Service" I get audio and > >>video that are slaved to the game, rather than a conversational adjunct > >>to the game that allows me to converse with the other player(s) while > >>playing. If so, then it is a lot like an IVR or a VM server. If so, then > >>I agree with you that it *should* be represented as a separate tuple. > >>But I also think it *should* have a separate contact, so that it is > >>clear how to reach that particular service. > >> > >>I gather you have in mind that if I negotiate the doom control protocol > >>I will get the doom service and the audio/video will be slaved to it, > >>but if I don't negotiate the doom control protocol then I get the > >>"conversational" service managing my voice/video. I don't see why I > >>would be able to draw that conclusion from the RPID. > >> > >> > >>>However, stepping back for a moment. > >>> > >>>Seems there is still some fundamental desire here to restrict the > >>>presence data model to suit the "unique-URI" concept. > >>> > >>>But like Henning has pointed out many times before, there will be > >>>multiple tuples in a document. So inherently, the watcher is faced with > >>>having to make a selection. Henning has also pointed out that to > >>>determine uniqueness, the contact is a very poor key to use. Whether > >>>some of those tuples have the contact address is therefore immaterial > >>>(and depends exclusively on the uniqueness rules of the URI scheme). > >>>Also, we aren't going to forbid a dumb composer passing all of the > >>>received tuples to the watcher using the union composition. > >> > >>In most cases I see no reason why the watcher has a need to determine > >>uniqueness. All it has to do is present the alternatives to the user, > >>let the user choose one, and send a request to the contact of the one > >>chosen. The kind of request sent can either be determined by default > >>based on capabilities advertised in the tuple and local capabilities, or > >>can be adjusted based on explicit choices made by the user. > >> > >> > >>>If we were to *mandate* that all SIP-enabled services are represented > >>>using a single tuple, where would you enforce this rule? And what would > >>>be the benefit compared to allowing more than a single tuple? > >> > >>I'm not sure this is something to mandate. I think it is more of a "best > >>practices" kind of thing. It seems clear that people are going to do a > >>bunch of weird things, and results will vary. About all we can do is > >>give suggestions on how to get a good result. > >> > >> > >>>Simply saying that it is possible in some instances to do things that > >>>way is not a good enough reason, if there are instances where it does > >>>not work. > >> > >>I think this might best be approached by restarting the work on presence > >>use cases. > >> > >>Here is (a bad) one, based on what I think you have in mind. (Please > >>feel free to provide a better way to handle this case.) > >> > >>Suppose your presence includes one tuple listing audio, video, and doom. > >>My presence client doesn't understand doom or video, so it simply > >>renders the tuple as available for voice. I pick it and make a voice > >>call. Your Doom service slaves audio to the game, so I just hear a bunch > >>of bleeps and gun fire. I am likely to be annoyed with you for having > >>announced that you were available for voice when you were not. > >> > >>Or, your UA refused my call because I didn't offer doom control > >>protocol. I'm still annoyed that you said you were available for voice > >>but refused my call. (But at least this is within the realm of > >>reasonable behaviors.) > >> > >> Paul > >> > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > >> > > > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 2 10:14:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14062; Wed, 2 Feb 2005 10:14:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwMVG-0001va-I0; Wed, 02 Feb 2005 10:33:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwM4E-0008DZ-M5; Wed, 02 Feb 2005 10:05:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwLz5-0005HY-KM for simple@megatron.ietf.org; Wed, 02 Feb 2005 09:59:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11883 for ; Wed, 2 Feb 2005 09:59:55 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwMHT-0001QG-1o for simple@ietf.org; Wed, 02 Feb 2005 10:18:59 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j12ExPZ1027901; Wed, 2 Feb 2005 08:59:25 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j12ExPn00318; Wed, 2 Feb 2005 08:59:25 -0600 (CST) Message-ID: <4200EACD.30507@lucent.com> Date: Wed, 02 Feb 2005 08:59:25 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Re: Single tuple or many tuples References: <41F33C72.2070306@cisco.com> <41F778F5.8040004@nokia.com> <41FA2D02.3020008@cisco.com> <41FE4707.8030602@nokia.com> <41FE4F2C.8000806@cisco.com> <41FE5B74.3020105@nokia.com> <41FE6C99.6060708@cisco.com> <41FF87A5.3060301@nokia.com> <41FF98DC.8060605@cisco.com> <42007DD0.4050802@cisco.com> In-Reply-To: <42007DD0.4050802@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > To be clear - I don't think any of this impacts the compromise position > we have reached around the data model; rather this discussion is follow > on to help us sort out what multiple tuples might mean in different cases. Jonathan: With a lot of email floating around on this subject, it may help to enunciate the compromise position(s) we have reached. I took a stab at it last week -- see http://www1.ietf.org/mail-archive/web/simple/current/msg04919.html If this is helpful, I will update it to reflect the latest developments. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 2 11:12:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22468; Wed, 2 Feb 2005 11:12:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwNQ6-0003wY-Ul; Wed, 02 Feb 2005 11:31:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwMrw-0003LT-LF; Wed, 02 Feb 2005 10:56:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwMlN-0000ni-TH for simple@megatron.ietf.org; Wed, 02 Feb 2005 10:49:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19559 for ; Wed, 2 Feb 2005 10:49:49 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwN3k-00038T-CI for simple@ietf.org; Wed, 02 Feb 2005 11:08:54 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Feb 2005 08:59:40 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j12FnDHo001162; Wed, 2 Feb 2005 07:49:14 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-16.cisco.com [10.86.240.16]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOU24637; Wed, 2 Feb 2005 10:49:15 -0500 (EST) Message-ID: <4200F67A.4060007@cisco.com> Date: Wed, 02 Feb 2005 10:49:14 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: Single tuple or many tuples (was: Re: [Simple] another try atdata model compromise regarding unique service URI) References: <3q2adl$188oa2@sj-inbound-e.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2f0065339d489fe5a2873ea9ad776d1a Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ba9cd4f9acda58dbe142afff7265daff Content-Transfer-Encoding: 7bit I think we are still talking past one another. I think Doom and PTT are very different in character from one another. So lets talk about them separately. I can imagine several ways that the Doom stuff might work: Doom-1) There is a Doom game server somewhere. (Something like a conference focus.) To use it you call it, establishing audio, video, and doom-control-protocol media streams. The audio and video you receive are a rendering of the game. Doom-2) You and your friends have sip-enabled Doom game consoles. You can connect them via a sip call, establishing audio, video, and doom-control-protocol media streams. The audio and video you send and receive are renderings of some/all of the game. Doom-3) You and your friends have sip-enabled Doom game consoles. You can connect them via a sip call, establishing audio, and/or doom-control-protocol media streams. Only the doom-control-protocol is strongly related to doom. The two game consoles use it to synchronize state, and each then renders the game to its user. The audio stream, if present, just lets the players communicate directly via voice - the audio is mixed with the game audio at each end. If this device is called and doom-control-protocol is not negotiated, but voice is, then the game machine simply acts as an audio phone. I can imagine Doom-1, but don't think it is a great model. Having the server do the audio and video rendering for all the users isn't consistent with the way games usually work. If you were to follow this model, then the game server would probably be represented as an AoR. Presence would be possible but not especially interesting. I have difficulty seeing how Doom-2 would work, since each game console probably want to do its own rendering of the game. At best this would require that they negotiate and pick one to do the rendering, and the other to be a slave. IF this was the model, then I agree that the entire combination needs to be understood as a unit, as Brian suggests. The model in Doom-3 makes more sense to me. And not surprisingly it fits with my capability model of representing presence. The doom-control-protocol is the only part that is doom specific. This model also can be used with a conference server to support multiplayer games in a way that is more plausible than Doom-1. More below. Brian Rosen wrote: > I don't think we have a prayer of making a Doom game with audio and video > streams as well as the game stream work in presence without having a notion > of service that has some kind of name which is used to describe the service. > That service description can be text as long as it is unique enough that the > watcher (client) can render some good enough UI and the watcher (human) > understands what to do with it. What you describe is true for Doom-2. For Doom-1 the entire presentity represents the "service". And Doom-3 doesn't require a separate service. > So if someone defines "Doom" as being a service that has a game stream and > optional audio and video streams, then you can build a watcher that > understands what Doom is and render a very nice interface with, say, a Doom > icon, and a basic watcher can show the name of the service and the media > streams on it that a human can interpret it. I think we all agree that, at > the very least, the presence of the Doom service is contained in one tuple. > The only thing you really would like to understand about service is name and > the fact that it can contain multiple streams and multiple capabilities. > > I don't think you can infer this notion of service from the aggregate of > capabilities, and I don't want to try. You can DEFINE a service as having > some fixed and optional capabilities with the watcher being able to discover > which of them a particular presentity has available at a point in time. > That we can do. So don't guess that audio and/or video with half duplex and > floor control MEANS PTT, instead DEFINE PTT as a service that has audio, > optional video, half duplex and floor control and let a tuple state that the > presentity supports a PTT service and at the present time only has audio > (not video) available. I don't get this. The floor control is the essence of PTT. Otherwise it is just audio. As Jonathan has pointed out, this may be a case where the implementation won't allow you to negotiate a session without the floor control. If so we need some way to indicate that. But that is the only special thing. > Then I can offer a Telephone service and Doom service, both of which support > audio, and we won't get anyone confused. I'm still seeing it differently, because I think Doom-2 is the only plausible model. Which model of Doom do you have in mind? Paul > Brian > > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Tuesday, February 01, 2005 1:51 PM >>To: Brian Rosen >>Cc: 'Aki Niemi'; 'Simple WG' >>Subject: Re: Single tuple or many tuples (was: Re: [Simple] another try >>atdata model compromise regarding unique service URI) >> >>Brian - inline. >> >> Paul >> >>Brian Rosen wrote: >> >>>I've pretty much stayed out of this whole set of threads, but this one >>>really had me wondering where everyone's head is again. >>> >>>We're getting wrapped around the axle of not having a definition of >>>"service" again. >> >>Well, we had decided that a service is whatever a tuple describes. >>But functionally I agree it has still not really been resolved. >> >> >>>Specifically, I believe that the Doom case you describe below is a >> >>Service >> >>>called Doom that has a number of media streams it supports. It does NOT >>>offer a voice SERVICE, the DOOM service includes game, audio and video >> >>media >> >>>capability. >> >>I infer that you are using "service" to denote what kind of >>functionality is provided via the communication channel(s) described. >> >>So in this case there is an automaton executing the Doom game, providing >>a rendering of that via the output streams, and accepting input to it >>via the input streams. >> >> >>>Now the TUPLE might offer a voice SERVICE, in addition to Doom, possibly >>>using the same hardware, possibly not. You don't care. >> >>We currently have no definition of, or way to describe, services such as >>these. The closest we can get to this right now is via a few attributes: >> >>- automaton >>- attendant >>- message-taker >> >>If all of those are false, in absence of any extentions, I think you >>have a "conversational" service facilitating interactive conversation >>with a human being. >> >>Even with the limited range of "service"s that can be represented via >>those attributes, it is impossible to say in a single tuple that you >>have a conversational service and an automated message taking service, >>except in the negative - by saying nothing about what is provided. >> >> >>>PTT is a SERVICE. It supports voice, possibly video and has floor >> >>control. >> >> From what I have inferred above, I don't see how this can be considered >>a service. It says nothing about the content, and its not an automaton. >>It simply provides different ways to control the media in a >>conversational session - like a different codec does. >> >> >>>But there is nothing in the set of capabilities such as: audio=true, >>>video=false, duplex=full, floor-control=false that could possibly >> >>indicates >> >>>PTT isn't there. A dumb but straightforward audio conference phone >> >>could >> >>>have exactly the same capabilities. The dumb conference phone could >> >>have >> >>>that also. The "floor control=true" and "duplex=half" capabilities, in >>>particular, are not peculiar to PTT. A cell phone with PTT today would >> >>have >> >>>at least two services (voice and PTT). Today, those services are >> >>separate; >> >>>even the voice path is separate in many implementations. >> >>Why is this any different than audio vs video? I might want to have a >>conversation with you using any of those, and switch back and forth >>between them during the call. I think I know the answer, but its not an >>appealing one - the UA will simply not permit mixing the capabilities in >>a single call, or even switching among them serially within a call. Of >>course there are lots of technological excuses for this, but it makes no >>real sense from a user standpoint. >> >>I can at least imagine using PTT to talk to a VM "service" or auto >>attendant "service". This all suggests to me that PTT is not a service >>in the sense that Doom might me. >> >>The PTT case is, I think, just a matter of wanting a way to describe >>mutually exclusive combinations of capabilities. I believe we agreed >>some weeks ago that this was potentially still of interest, but >>postponed dealing with it. Until then, multiple tuples with the same >>contact provides a way at the expense of being ambiguous about what is >>intended. >> >>I have been trying for years now to understand what you "service" >>oriented people are talking about. It always seems like there is >>*something* there, but its elusive, and you don't all seem to have the >>same concept. I think there may be some opportunity to describe this as >>the behavior behind the media, encompassing VM, Attendant, Doom. >> >> >>>And please keep in mind that I want to be able to offer a presence >> >>service >> >>>with ONE contact, which I assumed was one tuple, but don't care if there >> >>are >> >>>multiple tuples as long as they have the same contact URI. That >> >>represents >> >>>the presence information of the presentity, full stop, including all of >> >>the >> >>>services it might support. >> >>You have been quiet for so long now that I thought you had got the >>correct religion, or fallen asleep, or something. :-) >> >>If you are going to offer a single tuple, and hide both a conversational >>voice service and Doom behind it, I don't see how you are going to avoid >> disappointing someone. Somebody is going to end up on their phone >>talking to a doom game. >> >> >>>Brian >>> >>> >>> >>>>-----Original Message----- >>>>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf >>>>Of Paul Kyzivat >>>>Sent: Tuesday, February 01, 2005 9:58 AM >>>>To: Aki Niemi >>>>Cc: Simple WG >>>>Subject: Re: Single tuple or many tuples (was: Re: [Simple] another try >>>>atdata model compromise regarding unique service URI) >>>> >>>> >>>> >>>>Aki Niemi wrote: >>>> >>>> >>>>>ext Paul Kyzivat wrote: >>>>> >>>>>...snip... >>>>> >>>>> >>>>> >>>>>>For devices with the real estate, it would be better to simply display >>>>>>multiple icons for each buddy indicating what capabilities are >>>>>>currently available. (Perhaps icons of phones and cameras can turn >>>>> >>>>>>from red to green.) >>>>> >>>>>I don't buy this. Think of a "doom" icon that can be either red, green, >>>>>or indicate deathmatch. Capabilities are uninportant, it's the service >>>>>that is composed of those capabilities that is important. >>>> >>>>I don't understand your point at all. >>>> >>>>It seems to me that either: >>>> >>>>- you have a separate tuple/service for Doom, with its own unique >>>> contact that I can call. In this case doom itself may have >>>> "doom" capability, and perhaps audio, video, etc. as well. >>>> >>>> you then have other contacts with differing sets of capabilities >>>> and different contact addresses. Perhaps one with basic voice. >>>> >>>>- you have a single multipurpose tuple/service. It has capabilities >>>> for voice, and maybe doom as well. >>>> >>>>- you have multiple tuples - one for doom, another for basic voice, >>>> but they share a contact address. >>>> >>>>The question is, how do I know what to expect when making a call in each >>>>case? E.g. if I make a voice-only call, do I talk to you, or do I hear >>>>the audio from a doom game I can't control? >>>> >>>>I guess it depends a bit on how you expect doom to work. Do you imagine >>>>it to consist of a game control protocol plus audio and video streams >>>>rendering the game? >>>> >>>> >>>> >>>>>And do you really think users will generally be happy to interpret that >>>>>someone is available for push-to-talk by examining a set of three (or >>>>>more) icons? >>>> >>>>I see a couple of alternatives here: >>>> >>>>- the user has a PTT application displaying presence. It is only >>>> interested in PTT, so it filters what it displays. All I get is a >>>> list of buddies with red or green status. >>>> >>>>- the user has a general purpose presence client, that can do PTT, >>>> regular voice, video, Doom, whatever. (The user has to both pick >>>> a buddy and then pick an action to do something.) >>>> >>>> In this case, it has three or more things to display regardless >>>> of how the RPID document is formatted. Either it has multiple >>>> capabilities for a single tuple, or it has multiple tuples each >>>> with (potentially multiple) capabilities. There are many ways >>>> of rendering each of these, but the fundamental complexity of >>>> what is to be rendered is pretty much the same. >>>> >>>> >>>> >>>>>>You seem to have in mind a "video service" that includes both voice >>>>>>and video, and a separate "audio service" that includes only audio. >>>>>>And then either or both can be available. >>>>> >>>>> >>>>>I gave an example of *three* different services. But fine, let's say >>>> >>you >> >>>>>only have two: a videophone capable of both video and audio (together >>>> >>or >> >>>>>separate) and a push-to-talk client (audio, half-duplex and floor >>>>>control). Now, let's say video is unavailable, audio is available, and >>>>>push-to-talk is unavailable. >>>>> >>>>>How would you represent that in a single tuple? >>>> >>>>I left out the PTT to keep things simple, since I don't think we have >>>>agreed in detail how to represent it as a capability. But lets try >>> >>anyway. >> >>>>In the state you describe it, I would simply represent it as a tuple >>>>with audio=true, video=false, duplex=full, floor-control=false. What is >>>>so hard about that? >>>> >>>> >>>> >>>>>>But how is this better (or even as good as) a single videophone >>>>>>service that is capable of supporting both voice and video, or just >>>>>>voice, or just video, depending on what is negotiated in a call? With >>>>>>such a service, if I don't want to be available for video, I just >>>>>>disable it, so it won't be offered or answered, and then video then >>>>>>isn't advertised in the (single) presence tuple either. >>>>> >>>>> >>>>>I'm not going to debate over details about voice and/or video. My >>>>>attempt was to demonstrate that there are "services" that aren't going >>>>>to be described only using a single, simple media attribute, like >>>>>"voice" and "video", but will be composed of a set of capabilities, >>>>>where this capability set then shares a status that will have more >>>>>states available than simple on or off. >>>> >>>>Ahh. This may be hinting at the real issue. But it is only a hint, and I >>>>think you need to say a lot more to establish the use case. I've got a >>>>feeling that PTT is a bad example because its "differences" are more >>>>about limitations in the technology that intrinsic feature differences. >>>> >>>>I suspect Doom may be a better example. I have the idea that what you >>>>have in mind is that when I call the "Doom Service" I get audio and >>>>video that are slaved to the game, rather than a conversational adjunct >>>>to the game that allows me to converse with the other player(s) while >>>>playing. If so, then it is a lot like an IVR or a VM server. If so, then >>>>I agree with you that it *should* be represented as a separate tuple. >>>>But I also think it *should* have a separate contact, so that it is >>>>clear how to reach that particular service. >>>> >>>>I gather you have in mind that if I negotiate the doom control protocol >>>>I will get the doom service and the audio/video will be slaved to it, >>>>but if I don't negotiate the doom control protocol then I get the >>>>"conversational" service managing my voice/video. I don't see why I >>>>would be able to draw that conclusion from the RPID. >>>> >>>> >>>> >>>>>However, stepping back for a moment. >>>>> >>>>>Seems there is still some fundamental desire here to restrict the >>>>>presence data model to suit the "unique-URI" concept. >>>>> >>>>>But like Henning has pointed out many times before, there will be >>>>>multiple tuples in a document. So inherently, the watcher is faced with >>>>>having to make a selection. Henning has also pointed out that to >>>>>determine uniqueness, the contact is a very poor key to use. Whether >>>>>some of those tuples have the contact address is therefore immaterial >>>>>(and depends exclusively on the uniqueness rules of the URI scheme). >>>>>Also, we aren't going to forbid a dumb composer passing all of the >>>>>received tuples to the watcher using the union composition. >>>> >>>>In most cases I see no reason why the watcher has a need to determine >>>>uniqueness. All it has to do is present the alternatives to the user, >>>>let the user choose one, and send a request to the contact of the one >>>>chosen. The kind of request sent can either be determined by default >>>>based on capabilities advertised in the tuple and local capabilities, or >>>>can be adjusted based on explicit choices made by the user. >>>> >>>> >>>> >>>>>If we were to *mandate* that all SIP-enabled services are represented >>>>>using a single tuple, where would you enforce this rule? And what would >>>>>be the benefit compared to allowing more than a single tuple? >>>> >>>>I'm not sure this is something to mandate. I think it is more of a "best >>>>practices" kind of thing. It seems clear that people are going to do a >>>>bunch of weird things, and results will vary. About all we can do is >>>>give suggestions on how to get a good result. >>>> >>>> >>>> >>>>>Simply saying that it is possible in some instances to do things that >>>>>way is not a good enough reason, if there are instances where it does >>>>>not work. >>>> >>>>I think this might best be approached by restarting the work on presence >>>>use cases. >>>> >>>>Here is (a bad) one, based on what I think you have in mind. (Please >>>>feel free to provide a better way to handle this case.) >>>> >>>>Suppose your presence includes one tuple listing audio, video, and doom. >>>>My presence client doesn't understand doom or video, so it simply >>>>renders the tuple as available for voice. I pick it and make a voice >>>>call. Your Doom service slaves audio to the game, so I just hear a bunch >>>>of bleeps and gun fire. I am likely to be annoyed with you for having >>>>announced that you were available for voice when you were not. >>>> >>>>Or, your UA refused my call because I didn't offer doom control >>>>protocol. I'm still annoyed that you said you were available for voice >>>>but refused my call. (But at least this is within the realm of >>>>reasonable behaviors.) >>>> >>>> Paul >>>> >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>>> >>> >>> >>> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From Hoover@icqmail.com Wed Feb 2 11:30:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24616; Wed, 2 Feb 2005 11:30:14 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwNgn-0004Wt-W0; Wed, 02 Feb 2005 11:49:20 -0500 Received: from [210.205.180.202] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CwNOG-0008Ab-Ai; Wed, 02 Feb 2005 11:30:05 -0500 Received: from [213.0.189.152] by nutritive%DIGITS.share.210.205.180.202 via HTTP; Wed, 02 Feb 2005 11:29:23 -0800 Reply-To: "a Blair Limited" From: "a Blair Limited" To: Subject: Find them here Date: Wed, 02 Feb 2005 11:29:23 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--3826386593hqvd9278" Message-Id: X-Spam-Score: 19.4 (+++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----3826386593hqvd9278 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable 4 Wives looking for fun have been matched for you in your area: 1. Chelsea, 128 lbs, 5'6, 36c, 11 miles away, available most nights (husba= nd works midnights) 2. Jennifer, 131 lbs, 5'8, 36d, 12 miles away, available Jan 30- Feb 5rd 3. Samantha, 121 lbs, 5'5, 34b, 7 miles away, available most week nights (= looking for side-fling) 4. Nicole, 125 lbs, 5'8, 36c, 14 miles away, available Jan 31- Feb 3rd All 4 women are waiting to speak with you live & have photos. Webcam's are= available for all 4. http://godatesoon.com/d/10.php If you have found a lady or not to be paired up then continue. http://godatesoon.com/out/=20 ----3826386593hqvd9278-- From simple-bounces@ietf.org Wed Feb 2 11:41:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25892; Wed, 2 Feb 2005 11:41:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwNrm-0004st-Pu; Wed, 02 Feb 2005 12:00:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwNPn-0005Sr-TB; Wed, 02 Feb 2005 11:31:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwNHO-0002fL-0v for simple@megatron.ietf.org; Wed, 02 Feb 2005 11:22:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23608 for ; Wed, 2 Feb 2005 11:22:53 -0500 (EST) Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwNZl-0004Fd-KN for simple@ietf.org; Wed, 02 Feb 2005 11:41:58 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8984170 for simple@ietf.org; Wed, 02 Feb 2005 11:22:47 -0500 Message-Id: <6.1.2.0.0.20050202111743.062c1570@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 02 Feb 2005 11:21:54 -0500 To: Simple WG From: "Joel M. Halpern" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Simple] XCAP xmlns minor questions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Assume we use xmlns(qual="uri") for defining namespaces. Assume we set the default suitably. Assume we stick with the current XCAP path syntax. Side note: I prefer sticking with that rather than wrapping it up in an xpointer(). I am missing the value to us in the xpointer() reference. Two minor questions: 1) Is the default name space document dependent? It seems that making it document dependent would simplify references, but complicate processing significantly. 2) If the user wants to specify several name spaces, presumably several xmlns() declarations are used. Are these separated by whitespace, slashes, or some other separator? Thanks, Joel _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From HRATPP@hotmail.com Wed Feb 2 11:55:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28823; Wed, 2 Feb 2005 11:55:36 -0500 (EST) Received: from 218-162-95-246.dynamic.hinet.net ([218.162.95.246]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CwO5N-0005S0-06; Wed, 02 Feb 2005 12:14:42 -0500 Received: from by ..sitadelle.com with id 1A690K-0549Jb-00 for ; Wed, 02 Feb 2005 17:46:33 +0100 Message-ID: <11231002160959.GI32577@.tech.sitadelle.com> References: In-Reply-To: Date: Wed, 02 Feb 2005 11:46:33 -0500 From: "Malinda Mcknight" To: sg@ietf.org Subject: Look...Here Sg X-Spam-Score: 4.9 (++++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Wide range of medss available to choose in our stores. Saveee uup to 7o % Vicodiin, Viiagraa, Ciallis, Vallium, Xanaax and many moore.. http://vigra4.info/in.php?aid=56 Happy New Year HZwqg1dG0vmfj1INxPR2pAbxC4QhDAlpI6VI7n5vMRBB4RC3HzNx From simple-bounces@ietf.org Wed Feb 2 14:50:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19983; Wed, 2 Feb 2005 14:50:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwQom-0003Ij-6j; Wed, 02 Feb 2005 15:09:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQOS-00007A-RV; Wed, 02 Feb 2005 14:42:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQJr-0006jR-B3 for simple@megatron.ietf.org; Wed, 02 Feb 2005 14:37:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18540 for ; Wed, 2 Feb 2005 14:37:37 -0500 (EST) Received: from dns2.xten.net ([64.69.76.5] helo=mail.xten.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwQcF-0002pw-Al for simple@ietf.org; Wed, 02 Feb 2005 14:56:43 -0500 Received: from [24.85.92.32] by mail.xten.com (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.5.3)); Wed, 2 Feb 2005 11:41:17 -0800 From: "Nelson Hung" To: "'Joel M. Halpern'" , "'Simple WG'" Subject: RE: [Simple] XCAP xmlns minor questions Date: Wed, 2 Feb 2005 11:37:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <6.1.2.0.0.20050202111743.062c1570@localhost> Thread-Index: AcUJRpmkp8gGiMm3Q3K+wZ6MW+VWTQAFM2Pg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-ArGoMail-Authenticated: nelson@xten.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Inline > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Wednesday, February 02, 2005 8:22 AM > To: Simple WG > Subject: [Simple] XCAP xmlns minor questions > > Assume we use xmlns(qual="uri") for defining namespaces. > Assume we set the default suitably. > Assume we stick with the current XCAP path syntax. > Side note: I prefer sticking with that rather than wrapping it up in > an xpointer(). I am missing the value to us in the xpointer() reference. > > Two minor questions: > 1) Is the default name space document dependent? It seems that making it > document dependent would simplify references, but complicate processing > significantly. If the xcap path's default namespace is document dependent, XCAP client would then need to have another mechanism to found out the default namespace (not the default namespace of the XCAP document) to be used on an xcap path... I do not quite understand what you mean by "simplify references". Can you provide an example? > > 2) If the user wants to specify several name spaces, presumably several > xmlns() declarations are used. Are these separated by whitespace, slashes, > or some other separator? They are separated by zero or more white space character http://www.w3.org/TR/2003/REC-xptr-framework-20030325/#syntax [3] SchemeBased ::= PointerPart (S? PointerPart)* [4] PointerPart ::= SchemeName '(' SchemeData ')' http://www.w3.org/TR/REC-xml/#NT-S [3] S ::= (#x20 | #x9 | #xD | #xA)+ > > Thanks, > Joel .ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 2 15:06:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22387; Wed, 2 Feb 2005 15:06:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwR4W-0003uJ-5W; Wed, 02 Feb 2005 15:25:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQgg-0007ED-PZ; Wed, 02 Feb 2005 15:01:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQdC-0005hS-K0 for simple@megatron.ietf.org; Wed, 02 Feb 2005 14:57:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21168 for ; Wed, 2 Feb 2005 14:57:38 -0500 (EST) Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwQvX-0003bf-L0 for simple@ietf.org; Wed, 02 Feb 2005 15:16:45 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8987087 for simple@ietf.org; Wed, 02 Feb 2005 14:57:35 -0500 Message-Id: <6.2.0.14.0.20050202145434.03252e40@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 02 Feb 2005 14:56:25 -0500 To: "'Simple WG'" From: "Joel M. Halpern" Subject: RE: [Simple] XCAP xmlns minor questions In-Reply-To: References: <6.1.2.0.0.20050202111743.062c1570@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a I suspect the problem of knowing which namespace is the "default" makes per document defaults too painful. But the reason for raising the question is that the XML for presence, privacy policy, and conference policy is defined in different documents. if the default is global, we are going to end up requiring xmlns declarations most of the time. Which is noisy and verbose. But not fatal. Yours, Joel At 02:37 PM 2/2/2005, Nelson Hung wrote: > > Two minor questions: > > 1) Is the default name space document dependent? It seems that making it > > document dependent would simplify references, but complicate processing > > significantly. > >If the xcap path's default namespace is document dependent, XCAP client >would then need to have another mechanism to found out the default namespace >(not the default namespace of the XCAP document) to be used on an xcap >path... > >I do not quite understand what you mean by "simplify references". Can you >provide an example? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 2 23:20:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21709; Wed, 2 Feb 2005 23:20:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwYmE-0006ls-Bt; Wed, 02 Feb 2005 23:39:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwYQw-000481-NA; Wed, 02 Feb 2005 23:17:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwYPU-0003av-Th for simple@megatron.ietf.org; Wed, 02 Feb 2005 23:16:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21339 for ; Wed, 2 Feb 2005 23:15:59 -0500 (EST) Message-Id: <200502030415.XAA21339@ietf.org> Received: from winwebhosting.com ([67.15.20.8] helo=dx24.winwebhosting.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwYhx-0006dZ-8p for simple@ietf.org; Wed, 02 Feb 2005 23:35:11 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx24.winwebhosting.com with esmtpa (Exim 4.43) id 1CwYOi-0007U0-0F; Wed, 02 Feb 2005 21:15:16 -0700 From: "Brian Rosen" To: "'Paul Kyzivat'" Subject: RE: Single tuple or many tuples (was: Re: [Simple] another try atdata model compromise regarding unique service URI) Date: Wed, 2 Feb 2005 23:15:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUJPsLBOiTpDFBWRWmuffLQPpSEIAAZWPsg In-Reply-To: <4200F67A.4060007@cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx24.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-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit I think the basic model is close to Doom-3, but a bit different from what you describe it. It's not Doom-1 or 2. First of all, the audio and video in a Doom game that are the actual Doom visual and auditory outputs of the game are locally generated. The Doom control protocol is all that is needed for the basic game. I think if there is audio, it's a conference call-like open audio channel between players. As in Doom-3, it would be locally mixed with the local Doom game sounds. It could have PTT, it could have a notion of "side" (ie normally I talk to only my side, but I have a floor that lets me talk to all the players), but it's defined by the Doom game what it does and how you use it. It's not a general purpose telephone, and it's unlikely to be precisely the mobile guy's notion of PTT. That's what I would do. Someone else may define it differently. However it's defined, it's an audio service specifically specified for Doom. The audio and game control are intertwined into the Doom service. You can't infer how it works; you need to read the description of it in the Doom service. Probably, someone wrote a spec for it and published it. Probably, they registered the service name with IANA. That lets multiple implementations of the client exist and interoperate. You don't know, for example, unless you understand the Doom service, if it makes any sense to run the Doom game stream without the audio or vice versa. > I don't get this. The floor control is the essence of PTT. Otherwise it > is just audio. As Jonathan has pointed out, this may be a case where the > implementation won't allow you to negotiate a session without the floor > control. If so we need some way to indicate that. But that is the only > special thing. Nope, floor control is not the "essence" of PTT, it's just one of its common characteristics. You can have floor control without PTT. You actually can have PTT without floor control; a real radio system is PTT without floor control -- you push the button and talk -- if two people do it at the same time, third parties hear one or both, and the two speakers don't hear each other. Some PTTs assume half duplex, others don't. You can define a PTT service that is half duplex, and another that is half or full duplex. There isn't going to be ONE PTT service, their probably will be more than one. Brian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 3 01:29:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03717; Thu, 3 Feb 2005 01:29:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwanZ-0002LJ-I2; Thu, 03 Feb 2005 01:49:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwaN6-0007zO-W0; Thu, 03 Feb 2005 01:21:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwaHe-0006Gx-8r for simple@megatron.ietf.org; Thu, 03 Feb 2005 01:16:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02341 for ; Thu, 3 Feb 2005 01:16:05 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwaa9-0001pf-0m for simple@ietf.org; Thu, 03 Feb 2005 01:35:14 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 02 Feb 2005 22:23:01 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j136FQHo029807; Wed, 2 Feb 2005 22:15:27 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-136.cisco.com [10.86.242.136]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHM24667; Wed, 2 Feb 2005 22:15:29 -0800 (PST) Message-ID: <4201C181.5080108@cisco.com> Date: Thu, 03 Feb 2005 01:15:29 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: [Simple] XCAP xmlns minor questions References: <6.1.2.0.0.20050202111743.062c1570@localhost> <6.2.0.14.0.20050202145434.03252e40@localhost> In-Reply-To: <6.2.0.14.0.20050202145434.03252e40@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit I think the default would be per app usage. So, in the case of presence authorization, that would presumably be urn:ietf:params:xml:ns:common-policy. Odds are good that many queries would also require urn:ietf:params:xml:ns:pres-rules to be defined in the URI. In the case of the resource list application usage, it would presumably be urn:ietf:params:xml:ns:resource-lists. For the RLS services, it would be urn:ietf:params:xml:ns:rls-services, and most queries would also require urn:ietf:params:xml:ns:resource-lists to be defined in the URI. -Jonathan R. Joel M. Halpern wrote: > I suspect the problem of knowing which namespace is the "default" makes > per document defaults too painful. > But the reason for raising the question is that the XML for presence, > privacy policy, and conference policy is defined in different > documents. if the default is global, we are going to end up requiring > xmlns declarations most of the time. Which is noisy and verbose. But > not fatal. > > Yours, > Joel > > At 02:37 PM 2/2/2005, Nelson Hung wrote: > >> > Two minor questions: >> > 1) Is the default name space document dependent? It seems that >> making it >> > document dependent would simplify references, but complicate processing >> > significantly. >> >> If the xcap path's default namespace is document dependent, XCAP client >> would then need to have another mechanism to found out the default >> namespace >> (not the default namespace of the XCAP document) to be used on an xcap >> path... >> >> I do not quite understand what you mean by "simplify references". Can you >> provide an example? > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 3 01:40:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04875; Thu, 3 Feb 2005 01:40:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwayE-0002fi-Us; Thu, 03 Feb 2005 02:00:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwabo-0003hq-3t; Thu, 03 Feb 2005 01:36:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwaYB-0002iM-Nq for simple@megatron.ietf.org; Thu, 03 Feb 2005 01:33:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04136 for ; Thu, 3 Feb 2005 01:33:10 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwaqh-0002Rc-Mp for simple@ietf.org; Thu, 03 Feb 2005 01:52:20 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 02 Feb 2005 22:40:07 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j136WaHo005020; Wed, 2 Feb 2005 22:32:38 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-136.cisco.com [10.86.242.136]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHM25217; Wed, 2 Feb 2005 22:32:35 -0800 (PST) Message-ID: <4201C583.7050600@cisco.com> Date: Thu, 03 Feb 2005 01:32:35 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari urpalainen Subject: Re: [Simple] Namespaces and XCAP References: <41FE9B4C.1070106@cisco.com> <1107242622.26454.54.camel@xitami.research.nokia.com> <41FF3331.8010008@cisco.com> <1107338919.27837.34.camel@xitami.research.nokia.com> In-Reply-To: <1107338919.27837.34.camel@xitami.research.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: 7bit inline. jari urpalainen wrote: > On Tue, 2005-02-01 at 02:43 -0500, ext Jonathan Rosenberg wrote: > >>inline. >> >>jari urpalainen wrote: >> >> >>>>So, which to use? Considering the issues involved, I think the best >>>>option is 5(A). >>>> >>>>Comments? >>>> >>>>Thanks, >>>>Jonathan R. >>>> >>>> >>> >>> >>>In principle I am in favor of 5A. However, I have a difficulty >>>understanding why we should use a different syntax than what xpointer >>>spec has ? >> >>Why is it different? I was proposing to use the xmlns xpointer >>expression exactly as defined. >> >> >>>http://www.w3.org/TR/WD-xptr >>> >>>xmlns(x=http://example.com/foo) xpointer(//x:a) >> >>Oh, so you are saying ditch the whole xpath thing in favor of xpointers >>for element naming? >> > > yes definitely. Well, I am reluctant for such a significant change at this point. I don't see what is gained. How is: xpointer(/doc-root/el1/el2) better than: /doc-root/el1/el2 except that the former is harder to map into a URI and thus harder to use with xcap? > > >>My read of xpointer was that it was primarily aimed at solving a broader >>problem even than path, namely being able to identify points and text >>ranges within an xml document. We don't need or want that. I also don't >>know how to map this easily into URI's, whereas xpath is easily mapped. >>Since the ONLY thing xpointer() would give us is syntax, what is gained?? >> > > yes it does extend basic xpath with these ranges and points and of > course I don't want to propose to use them just this xcap scoped > restricted xpath. I just don't want yet another buggy uri selector as > w3c has already found a proper model for selectors with xpointers. Xpointers uses xpath directly but extends it in ways we don't need, and adds syntax that is cumbersome for us. So, if we stick with the current xpath-based model, what kind of "bugginess" does this introduce? Are you saying that our current model is buggy? > > >>>Furthermore, there seems to be a tendency to use fragment identifiers, >>>so I would propose to use them. >> >>URL fragment identifiers? AS in #fragment-id? As an alternative to the >>~~ approach in the URI? >> > > yes. this seems to be w3c preference (xlink, xinclude etc.) and I think > we should really follow that. I don't understand the proposal. If you want to make a major change in direction here you need to provide a concrete proposal. >>If the element had redefined the default namespace to something else, >>the URI would no longer select the element just inserted, and the >>operation wouldn't meet the GET(PUT(X))==X property and be rejected. >> > > my aim was to raise a question whether to allow a more xml-ish way of > allowing e.g. the server to decide when to drop duplicate namespace > definitions or change e.g. default namespace usage to a prefixed version > etc. Granted, I don't have a clear view on this, but I am just afraid > that we may miss some useful usecase given this tight schedule. I don't know how to react to this; we can't change or improve our approach unless there is a specific problem you are seeing. > >>>Character encodings should also be addressed somehow as we are heading >>>towards better "blind" updates, i.e. if the document uses e.g. UTF-8 >>>encoding and the client uses charset=iso-xxx, what would be the result >>>of an append operation ? >> >>Good question. This came up as a comment from others during last call. I >>have already added text to my working copy which says that this would be >>rejected. An error code has been defined for this too. Indeed, the >>current text mandates UTF-8 so anything but that in the charset is rejected. >> > > Sorry I may have missed that thread, but I'll hope this means that the > server has to support UTF-8 but may support UTF-16, ISOxxx, right ? My current working copy explicitly mandates UTF-8, and nothing else. This is based primarily on the view that nearly all xml protocols we've been producing in the sip/simple community at least are utf-8. Do you feel we need to support other charsets? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 3 05:27:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07427; Thu, 3 Feb 2005 05:27:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CweVg-0000dq-F2; Thu, 03 Feb 2005 05:46:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwe8m-0001pD-NL; Thu, 03 Feb 2005 05:23:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwe3z-0000Xx-9F for simple@megatron.ietf.org; Thu, 03 Feb 2005 05:18:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06755 for ; Thu, 3 Feb 2005 05:18:12 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CweMW-0000NX-Vn for simple@ietf.org; Thu, 03 Feb 2005 05:37:25 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j13AHAc09634; Thu, 3 Feb 2005 12:17:10 +0200 (EET) X-Scanned: Thu, 3 Feb 2005 12:16:52 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j13AGqJc003013; Thu, 3 Feb 2005 12:16:52 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00fLo52A; Thu, 03 Feb 2005 12:16:51 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j13AGpx04445; Thu, 3 Feb 2005 12:16:51 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Feb 2005 12:12:38 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Feb 2005 12:12:38 +0200 Received: from 172.21.50.105 ([172.21.50.105]) by esebe105.NOE.Nokia.com ([172.21.143.53]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Feb 2005 10:12:37 +0000 Received: from xitami.research.nokia.com by esebe105.ntc.nokia.com; 03 Feb 2005 12:12:37 +0200 Subject: Re: [Simple] Namespaces and XCAP From: jari urpalainen To: ext Jonathan Rosenberg In-Reply-To: <4201C583.7050600@cisco.com> References: <41FE9B4C.1070106@cisco.com> <1107242622.26454.54.camel@xitami.research.nokia.com> <41FF3331.8010008@cisco.com> <1107338919.27837.34.camel@xitami.research.nokia.com> <4201C583.7050600@cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 03 Feb 2005 11:11:21 +0200 Message-Id: <1107421882.30334.62.camel@xitami.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-OriginalArrivalTime: 03 Feb 2005 10:12:38.0564 (UTC) FILETIME=[E393FE40:01C509D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: 7bit On Thu, 2005-02-03 at 01:32 -0500, ext Jonathan Rosenberg wrote: > inline. > > jari urpalainen wrote: > > > On Tue, 2005-02-01 at 02:43 -0500, ext Jonathan Rosenberg wrote: > > > >>inline. > >> > >>jari urpalainen wrote: > >> > >> > >>>>So, which to use? Considering the issues involved, I think the best > >>>>option is 5(A). > >>>> > >>>>Comments? > >>>> > >>>>Thanks, > >>>>Jonathan R. > >>>> > >>>> > >>> > >>> > >>>In principle I am in favor of 5A. However, I have a difficulty > >>>understanding why we should use a different syntax than what xpointer > >>>spec has ? > >> > >>Why is it different? I was proposing to use the xmlns xpointer > >>expression exactly as defined. > >> > >> > >>>http://www.w3.org/TR/WD-xptr > >>> > >>>xmlns(x=http://example.com/foo) xpointer(//x:a) > >> > >>Oh, so you are saying ditch the whole xpath thing in favor of xpointers > >>for element naming? > >> > > > > yes definitely. > > Well, I am reluctant for such a significant change at this point. I > don't see what is gained. How is: > > xpointer(/doc-root/el1/el2) > > better than: > > /doc-root/el1/el2 > > except that the former is harder to map into a URI and thus harder to > use with xcap? > I don't know the reasons why w3c chose the model they have with the current set, i.e. this bare-name and schemes: element(), xmlns() and xpointer() stuff. However, it happens to solve the namespace problem properly with a standard way. I really dislike to introduce a model that is almost valid xpointer. So we had almost valid xpath 1.0 and now almost valid xpointer. One complain about the current approach was that you can't use a standard xpath library. If you'll use your proposal you can't either use a standard xpointer library. And still with a standard xpath library you'll have to do some tweaking. I'll agree this is a significant change and at least I don't know of all the implications that may arise, sorry. > > > > > >>My read of xpointer was that it was primarily aimed at solving a broader > >>problem even than path, namely being able to identify points and text > >>ranges within an xml document. We don't need or want that. I also don't > >>know how to map this easily into URI's, whereas xpath is easily mapped. > >>Since the ONLY thing xpointer() would give us is syntax, what is gained?? > >> > > > > yes it does extend basic xpath with these ranges and points and of > > course I don't want to propose to use them just this xcap scoped > > restricted xpath. I just don't want yet another buggy uri selector as > > w3c has already found a proper model for selectors with xpointers. > > Xpointers uses xpath directly but extends it in ways we don't need, and > adds syntax that is cumbersome for us. So, if we stick with the current > xpath-based model, what kind of "bugginess" does this introduce? Are you > saying that our current model is buggy? > > > > > > >>>Furthermore, there seems to be a tendency to use fragment identifiers, > >>>so I would propose to use them. > >> > >>URL fragment identifiers? AS in #fragment-id? As an alternative to the > >>~~ approach in the URI? > >> > > > > yes. this seems to be w3c preference (xlink, xinclude etc.) and I think > > we should really follow that. > > I don't understand the proposal. If you want to make a major change in > direction here you need to provide a concrete proposal. > Some reference from "The XML Bible, 2nd Edition" http://www.cafeconleche.org/books/bible2/chapters/ch20.html Just quoting examples from the above reference: http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(id("ebnf")) http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(descendant::language[position()=2]) http://www.w3.org/TR/1998/REC-xml-19980210.xml#ebnf http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(/child::spec/child::body/child::*/child::language[2]) http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(/spec/body/*/language[2]) http://www.w3.org/TR/1998/REC-xml-19980210.xml#/1/14/2 http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(id("ebnf"))xpointer(id("EBNF")) I don't understand what is so hard in this mapping ? Sure, we just need a small subset of this, but already xcap bnf is a subset of xpath, what's the problem doing that with xpointer, just take what is needed but use a compatible reference. If w3c didn't have anything like this, I wouldn't object doing one of our own, but I see no point in reinventing the wheel. > >>If the element had redefined the default namespace to something else, > >>the URI would no longer select the element just inserted, and the > >>operation wouldn't meet the GET(PUT(X))==X property and be rejected. > >> > > > > my aim was to raise a question whether to allow a more xml-ish way of > > allowing e.g. the server to decide when to drop duplicate namespace > > definitions or change e.g. default namespace usage to a prefixed version > > etc. Granted, I don't have a clear view on this, but I am just afraid > > that we may miss some useful usecase given this tight schedule. > > I don't know how to react to this; we can't change or improve our > approach unless there is a specific problem you are seeing. > Agreed. Once we are on this "blind" update track I am e.g. uncertain how to deal with the namespace definitions in the body, just like in the example that I gave. We can certainly stay with the document context here, because I don't want to delay this work because of this. > > > >>>Character encodings should also be addressed somehow as we are heading > >>>towards better "blind" updates, i.e. if the document uses e.g. UTF-8 > >>>encoding and the client uses charset=iso-xxx, what would be the result > >>>of an append operation ? > >> > >>Good question. This came up as a comment from others during last call. I > >>have already added text to my working copy which says that this would be > >>rejected. An error code has been defined for this too. Indeed, the > >>current text mandates UTF-8 so anything but that in the charset is rejected. > >> > > > > Sorry I may have missed that thread, but I'll hope this means that the > > server has to support UTF-8 but may support UTF-16, ISOxxx, right ? > > My current working copy explicitly mandates UTF-8, and nothing else. > This is based primarily on the view that nearly all xml protocols we've > been producing in the sip/simple community at least are utf-8. > > Do you feel we need to support other charsets? > Personally I don't need e.g. UTF-16 but in some languages it results in shorter documents. However, I doubt that we'll have to mandate that. > -Jonathan R. > br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 3 08:45:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22025; Thu, 3 Feb 2005 08:45:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwhb4-0006Iy-30; Thu, 03 Feb 2005 09:04:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwhGN-0007ic-1o; Thu, 03 Feb 2005 08:43:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwhBV-0006Oa-C3 for simple@megatron.ietf.org; Thu, 03 Feb 2005 08:38:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21545 for ; Thu, 3 Feb 2005 08:38:12 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwhU4-000644-Ud for simple@ietf.org; Thu, 03 Feb 2005 08:57:25 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 03 Feb 2005 06:48:14 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j13DbbHo013395; Thu, 3 Feb 2005 05:37:37 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-136.cisco.com [10.86.242.136]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHM36881; Thu, 3 Feb 2005 05:37:38 -0800 (PST) Message-ID: <42022922.5090501@cisco.com> Date: Thu, 03 Feb 2005 08:37:38 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari urpalainen Subject: Re: [Simple] Namespaces and XCAP References: <41FE9B4C.1070106@cisco.com> <1107242622.26454.54.camel@xitami.research.nokia.com> <41FF3331.8010008@cisco.com> <1107338919.27837.34.camel@xitami.research.nokia.com> <4201C583.7050600@cisco.com> <1107421882.30334.62.camel@xitami.research.nokia.com> In-Reply-To: <1107421882.30334.62.camel@xitami.research.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Content-Transfer-Encoding: 7bit inline. jari urpalainen wrote: > On Thu, 2005-02-03 at 01:32 -0500, ext Jonathan Rosenberg wrote: > >>inline. >> >>jari urpalainen wrote: >> >> >>>On Tue, 2005-02-01 at 02:43 -0500, ext Jonathan Rosenberg wrote: >>> >>> >>>>inline. >>>> >>>>jari urpalainen wrote: >>>> >>>> >>>> >>>>>>So, which to use? Considering the issues involved, I think the best >>>>>>option is 5(A). >>>>>> >>>>>>Comments? >>>>>> >>>>>>Thanks, >>>>>>Jonathan R. >>>>>> >>>>>> >>>>> >>>>> >>>>>In principle I am in favor of 5A. However, I have a difficulty >>>>>understanding why we should use a different syntax than what xpointer >>>>>spec has ? >>>> >>>>Why is it different? I was proposing to use the xmlns xpointer >>>>expression exactly as defined. >>>> >>>> >>>> >>>>>http://www.w3.org/TR/WD-xptr >>>>> >>>>>xmlns(x=http://example.com/foo) xpointer(//x:a) >>>> >>>>Oh, so you are saying ditch the whole xpath thing in favor of xpointers >>>>for element naming? >>>> >>> >>>yes definitely. >> >>Well, I am reluctant for such a significant change at this point. I >>don't see what is gained. How is: >> >>xpointer(/doc-root/el1/el2) >> >>better than: >> >>/doc-root/el1/el2 >> >>except that the former is harder to map into a URI and thus harder to >>use with xcap? >> > > I don't know the reasons why w3c chose the model they have with the > current set, i.e. this bare-name and schemes: element(), xmlns() and > xpointer() stuff. However, it happens to solve the namespace problem > properly with a standard way. I really dislike to introduce a model that > is almost valid xpointer. So we had almost valid xpath 1.0 and now > almost valid xpointer. With the model I am proposing the URI can be trivially transformed into a valid xpointer expression by wrapping the node selector inside xpointer(). Once you do that, in what wa you "standard" xpointer implementations not be usable? > > One complain about the current approach was that you can't use a > standard xpath library. we are fixing that with the namespace proposal. > If you'll use your proposal you can't either use > a standard xpointer library. per above, why not? > And still with a standard xpath library > you'll have to do some tweaking. can you elaborate?? >>>yes. this seems to be w3c preference (xlink, xinclude etc.) and I think >>>we should really follow that. >> >>I don't understand the proposal. If you want to make a major change in >>direction here you need to provide a concrete proposal. >> > > > Some reference from "The XML Bible, 2nd Edition" > > http://www.cafeconleche.org/books/bible2/chapters/ch20.html > > Just quoting examples from the above reference: > > http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(id("ebnf")) > http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(descendant::language[position()=2]) > http://www.w3.org/TR/1998/REC-xml-19980210.xml#ebnf > http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(/child::spec/child::body/child::*/child::language[2]) > http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(/spec/body/*/language[2]) > http://www.w3.org/TR/1998/REC-xml-19980210.xml#/1/14/2 > http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(id("ebnf"))xpointer(id("EBNF")) THis won't work for us at all. As you know fragments are evaluated on the CLIENT side. That is why we discarded the usage of fragments to begin with. > > I don't understand what is so hard in this mapping ? Sure, we just need > a small subset of this, but already xcap bnf is a subset of xpath, > what's the problem doing that with xpointer, just take what is needed > but use a compatible reference. It doesn't work because the fragments are evaluated on the client side. In the URI above, the fragments would not even be passed to a server. We need them to be passed to the server. We could use a query string, but that brings up the whole specter of issues we had in another thread about how we then break the architectural model on which xcap is built. > > If w3c didn't have anything like this, I wouldn't object doing one of > our own, but I see no point in reinventing the wheel. Hopefully I have explained that we cannot use the approach above. > > >>>>If the element had redefined the default namespace to something else, >>>>the URI would no longer select the element just inserted, and the >>>>operation wouldn't meet the GET(PUT(X))==X property and be rejected. >>>> >>> >>>my aim was to raise a question whether to allow a more xml-ish way of >>>allowing e.g. the server to decide when to drop duplicate namespace >>>definitions or change e.g. default namespace usage to a prefixed version >>>etc. Granted, I don't have a clear view on this, but I am just afraid >>>that we may miss some useful usecase given this tight schedule. >> >>I don't know how to react to this; we can't change or improve our >>approach unless there is a specific problem you are seeing. >> > > Agreed. Once we are on this "blind" update track I am e.g. uncertain how > to deal with the namespace definitions in the body, Again - I don't understand the problem you are pointing too. Can you give an example where there is uncertainty. just like in the > example that I gave. I didn't see the problem in the example you gave. Behavior seemed well defined. >>My current working copy explicitly mandates UTF-8, and nothing else. >>This is based primarily on the view that nearly all xml protocols we've >>been producing in the sip/simple community at least are utf-8. >> >>Do you feel we need to support other charsets? >> > > Personally I don't need e.g. UTF-16 but in some languages it results in > shorter documents. However, I doubt that we'll have to mandate that. Since we are primarily dealing with documents defined to be interpreted by automata, and furhter documents oftentimes standardized here in ietf, free-form text is not likely to be a common part of the definition. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 3 10:02:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29424; Thu, 3 Feb 2005 10:02:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwinp-0000KY-Is; Thu, 03 Feb 2005 10:21:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwiNg-00004v-Md; Thu, 03 Feb 2005 09:54:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwiGC-0006lv-Oq for simple@megatron.ietf.org; Thu, 03 Feb 2005 09:47:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27947 for ; Thu, 3 Feb 2005 09:47:07 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwiYm-0008Fa-E1 for simple@ietf.org; Thu, 03 Feb 2005 10:06:21 -0500 Received: from razor.cs.columbia.edu (IDENT:U2FsdGVkX1+rqDW1+JPcq3WvVC/xEx3MIfXEcHw2xws@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j13El3ir022280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Feb 2005 09:47:03 -0500 (EST) Received: from [127.0.0.1] (IDENT:U2FsdGVkX1+OT09iWYQbNpiKXlpwI14CTN+JAXc3UTc@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j13Ekvmb011616; Thu, 3 Feb 2005 09:46:59 -0500 Message-ID: <42023963.8030303@cs.columbia.edu> Date: Thu, 03 Feb 2005 09:46:59 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Re: Single tuple or many tuples References: <41F33C72.2070306@cisco.com> <41F778F5.8040004@nokia.com> <41FA2D02.3020008@cisco.com> <41FE4707.8030602@nokia.com> <41FE4F2C.8000806@cisco.com> <41FE5B74.3020105@nokia.com> <41FE6C99.6060708@cisco.com> <41FF87A5.3060301@nokia.com> <41FF98DC.8060605@cisco.com> <42007DD0.4050802@cisco.com> In-Reply-To: <42007DD0.4050802@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , Aki Niemi , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit The complexity, compared to the incremental value, seems rather scary. From a watcher perspective, I fail to see the substantial difference between this complicated version and simply saying "I'm open for IM" (I might sometimes also do audio, but I'm not right now, so this is irrelevant), expressed as prescaps What advantage does it have to "tease" the observer that I might have some other capability at some other time, left undefined, but I won't let you have it? (If I know that I will have this capability at some future point, timed status would be the appropriate mechanism to express this.) I'm rather concerned about conveying and having users understand fine philosophical differences between degrees of unavailability. Jonathan Rosenberg wrote: > inline. > > Paul Kyzivat wrote: > >> Here is (a bad) one, based on what I think you have in mind. (Please >> feel free to provide a better way to handle this case.) >> >> Suppose your presence includes one tuple listing audio, video, and >> doom. My presence client doesn't understand doom or video, so it >> simply renders the tuple as available for voice. I pick it and make a >> voice call. Your Doom service slaves audio to the game, so I just hear >> a bunch of bleeps and gun fire. I am likely to be annoyed with you for >> having announced that you were available for voice when you were not. >> >> Or, your UA refused my call because I didn't offer doom control >> protocol. I'm still annoyed that you said you were available for voice >> but refused my call. (But at least this is within the realm of >> reasonable behaviors.) > > > We've touched on this kind of case before. Its another example of a case > where there is a mandatory feature or media stream that needs to be used > by the watcher in order to connect. If you want this, I think it is far > preferable to explicitly state that. That makes it more than just a > capability, so its not just a prescaps issue. > > We ran into this previously for PTT, where folks wanted a way to say > that you HAD to use this floor control protocol. I recall advocating > that a non-SIP URI might even be the best way to handle these things > since they are arguably not really SIP proper. > > However, I think Aki's case is different still. The example he has been > giving is "I'm available for IM, not for audio". This is not saying that > a watcher has to use both IM and audio, and thus seems different from > the doom case. > > I think what it means is that the actual status of communications is no > longer readily expressed as OPEN/CLOSED. Rather, it is effectively a > boolean function over a set of session characteristics. In other words, > whether I am available depends on the details of the session. Here, I'm > available if we have IM only, but not if we have audio. > > One can imagine complex boolean functions which are not readily > decomposed in a way that makes them amenable to representation using a > number of separate tuples each just with a simple OPEN/CLOSED. > > For example, what if I want to say that I'm available if you have audio > AND video, but not if you use audio alone or video alone. Admittedly > this is a stretch, but this seems harder to do using separate tuples. > Worse case with N variables you could require 2^^N tuples. Yuck. > > I would suggest that another approach would be to define an alternative > status indication that actually contains the boolean function: > > (AND (EQUAL audio TRUE) (EQUAL video true)) > > where I am using rfc2533-style syntax for boolean expressions. > > As Paul suggested, I think the status here would still be OPEN, > but this more complicated status would provide more complex information > about availability. > > To be clear - I don't think any of this impacts the compromise position > we have reached around the data model; rather this discussion is follow > on to help us sort out what multiple tuples might mean in different cases. > > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 3 10:04:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29534; Thu, 3 Feb 2005 10:04:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwipF-0000Ms-Q3; Thu, 03 Feb 2005 10:23:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwiOF-0000Ik-Pc; Thu, 03 Feb 2005 09:55:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwiIU-0006zj-WC for simple@megatron.ietf.org; Thu, 03 Feb 2005 09:49:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28106 for ; Thu, 3 Feb 2005 09:49:28 -0500 (EST) Received: from av11-1-sn2.hy.skanova.net ([81.228.8.183]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwib4-0008JX-Id for simple@ietf.org; Thu, 03 Feb 2005 10:08:43 -0500 Received: by av11-1-sn2.hy.skanova.net (Postfix, from userid 502) id B4F0F383DD; Thu, 3 Feb 2005 15:48:56 +0100 (CET) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av11-1-sn2.hy.skanova.net (Postfix) with ESMTP id A4D6D380E4; Thu, 3 Feb 2005 15:48:56 +0100 (CET) Received: from [192.168.1.102] (h217n2fls31o898.telia.com [217.209.140.217]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 644B337E92; Thu, 3 Feb 2005 15:48:55 +0100 (CET) In-Reply-To: <1107421882.30334.62.camel@xitami.research.nokia.com> References: <41FE9B4C.1070106@cisco.com> <1107242622.26454.54.camel@xitami.research.nokia.com> <41FF3331.8010008@cisco.com> <1107338919.27837.34.camel@xitami.research.nokia.com> <4201C583.7050600@cisco.com> <1107421882.30334.62.camel@xitami.research.nokia.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Namespaces and XCAP Date: Thu, 3 Feb 2005 15:48:54 +0100 To: jari urpalainen X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Content-Transfer-Encoding: 7bit (As WG chair) As you know, this draft has gone through WG last call and IETF last call. Unless you have identified show stoppers or bugs in the specification, please accept the consensus that was reached in the WG. It is too late to argue personal taste. Regards, Hisham On Feb 3, 2005, at 10:11 AM, jari urpalainen wrote: > On Thu, 2005-02-03 at 01:32 -0500, ext Jonathan Rosenberg wrote: >> inline. >> >> jari urpalainen wrote: >> >>> On Tue, 2005-02-01 at 02:43 -0500, ext Jonathan Rosenberg wrote: >>> >>>> inline. >>>> >>>> jari urpalainen wrote: >>>> >>>> >>>>>> So, which to use? Considering the issues involved, I think the >>>>>> best >>>>>> option is 5(A). >>>>>> >>>>>> Comments? >>>>>> >>>>>> Thanks, >>>>>> Jonathan R. >>>>>> >>>>>> >>>>> >>>>> >>>>> In principle I am in favor of 5A. However, I have a difficulty >>>>> understanding why we should use a different syntax than what >>>>> xpointer >>>>> spec has ? >>>> >>>> Why is it different? I was proposing to use the xmlns xpointer >>>> expression exactly as defined. >>>> >>>> >>>>> http://www.w3.org/TR/WD-xptr >>>>> >>>>> xmlns(x=http://example.com/foo) xpointer(//x:a) >>>> >>>> Oh, so you are saying ditch the whole xpath thing in favor of >>>> xpointers >>>> for element naming? >>>> >>> >>> yes definitely. >> >> Well, I am reluctant for such a significant change at this point. I >> don't see what is gained. How is: >> >> xpointer(/doc-root/el1/el2) >> >> better than: >> >> /doc-root/el1/el2 >> >> except that the former is harder to map into a URI and thus harder to >> use with xcap? >> > I don't know the reasons why w3c chose the model they have with the > current set, i.e. this bare-name and schemes: element(), xmlns() and > xpointer() stuff. However, it happens to solve the namespace problem > properly with a standard way. I really dislike to introduce a model > that > is almost valid xpointer. So we had almost valid xpath 1.0 and now > almost valid xpointer. > > One complain about the current approach was that you can't use a > standard xpath library. If you'll use your proposal you can't either > use > a standard xpointer library. And still with a standard xpath library > you'll have to do some tweaking. > > I'll agree this is a significant change and at least I don't know of > all > the implications that may arise, sorry. > >>> >>> >>>> My read of xpointer was that it was primarily aimed at solving a >>>> broader >>>> problem even than path, namely being able to identify points and >>>> text >>>> ranges within an xml document. We don't need or want that. I also >>>> don't >>>> know how to map this easily into URI's, whereas xpath is easily >>>> mapped. >>>> Since the ONLY thing xpointer() would give us is syntax, what is >>>> gained?? >>>> >>> >>> yes it does extend basic xpath with these ranges and points and of >>> course I don't want to propose to use them just this xcap scoped >>> restricted xpath. I just don't want yet another buggy uri selector as >>> w3c has already found a proper model for selectors with xpointers. >> >> Xpointers uses xpath directly but extends it in ways we don't need, >> and >> adds syntax that is cumbersome for us. So, if we stick with the >> current >> xpath-based model, what kind of "bugginess" does this introduce? Are >> you >> saying that our current model is buggy? >> >>> >>> >>>>> Furthermore, there seems to be a tendency to use fragment >>>>> identifiers, >>>>> so I would propose to use them. >>>> >>>> URL fragment identifiers? AS in #fragment-id? As an alternative to >>>> the >>>> ~~ approach in the URI? >>>> >>> >>> yes. this seems to be w3c preference (xlink, xinclude etc.) and I >>> think >>> we should really follow that. >> >> I don't understand the proposal. If you want to make a major change in >> direction here you need to provide a concrete proposal. >> > > Some reference from "The XML Bible, 2nd Edition" > > http://www.cafeconleche.org/books/bible2/chapters/ch20.html > > Just quoting examples from the above reference: > > http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(id("ebnf")) > http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(descendant:: > language[position()=2]) > http://www.w3.org/TR/1998/REC-xml-19980210.xml#ebnf > http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(/child::spec/ > child::body/child::*/child::language[2]) > http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(/spec/body/*/ > language[2]) > http://www.w3.org/TR/1998/REC-xml-19980210.xml#/1/14/2 > http://www.w3.org/TR/1998/REC-xml > -19980210.xml#xpointer(id("ebnf"))xpointer(id("EBNF")) > > I don't understand what is so hard in this mapping ? Sure, we just need > a small subset of this, but already xcap bnf is a subset of xpath, > what's the problem doing that with xpointer, just take what is needed > but use a compatible reference. > > If w3c didn't have anything like this, I wouldn't object doing one of > our own, but I see no point in reinventing the wheel. > >>>> If the element had redefined the default namespace to something >>>> else, >>>> the URI would no longer select the element just inserted, and the >>>> operation wouldn't meet the GET(PUT(X))==X property and be rejected. >>>> >>> >>> my aim was to raise a question whether to allow a more xml-ish way of >>> allowing e.g. the server to decide when to drop duplicate namespace >>> definitions or change e.g. default namespace usage to a prefixed >>> version >>> etc. Granted, I don't have a clear view on this, but I am just afraid >>> that we may miss some useful usecase given this tight schedule. >> >> I don't know how to react to this; we can't change or improve our >> approach unless there is a specific problem you are seeing. >> > Agreed. Once we are on this "blind" update track I am e.g. uncertain > how > to deal with the namespace definitions in the body, just like in the > example that I gave. We can certainly stay with the document context > here, because I don't want to delay this work because of this. >>> >>>>> Character encodings should also be addressed somehow as we are >>>>> heading >>>>> towards better "blind" updates, i.e. if the document uses e.g. >>>>> UTF-8 >>>>> encoding and the client uses charset=iso-xxx, what would be the >>>>> result >>>>> of an append operation ? >>>> >>>> Good question. This came up as a comment from others during last >>>> call. I >>>> have already added text to my working copy which says that this >>>> would be >>>> rejected. An error code has been defined for this too. Indeed, the >>>> current text mandates UTF-8 so anything but that in the charset is >>>> rejected. >>>> >>> >>> Sorry I may have missed that thread, but I'll hope this means that >>> the >>> server has to support UTF-8 but may support UTF-16, ISOxxx, right ? >> >> My current working copy explicitly mandates UTF-8, and nothing else. >> This is based primarily on the view that nearly all xml protocols >> we've >> been producing in the sip/simple community at least are utf-8. >> >> Do you feel we need to support other charsets? >> > Personally I don't need e.g. UTF-16 but in some languages it results in > shorter documents. However, I doubt that we'll have to mandate that. > >> -Jonathan R. >> > br, > Jari > > > _______________________________________________ > 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 Feb 3 10:04:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29611; Thu, 3 Feb 2005 10:04:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwipo-0000Nw-Ax; Thu, 03 Feb 2005 10:23:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwiOH-0000Jp-VE; Thu, 03 Feb 2005 09:55:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwiLL-0007i9-6S for simple@megatron.ietf.org; Thu, 03 Feb 2005 09:52:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28435 for ; Thu, 3 Feb 2005 09:52:24 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwidt-0008Qv-Rh for simple@ietf.org; Thu, 03 Feb 2005 10:11:38 -0500 Received: from razor.cs.columbia.edu (IDENT:U2FsdGVkX1/2wotY5f3xczWsCu9aW4ezWsOUgtSLOPk@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j13EqIir023346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Feb 2005 09:52:19 -0500 (EST) Received: from [127.0.0.1] (IDENT:U2FsdGVkX18A+fk9bxn7nqU3NMMeXwNWDSPWrSAfSYQ@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j13EqDjP011664; Thu, 3 Feb 2005 09:52:15 -0500 Message-ID: <42023AA0.4050008@cs.columbia.edu> Date: Thu, 03 Feb 2005 09:52:16 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: FW: Single tuple or many tuples (was: Re: [Simple] another try atdata model compromise regarding unique service URI) References: <200502021350.IAA03673@ietf.org> In-Reply-To: <200502021350.IAA03673@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 14278aea5bdd1edf35ec09ffb7b61f9d Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00134749b78ab2213964fc53d03de937 Content-Transfer-Encoding: 7bit I agree that we need a separate dimension for identifying the content of media streams or services. This seems orthogonal to capabilities. In some cases, there might be a way to enumerate the service in some pick-from-list manner, in a MIME-type fashion, in many others this is likely to be pretty useless. Picture the availability for delta.com (the airline), which might include services for flight information, international and domestic reservations and probably many more. Brian Rosen wrote: > I don't think we have a prayer of making a Doom game with audio and video > streams as well as the game stream work in presence without having a notion > of service that has some kind of name which is used to describe the service. > That service description can be text as long as it is unique enough that the > watcher (client) can render some good enough UI and the watcher (human) > understands what to do with it. > > So if someone defines "Doom" as being a service that has a game stream and > optional audio and video streams, then you can build a watcher that > understands what Doom is and render a very nice interface with, say, a Doom > icon, and a basic watcher can show the name of the service and the media > streams on it that a human can interpret it. I think we all agree that, at > the very least, the presence of the Doom service is contained in one tuple. > The only thing you really would like to understand about service is name and > the fact that it can contain multiple streams and multiple capabilities. > > I don't think you can infer this notion of service from the aggregate of > capabilities, and I don't want to try. You can DEFINE a service as having > some fixed and optional capabilities with the watcher being able to discover > which of them a particular presentity has available at a point in time. > That we can do. So don't guess that audio and/or video with half duplex and > floor control MEANS PTT, instead DEFINE PTT as a service that has audio, > optional video, half duplex and floor control and let a tuple state that the > presentity supports a PTT service and at the present time only has audio > (not video) available. > > Then I can offer a Telephone service and Doom service, both of which support > audio, and we won't get anyone confused. > > Brian > > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Tuesday, February 01, 2005 1:51 PM >>To: Brian Rosen >>Cc: 'Aki Niemi'; 'Simple WG' >>Subject: Re: Single tuple or many tuples (was: Re: [Simple] another try >>atdata model compromise regarding unique service URI) >> >>Brian - inline. >> >> Paul >> >>Brian Rosen wrote: >> >>>I've pretty much stayed out of this whole set of threads, but this one >>>really had me wondering where everyone's head is again. >>> >>>We're getting wrapped around the axle of not having a definition of >>>"service" again. >> >>Well, we had decided that a service is whatever a tuple describes. >>But functionally I agree it has still not really been resolved. >> >> >>>Specifically, I believe that the Doom case you describe below is a >> >>Service >> >>>called Doom that has a number of media streams it supports. It does NOT >>>offer a voice SERVICE, the DOOM service includes game, audio and video >> >>media >> >>>capability. >> >>I infer that you are using "service" to denote what kind of >>functionality is provided via the communication channel(s) described. >> >>So in this case there is an automaton executing the Doom game, providing >>a rendering of that via the output streams, and accepting input to it >>via the input streams. >> >> >>>Now the TUPLE might offer a voice SERVICE, in addition to Doom, possibly >>>using the same hardware, possibly not. You don't care. >> >>We currently have no definition of, or way to describe, services such as >>these. The closest we can get to this right now is via a few attributes: >> >>- automaton >>- attendant >>- message-taker >> >>If all of those are false, in absence of any extentions, I think you >>have a "conversational" service facilitating interactive conversation >>with a human being. >> >>Even with the limited range of "service"s that can be represented via >>those attributes, it is impossible to say in a single tuple that you >>have a conversational service and an automated message taking service, >>except in the negative - by saying nothing about what is provided. >> >> >>>PTT is a SERVICE. It supports voice, possibly video and has floor >> >>control. >> >> From what I have inferred above, I don't see how this can be considered >>a service. It says nothing about the content, and its not an automaton. >>It simply provides different ways to control the media in a >>conversational session - like a different codec does. >> >> >>>But there is nothing in the set of capabilities such as: audio=true, >>>video=false, duplex=full, floor-control=false that could possibly >> >>indicates >> >>>PTT isn't there. A dumb but straightforward audio conference phone >> >>could >> >>>have exactly the same capabilities. The dumb conference phone could >> >>have >> >>>that also. The "floor control=true" and "duplex=half" capabilities, in >>>particular, are not peculiar to PTT. A cell phone with PTT today would >> >>have >> >>>at least two services (voice and PTT). Today, those services are >> >>separate; >> >>>even the voice path is separate in many implementations. >> >>Why is this any different than audio vs video? I might want to have a >>conversation with you using any of those, and switch back and forth >>between them during the call. I think I know the answer, but its not an >>appealing one - the UA will simply not permit mixing the capabilities in >>a single call, or even switching among them serially within a call. Of >>course there are lots of technological excuses for this, but it makes no >>real sense from a user standpoint. >> >>I can at least imagine using PTT to talk to a VM "service" or auto >>attendant "service". This all suggests to me that PTT is not a service >>in the sense that Doom might me. >> >>The PTT case is, I think, just a matter of wanting a way to describe >>mutually exclusive combinations of capabilities. I believe we agreed >>some weeks ago that this was potentially still of interest, but >>postponed dealing with it. Until then, multiple tuples with the same >>contact provides a way at the expense of being ambiguous about what is >>intended. >> >>I have been trying for years now to understand what you "service" >>oriented people are talking about. It always seems like there is >>*something* there, but its elusive, and you don't all seem to have the >>same concept. I think there may be some opportunity to describe this as >>the behavior behind the media, encompassing VM, Attendant, Doom. >> >> >>>And please keep in mind that I want to be able to offer a presence >> >>service >> >>>with ONE contact, which I assumed was one tuple, but don't care if there >> >>are >> >>>multiple tuples as long as they have the same contact URI. That >> >>represents >> >>>the presence information of the presentity, full stop, including all of >> >>the >> >>>services it might support. >> >>You have been quiet for so long now that I thought you had got the >>correct religion, or fallen asleep, or something. :-) >> >>If you are going to offer a single tuple, and hide both a conversational >>voice service and Doom behind it, I don't see how you are going to avoid >> disappointing someone. Somebody is going to end up on their phone >>talking to a doom game. >> >> >>>Brian >>> >>> >>> >>>>-----Original Message----- >>>>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf >>>>Of Paul Kyzivat >>>>Sent: Tuesday, February 01, 2005 9:58 AM >>>>To: Aki Niemi >>>>Cc: Simple WG >>>>Subject: Re: Single tuple or many tuples (was: Re: [Simple] another try >>>>atdata model compromise regarding unique service URI) >>>> >>>> >>>> >>>>Aki Niemi wrote: >>>> >>>> >>>>>ext Paul Kyzivat wrote: >>>>> >>>>>...snip... >>>>> >>>>> >>>>> >>>>>>For devices with the real estate, it would be better to simply display >>>>>>multiple icons for each buddy indicating what capabilities are >>>>>>currently available. (Perhaps icons of phones and cameras can turn >>>>> >>>>>>from red to green.) >>>>> >>>>>I don't buy this. Think of a "doom" icon that can be either red, green, >>>>>or indicate deathmatch. Capabilities are uninportant, it's the service >>>>>that is composed of those capabilities that is important. >>>> >>>>I don't understand your point at all. >>>> >>>>It seems to me that either: >>>> >>>>- you have a separate tuple/service for Doom, with its own unique >>>> contact that I can call. In this case doom itself may have >>>> "doom" capability, and perhaps audio, video, etc. as well. >>>> >>>> you then have other contacts with differing sets of capabilities >>>> and different contact addresses. Perhaps one with basic voice. >>>> >>>>- you have a single multipurpose tuple/service. It has capabilities >>>> for voice, and maybe doom as well. >>>> >>>>- you have multiple tuples - one for doom, another for basic voice, >>>> but they share a contact address. >>>> >>>>The question is, how do I know what to expect when making a call in each >>>>case? E.g. if I make a voice-only call, do I talk to you, or do I hear >>>>the audio from a doom game I can't control? >>>> >>>>I guess it depends a bit on how you expect doom to work. Do you imagine >>>>it to consist of a game control protocol plus audio and video streams >>>>rendering the game? >>>> >>>> >>>> >>>>>And do you really think users will generally be happy to interpret that >>>>>someone is available for push-to-talk by examining a set of three (or >>>>>more) icons? >>>> >>>>I see a couple of alternatives here: >>>> >>>>- the user has a PTT application displaying presence. It is only >>>> interested in PTT, so it filters what it displays. All I get is a >>>> list of buddies with red or green status. >>>> >>>>- the user has a general purpose presence client, that can do PTT, >>>> regular voice, video, Doom, whatever. (The user has to both pick >>>> a buddy and then pick an action to do something.) >>>> >>>> In this case, it has three or more things to display regardless >>>> of how the RPID document is formatted. Either it has multiple >>>> capabilities for a single tuple, or it has multiple tuples each >>>> with (potentially multiple) capabilities. There are many ways >>>> of rendering each of these, but the fundamental complexity of >>>> what is to be rendered is pretty much the same. >>>> >>>> >>>> >>>>>>You seem to have in mind a "video service" that includes both voice >>>>>>and video, and a separate "audio service" that includes only audio. >>>>>>And then either or both can be available. >>>>> >>>>> >>>>>I gave an example of *three* different services. But fine, let's say >> >>you >> >>>>>only have two: a videophone capable of both video and audio (together >> >>or >> >>>>>separate) and a push-to-talk client (audio, half-duplex and floor >>>>>control). Now, let's say video is unavailable, audio is available, and >>>>>push-to-talk is unavailable. >>>>> >>>>>How would you represent that in a single tuple? >>>> >>>>I left out the PTT to keep things simple, since I don't think we have >>>>agreed in detail how to represent it as a capability. But lets try >> >>anyway. >> >>>>In the state you describe it, I would simply represent it as a tuple >>>>with audio=true, video=false, duplex=full, floor-control=false. What is >>>>so hard about that? >>>> >>>> >>>> >>>>>>But how is this better (or even as good as) a single videophone >>>>>>service that is capable of supporting both voice and video, or just >>>>>>voice, or just video, depending on what is negotiated in a call? With >>>>>>such a service, if I don't want to be available for video, I just >>>>>>disable it, so it won't be offered or answered, and then video then >>>>>>isn't advertised in the (single) presence tuple either. >>>>> >>>>> >>>>>I'm not going to debate over details about voice and/or video. My >>>>>attempt was to demonstrate that there are "services" that aren't going >>>>>to be described only using a single, simple media attribute, like >>>>>"voice" and "video", but will be composed of a set of capabilities, >>>>>where this capability set then shares a status that will have more >>>>>states available than simple on or off. >>>> >>>>Ahh. This may be hinting at the real issue. But it is only a hint, and I >>>>think you need to say a lot more to establish the use case. I've got a >>>>feeling that PTT is a bad example because its "differences" are more >>>>about limitations in the technology that intrinsic feature differences. >>>> >>>>I suspect Doom may be a better example. I have the idea that what you >>>>have in mind is that when I call the "Doom Service" I get audio and >>>>video that are slaved to the game, rather than a conversational adjunct >>>>to the game that allows me to converse with the other player(s) while >>>>playing. If so, then it is a lot like an IVR or a VM server. If so, then >>>>I agree with you that it *should* be represented as a separate tuple. >>>>But I also think it *should* have a separate contact, so that it is >>>>clear how to reach that particular service. >>>> >>>>I gather you have in mind that if I negotiate the doom control protocol >>>>I will get the doom service and the audio/video will be slaved to it, >>>>but if I don't negotiate the doom control protocol then I get the >>>>"conversational" service managing my voice/video. I don't see why I >>>>would be able to draw that conclusion from the RPID. >>>> >>>> >>>> >>>>>However, stepping back for a moment. >>>>> >>>>>Seems there is still some fundamental desire here to restrict the >>>>>presence data model to suit the "unique-URI" concept. >>>>> >>>>>But like Henning has pointed out many times before, there will be >>>>>multiple tuples in a document. So inherently, the watcher is faced with >>>>>having to make a selection. Henning has also pointed out that to >>>>>determine uniqueness, the contact is a very poor key to use. Whether >>>>>some of those tuples have the contact address is therefore immaterial >>>>>(and depends exclusively on the uniqueness rules of the URI scheme). >>>>>Also, we aren't going to forbid a dumb composer passing all of the >>>>>received tuples to the watcher using the union composition. >>>> >>>>In most cases I see no reason why the watcher has a need to determine >>>>uniqueness. All it has to do is present the alternatives to the user, >>>>let the user choose one, and send a request to the contact of the one >>>>chosen. The kind of request sent can either be determined by default >>>>based on capabilities advertised in the tuple and local capabilities, or >>>>can be adjusted based on explicit choices made by the user. >>>> >>>> >>>> >>>>>If we were to *mandate* that all SIP-enabled services are represented >>>>>using a single tuple, where would you enforce this rule? And what would >>>>>be the benefit compared to allowing more than a single tuple? >>>> >>>>I'm not sure this is something to mandate. I think it is more of a "best >>>>practices" kind of thing. It seems clear that people are going to do a >>>>bunch of weird things, and results will vary. About all we can do is >>>>give suggestions on how to get a good result. >>>> >>>> >>>> >>>>>Simply saying that it is possible in some instances to do things that >>>>>way is not a good enough reason, if there are instances where it does >>>>>not work. >>>> >>>>I think this might best be approached by restarting the work on presence >>>>use cases. >>>> >>>>Here is (a bad) one, based on what I think you have in mind. (Please >>>>feel free to provide a better way to handle this case.) >>>> >>>>Suppose your presence includes one tuple listing audio, video, and doom. >>>>My presence client doesn't understand doom or video, so it simply >>>>renders the tuple as available for voice. I pick it and make a voice >>>>call. Your Doom service slaves audio to the game, so I just hear a bunch >>>>of bleeps and gun fire. I am likely to be annoyed with you for having >>>>announced that you were available for voice when you were not. >>>> >>>>Or, your UA refused my call because I didn't offer doom control >>>>protocol. I'm still annoyed that you said you were available for voice >>>>but refused my call. (But at least this is within the realm of >>>>reasonable behaviors.) >>>> >>>> Paul >>>> >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>>> >>> >>> >>> > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 3 10:43:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05964; Thu, 3 Feb 2005 10:43:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwjRN-0001zm-IZ; Thu, 03 Feb 2005 11:02:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwivF-0006j6-Op; Thu, 03 Feb 2005 10:29:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwioH-0002r6-Jv for simple@megatron.ietf.org; Thu, 03 Feb 2005 10:22:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02270 for ; Thu, 3 Feb 2005 10:22:19 -0500 (EST) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwj6p-0000xg-0Q for simple@ietf.org; Thu, 03 Feb 2005 10:41:34 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j13FMD818782; Thu, 3 Feb 2005 17:22:13 +0200 (EET) X-Scanned: Thu, 3 Feb 2005 17:22:01 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j13FM1sF023213; Thu, 3 Feb 2005 17:22:01 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 007ZPcqV; Thu, 03 Feb 2005 16:59:39 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j13EwIU25661; Thu, 3 Feb 2005 16:58:18 +0200 (EET) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Feb 2005 16:57:58 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Feb 2005 16:57:57 +0200 Received: from 172.21.50.105 ([172.21.50.105]) by esebe105.NOE.Nokia.com ([172.21.143.53]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Feb 2005 14:57:57 +0000 Received: from xitami.research.nokia.com by esebe105.ntc.nokia.com; 03 Feb 2005 16:57:56 +0200 Subject: Re: [Simple] Namespaces and XCAP From: jari urpalainen To: ext Jonathan Rosenberg In-Reply-To: <42022922.5090501@cisco.com> References: <41FE9B4C.1070106@cisco.com> <1107242622.26454.54.camel@xitami.research.nokia.com> <41FF3331.8010008@cisco.com> <1107338919.27837.34.camel@xitami.research.nokia.com> <4201C583.7050600@cisco.com> <1107421882.30334.62.camel@xitami.research.nokia.com> <42022922.5090501@cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 03 Feb 2005 16:57:56 +0200 Message-Id: <1107442676.30959.15.camel@xitami.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-OriginalArrivalTime: 03 Feb 2005 14:57:57.0804 (UTC) FILETIME=[BF70B6C0:01C50A00] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit On Thu, 2005-02-03 at 08:37 -0500, ext Jonathan Rosenberg wrote: > inline. > > Some reference from "The XML Bible, 2nd Edition" > > > > http://www.cafeconleche.org/books/bible2/chapters/ch20.html > > > > Just quoting examples from the above reference: > > > > http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(id("ebnf")) > > http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(descendant::language[position()=2]) > > http://www.w3.org/TR/1998/REC-xml-19980210.xml#ebnf > > http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(/child::spec/child::body/child::*/child::language[2]) > > http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(/spec/body/*/language[2]) > > http://www.w3.org/TR/1998/REC-xml-19980210.xml#/1/14/2 > > http://www.w3.org/TR/1998/REC-xml-19980210.xml#xpointer(id("ebnf"))xpointer(id("EBNF")) > > THis won't work for us at all. > > As you know fragments are evaluated on the CLIENT side. That is why we > discarded the usage of fragments to begin with. > oops, sorry being stupid... That said I still don't feel comfortable with the mixture of xpointer and xpath. Sorry for generating unnecessary noise... br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 3 11:46:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14031; Thu, 3 Feb 2005 11:46:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwkQI-0004Sj-9g; Thu, 03 Feb 2005 12:05:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwjpc-0007dP-8P; Thu, 03 Feb 2005 11:27:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwRNA-0001cG-6D; Wed, 02 Feb 2005 15:45:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27022; Wed, 2 Feb 2005 15:45:08 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwRfa-0005EU-Vo; Wed, 02 Feb 2005 16:04:15 -0500 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j12KhhQ17667; Wed, 2 Feb 2005 12:43:43 -0800 (PST) Message-Id: <200502022043.j12KhhQ17667@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 02 Feb 2005 12:43:42 -0800 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 X-Mailman-Approved-At: Thu, 03 Feb 2005 11:27:46 -0500 Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 3994 on Indication of Message Composition for Instant Messaging X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3994 Title: Indication of Message Composition for Instant Messaging Author(s): H. Schulzrinne Status: Standards Track Date: January 2005 Mailbox: hgs@cs.columbia.edu Pages: 13 Characters: 27472 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-iscomposing-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3994.txt In instant messaging (IM) systems, it is useful to know during an IM conversation whether the other party is composing a message; e.g., typing or recording an audio message. This document defines a new status message content type and XML namespace that conveys information about a message being composed. The status message can indicate the composition of a message of any type, including text, voice, or video. The status messages are delivered to the instant messaging recipient in the same manner as the instant messages themselves. This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050202124217.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3994 --OtherAccess Content-Type: Message/External-body; name="rfc3994.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050202124217.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From Stokes@didamail.com Thu Feb 3 15:37:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06280; Thu, 3 Feb 2005 15:37:15 -0500 (EST) Message-Id: <200502032037.PAA06280@ietf.org> Received: from [61.33.194.207] (helo=KING3) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cwo1f-0003I9-7h; Thu, 03 Feb 2005 15:56:33 -0500 Received: from [12.67.12.106] by during%DIGITS.bethlehem.61.33.194.207 via HTTP; Thu, 03 Feb 2005 15:36:36 -0800 Reply-To: "fastermail.com" From: "fastermail.com" To: Subject: Heyyy,, me again Date: Thu, 03 Feb 2005 15:36:36 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9882475875qjpl8568" X-Spam-Score: 8.6 (++++++++) X-Spam-Flag: YES X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 ----9882475875qjpl8568 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable Would you like to keep me some company? My Sack of shit husband=20 works night shifts, which makes me very lonely = at night. To contact me please go here: http://godatesunday.com/d/1.php P.S. it's me Sarah c ----9882475875qjpl8568-- From txjeuwynbubapm@rogers.com Thu Feb 3 17:02:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22136; Thu, 3 Feb 2005 17:02:27 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwpM8-0000Bk-Sf; Thu, 03 Feb 2005 17:21:46 -0500 Received: from 193.56.150.220.ap.yournet.ne.jp ([220.150.56.193]) by mx2.foretec.com with smtp (Exim 4.24) id 1Cwp3N-0007hn-Oc; Thu, 03 Feb 2005 17:02:27 -0500 Received: from mail15030.gvvd.comstar.com (212.2.170.121) by sc11-bk199.comstar.com with Microsoft SMTPSVC(5.0.2195.6824); Fri, 04 Feb 2005 01:01:22 +0300 Received: from DZB610 (c36.0.63.153.v896.bws.comstar.com 126.28.54.234) by mail17.rwg.comstar.com (740.15.3hy3/8.459.55) with SMTP id wm2AS4FChva7271; Thu, 03 Feb 2005 17:59:22 -0400 Message-ID: <7d0pgw24vz40bz$y5am7lry151$o56tn027@E096> From: "Ivory Mcfarland" To: "Simple-archive" References: Subject: You've been approved at 3.25 Date: Thu, 03 Feb 2005 22:56:22 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--xiirwlkouy1181835941725239wpriyvfvxsz" X-Spam-Score: 16.3 (++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f ----xiirwlkouy1181835941725239wpriyvfvxsz Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Hello, I sent you an email a few days ago because you now qualify for a new mortg= age. You could get a $300,000 for as little as $700 a month! credit is no problem, you can pull cash out or refinance. Quick Form http://lawyer.grger.per-fect-mor-tgage.com/?h0p=20 Best Regards, Dustin Rosado Quick Form http://lawyer.grger.per-fect-mor-tgage.com/?h0p=20 ----------------------------------------- Discontinue http://bfijdeacghkl.comcities.info/go.php?egjkbdxyclzafhim ----xiirwlkouy1181835941725239wpriyvfvxsz-- From simple-bounces@ietf.org Thu Feb 3 17:27:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29265; Thu, 3 Feb 2005 17:27:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwpkg-0001yK-Ul; Thu, 03 Feb 2005 17:47:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwpEY-0005uo-EX; Thu, 03 Feb 2005 17:13:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwocS-0004YV-Pk for simple@megatron.ietf.org; Thu, 03 Feb 2005 16:34:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15528 for ; Thu, 3 Feb 2005 16:34:30 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwov4-0006Sl-El for simple@ietf.org; Thu, 03 Feb 2005 16:53:49 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 03 Feb 2005 13:43:24 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j13LXuoQ011561; Thu, 3 Feb 2005 13:33:56 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-16.cisco.com [10.86.240.16]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOV50170; Thu, 3 Feb 2005 16:33:54 -0500 (EST) Message-ID: <420298C2.8000307@cisco.com> Date: Thu, 03 Feb 2005 16:33:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: Single tuple or many tuples (was: Re: [Simple] another try atdata model compromise regarding unique service URI) References: <3q28cg$14ais0@sj-inbound-b.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Brian Rosen wrote: > I think the basic model is close to Doom-3, but a bit different from what > you describe it. It's not Doom-1 or 2. > > First of all, the audio and video in a Doom game that are the actual Doom > visual and auditory outputs of the game are locally generated. The Doom > control protocol is all that is needed for the basic game. > > I think if there is audio, it's a conference call-like open audio channel > between players. As in Doom-3, it would be locally mixed with the local > Doom game sounds. It could have PTT, it could have a notion of "side" (ie > normally I talk to only my side, but I have a floor that lets me talk to all > the players), but it's defined by the Doom game what it does and how you use > it. It's not a general purpose telephone, and it's unlikely to be precisely > the mobile guy's notion of PTT. That's what I would do. Someone else may > define it differently. However it's defined, it's an audio service > specifically specified for Doom. The audio and game control are intertwined > into the Doom service. You can't infer how it works; you need to read the > description of it in the Doom service. This could be refined further, but I don't know if we want to do that. It sounds to me that the media other than the game control are however close enough to what they "normally" mean to be considered "normal". It would be pretty reasonable to me for a Doom game machine that supports this to answer a voice-only call. The game player then talks while playing his game, and the other party only talks and listens. So the caller being a regular phone works fine. If this game machine originated a call, while it would presumably offer doom-protocol, with voice perhaps optionally being offered. If voice was offered, and the recipient accepted voice and not the doom-protocol, it would again make sense for it to work. (I am using the principle of least surprise here to decide what I consider to be reasonable.) > Probably, someone wrote a spec for > it and published it. Probably, they registered the service name with IANA. Is this just an off-hand suggestion, or are you referring to some real IANA registry that already exists? If there is one that already exists, that you think is applicable here, then lets discuss it. If not, then that becomes yet another item of work which we may or may not want to take up. Seems analogous to what Henning mentioned, for describing media *content*. > That lets multiple implementations of the client exist and interoperate. You > don't know, for example, unless you understand the Doom service, if it makes > any sense to run the Doom game stream without the audio or vice versa. > > >>I don't get this. The floor control is the essence of PTT. Otherwise it >>is just audio. As Jonathan has pointed out, this may be a case where the >>implementation won't allow you to negotiate a session without the floor >>control. If so we need some way to indicate that. But that is the only >>special thing. > > Nope, floor control is not the "essence" of PTT, it's just one of its common > characteristics. You can have floor control without PTT. Certainly true. My impression is that what is special about PTT is that currently the floor control protocol is special for PTT. If PTT used a "standard" floor control that was also implemented as part of a generic conference server, then you wouldn't be able to tell the difference between doing PTT and calling such a conference server. > You actually can > have PTT without floor control; a real radio system is PTT without floor > control -- you push the button and talk -- if two people do it at the same > time, third parties hear one or both, and the two speakers don't hear each > other. Some PTTs assume half duplex, others don't. You can define a PTT > service that is half duplex, and another that is half or full duplex. There > isn't going to be ONE PTT service, their probably will be more than one. I think you can imagine various ways of implemented "PTT", as you describe. But I don't think you need a registry of different flavors of "PTT Service" to understand these. The only things that seem to matter here are: - what kinds of media streams are included - what floor control protocol (if any) is negotiated - whether the stream(s) are "half duplex" The half duplex is problematic, because its meaning in the context of sip isn't well defined. We probably ought to either get rid of it, or define what it means operationally. I can think of two ways to define it: - half-duplex-1: a=sendrecv isn't allowed. Direction of communication is negotiated via offer/answer. - half-duplex-2: this session requires a floor control protocol With all of this I think what needs to be done can be understood entirely by the combination of the various attributes. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 3 17:36:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00165; Thu, 3 Feb 2005 17:36:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwptX-0002Ic-5z; Thu, 03 Feb 2005 17:56:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwpHj-0008DX-Oc; Thu, 03 Feb 2005 17:17:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwovI-0001jh-CT for simple@megatron.ietf.org; Thu, 03 Feb 2005 16:54:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19765 for ; Thu, 3 Feb 2005 16:53:57 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwpDu-0007xI-Nn for simple@ietf.org; Thu, 03 Feb 2005 17:13:16 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 03 Feb 2005 17:03:42 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j13LrOQL011836; Thu, 3 Feb 2005 16:53:25 -0500 (EST) Received: from cisco.com (che-vpn-cluster-1-16.cisco.com [10.86.240.16]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOV52140; Thu, 3 Feb 2005 16:53:23 -0500 (EST) Message-ID: <42029D53.8080608@cisco.com> Date: Thu, 03 Feb 2005 16:53:23 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: FW: Single tuple or many tuples (was: Re: [Simple] another try atdata model compromise regarding unique service URI) References: <200502021350.IAA03673@ietf.org> <42023AA0.4050008@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8e140a89d08e89747ee196e282ac2228 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d188b91ff79eaa1be2a0e9635461d9a Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > I agree that we need a separate dimension for identifying the content of > media streams or services. This seems orthogonal to capabilities. In > some cases, there might be a way to enumerate the service in some > pick-from-list manner, in a MIME-type fashion, in many others this is > likely to be pretty useless. We have started down this path with: - attendant - message-taker I always had a feeling this was the beginning of a slippery slope. I suppose I could imagine some kind of registry. But I can't quite imagine what criteria would be used to decide what to name - there would probably need to be some kind of taxonomy. (This starts to look like the yellow pages.) I'm not convinced we want to go much further down this slope. So far I think the cases people have made that they need this are pretty weak. While it is possible to structure your implementation to need this, so far I think it is also possible to structure things so that isn't needed. > Picture the availability for delta.com (the airline), which might > include services for flight information, international and domestic > reservations and probably many more. Yup. This is really starting to look like the yellow pages. Paul > Brian Rosen wrote: > >> I don't think we have a prayer of making a Doom game with audio and video >> streams as well as the game stream work in presence without having a >> notion >> of service that has some kind of name which is used to describe the >> service. >> That service description can be text as long as it is unique enough >> that the >> watcher (client) can render some good enough UI and the watcher (human) >> understands what to do with it. >> >> So if someone defines "Doom" as being a service that has a game stream >> and >> optional audio and video streams, then you can build a watcher that >> understands what Doom is and render a very nice interface with, say, a >> Doom >> icon, and a basic watcher can show the name of the service and the media >> streams on it that a human can interpret it. I think we all agree >> that, at >> the very least, the presence of the Doom service is contained in one >> tuple. >> The only thing you really would like to understand about service is >> name and >> the fact that it can contain multiple streams and multiple capabilities. >> I don't think you can infer this notion of service from the aggregate of >> capabilities, and I don't want to try. You can DEFINE a service as >> having >> some fixed and optional capabilities with the watcher being able to >> discover >> which of them a particular presentity has available at a point in time. >> That we can do. So don't guess that audio and/or video with half >> duplex and >> floor control MEANS PTT, instead DEFINE PTT as a service that has audio, >> optional video, half duplex and floor control and let a tuple state >> that the >> presentity supports a PTT service and at the present time only has audio >> (not video) available. >> Then I can offer a Telephone service and Doom service, both of which >> support >> audio, and we won't get anyone confused. >> >> Brian >> >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Tuesday, February 01, 2005 1:51 PM >>> To: Brian Rosen >>> Cc: 'Aki Niemi'; 'Simple WG' >>> Subject: Re: Single tuple or many tuples (was: Re: [Simple] another try >>> atdata model compromise regarding unique service URI) >>> >>> Brian - inline. >>> >>> Paul >>> >>> Brian Rosen wrote: >>> >>>> I've pretty much stayed out of this whole set of threads, but this one >>>> really had me wondering where everyone's head is again. >>>> >>>> We're getting wrapped around the axle of not having a definition of >>>> "service" again. >>> >>> >>> Well, we had decided that a service is whatever a tuple describes. >>> But functionally I agree it has still not really been resolved. >>> >>> >>>> Specifically, I believe that the Doom case you describe below is a >>> >>> >>> Service >>> >>>> called Doom that has a number of media streams it supports. It does >>>> NOT >>>> offer a voice SERVICE, the DOOM service includes game, audio and video >>> >>> >>> media >>> >>>> capability. >>> >>> >>> I infer that you are using "service" to denote what kind of >>> functionality is provided via the communication channel(s) described. >>> >>> So in this case there is an automaton executing the Doom game, providing >>> a rendering of that via the output streams, and accepting input to it >>> via the input streams. >>> >>> >>>> Now the TUPLE might offer a voice SERVICE, in addition to Doom, >>>> possibly >>>> using the same hardware, possibly not. You don't care. >>> >>> >>> We currently have no definition of, or way to describe, services such as >>> these. The closest we can get to this right now is via a few attributes: >>> >>> - automaton >>> - attendant >>> - message-taker >>> >>> If all of those are false, in absence of any extentions, I think you >>> have a "conversational" service facilitating interactive conversation >>> with a human being. >>> >>> Even with the limited range of "service"s that can be represented via >>> those attributes, it is impossible to say in a single tuple that you >>> have a conversational service and an automated message taking service, >>> except in the negative - by saying nothing about what is provided. >>> >>> >>>> PTT is a SERVICE. It supports voice, possibly video and has floor >>> >>> >>> control. >>> >>> From what I have inferred above, I don't see how this can be considered >>> a service. It says nothing about the content, and its not an automaton. >>> It simply provides different ways to control the media in a >>> conversational session - like a different codec does. >>> >>> >>>> But there is nothing in the set of capabilities such as: audio=true, >>>> video=false, duplex=full, floor-control=false that could possibly >>> >>> >>> indicates >>> >>>> PTT isn't there. A dumb but straightforward audio conference phone >>> >>> >>> could >>> >>>> have exactly the same capabilities. The dumb conference phone could >>> >>> >>> have >>> >>>> that also. The "floor control=true" and "duplex=half" capabilities, in >>>> particular, are not peculiar to PTT. A cell phone with PTT today would >>> >>> >>> have >>> >>>> at least two services (voice and PTT). Today, those services are >>> >>> >>> separate; >>> >>>> even the voice path is separate in many implementations. >>> >>> >>> Why is this any different than audio vs video? I might want to have a >>> conversation with you using any of those, and switch back and forth >>> between them during the call. I think I know the answer, but its not an >>> appealing one - the UA will simply not permit mixing the capabilities in >>> a single call, or even switching among them serially within a call. Of >>> course there are lots of technological excuses for this, but it makes no >>> real sense from a user standpoint. >>> >>> I can at least imagine using PTT to talk to a VM "service" or auto >>> attendant "service". This all suggests to me that PTT is not a service >>> in the sense that Doom might me. >>> >>> The PTT case is, I think, just a matter of wanting a way to describe >>> mutually exclusive combinations of capabilities. I believe we agreed >>> some weeks ago that this was potentially still of interest, but >>> postponed dealing with it. Until then, multiple tuples with the same >>> contact provides a way at the expense of being ambiguous about what is >>> intended. >>> >>> I have been trying for years now to understand what you "service" >>> oriented people are talking about. It always seems like there is >>> *something* there, but its elusive, and you don't all seem to have the >>> same concept. I think there may be some opportunity to describe this as >>> the behavior behind the media, encompassing VM, Attendant, Doom. >>> >>> >>>> And please keep in mind that I want to be able to offer a presence >>> >>> >>> service >>> >>>> with ONE contact, which I assumed was one tuple, but don't care if >>>> there >>> >>> >>> are >>> >>>> multiple tuples as long as they have the same contact URI. That >>> >>> >>> represents >>> >>>> the presence information of the presentity, full stop, including all of >>> >>> >>> the >>> >>>> services it might support. >>> >>> >>> You have been quiet for so long now that I thought you had got the >>> correct religion, or fallen asleep, or something. :-) >>> >>> If you are going to offer a single tuple, and hide both a conversational >>> voice service and Doom behind it, I don't see how you are going to avoid >>> disappointing someone. Somebody is going to end up on their phone >>> talking to a doom game. >>> >>> >>>> Brian >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >>>>> Behalf >>>>> Of Paul Kyzivat >>>>> Sent: Tuesday, February 01, 2005 9:58 AM >>>>> To: Aki Niemi >>>>> Cc: Simple WG >>>>> Subject: Re: Single tuple or many tuples (was: Re: [Simple] another >>>>> try >>>>> atdata model compromise regarding unique service URI) >>>>> >>>>> >>>>> >>>>> Aki Niemi wrote: >>>>> >>>>> >>>>>> ext Paul Kyzivat wrote: >>>>>> >>>>>> ...snip... >>>>>> >>>>>> >>>>>> >>>>>>> For devices with the real estate, it would be better to simply >>>>>>> display >>>>>>> multiple icons for each buddy indicating what capabilities are >>>>>>> currently available. (Perhaps icons of phones and cameras can turn >>>>>> >>>>>> >>>>>>> from red to green.) >>>>>> >>>>>> >>>>>> I don't buy this. Think of a "doom" icon that can be either red, >>>>>> green, >>>>>> or indicate deathmatch. Capabilities are uninportant, it's the >>>>>> service >>>>>> that is composed of those capabilities that is important. >>>>> >>>>> >>>>> I don't understand your point at all. >>>>> >>>>> It seems to me that either: >>>>> >>>>> - you have a separate tuple/service for Doom, with its own unique >>>>> contact that I can call. In this case doom itself may have >>>>> "doom" capability, and perhaps audio, video, etc. as well. >>>>> >>>>> you then have other contacts with differing sets of capabilities >>>>> and different contact addresses. Perhaps one with basic voice. >>>>> >>>>> - you have a single multipurpose tuple/service. It has capabilities >>>>> for voice, and maybe doom as well. >>>>> >>>>> - you have multiple tuples - one for doom, another for basic voice, >>>>> but they share a contact address. >>>>> >>>>> The question is, how do I know what to expect when making a call in >>>>> each >>>>> case? E.g. if I make a voice-only call, do I talk to you, or do I hear >>>>> the audio from a doom game I can't control? >>>>> >>>>> I guess it depends a bit on how you expect doom to work. Do you >>>>> imagine >>>>> it to consist of a game control protocol plus audio and video streams >>>>> rendering the game? >>>>> >>>>> >>>>> >>>>>> And do you really think users will generally be happy to interpret >>>>>> that >>>>>> someone is available for push-to-talk by examining a set of three (or >>>>>> more) icons? >>>>> >>>>> >>>>> I see a couple of alternatives here: >>>>> >>>>> - the user has a PTT application displaying presence. It is only >>>>> interested in PTT, so it filters what it displays. All I get is a >>>>> list of buddies with red or green status. >>>>> >>>>> - the user has a general purpose presence client, that can do PTT, >>>>> regular voice, video, Doom, whatever. (The user has to both pick >>>>> a buddy and then pick an action to do something.) >>>>> >>>>> In this case, it has three or more things to display regardless >>>>> of how the RPID document is formatted. Either it has multiple >>>>> capabilities for a single tuple, or it has multiple tuples each >>>>> with (potentially multiple) capabilities. There are many ways >>>>> of rendering each of these, but the fundamental complexity of >>>>> what is to be rendered is pretty much the same. >>>>> >>>>> >>>>> >>>>>>> You seem to have in mind a "video service" that includes both voice >>>>>>> and video, and a separate "audio service" that includes only audio. >>>>>>> And then either or both can be available. >>>>>> >>>>>> >>>>>> >>>>>> I gave an example of *three* different services. But fine, let's say >>>>> >>> >>> you >>> >>>>>> only have two: a videophone capable of both video and audio (together >>>>> >>> >>> or >>> >>>>>> separate) and a push-to-talk client (audio, half-duplex and floor >>>>>> control). Now, let's say video is unavailable, audio is available, >>>>>> and >>>>>> push-to-talk is unavailable. >>>>>> >>>>>> How would you represent that in a single tuple? >>>>> >>>>> >>>>> I left out the PTT to keep things simple, since I don't think we have >>>>> agreed in detail how to represent it as a capability. But lets try >>>> >>> >>> anyway. >>> >>>>> In the state you describe it, I would simply represent it as a tuple >>>>> with audio=true, video=false, duplex=full, floor-control=false. >>>>> What is >>>>> so hard about that? >>>>> >>>>> >>>>> >>>>>>> But how is this better (or even as good as) a single videophone >>>>>>> service that is capable of supporting both voice and video, or just >>>>>>> voice, or just video, depending on what is negotiated in a call? >>>>>>> With >>>>>>> such a service, if I don't want to be available for video, I just >>>>>>> disable it, so it won't be offered or answered, and then video then >>>>>>> isn't advertised in the (single) presence tuple either. >>>>>> >>>>>> >>>>>> >>>>>> I'm not going to debate over details about voice and/or video. My >>>>>> attempt was to demonstrate that there are "services" that aren't >>>>>> going >>>>>> to be described only using a single, simple media attribute, like >>>>>> "voice" and "video", but will be composed of a set of capabilities, >>>>>> where this capability set then shares a status that will have more >>>>>> states available than simple on or off. >>>>> >>>>> >>>>> Ahh. This may be hinting at the real issue. But it is only a hint, >>>>> and I >>>>> think you need to say a lot more to establish the use case. I've got a >>>>> feeling that PTT is a bad example because its "differences" are more >>>>> about limitations in the technology that intrinsic feature >>>>> differences. >>>>> >>>>> I suspect Doom may be a better example. I have the idea that what you >>>>> have in mind is that when I call the "Doom Service" I get audio and >>>>> video that are slaved to the game, rather than a conversational >>>>> adjunct >>>>> to the game that allows me to converse with the other player(s) while >>>>> playing. If so, then it is a lot like an IVR or a VM server. If so, >>>>> then >>>>> I agree with you that it *should* be represented as a separate tuple. >>>>> But I also think it *should* have a separate contact, so that it is >>>>> clear how to reach that particular service. >>>>> >>>>> I gather you have in mind that if I negotiate the doom control >>>>> protocol >>>>> I will get the doom service and the audio/video will be slaved to it, >>>>> but if I don't negotiate the doom control protocol then I get the >>>>> "conversational" service managing my voice/video. I don't see why I >>>>> would be able to draw that conclusion from the RPID. >>>>> >>>>> >>>>> >>>>>> However, stepping back for a moment. >>>>>> >>>>>> Seems there is still some fundamental desire here to restrict the >>>>>> presence data model to suit the "unique-URI" concept. >>>>>> >>>>>> But like Henning has pointed out many times before, there will be >>>>>> multiple tuples in a document. So inherently, the watcher is faced >>>>>> with >>>>>> having to make a selection. Henning has also pointed out that to >>>>>> determine uniqueness, the contact is a very poor key to use. Whether >>>>>> some of those tuples have the contact address is therefore immaterial >>>>>> (and depends exclusively on the uniqueness rules of the URI scheme). >>>>>> Also, we aren't going to forbid a dumb composer passing all of the >>>>>> received tuples to the watcher using the union composition. >>>>> >>>>> >>>>> In most cases I see no reason why the watcher has a need to determine >>>>> uniqueness. All it has to do is present the alternatives to the user, >>>>> let the user choose one, and send a request to the contact of the one >>>>> chosen. The kind of request sent can either be determined by default >>>>> based on capabilities advertised in the tuple and local >>>>> capabilities, or >>>>> can be adjusted based on explicit choices made by the user. >>>>> >>>>> >>>>> >>>>>> If we were to *mandate* that all SIP-enabled services are represented >>>>>> using a single tuple, where would you enforce this rule? And what >>>>>> would >>>>>> be the benefit compared to allowing more than a single tuple? >>>>> >>>>> >>>>> I'm not sure this is something to mandate. I think it is more of a >>>>> "best >>>>> practices" kind of thing. It seems clear that people are going to do a >>>>> bunch of weird things, and results will vary. About all we can do is >>>>> give suggestions on how to get a good result. >>>>> >>>>> >>>>> >>>>>> Simply saying that it is possible in some instances to do things that >>>>>> way is not a good enough reason, if there are instances where it does >>>>>> not work. >>>>> >>>>> >>>>> I think this might best be approached by restarting the work on >>>>> presence >>>>> use cases. >>>>> >>>>> Here is (a bad) one, based on what I think you have in mind. (Please >>>>> feel free to provide a better way to handle this case.) >>>>> >>>>> Suppose your presence includes one tuple listing audio, video, and >>>>> doom. >>>>> My presence client doesn't understand doom or video, so it simply >>>>> renders the tuple as available for voice. I pick it and make a voice >>>>> call. Your Doom service slaves audio to the game, so I just hear a >>>>> bunch >>>>> of bleeps and gun fire. I am likely to be annoyed with you for having >>>>> announced that you were available for voice when you were not. >>>>> >>>>> Or, your UA refused my call because I didn't offer doom control >>>>> protocol. I'm still annoyed that you said you were available for voice >>>>> but refused my call. (But at least this is within the realm of >>>>> reasonable behaviors.) >>>>> >>>>> Paul >>>>> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>> >>>> >>>> >> >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 4 01:18:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09904; Fri, 4 Feb 2005 01:18:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwx6V-0006sD-LB; Fri, 04 Feb 2005 01:38:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwwj9-0004Ml-P7; Fri, 04 Feb 2005 01:13:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwwYD-0001Jx-Bb for simple@megatron.ietf.org; Fri, 04 Feb 2005 01:02:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08718 for ; Fri, 4 Feb 2005 01:02:40 -0500 (EST) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwwqu-0006VN-NH for simple@ietf.org; Fri, 04 Feb 2005 01:22:02 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1461hO02572; Fri, 4 Feb 2005 08:01:43 +0200 (EET) X-Scanned: Fri, 4 Feb 2005 08:00:46 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j1460k9S022095; Fri, 4 Feb 2005 08:00:46 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00SnsaAv; Fri, 04 Feb 2005 07:59:39 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j145xDU21420; Fri, 4 Feb 2005 07:59:13 +0200 (EET) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 4 Feb 2005 07:56:40 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 4 Feb 2005 07:56:40 +0200 Received: from 172.21.50.105 ([172.21.50.105]) by esebe105.NOE.Nokia.com ([172.21.143.53]) with Microsoft Exchange Server HTTP-DAV ; Fri, 4 Feb 2005 05:56:39 +0000 Received: from xitami.research.nokia.com by esebe105.ntc.nokia.com; 04 Feb 2005 07:56:39 +0200 Subject: Re: [Simple] Namespaces and XCAP From: jari urpalainen To: ext Hisham Khartabil In-Reply-To: References: <41FE9B4C.1070106@cisco.com> <1107242622.26454.54.camel@xitami.research.nokia.com> <41FF3331.8010008@cisco.com> <1107338919.27837.34.camel@xitami.research.nokia.com> <4201C583.7050600@cisco.com> <1107421882.30334.62.camel@xitami.research.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 04 Feb 2005 07:56:38 +0200 Message-Id: <1107496599.31782.22.camel@xitami.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-OriginalArrivalTime: 04 Feb 2005 05:56:40.0096 (UTC) FILETIME=[4BA18200:01C50A7E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit On Thu, 2005-02-03 at 15:48 +0100, ext Hisham Khartabil wrote: > (As WG chair) > > As you know, this draft has gone through WG last call and IETF last > call. Unless you have identified show stoppers or bugs in the > specification, please accept the consensus that was reached in the WG. > > It is too late to argue personal taste. > > Regards, > Hisham ok, I'll stop whining about the syntax. Just one minor editorial comment. Imo, it is worth mentioning in the draft (sorry Jonathan if it already exists) that if implementations utilize standard xpath or xpointer libraries: 1. if the xpath library has "registration" apis for namespaces uris and prefixes they can be used in location step parsing. 2. if the xpath library doesn't support those extensions, i.e. it is fully xpath 1.0 compatible, the server/client may have to change the location step request from pref:foo to *[local-name()="foo"][namespace- uri()="uri for pref"] 3. if xpointer library is being used in evaluation step parsing the evaluation step request has to be changed so that xpath-part is encapsulated within xpointer(). br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 4 03:47:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03168; Fri, 4 Feb 2005 03:47:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwzQT-0001sm-CV; Fri, 04 Feb 2005 04:06:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwz6H-0006XK-Sb; Fri, 04 Feb 2005 03:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwz1x-0005T6-UA for simple@megatron.ietf.org; Fri, 04 Feb 2005 03:41:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02865 for ; Fri, 4 Feb 2005 03:41:30 -0500 (EST) Received: from bigipbgp.itri.org.tw ([61.61.254.20] helo=maillog.itri.org.tw) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwzKd-0001a0-H9 for simple@ietf.org; Fri, 04 Feb 2005 04:00:54 -0500 Received: from mail.itri.org.tw (mail [140.96.157.2]) by maillog.itri.org.tw (8.11.6+Sun/8.11.6) with ESMTP id j148gMk29990 for ; Fri, 4 Feb 2005 16:42:22 +0800 (CST) Received: from ms3.itri.org.tw (ms3.itri.org.tw [140.96.150.43]) by mail.itri.org.tw (8.11.6+Sun/8.11.6) with ESMTP id j148XJc07866 for ; Fri, 4 Feb 2005 16:33:20 +0800 (CST) Received: from 01092035392 ([140.96.254.153]) by ms3.itri.org.tw (Lotus Domino Release 5.0.13a) with ESMTP id 2005020416404928:10746 ; Fri, 4 Feb 2005 16:40:49 +0800 From: "Jeffrey" To: Subject: RE: [Simple] About change in authorization policy Date: Fri, 4 Feb 2005 16:45:45 +0800 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <41FE6043.1040801@cisco.com> Thread-Index: AcUHtBZTXBXfdV5cSSiA19BJ4L8X1gCybIAw X-MIMETrack: Itemize by SMTP Server on MS3/ITRI(Release 5.0.13a |April 8, 2004) at 2005-02-04 04:40:49 PM, Serialize by Router on MS3/ITRI(Release 5.0.13a |April 8, 2004) at 2005-02-04 04:40:50 PM, Serialize complete at 2005-02-04 04:40:50 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="big5" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: 7bit Hi Paul, Thanks very much for your response. >From my point of view, according to the statement of the 16th page in RFC 3265, rejected: The subscription has been terminated due to change in authorization policy. Clients SHOULD NOT attempt to re-subscribe. The "retry-after" parameter has no semantics for "rejected". So I assume that when a presentity blocks some watcher who was granted before, the Notifier regards this event as authorization policy change and replies to the Subscribe request with the "Subscription-State" value being "terminated". Do you think it is better to notify subscriber with the "Subscription-State" value being "pending" rather than "terminated"? But if I consider the statements in the section 3.2.2 in RFC 3265, The "pending" value indicates that the subscription has been received, but that policy information is insufficient to accept or deny the subscription at this time. It seems the value of "pending" doesn't be suitable for such situation because "block" should imply to deny the subscription. Am I wrong? BR, Jeffrey -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Tuesday, February 01, 2005 12:44 AM To: hocs@itri.org.tw Cc: jdrosen@cisco.com; Markus.Isomaki@nokia.com; 'simple@ietf.org'; 'Markus. Isomaki@nokia.com' Subject: Re: [Simple] About change in authorization policy hocs@itri.org.tw wrote: > Hi all, > > I am afraid that I might miss something or not capture your focus. I > just wonder if revising the authorization rule document is enough for > solving this problem. I would like to emphasize a point that when a > subscription state at Notifier become 'terminated' due to authorization change (e.g. > presentity block some watcher), this subscription will never be > re-active even the presentity changes his mind to do the unblock > action later. This will result in a problem that watcher can't be > notified of presence information except the watcher re-subscribe > again. I wonder if it is possible to add a new subscription state of > "forbidden" for this purpose, so that a subscription state can be from > "active" to "forbidden" and have a chance to go back to "active" in case. > Thanks. If you want to keep the subscription active, you already have two options: - just leave it active, but change the filter criteria so you don't tell the watcher much - change the state to pending, and then don't tell the watcher much. These seem sufficient to handle the case - why do you need yet another state? Paul > BRs, > Jeffrey > > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On > Behalf Of Jonathan Rosenberg > Sent: Friday, January 21, 2005 10:07 AM > To: Paul Kyzivat > Cc: simple@ietf.org; Markus.Isomaki@nokia.com > Subject: Re: [Simple] About change in authorization policy > > inline. > > Paul Kyzivat wrote: > > >> >>Markus.Isomaki@nokia.com wrote: >> >> >>>Paul, >>> >>>I think there is at least one realistic case where what Jeffrey >>>brought up causes some trouble. >>>If value is used to influence the authorization decisions, >>>i.e. different authorization rules apply when sphere=="home" than >>>sphere=="work", the allowed vs. forbidden state for a particular >>>subscriber could very well change at least twice a day. If that >>>subscriber wants to be constantly subscribed to presence whenever it >>>is allowed, she would have to do some polling. For instance if >>>someone forbids her boss to subscribe while she is not working, the >>>boss would not know when to subscribe again after the previous >>>subscription was terminated. >>> >>>This makes me think that the recommended way to use should >>>be not to make it affect the subscription state, but just the >>>content, perhaps using polite blocking. >> >> >>Yes. This falls into the category of "if it hurts, don't do it". In >>this case, you may not want your boss bothering you while you are not >>working, but you probably don't want to piss off your boss. > > > I concur here as well. I think this issue has been raised in the past > as a general concern around using presence state itself as a condition > for subscription acceptance/rejection. However, I will note that the > same issues arise for any decision based on dynamic data, such as time of day. > > > > >>>If we don't come up with any other fix to this, I think at least this >>>issue should be written in a relevant section of the presence-rules RFC. >> >> >>This sounds like a different document - a best practices for presence. > > > I don't think it could hurt to mention this in the authorization rules > document. I'll do that. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From Jarlath722Claus@optusnet.com Fri Feb 4 07:18:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18135; Fri, 4 Feb 2005 07:18:04 -0500 (EST) Received: from [61.76.22.131] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cx2iI-0007Lt-Ss; Fri, 04 Feb 2005 07:37:32 -0500 Received: from mail.sgi.net (61.76.22.131) by l16-wg.sgi.net with Microsoft SMTPSVC(80.26.27573.28813);Fri, 04 Feb 2005 10:14:02 -0200 Message-ID: <95586.XJXBCS@sgi.net> Reply-To: "Ferdinand Kaaren" From: "Ferdinand Kaaren" To: secdir-web-archive@ietf.org Cc: secretariat@ietf.org, secretary@ietf.org, sg@ietf.org, sic@ietf.org, sigtran@ietf.org, sigtran-admin@ietf.org, simple@ietf.org, simple-admin@ietf.org, simple-archive@ietf.org, simple-request@ietf.org Subject: Payment Received: $042427 Date: Fri, 04 Feb 2005 05:15:02 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--149950_82380413.2OM233" X-Spam-Score: 3.3 (+++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ----149950_82380413.2OM233 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Applicant, Your application was processed and approved. You are eligible for $ 405,000 with a 2.8% rate. Please verify your information here: http://know12.gsvdvs.info:443/azbrg We look forward to hearing from you. Ferdinand Kaaren, Account Manager TJK Associates r*mv - http//gsvdvs.info:443/index.php ----149950_82380413.2OM233-- From simple-bounces@ietf.org Fri Feb 4 09:50:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02477; Fri, 4 Feb 2005 09:50:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx55q-0003Uy-NW; Fri, 04 Feb 2005 10:09:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx4gs-0007zN-Ur; Fri, 04 Feb 2005 09:44:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx4en-00073g-NK for simple@megatron.ietf.org; Fri, 04 Feb 2005 09:42:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01967 for ; Fri, 4 Feb 2005 09:41:59 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx4xX-0003Gw-RR for simple@ietf.org; Fri, 04 Feb 2005 10:01:27 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 04 Feb 2005 06:41:43 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j14EfO82006669; Fri, 4 Feb 2005 06:41:25 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-149.cisco.com [10.86.240.149]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHN18889; Fri, 4 Feb 2005 06:41:23 -0800 (PST) Message-ID: <42038993.6050402@cisco.com> Date: Fri, 04 Feb 2005 09:41:23 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari urpalainen Subject: Re: [Simple] Namespaces and XCAP References: <41FE9B4C.1070106@cisco.com> <1107242622.26454.54.camel@xitami.research.nokia.com> <41FF3331.8010008@cisco.com> <1107338919.27837.34.camel@xitami.research.nokia.com> <4201C583.7050600@cisco.com> <1107421882.30334.62.camel@xitami.research.nokia.com> <1107496599.31782.22.camel@xitami.research.nokia.com> In-Reply-To: <1107496599.31782.22.camel@xitami.research.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit inline. jari urpalainen wrote: > On Thu, 2005-02-03 at 15:48 +0100, ext Hisham Khartabil wrote: > >>(As WG chair) >> >>As you know, this draft has gone through WG last call and IETF last >>call. Unless you have identified show stoppers or bugs in the >>specification, please accept the consensus that was reached in the WG. >> >>It is too late to argue personal taste. >> >>Regards, >>Hisham > > ok, I'll stop whining about the syntax. Just one minor editorial > comment. Imo, it is worth mentioning in the draft (sorry Jonathan if it > already exists) that if implementations utilize standard xpath or > xpointer libraries: > 1. if the xpath library has "registration" apis for namespaces uris and > prefixes they can be used in location step parsing. > 2. if the xpath library doesn't support those extensions, i.e. it is > fully xpath 1.0 compatible, the server/client may have to change the > location step request from pref:foo to *[local-name()="foo"][namespace- > uri()="uri for pref"] > 3. if xpointer library is being used in evaluation step parsing the > evaluation step request has to be changed so that xpath-part is > encapsulated within xpointer(). Generally speaking, this kind of implementation specific guidance is not something we put in specifications. The APIs tend to evolve and change, but the RFC is fixed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From Egan@mailpride.com Fri Feb 4 10:59:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09456; Fri, 4 Feb 2005 10:58:57 -0500 (EST) Message-Id: <200502041558.KAA09456@ietf.org> Received: from [211.36.177.210] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cx6A3-00055M-T6; Fri, 04 Feb 2005 11:18:26 -0500 Received: from [160.191.16.23] by economy%DIGITS.paramus.211.36.177.210 via HTTP; Fri, 04 Feb 2005 10:58:19 -0800 Reply-To: "h Mayes Ltd." From: "h Mayes Ltd." To: Subject: Night life Date: Fri, 04 Feb 2005 10:58:19 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--4016876913taep4726" X-Spam-Score: 18.2 (++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----4016876913taep4726 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable 4 Wives looking for fun have been matched for you in your area: 1) Lauren, 130 lbs, 5'9, 36c, 18 miles away, available most nights (husban= d works midnights) 2) Kayla, 120 lbs, 5'9, 36d, 12 miles away, available most nights (husband= works midnights) 3) Morgan, 125 lbs, 5'6, 34b, 18 miles away, available Jan 31- Feb 3rd 4) Rebecca, 131 lbs, 5'9, 36c, 19 miles away, available Jan 31- Feb 7rd All 4 women are waiting to speak with you live & have photos. Webcam's are= available for all 4. http://godatesoon.com/d/10.php If you have found a lady or not to be paired up then continue. http://godatesoon.com/out/=20 ----4016876913taep4726-- From simple-bounces@ietf.org Fri Feb 4 11:03:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09947; Fri, 4 Feb 2005 11:03:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx6ET-0005DU-JW; Fri, 04 Feb 2005 11:22:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx5sw-00044h-5V; Fri, 04 Feb 2005 11:00:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx5sR-0003kg-9v for simple@megatron.ietf.org; Fri, 04 Feb 2005 11:00:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09653 for ; Fri, 4 Feb 2005 11:00:08 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx6BD-000583-2I for simple@ietf.org; Fri, 04 Feb 2005 11:19:37 -0500 Received: from [192.168.0.103] (c-24-1-68-89.client.comcast.net [24.1.68.89]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j14G032G086924 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 4 Feb 2005 10:00:04 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: Simple WG From: Robert Sparks Date: Fri, 4 Feb 2005 10:00:01 -0600 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [Simple] WG -00s X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Folks - Hisham and I are not expecting any new working group -00 drafts between now and the -00 deadline. If we've managed to not remember something you're working on, send us a note asap. We are expecting a handful of individual submission -00s this time around. Thanks! RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 4 11:16:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11148; Fri, 4 Feb 2005 11:16:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx6RA-0005Si-8L; Fri, 04 Feb 2005 11:36:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx62O-00063V-Mh; Fri, 04 Feb 2005 11:10:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx5xy-00056k-Id for simple@megatron.ietf.org; Fri, 04 Feb 2005 11:05:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10085 for ; Fri, 4 Feb 2005 11:05:51 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx6Gm-0005GC-9U for simple@ietf.org; Fri, 04 Feb 2005 11:25:20 -0500 Received: from [192.168.0.103] (c-24-1-68-89.client.comcast.net [24.1.68.89]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j14G5hDQ087302 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 4 Feb 2005 10:05:44 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <42038993.6050402@cisco.com> References: <41FE9B4C.1070106@cisco.com> <1107242622.26454.54.camel@xitami.research.nokia.com> <41FF3331.8010008@cisco.com> <1107338919.27837.34.camel@xitami.research.nokia.com> <4201C583.7050600@cisco.com> <1107421882.30334.62.camel@xitami.research.nokia.com> <1107496599.31782.22.camel@xitami.research.nokia.com> <42038993.6050402@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Simple] Namespaces and XCAP Date: Fri, 4 Feb 2005 10:05:41 -0600 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: jari urpalainen , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit If you can compile enough things like this, putting them in an informational "Implementer's Guide" draft would be a good thing. RjS On Feb 4, 2005, at 8:41 AM, Jonathan Rosenberg wrote: > inline. > > jari urpalainen wrote: > >> On Thu, 2005-02-03 at 15:48 +0100, ext Hisham Khartabil wrote: >>> (As WG chair) >>> >>> As you know, this draft has gone through WG last call and IETF last >>> call. Unless you have identified show stoppers or bugs in the >>> specification, please accept the consensus that was reached in the >>> WG. >>> >>> It is too late to argue personal taste. >>> >>> Regards, >>> Hisham >> ok, I'll stop whining about the syntax. Just one minor editorial >> comment. Imo, it is worth mentioning in the draft (sorry Jonathan if >> it >> already exists) that if implementations utilize standard xpath or >> xpointer libraries: 1. if the xpath library has "registration" apis >> for namespaces uris and >> prefixes they can be used in location step parsing. >> 2. if the xpath library doesn't support those extensions, i.e. it is >> fully xpath 1.0 compatible, the server/client may have to change the >> location step request from pref:foo to >> *[local-name()="foo"][namespace- >> uri()="uri for pref"] >> 3. if xpointer library is being used in evaluation step parsing the >> evaluation step request has to be changed so that xpath-part is >> encapsulated within xpointer(). > > Generally speaking, this kind of implementation specific guidance is > not something we put in specifications. The APIs tend to evolve and > change, but the RFC is fixed. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 4 15:30:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01920; Fri, 4 Feb 2005 15:30:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxAPF-0002pL-B5; Fri, 04 Feb 2005 15:50:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxA3G-0007OD-QK; Fri, 04 Feb 2005 15:27:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx9zk-000573-EG for simple@megatron.ietf.org; Fri, 04 Feb 2005 15:24:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01194 for ; Fri, 4 Feb 2005 15:23:58 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxAIZ-0002gw-N6 for simple@ietf.org; Fri, 04 Feb 2005 15:43:28 -0500 Received: from razor.cs.columbia.edu (IDENT:U2FsdGVkX1+3yqBp5caDrCVlAYhA64hMclyuOmkSpNY@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j14KNiir000466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Feb 2005 15:23:45 -0500 (EST) Received: from [127.0.0.1] (IDENT:U2FsdGVkX19Z4H9v6xWcB3eTyMGZlIoW8Go4XyKv/QE@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j14KNe0B018983; Fri, 4 Feb 2005 15:23:41 -0500 Message-ID: <4203D9D0.4080704@cs.columbia.edu> Date: Fri, 04 Feb 2005 15:23:44 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat References: <200502021350.IAA03673@ietf.org> <42023AA0.4050008@cs.columbia.edu> <42029D53.8080608@cisco.com> In-Reply-To: <42029D53.8080608@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 81ca0cebdb446e1ff4e2b634791f24a9 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: [Simple] Re: FW: Single tuple or many tuples X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3077fcbbd2d4a1504dfa044ebcf773 Content-Transfer-Encoding: 7bit I agree we don't want yellow pages in presence (and, for the case I mentioned, this wouldn't even help, since all of these would be listed under "airlines"...). I think the sane and simple solution is to use the notes field and possibly an icon hint. Paul Kyzivat wrote: > > > Henning Schulzrinne wrote: > >> I agree that we need a separate dimension for identifying the content >> of media streams or services. This seems orthogonal to capabilities. >> In some cases, there might be a way to enumerate the service in some >> pick-from-list manner, in a MIME-type fashion, in many others this is >> likely to be pretty useless. > > > We have started down this path with: > - attendant > - message-taker > > I always had a feeling this was the beginning of a slippery slope. > > I suppose I could imagine some kind of registry. But I can't quite > imagine what criteria would be used to decide what to name - there would > probably need to be some kind of taxonomy. (This starts to look like the > yellow pages.) > > I'm not convinced we want to go much further down this slope. So far I > think the cases people have made that they need this are pretty weak. > While it is possible to structure your implementation to need this, so > far I think it is also possible to structure things so that isn't needed. > >> Picture the availability for delta.com (the airline), which might >> include services for flight information, international and domestic >> reservations and probably many more. > > > Yup. This is really starting to look like the yellow pages. > > Paul > >> Brian Rosen wrote: >> >>> I don't think we have a prayer of making a Doom game with audio and >>> video >>> streams as well as the game stream work in presence without having a >>> notion >>> of service that has some kind of name which is used to describe the >>> service. >>> That service description can be text as long as it is unique enough >>> that the >>> watcher (client) can render some good enough UI and the watcher (human) >>> understands what to do with it. >>> >>> So if someone defines "Doom" as being a service that has a game >>> stream and >>> optional audio and video streams, then you can build a watcher that >>> understands what Doom is and render a very nice interface with, say, >>> a Doom >>> icon, and a basic watcher can show the name of the service and the media >>> streams on it that a human can interpret it. I think we all agree >>> that, at >>> the very least, the presence of the Doom service is contained in one >>> tuple. >>> The only thing you really would like to understand about service is >>> name and >>> the fact that it can contain multiple streams and multiple >>> capabilities. I don't think you can infer this notion of service from >>> the aggregate of >>> capabilities, and I don't want to try. You can DEFINE a service as >>> having >>> some fixed and optional capabilities with the watcher being able to >>> discover >>> which of them a particular presentity has available at a point in time. >>> That we can do. So don't guess that audio and/or video with half >>> duplex and >>> floor control MEANS PTT, instead DEFINE PTT as a service that has audio, >>> optional video, half duplex and floor control and let a tuple state >>> that the >>> presentity supports a PTT service and at the present time only has audio >>> (not video) available. >>> Then I can offer a Telephone service and Doom service, both of which >>> support >>> audio, and we won't get anyone confused. >>> >>> Brian >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Tuesday, February 01, 2005 1:51 PM >>>> To: Brian Rosen >>>> Cc: 'Aki Niemi'; 'Simple WG' >>>> Subject: Re: Single tuple or many tuples (was: Re: [Simple] another try >>>> atdata model compromise regarding unique service URI) >>>> >>>> Brian - inline. >>>> >>>> Paul >>>> >>>> Brian Rosen wrote: >>>> >>>>> I've pretty much stayed out of this whole set of threads, but this one >>>>> really had me wondering where everyone's head is again. >>>>> >>>>> We're getting wrapped around the axle of not having a definition of >>>>> "service" again. >>>> >>>> >>>> >>>> Well, we had decided that a service is whatever a tuple describes. >>>> But functionally I agree it has still not really been resolved. >>>> >>>> >>>>> Specifically, I believe that the Doom case you describe below is a >>>> >>>> >>>> >>>> Service >>>> >>>>> called Doom that has a number of media streams it supports. It >>>>> does NOT >>>>> offer a voice SERVICE, the DOOM service includes game, audio and video >>>> >>>> >>>> >>>> media >>>> >>>>> capability. >>>> >>>> >>>> >>>> I infer that you are using "service" to denote what kind of >>>> functionality is provided via the communication channel(s) described. >>>> >>>> So in this case there is an automaton executing the Doom game, >>>> providing >>>> a rendering of that via the output streams, and accepting input to it >>>> via the input streams. >>>> >>>> >>>>> Now the TUPLE might offer a voice SERVICE, in addition to Doom, >>>>> possibly >>>>> using the same hardware, possibly not. You don't care. >>>> >>>> >>>> >>>> We currently have no definition of, or way to describe, services >>>> such as >>>> these. The closest we can get to this right now is via a few >>>> attributes: >>>> >>>> - automaton >>>> - attendant >>>> - message-taker >>>> >>>> If all of those are false, in absence of any extentions, I think you >>>> have a "conversational" service facilitating interactive conversation >>>> with a human being. >>>> >>>> Even with the limited range of "service"s that can be represented via >>>> those attributes, it is impossible to say in a single tuple that you >>>> have a conversational service and an automated message taking service, >>>> except in the negative - by saying nothing about what is provided. >>>> >>>> >>>>> PTT is a SERVICE. It supports voice, possibly video and has floor >>>> >>>> >>>> >>>> control. >>>> >>>> From what I have inferred above, I don't see how this can be considered >>>> a service. It says nothing about the content, and its not an automaton. >>>> It simply provides different ways to control the media in a >>>> conversational session - like a different codec does. >>>> >>>> >>>>> But there is nothing in the set of capabilities such as: audio=true, >>>>> video=false, duplex=full, floor-control=false that could possibly >>>> >>>> >>>> >>>> indicates >>>> >>>>> PTT isn't there. A dumb but straightforward audio conference phone >>>> >>>> >>>> >>>> could >>>> >>>>> have exactly the same capabilities. The dumb conference phone could >>>> >>>> >>>> >>>> have >>>> >>>>> that also. The "floor control=true" and "duplex=half" >>>>> capabilities, in >>>>> particular, are not peculiar to PTT. A cell phone with PTT today >>>>> would >>>> >>>> >>>> >>>> have >>>> >>>>> at least two services (voice and PTT). Today, those services are >>>> >>>> >>>> >>>> separate; >>>> >>>>> even the voice path is separate in many implementations. >>>> >>>> >>>> >>>> Why is this any different than audio vs video? I might want to have a >>>> conversation with you using any of those, and switch back and forth >>>> between them during the call. I think I know the answer, but its not an >>>> appealing one - the UA will simply not permit mixing the >>>> capabilities in >>>> a single call, or even switching among them serially within a call. Of >>>> course there are lots of technological excuses for this, but it >>>> makes no >>>> real sense from a user standpoint. >>>> >>>> I can at least imagine using PTT to talk to a VM "service" or auto >>>> attendant "service". This all suggests to me that PTT is not a service >>>> in the sense that Doom might me. >>>> >>>> The PTT case is, I think, just a matter of wanting a way to describe >>>> mutually exclusive combinations of capabilities. I believe we agreed >>>> some weeks ago that this was potentially still of interest, but >>>> postponed dealing with it. Until then, multiple tuples with the same >>>> contact provides a way at the expense of being ambiguous about what is >>>> intended. >>>> >>>> I have been trying for years now to understand what you "service" >>>> oriented people are talking about. It always seems like there is >>>> *something* there, but its elusive, and you don't all seem to have the >>>> same concept. I think there may be some opportunity to describe this as >>>> the behavior behind the media, encompassing VM, Attendant, Doom. >>>> >>>> >>>>> And please keep in mind that I want to be able to offer a presence >>>> >>>> >>>> >>>> service >>>> >>>>> with ONE contact, which I assumed was one tuple, but don't care if >>>>> there >>>> >>>> >>>> >>>> are >>>> >>>>> multiple tuples as long as they have the same contact URI. That >>>> >>>> >>>> >>>> represents >>>> >>>>> the presence information of the presentity, full stop, including >>>>> all of >>>> >>>> >>>> >>>> the >>>> >>>>> services it might support. >>>> >>>> >>>> >>>> You have been quiet for so long now that I thought you had got the >>>> correct religion, or fallen asleep, or something. :-) >>>> >>>> If you are going to offer a single tuple, and hide both a >>>> conversational >>>> voice service and Doom behind it, I don't see how you are going to >>>> avoid >>>> disappointing someone. Somebody is going to end up on their phone >>>> talking to a doom game. >>>> >>>> >>>>> Brian >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >>>>>> Behalf >>>>>> Of Paul Kyzivat >>>>>> Sent: Tuesday, February 01, 2005 9:58 AM >>>>>> To: Aki Niemi >>>>>> Cc: Simple WG >>>>>> Subject: Re: Single tuple or many tuples (was: Re: [Simple] >>>>>> another try >>>>>> atdata model compromise regarding unique service URI) >>>>>> >>>>>> >>>>>> >>>>>> Aki Niemi wrote: >>>>>> >>>>>> >>>>>>> ext Paul Kyzivat wrote: >>>>>>> >>>>>>> ...snip... >>>>>>> >>>>>>> >>>>>>> >>>>>>>> For devices with the real estate, it would be better to simply >>>>>>>> display >>>>>>>> multiple icons for each buddy indicating what capabilities are >>>>>>>> currently available. (Perhaps icons of phones and cameras can turn >>>>>>> >>>>>>> >>>>>>> >>>>>>>> from red to green.) >>>>>>> >>>>>>> >>>>>>> >>>>>>> I don't buy this. Think of a "doom" icon that can be either red, >>>>>>> green, >>>>>>> or indicate deathmatch. Capabilities are uninportant, it's the >>>>>>> service >>>>>>> that is composed of those capabilities that is important. >>>>>> >>>>>> >>>>>> >>>>>> I don't understand your point at all. >>>>>> >>>>>> It seems to me that either: >>>>>> >>>>>> - you have a separate tuple/service for Doom, with its own unique >>>>>> contact that I can call. In this case doom itself may have >>>>>> "doom" capability, and perhaps audio, video, etc. as well. >>>>>> >>>>>> you then have other contacts with differing sets of capabilities >>>>>> and different contact addresses. Perhaps one with basic voice. >>>>>> >>>>>> - you have a single multipurpose tuple/service. It has capabilities >>>>>> for voice, and maybe doom as well. >>>>>> >>>>>> - you have multiple tuples - one for doom, another for basic voice, >>>>>> but they share a contact address. >>>>>> >>>>>> The question is, how do I know what to expect when making a call >>>>>> in each >>>>>> case? E.g. if I make a voice-only call, do I talk to you, or do I >>>>>> hear >>>>>> the audio from a doom game I can't control? >>>>>> >>>>>> I guess it depends a bit on how you expect doom to work. Do you >>>>>> imagine >>>>>> it to consist of a game control protocol plus audio and video streams >>>>>> rendering the game? >>>>>> >>>>>> >>>>>> >>>>>>> And do you really think users will generally be happy to >>>>>>> interpret that >>>>>>> someone is available for push-to-talk by examining a set of three >>>>>>> (or >>>>>>> more) icons? >>>>>> >>>>>> >>>>>> >>>>>> I see a couple of alternatives here: >>>>>> >>>>>> - the user has a PTT application displaying presence. It is only >>>>>> interested in PTT, so it filters what it displays. All I get is a >>>>>> list of buddies with red or green status. >>>>>> >>>>>> - the user has a general purpose presence client, that can do PTT, >>>>>> regular voice, video, Doom, whatever. (The user has to both pick >>>>>> a buddy and then pick an action to do something.) >>>>>> >>>>>> In this case, it has three or more things to display regardless >>>>>> of how the RPID document is formatted. Either it has multiple >>>>>> capabilities for a single tuple, or it has multiple tuples each >>>>>> with (potentially multiple) capabilities. There are many ways >>>>>> of rendering each of these, but the fundamental complexity of >>>>>> what is to be rendered is pretty much the same. >>>>>> >>>>>> >>>>>> >>>>>>>> You seem to have in mind a "video service" that includes both voice >>>>>>>> and video, and a separate "audio service" that includes only audio. >>>>>>>> And then either or both can be available. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I gave an example of *three* different services. But fine, let's say >>>>>> >>>>>> >>>> >>>> you >>>> >>>>>>> only have two: a videophone capable of both video and audio >>>>>>> (together >>>>>> >>>>>> >>>> >>>> or >>>> >>>>>>> separate) and a push-to-talk client (audio, half-duplex and floor >>>>>>> control). Now, let's say video is unavailable, audio is >>>>>>> available, and >>>>>>> push-to-talk is unavailable. >>>>>>> >>>>>>> How would you represent that in a single tuple? >>>>>> >>>>>> >>>>>> >>>>>> I left out the PTT to keep things simple, since I don't think we have >>>>>> agreed in detail how to represent it as a capability. But lets try >>>>> >>>>> >>>> >>>> anyway. >>>> >>>>>> In the state you describe it, I would simply represent it as a tuple >>>>>> with audio=true, video=false, duplex=full, floor-control=false. >>>>>> What is >>>>>> so hard about that? >>>>>> >>>>>> >>>>>> >>>>>>>> But how is this better (or even as good as) a single videophone >>>>>>>> service that is capable of supporting both voice and video, or just >>>>>>>> voice, or just video, depending on what is negotiated in a call? >>>>>>>> With >>>>>>>> such a service, if I don't want to be available for video, I just >>>>>>>> disable it, so it won't be offered or answered, and then video then >>>>>>>> isn't advertised in the (single) presence tuple either. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I'm not going to debate over details about voice and/or video. My >>>>>>> attempt was to demonstrate that there are "services" that aren't >>>>>>> going >>>>>>> to be described only using a single, simple media attribute, like >>>>>>> "voice" and "video", but will be composed of a set of capabilities, >>>>>>> where this capability set then shares a status that will have more >>>>>>> states available than simple on or off. >>>>>> >>>>>> >>>>>> >>>>>> Ahh. This may be hinting at the real issue. But it is only a hint, >>>>>> and I >>>>>> think you need to say a lot more to establish the use case. I've >>>>>> got a >>>>>> feeling that PTT is a bad example because its "differences" are more >>>>>> about limitations in the technology that intrinsic feature >>>>>> differences. >>>>>> >>>>>> I suspect Doom may be a better example. I have the idea that what you >>>>>> have in mind is that when I call the "Doom Service" I get audio and >>>>>> video that are slaved to the game, rather than a conversational >>>>>> adjunct >>>>>> to the game that allows me to converse with the other player(s) while >>>>>> playing. If so, then it is a lot like an IVR or a VM server. If >>>>>> so, then >>>>>> I agree with you that it *should* be represented as a separate tuple. >>>>>> But I also think it *should* have a separate contact, so that it is >>>>>> clear how to reach that particular service. >>>>>> >>>>>> I gather you have in mind that if I negotiate the doom control >>>>>> protocol >>>>>> I will get the doom service and the audio/video will be slaved to it, >>>>>> but if I don't negotiate the doom control protocol then I get the >>>>>> "conversational" service managing my voice/video. I don't see why I >>>>>> would be able to draw that conclusion from the RPID. >>>>>> >>>>>> >>>>>> >>>>>>> However, stepping back for a moment. >>>>>>> >>>>>>> Seems there is still some fundamental desire here to restrict the >>>>>>> presence data model to suit the "unique-URI" concept. >>>>>>> >>>>>>> But like Henning has pointed out many times before, there will be >>>>>>> multiple tuples in a document. So inherently, the watcher is >>>>>>> faced with >>>>>>> having to make a selection. Henning has also pointed out that to >>>>>>> determine uniqueness, the contact is a very poor key to use. Whether >>>>>>> some of those tuples have the contact address is therefore >>>>>>> immaterial >>>>>>> (and depends exclusively on the uniqueness rules of the URI scheme). >>>>>>> Also, we aren't going to forbid a dumb composer passing all of the >>>>>>> received tuples to the watcher using the union composition. >>>>>> >>>>>> >>>>>> >>>>>> In most cases I see no reason why the watcher has a need to determine >>>>>> uniqueness. All it has to do is present the alternatives to the user, >>>>>> let the user choose one, and send a request to the contact of the one >>>>>> chosen. The kind of request sent can either be determined by default >>>>>> based on capabilities advertised in the tuple and local >>>>>> capabilities, or >>>>>> can be adjusted based on explicit choices made by the user. >>>>>> >>>>>> >>>>>> >>>>>>> If we were to *mandate* that all SIP-enabled services are >>>>>>> represented >>>>>>> using a single tuple, where would you enforce this rule? And what >>>>>>> would >>>>>>> be the benefit compared to allowing more than a single tuple? >>>>>> >>>>>> >>>>>> >>>>>> I'm not sure this is something to mandate. I think it is more of a >>>>>> "best >>>>>> practices" kind of thing. It seems clear that people are going to >>>>>> do a >>>>>> bunch of weird things, and results will vary. About all we can do is >>>>>> give suggestions on how to get a good result. >>>>>> >>>>>> >>>>>> >>>>>>> Simply saying that it is possible in some instances to do things >>>>>>> that >>>>>>> way is not a good enough reason, if there are instances where it >>>>>>> does >>>>>>> not work. >>>>>> >>>>>> >>>>>> >>>>>> I think this might best be approached by restarting the work on >>>>>> presence >>>>>> use cases. >>>>>> >>>>>> Here is (a bad) one, based on what I think you have in mind. (Please >>>>>> feel free to provide a better way to handle this case.) >>>>>> >>>>>> Suppose your presence includes one tuple listing audio, video, and >>>>>> doom. >>>>>> My presence client doesn't understand doom or video, so it simply >>>>>> renders the tuple as available for voice. I pick it and make a voice >>>>>> call. Your Doom service slaves audio to the game, so I just hear a >>>>>> bunch >>>>>> of bleeps and gun fire. I am likely to be annoyed with you for having >>>>>> announced that you were available for voice when you were not. >>>>>> >>>>>> Or, your UA refused my call because I didn't offer doom control >>>>>> protocol. I'm still annoyed that you said you were available for >>>>>> voice >>>>>> but refused my call. (But at least this is within the realm of >>>>>> reasonable behaviors.) >>>>>> >>>>>> Paul >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Simple mailing list >>>>>> Simple@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 4 17:43:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15195; Fri, 4 Feb 2005 17:43:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxCTc-0006oM-Vt; Fri, 04 Feb 2005 18:03:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxC6t-00009E-GF; Fri, 04 Feb 2005 17:39:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxC61-0008Gg-89 for simple@megatron.ietf.org; Fri, 04 Feb 2005 17:38:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14877 for ; Fri, 4 Feb 2005 17:38:34 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxCOr-0006gG-1G for simple@ietf.org; Fri, 04 Feb 2005 17:58:07 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 04 Feb 2005 14:47:40 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j14Mc0oQ004777; Fri, 4 Feb 2005 14:38:01 -0800 (PST) Received: from cisco.com ([161.44.79.129]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOW37869; Fri, 4 Feb 2005 17:37:59 -0500 (EST) Message-ID: <4203F947.6050006@cisco.com> Date: Fri, 04 Feb 2005 17:37:59 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Subject: Re: [Simple] About change in authorization policy References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, Markus.Isomaki@nokia.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Content-Transfer-Encoding: 7bit (retrying - had trouble first time) Jeffrey wrote: > Hi Paul, > > Thanks very much for your response. >>From my point of view, according to the statement of the 16th page in RFC > 3265, > > rejected: The subscription has been terminated due to change in > authorization policy. Clients SHOULD NOT attempt to > re-subscribe. > The "retry-after" parameter has no semantics for "rejected". > > So I assume that when a presentity blocks some watcher who was granted > before, the Notifier regards this event as authorization policy change and > replies to the Subscribe request with the "Subscription-State" value being > "terminated". Do you think it is better to notify subscriber with the > "Subscription-State" value being "pending" rather than "terminated"? But if > I consider the statements in the section 3.2.2 in RFC 3265, > > The "pending" value > indicates that the subscription has been received, but that > policy > information is insufficient to accept or deny the subscription > at > this time. > > It seems the value of "pending" doesn't be suitable for such situation > because "block" should imply to deny the subscription. Am I wrong? This is all a bit subjective - there are different ways to approach it and/or rationalize a particular way of responding. If the access policy is changed so that someone with an active subscription is no longer permitted to have one, then I think "rejected" is the right status to send. Terminated is wrong, because that means the subscription is over but another is probably still ok. In that case, I think the SHOULD NOT re-subscribe applies most directly to the subscribing UAC, so it shouldn't *automatically* try to resubscribe. However I think the user associated with that UAC is free to instruct the UAC to try again. This of course is what you want to avoid - the annoying human interactions. However, the whole pending status mechanism depends on authorization being at least tri-state: authorized, forbidden, unspecified. So, instead of kicking the subscriber off by changing access to forbidden, you could just change it to unspecified. Then, that change could cause a terminated response to the old subscription, and a retry could go into pending. Or you could short circuit that and just transition the existing subscription to pending state. Paul > BR, > Jeffrey > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, February 01, 2005 12:44 AM > To: hocs@itri.org.tw > Cc: jdrosen@cisco.com; Markus.Isomaki@nokia.com; 'simple@ietf.org'; 'Markus. > Isomaki@nokia.com' > Subject: Re: [Simple] About change in authorization policy > > > > hocs@itri.org.tw wrote: > >>Hi all, >> >>I am afraid that I might miss something or not capture your focus. I >>just wonder if revising the authorization rule document is enough for >>solving this problem. I would like to emphasize a point that when a >>subscription state at Notifier become 'terminated' due to authorization > > change (e.g. > >>presentity block some watcher), this subscription will never be >>re-active even the presentity changes his mind to do the unblock >>action later. This will result in a problem that watcher can't be >>notified of presence information except the watcher re-subscribe >>again. I wonder if it is possible to add a new subscription state of >>"forbidden" for this purpose, so that a subscription state can be from >>"active" to "forbidden" and have a chance to go back to "active" in case. >>Thanks. > > > If you want to keep the subscription active, you already have two options: > > - just leave it active, but change the filter criteria so you don't tell > the watcher much > > - change the state to pending, and then don't tell the watcher much. > > These seem sufficient to handle the case - why do you need yet another > state? > > Paul > > >>BRs, >>Jeffrey >> >> >>-----Original Message----- >>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On >>Behalf Of Jonathan Rosenberg >>Sent: Friday, January 21, 2005 10:07 AM >>To: Paul Kyzivat >>Cc: simple@ietf.org; Markus.Isomaki@nokia.com >>Subject: Re: [Simple] About change in authorization policy >> >>inline. >> >>Paul Kyzivat wrote: >> >> >> >>>Markus.Isomaki@nokia.com wrote: >>> >>> >>> >>>>Paul, >>>> >>>>I think there is at least one realistic case where what Jeffrey >>>>brought up causes some trouble. >>>>If value is used to influence the authorization decisions, >>>>i.e. different authorization rules apply when sphere=="home" than >>>>sphere=="work", the allowed vs. forbidden state for a particular >>>>subscriber could very well change at least twice a day. If that >>>>subscriber wants to be constantly subscribed to presence whenever it >>>>is allowed, she would have to do some polling. For instance if >>>>someone forbids her boss to subscribe while she is not working, the >>>>boss would not know when to subscribe again after the previous >>>>subscription was terminated. >>>> >>>>This makes me think that the recommended way to use should >>>>be not to make it affect the subscription state, but just the >>>>content, perhaps using polite blocking. >>> >>> >>>Yes. This falls into the category of "if it hurts, don't do it". In >>>this case, you may not want your boss bothering you while you are not >>>working, but you probably don't want to piss off your boss. >> >> >>I concur here as well. I think this issue has been raised in the past >>as a general concern around using presence state itself as a condition >>for subscription acceptance/rejection. However, I will note that the >>same issues arise for any decision based on dynamic data, such as time of > > day. > >> >> >> >>>>If we don't come up with any other fix to this, I think at least this >>>>issue should be written in a relevant section of the presence-rules RFC. >>> >>> >>>This sounds like a different document - a best practices for presence. >> >> >>I don't think it could hurt to mention this in the authorization rules >>document. I'll do that. >> >>-Jonathan R. >> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 >>Cisco Systems >>jdrosen@cisco.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.cisco.com >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> >> >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From wqsodxdhdiog@bellsouth.net Sun Feb 6 03:32:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03005; Sun, 6 Feb 2005 03:32:41 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cxi9d-0003Xf-EZ; Sun, 06 Feb 2005 03:52:30 -0500 Received: from modemcable142.111-130-66.mc.videotron.ca ([66.130.111.142]) by mx2.foretec.com with smtp (Exim 4.24) id 1CxhqS-0007j8-Lr; Sun, 06 Feb 2005 03:32:41 -0500 Received: from lehigh-dns.optonline.com (220.132.78.235) by s9-coq2.optonline.com with Microsoft SMTPSVC(5.0.2195.6824); Sun, 06 Feb 2005 03:33:09 -0500 Date: Sun, 06 Feb 2005 12:27:09 +0400 (CST) Message-Id: <1249646381.wuz5ATiP768@solo06.advisory19optonline.com> To: simple-archive@ietf.org Subject: Whiter teeth in just two weeks From: Teeth whitening MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--jslpfteebzwzdeb491040352518119acknf" X-Spam-Score: 15.8 (+++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b ----jslpfteebzwzdeb491040352518119acknf Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Pearly Whites Teeth Whitening Kit Want a Perly White Smile.? whiter teeth in just two weeks http://www.thenetbiz.info Want a professional quality teeth whitening, But Dentists charges in excess of $300 for this product. Now you can get-Pearly Whites, which is the most powerful at-home teeth whitening system available for a= ppox 10% of Market price, and is exactly the same system used in professio= nal dental offices. Spend a few minutes with us and discover how to whiten your teeth and brig= hten your smile. http://www.thenetbiz.info As a bonus, we offer cash incentives for referring your friends and family= to our product! Get-Pearly Whites Today.. Dont want Pearly Whites http://www.thenetbiz.info/r ----jslpfteebzwzdeb491040352518119acknf-- From Ware@awemail.com Sun Feb 6 09:39:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26248; Sun, 6 Feb 2005 09:39:33 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cxnsg-0006ha-LV; Sun, 06 Feb 2005 09:59:25 -0500 Received: from [69.65.131.42] (helo=SANTIAGO) by mx2.foretec.com with smtp (Exim 4.24) id 1CxnZK-0007iq-KN; Sun, 06 Feb 2005 09:39:28 -0500 Received: from [131.204.75.178] by may%DIGITS.autotransformer.69.65.131.42 via HTTP; Sun, 06 Feb 2005 09:38:15 -0800 Reply-To: "mail2world.com" From: "mail2world.com" To: Subject: Heyyy,, me again Date: Sun, 06 Feb 2005 09:38:15 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9233949790dltz8200" Message-Id: X-Spam-Score: 3.6 (+++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c ----9233949790dltz8200 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable I just wanted to know if you would like to accompany me. My Husband works night shifts, which makes me very lonely at night. To contact me please go here: http://www.godatesaturday.com/d/1.php P.S. it's me Katherine t ----9233949790dltz8200-- From Puckett@mailAccount.com Sun Feb 6 18:23:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08257; Sun, 6 Feb 2005 18:23:06 -0500 (EST) Message-Id: <200502062323.SAA08257@ietf.org> Received: from [211.38.24.17] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cxw3S-0000Lh-E3; Sun, 06 Feb 2005 18:43:04 -0500 Received: from [53.76.144.149] by delaware%DIGITS.mason.211.38.24.17 via HTTP; Sun, 06 Feb 2005 18:22:32 -0800 Reply-To: "w Fields Inc." From: "w Fields Inc." To: Subject: Four beautiful matches Date: Sun, 06 Feb 2005 18:22:32 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--7818843804vwvb3977" X-Spam-Score: 5.6 (+++++) X-Spam-Flag: YES X-Scan-Signature: 93238566e09e6e262849b4f805833007 ----7818843804vwvb3977 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable 4 Cheating House Wife have been matched for you in your area: 1) Amber, 127 lbs, 5'5, 36c, 14 miles away, available most week nights ( l= ooking for side-fling) 2) Amber, 130 lbs, 5'9, 36d, 5 miles away, available Jan29-31th 3) Kayla, 125 lbs, 5'6, 34b, 13 miles away, available Jan 31- Feb 3rd 4) Alexis, 120 lbs, 5'5, 36c, 9 miles away, available Jan29-31th All 4 women are waiting to speak with you live & have photos. Webcam's are= available for all 4. http://www.godatequickly.com/d/10.php If you have found a lady or not to be paired up then continue. http://godatequickly.com/out/=20 ----7818843804vwvb3977-- From simple-bounces@ietf.org Sun Feb 6 22:06:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24211; Sun, 6 Feb 2005 22:06:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxzXz-0004R8-LP; Sun, 06 Feb 2005 22:26:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxzDK-0000eA-Tz; Sun, 06 Feb 2005 22:05:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxzD2-0000ZH-Mt for simple@megatron.ietf.org; Sun, 06 Feb 2005 22:05:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24092 for ; Sun, 6 Feb 2005 22:05:06 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxzWJ-0004PG-9O for simple@ietf.org; Sun, 06 Feb 2005 22:25:05 -0500 Received: from razor.cs.columbia.edu (IDENT:U2FsdGVkX18NhqnmQxLP2qQONctJipaJdwbExiZVzdM@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j17352ir001816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 6 Feb 2005 22:05:03 -0500 (EST) Received: from [127.0.0.1] (IDENT:U2FsdGVkX1+Bu4O/1EnG6PdtB9isKeTGjgVBLI9PKQg@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j17352Bo003869 for ; Sun, 6 Feb 2005 22:05:02 -0500 Message-ID: <4206DADF.4060708@cs.columbia.edu> Date: Sun, 06 Feb 2005 22:05:03 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Subject: [Simple] Three dimensions of service X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit I think it might be helpful to dis-entangle describing a service into (at least) three dimensions: (D1) Protocol and network capabilities, describing what is necessary so that two devices can exchange messages. This encompasses most of prescaps. Knowing this won't guarantee that the service does what a human expect. For example, a user might be surprised to be connected to a robot when expecting a human to answer. (D2) Interaction capabilities: how does the service act - is it a human? does it only announce or only record? This applies across a range of protocols and media. (D3) Content - what gets conveyed by the media exchange. Am I talking to a flight reservation system or a Doom character or the game audio background music? This clarly applies to a range of media, protocol capabilities and even interaction styles. (Flight information can be delivered by a human or multiple kinds of robots.) PTT is mostly a media signaling and floor control mechanism and doesn't really affect D2 and D3. There seems to be some hierarchy, with D1 as the lowest level, but I don't think that particularly matters for the discussion. In some cases, only one or two of the three dimensions may be known or relevant. D1 and D2 seem to be more amenable to enumeration, while it seems to require a full-blown ontology to do justice to D3, so that we may simply have to live with free text and maybe rendering hints (e.g., icons). A service tuple should have a unique combination of these dimensions, which includes the "I don't know", "can be any one of a subset of them - call and you'll find out" and "I won't tell you" cases for any one of them. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From ojgjwbr.MHXPY@kmfi.com Sun Feb 6 23:48:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00202; Sun, 6 Feb 2005 23:48:25 -0500 (EST) Message-Id: <200502070448.XAA00202@ietf.org> Received: from [222.97.202.49] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cy18F-0006Fw-Sw; Mon, 07 Feb 2005 00:08:26 -0500 Received: from terminalr6.jewishchickenranchers.com (222.97.202.49) by 222.97.202.49 (MediaMailer 007) with SMTP id <3935E2u>; Sun, 06 Feb 2005 22:43:08 -0600 Reply-To: "christa odey" From: "christa odey" To: cna@ietf.org Cc: simple-archive@ietf.org, imrg-request@ietf.org, seamoby-web-archive@ietf.org, pim-request@ietf.org, asrg@ietf.org, rpsec@ietf.org, ips@ietf.org, iab-wireless-workshop@ietf.org, ietf-action@ietf.org, ietf-info@ietf.org, owner-ietf-announce@ietf.org Subject: Goods News. Application was accepted Date: Mon, 07 Feb 2005 05:45:08 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--5548779_0849310.jE8299" X-Spam-Score: 16.7 (++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 ----5548779_0849310.jE8299 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Hello Account #8737493, We tried contacting you awhile ago about your low interest mort[g]age rate. You have qualified for the lowest rate in years. You could get over $400,000 for as little as $300 a month! Have Bad cr[e]dit? No Problem! Low rates are fixed no matter what. To get a free, no obligation consultation please visit: http://ahoy.wexvd.info:443/azwmlcotyledon Regards, christa odey, Account Manager JNM Associates Inc. r*mv. -> http://assassin.wexvd.info:443/index.php ----5548779_0849310.jE8299-- From simple-bounces@ietf.org Mon Feb 7 09:32:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03324; Mon, 7 Feb 2005 09:32:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyAFk-0001nr-5t; Mon, 07 Feb 2005 09:52:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy9uG-0000qz-BN; Mon, 07 Feb 2005 09:30:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy9rl-0000NG-1a for simple@megatron.ietf.org; Mon, 07 Feb 2005 09:27:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02924 for ; Mon, 7 Feb 2005 09:27:50 -0500 (EST) Message-Id: <200502071427.JAA02924@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyAB9-0001iE-75 for simple@ietf.org; Mon, 07 Feb 2005 09:47:56 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1Cy9rh-0001dp-Lv; Mon, 07 Feb 2005 08:27:49 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Simple WG'" Subject: RE: [Simple] Three dimensions of service Date: Mon, 7 Feb 2005 09:27:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <4206DADF.4060708@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUMwhEZJBaj3I91RCyXqoBlKfhr/wAXPzPg X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Henning I'm not sure I understand the difference between D2 and D3, unless you somehow think that D2 can be specified in some way that without additional knowledge you can automatically determine how to interact with it. I think there are only two dimensions: D1, which are those characteristics that a service has that map into defined protocol mechanisms D2, which are those characteristics that a service has that don't map into precise SIP/SIMPLE protocol mechanisms and depend more on the specification of the service itself I think you can enumerate services defined by D2 characteristics, and you can have a specification for each of them that defines how they work, but that's about it. I think that's sufficient. For presence, we need a registry, and nothing else. For D1, we have prescaps, as you observe. I think that's enough, but I think we need a notion of service and a registry of services so that a presentity and its watchers have the same characteristics in mind when they see the service in the tuple. With respect to PTT, you can argue all you want about whether there is some kind of generic meaning to PTT, but I claim it doesn't matter; no one will ever precisely define it, and no one needs a generic PTT to be defined. The OMA guys can define their version of PTT, and someone else could define their own notion of PTT. I don't want someone trying to guess what the combination of, say, half duplex and floor control implies. It implies nothing other than there is a floor and the media streams are half duplex. Brian > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Henning Schulzrinne > Sent: Sunday, February 06, 2005 10:05 PM > To: Simple WG > Subject: [Simple] Three dimensions of service > > I think it might be helpful to dis-entangle describing a service into > (at least) three dimensions: > > (D1) Protocol and network capabilities, describing what is necessary so > that two devices can exchange messages. This encompasses most of > prescaps. Knowing this won't guarantee that the service does what a > human expect. For example, a user might be surprised to be connected to > a robot when expecting a human to answer. > > (D2) Interaction capabilities: how does the service act - is it a human? > does it only announce or only record? This applies across a range of > protocols and media. > > (D3) Content - what gets conveyed by the media exchange. Am I talking to > a flight reservation system or a Doom character or the game audio > background music? This clarly applies to a range of media, protocol > capabilities and even interaction styles. (Flight information can be > delivered by a human or multiple kinds of robots.) > > PTT is mostly a media signaling and floor control mechanism and doesn't > really affect D2 and D3. > > There seems to be some hierarchy, with D1 as the lowest level, but I > don't think that particularly matters for the discussion. In some cases, > only one or two of the three dimensions may be known or relevant. > > D1 and D2 seem to be more amenable to enumeration, while it seems to > require a full-blown ontology to do justice to D3, so that we may simply > have to live with free text and maybe rendering hints (e.g., icons). > > A service tuple should have a unique combination of these dimensions, > which includes the "I don't know", "can be any one of a subset of them - > call and you'll find out" and "I won't tell you" cases for any one of > them. > > Henning > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 7 10:01:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05346; Mon, 7 Feb 2005 10:01:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyAi3-0002Mz-DX; Mon, 07 Feb 2005 10:21:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyAIU-0004ft-2M; Mon, 07 Feb 2005 09:55:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyAIJ-0004Zy-BD for simple@megatron.ietf.org; Mon, 07 Feb 2005 09:55:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05023 for ; Mon, 7 Feb 2005 09:55:17 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyAbi-0002GG-5P for simple@ietf.org; Mon, 07 Feb 2005 10:15:23 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j17EtFJ19586 for ; Mon, 7 Feb 2005 16:55:15 +0200 (EET) X-Scanned: Mon, 7 Feb 2005 16:54:39 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j17Esdb1002743 for ; Mon, 7 Feb 2005 16:54:39 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 0045UlNb; Mon, 07 Feb 2005 16:54:29 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j17EsTx09834 for ; Mon, 7 Feb 2005 16:54:29 +0200 (EET) Received: from agni.research.nokia.com ([172.21.50.36]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 7 Feb 2005 16:53:44 +0200 Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.11/8.12.11) with ESMTP id j17EreV9021747 for ; Mon, 7 Feb 2005 16:53:40 +0200 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.11/8.12.11/Submit) id j17Ere9X021746; Mon, 7 Feb 2005 16:53:40 +0200 To: simple@ietf.org X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi Date: Mon, 07 Feb 2005 16:53:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 07 Feb 2005 14:53:44.0397 (UTC) FILETIME=[D20CDFD0:01C50D24] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Simple] Case-sensitiviness in MSRP ABNF X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Hello all, Here are some issues with case-sensitiviness of MSRP ABNF that might warrant some clarifications in spec. I'd like to mention explicitly in section 9 that tokens are case-insensitive. Section 6.2 defines the URL comparison. It would be nice to mention that and are matched case-insensitive. --Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 7 10:09:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06124; Mon, 7 Feb 2005 10:09:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyApa-0002XD-CV; Mon, 07 Feb 2005 10:29:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyAV4-0008HI-8G; Mon, 07 Feb 2005 10:08:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyAT7-0007YS-SJ for simple@megatron.ietf.org; Mon, 07 Feb 2005 10:06:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05723 for ; Mon, 7 Feb 2005 10:06:27 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyAmW-0002ST-Is for simple@ietf.org; Mon, 07 Feb 2005 10:26:33 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 07 Feb 2005 07:16:02 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j17F5nuC028578; Mon, 7 Feb 2005 07:05:50 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-29.cisco.com [10.86.240.29]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHO28354; Mon, 7 Feb 2005 07:05:52 -0800 (PST) Message-ID: <420783D0.7090700@cisco.com> Date: Mon, 07 Feb 2005 10:05:52 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg References: <41FE9B4C.1070106@cisco.com> In-Reply-To: <41FE9B4C.1070106@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: Simple WG Subject: [Simple] Re: Namespaces and XCAP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit While working through the text, and based on some comments Jari made, I have a variation on option 5 which might be better still: Jonathan Rosenberg wrote: > 5. Allow namespace bindings to be definde in the XCAP URI itself > > In this approach, bindings between namespace prefixes and namespace URI > are present in the xcap URI itself. The xpointer xmlns specification > (http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325/) provides a way to > define these. As an example of how this might work: > > http://xcap.example.com/services/resource-lists/users/bill/fr.xml/~~/ > xmlns(foo="http://foo.example.com")/ > resource-lists/list%5b@name=%22friends%22%5d/entry/foo:street-address > > > In other words, right after the ~~ delimiter, the next path segment is > actually a namespace definition, binding the namespace prefix "foo" to > the URI "http://foo.example.com". That prefix is then used later on in > the URI. > > The only question is where in the URI to place these definitions. Again, > we only have so many choices that I can see: > > CHOICE A: immediately after the ~~/, in the next path segment, which > would contain all such definitions as xmlns xpointer expressions. > > CHOICE B: anywhere in the URI, as a separate path segment > > CHOICE C: as part of a path segment that corresponds to an element, > attribute or document CHOICE D: as part of a query string We had a thread previously based on Lisa's comments about using the query string for the WHOLE xpath expression. I still think that is a fundamental change to the architecture of xcap. However, the namespace bindings are a different thing. They aren't part of the document naming at all, really; they provide additional context that allows the URI to be evaluated. As such, they are more appropriately placed in a query string, I think. This would look like: http://xcap.example.com/services/resource-lists/users/bill/fr.xml/~~/ resource-lists/list%5b@name=%22friends%22%5d/entry/foo:street-address ?xmlns(foo="http://foo.example.com") a major benefit of this approach is that, when only the default namespace bindings are needed, the query string can be absent entirely. Omitting the bindings is more troublesome in the previous approach, since it would leave an empty path segment. The only drawback is the potential issue that we discussed a long time back regarding query strings; they might cause a problem for some proxies in conjunction with PUT. Subsequent discussions indicated this may not be a real issue, so I am inclined to go this direction. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From oqngjsef@he.net Mon Feb 7 10:30:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08288; Mon, 7 Feb 2005 10:30:54 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyBA9-0002ww-JN; Mon, 07 Feb 2005 10:51:00 -0500 Received: from [80.102.146.157] (helo=CHORCHEHOME) by mx2.foretec.com with smtp (Exim 4.24) id 1CyApz-00071L-Ad; Mon, 07 Feb 2005 10:30:09 -0500 Received: from NQYKT-FB26 (80.102.146.157) by 80.102.146.157; Mon, 07 Feb 2005 07:29:31 -0800 From: "Staint Sybil Osp." To: simple@ietf.org, simple-admin@ietf.org, simple-archive@ietf.org, simple-web-archive@ietf.org, sip@ietf.org, sip-admin@ietf.org Subject: The Ultimate Online Phermacy! Date: Mon, 07 Feb 2005 07:29:31 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=0GU_01N2816YL_09O.291P12N0" X-Priority: 3 X-Mailer: QFIH Mailer v6.3.7 Message-Id: X-Spam-Score: 3.1 (+++) X-Scan-Signature: 6fc5b1c74c5bed09a3a9da2884900dec This is a multi-part message in MIME format. ------=0GU_01N2816YL_09O.291P12N0 Content-Type: multipart/alternative; boundary="----=0_00XA_04L2314ZW_02P.961D17J0" ------=0_00XA_04L2314ZW_02P.961D17J0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit http://lfgdqyylbqfnl182.focldplm.com/ All love shifts and changes. I don't know if you can be wholeheartedly in love all the time. Always remember that I have taken more out of alcohol than alcohol has taken out of me. The quality of the moment is more important than the number of our days. Take away love and our earth is a tomb. Compassion is the antitoxin of the soul: where there is compassion even the most poisonous impulses remain relatively harmless. What the world really needs is more love and less paper work. When love is not madness, it is not love. A woman drove me to drink and I didn't even have the decency to thank her. Blessed is the man who, having nothing to say, abstains from giving us wordy evidence of the fact. Drinking provides a beautiful excuse to pursue the one activity that truly gives me pleasure -- hooking up with fat, hairy girls. Always listen to experts. They'll tell you what can't be done, and why. Then do it. Solitude, if rightly used, becomes not only a privilege but a necessity. Only a superficial soul fears to fraternize with itself. Iron rusts from disuse; stagnant water loses its purity and in cold weather becomes frozen; even so does inaction sap the vigor of the mind. I'd rather have a bottle in front of me, than a frontal lobotomy. What lies behind us and what lies before us, are only small matters compared to what lies within us. Love does not begin and end the way we seem to think it does. Love is a battle, love is a war; love is a growing up. True friendship comes when the silence between two people is comfortable. When I read about the evils of drinking, I gave up reading. You can widen your life by yourself, but to deepen it you need a friend. Each encounter that becomes a friendship turns into a lifeline. One can never have too many, only too many to properly take care of. Begin doing what you want to do now. We are not living in eternity. We have only this moment, sparkling like a star in our hand and melting like a snowflake. Love is life. And if you miss love, you miss life. Life's challenges are not sup posed to paralyze you, they're supposed to help you discover who you are. I feel sorry for people who don't drink. When they wake up in the morning, that's as good as they're going to feel all day. When love is not madness, it is not love. Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has. Blessed is the man who, having nothing to say, abstains from giving us wordy evidence of the fact. I'd rather have a bottle in front of me, than a frontal lobotomy. Who so loves believes the impossible. Abstainer: a weak person who yields to the temptation of denying himself a pleasure. I feel sorry for people who don't drink. When they wake up in the morning, that's as good as they're going to feel all day. Love is the immortal flow of energy that nourishes, extends and preserves. Its eternal goal is life. Try not to become a man of success but rather to become a man of value. Always remember that I have taken more out of alcohol than alcohol has taken out of me. Abstainer: a weak person who yields to the temptation of denying himself a pleasure. Why is it drug addicts and computer afficionados are both called users? It's not that chocolates are a substitute for love. Love is a substitute for chocolate. Chocolate is, let's face it, far more reliable than a man. Always do sober what you said you'd do drunk. That will teach you to keep your mouth shut. Take away love and our earth is a tomb. Abstainer: a weak person who yields to the temptation of denying himself a pleasure. Love is the energy of the soul. Love is what heals the personality. There is nothing that cannot be healed by love. There is nothing but love. Without question, the greatest invention in the history of mankind is beer. Oh, I grant you that the wheel was also a fine invention, but the wheel does not go nearly as well with pizza. Life is a waste of time, time is a waste of life, so get wasted all of the time and have the time of your life. A kiss is a lovely trick designed by natu re to stop speech when words become superfluous. Treat people as if they were what they ought to be, and you help them to become what they are capable of being. Always remember that I have taken more out of alcohol than alcohol has taken out of me. Blessed is the man who, having nothing to say, abstains from giving us wordy evidence of the fact. All love shifts and changes. I don't know if you can be wholeheartedly in love all the time. Distance between two hearts is not an obstacle; rather a great reminder of just how strong true love can be. An intelligent man is sometimes forced to be drunk to spend time with his fools. The game of life is not so much in holding a good hand as playing a poor hand well. The Eskimo has fifty-two names for snow because it is important to them; there ought to be as many for love. A happy person is not a person in a certain set of circumstances, but rather a person with a certain set of attitudes. Why is it drug addicts and computer afficionados are both called users? Love is always bestowed as a gift - freely, willingly and without expectation. We don't love to be loved; we love to love. Love takes off masks that we fear we cannot live without and know we cannot live within. Love is the beauty of the soul. Can miles truly separate you from friends... If you want to be with someone you love, aren't you already there? Without question, the greatest invention in the history of mankind is beer. Oh, I grant you that the wheel was also a fine invention, but the wheel does not go nearly as well with pizza. I'd rather have a bottle in front of me than a ... brain operation. Hope is like a road in the country: there was never a road, but when many people walk on it, the road comes into existence. Opportunity is missed by most people because it is dressed in overalls and looks like work. Before I got married I had six theories about bringing up children; now I have six children and no theories. When a friend is in trouble, don't annoy him by asking if there is anything you can do. Think up something appropriate and do it. Always listen to experts. They'll tell you what can't be done, and why. Then do it. Life's challenges are not supposed to paralyze you, they're supposed to help you discover who you are. All right, Brain, I don't like you and you don't like me -- so let's just do this and I'll get back to killing you with beer. Hope is like a road in the country: there was never a road, but when many people walk on it, the road comes into existence. The Babylon project was our last, best hope for peace. .. It failed. .. But in the year of the Shadow war it became something greater: our last, best hope .. for victory. The year is 2260, the place: Babylon 5.Iron rusts from disuse; stagnant water loses its purity and in cold weather becomes frozen; even so does inaction sap the vigor of the mind. The problem with some people is that when they aren't drunk, they're sober. Hatch a dream and then believe it. When love is not madness, it is not love. The great thing about a computer notebook is that no matter how much you stuff into it, it doesn't get bigger or heavier. Not all chemicals are bad. Without chemicals such as hydrogen and oxygen, for example, there would be no way to make water, a vital ingredient in beer. No dictator, no invader, can hold an imprisoned population by force of arms forever. There is no greater power in the universe than the need for freedom. Against that power, governments and tyrants and armies cannot stand. A positive attitude will not solve all your problems, but it will annoy enough people to make it worth the effort. Books are the shoes with which we tread the footsteps of great minds. What contemptible scoundrel has stolen the cork to my lunch? You can't be a real country unless you have a beer and an airline. It helps if you have some kind of a football team, or some nuclear weapons, but at the very least you need a beer. A book may lie dormant for fifty years or for two thousand years in a forgotten corner of a library, only to reveal, upon being opened, the marvels or the abysses that it contains, or the line that seems to have been written for me alone. In this respect the writer is not different from any other human being: whatever we say or do can have far-reaching consequences. A book may lie dormant for fifty years or for two thousand years in a forgotten corner of a library, only to reveal, upon being opened, the marvels or the abysses that it contains, or the line that seems to have been written for me alone. In this respect the writer is not different from any other human being: whatever we say or do can have far-reaching consequences. Compassion alone stands apart from the continuous traffic between good and evil proceeding within us. When I read about the evils of drinking, I gave up reading. Reduce the complexity of life by eliminating the needless wants of life, and the labors of life reduce themselves. What contemptible scoundrel has stolen the cork to my lunch? All love shifts and changes. I don't know if you can be wholeheartedly in love all the time. Compassion alone stands apart from the continuous traffic between good and evil proceeding within us. Give me a woman who loves beer and I will conquer the world. The great thing about a computer notebook is that no matter how much you stuff into it, it doesn't get bigger or heavier. ------=0_00XA_04L2314ZW_02P.961D17J0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 3D"" All love shifts and changes. I don't know if you can be= wholeheartedly in love all the time. Always remember that I have taken mo= re out of alcohol than alcohol has taken out of me. The quality of the mom= ent is more important than the number of our days. Take away love and our = earth is a tomb. Compassion is the antitoxin of the soul: where there is c= ompassion even the most poisonous impulses remain relatively harmless. Wha= t the world really needs is more love and less paper work. When love is no= t madness, it is not love. A woman drove me to drink and I didn't even hav= e the decency to thank her. Blessed is the man who, having nothing to say,= abstains from giving us wordy evidence of the fact. Drinking provides a b= eautiful excuse to pursue the one activity that truly gives me pleasure --= hooking up with fat, hairy girls. Always listen to experts. They'll tell = you what can't be done, and why. Then do it. Solitude, if rightly used, be= comes not only a privilege but a necessity. Only a superficial soul fears = to fraternize with itself. Iron rusts from disuse; stagnant water loses it= s purity and in cold weather becomes frozen; even so does inaction sap the= vigor of the mind. I'd rather have a bottle in front of me, than a fronta= l lobotomy. What lies behind us and what lies before us, are only small ma= tters compared to what lies within us. Love does not begin and end the way= we seem to think it does. Love is a battle, love is a war; love is a grow= ing up. True friendship comes when the silence between two people is comfo= rtable. When I read about the evils of drinking, I gave up reading. You ca= n widen your life by yourself, but to deepen it you need a friend. Each en= counter that becomes a friendship turns into a lifeline. One can never hav= e too many, only too many to properly take care of. Begin doing what you w= ant to do now. We are not living in eternity. We have only this moment, sp= arkling like a star in our hand and melting like a snowflake. Love is life= And if you miss love, you miss life. Life's challenges are not supposed = to paralyze you, they're supposed to help you discover who you are. I feel= sorry for people who don't drink. When they wake up in the morning, that'= s as good as they're going to feel all day. When love is not madness, it i= s not love. Never doubt that a small group of thoughtful, committed citize= ns can change the world. Indeed, it is the only thing that ever has. Bless= ed is the man who, having nothing to say, abstains from giving us wordy ev= idence of the fact. I'd rather have a bottle in front of me, than a fronta= l lobotomy. Who so loves believes the impossible. Abstainer: a weak person= who yields to the temptation of denying himself a pleasure. I feel sorry = for people who don't drink. When they wake up in the morning, that's as go= od as they're going to feel all day. Love is the immortal flow of energy t= hat nourishes, extends and preserves. Its eternal goal is life. Try not to= become a man of success but rather to become a man of value. Always remem= ber that I have taken more out of alcohol than alcohol has taken out of me= Abstainer: a weak person who yields to the temptation of denying himself= a pleasure. Why is it drug addicts and computer afficionados are both cal= led users? It's not that chocolates are a substitute for love. Love is a s= ubstitute for chocolate. Chocolate is, let's face it, far more reliable th= an a man. Always do sober what you said you'd do drunk. That will teach yo= u to keep your mouth shut. Take away love and our earth is a tomb. Abstain= er: a weak person who yields to the temptation of denying himself a pleasu= re. Love is the energy of the soul. Love is what heals the personality. Th= ere is nothing that cannot be healed by love. There is nothing but love. W= ithout question, the greatest invention in the history of mankind is beer.= Oh, I grant you that the wheel was also a fine invention, but the wheel d= oes not go nearly as well with pizza. Life is a waste of time, time is a w= aste of life, so get wasted all of the time and have the time of your life= A kiss is a lovely trick designed by nature to stop speech when words be= come superfluous. Treat people as if they were what they ought to be, and = you help them to become what they are capable of being. Always remember th= at I have taken more out of alcohol than alcohol has taken out of me. Bles= sed is the man who, having nothing to say, abstains from giving us wordy e= vidence of the fact. All love shifts and changes. I don't know if you can = be wholeheartedly in love all the time. Distance between two hearts is not= an obstacle; rather a great reminder of just how strong true love can be.= An intelligent man is sometimes forced to be drunk to spend time with his= fools. The game of life is not so much in holding a good hand as playing = a poor hand well. The Eskimo has fifty-two names for snow because it is im= portant to them; there ought to be as many for love. A happy person is not= a person in a certain set of circumstances, but rather a person with a ce= rtain set of attitudes. Why is it drug addicts and computer afficionados a= re both called users? Love is always bestowed as a gift - freely, willingl= y and without expectation. We don't love to be loved; we love to love. Lov= e takes off masks that we fear we cannot live without and know we cannot l= ive within. Love is the beauty of the soul. Can miles truly separate you f= rom friends... If you want to be with someone you love, aren't you already= there? Without question, the greatest invention in the history of mankind= is beer. Oh, I grant you that the wheel was also a fine invention, but th= e wheel does not go nearly as well with pizza. I'd rather have a bottle in= front of me than a ... brain operation. Hope is like a road in the countr= y: there was never a road, but when many people walk on it, the road comes= into existence. Opportunity is missed by most people because it is dresse= d in overalls and looks like work. Before I got married I had six theories= about bringing up children; now I have six children and no theories. When= a friend is in trouble, don't annoy him by asking if there is anything yo= u can do. Think up something appropriate and do it. Always listen to exper= ts. They'll tell you what can't be done, and why. Then do it. Life's chall= enges are not supposed to paralyze you, they're supposed to help you disco= ver who you are. All right, Brain, I don't like you and you don't like me = -- so let's just do this and I'll get back to killing you with beer. Hope = is like a road in the country: there was never a road, but when many peopl= e walk on it, the road comes into existence. The Babylon project was our l= ast, best hope for peace. .. It failed. .. But in the year of the Shadow w= ar it became something greater: our last, best hope .. for victory. The ye= ar is 2260, the place: Babylon 5.Iron rusts from disuse; stagnant water lo= ses its purity and in cold weather becomes frozen; even so does inaction s= ap the vigor of the mind. The problem with some people is that when they a= ren't drunk, they're sober. Hatch a dream and then believe it. When love i= s not madness, it is not love. The great thing about a computer notebook i= s that no matter how much you stuff into it, it doesn't get bigger or heav= ier. Not all chemicals are bad. Without chemicals such as hydrogen and oxy= gen, for example, there would be no way to make water, a vital ingredient = in beer. No dictator, no invader, can hold an imprisoned population by for= ce of arms forever. There is no greater power in the universe than the nee= d for freedom. Against that power, governments and tyrants and armies cann= ot stand. A positive attitude will not solve all your problems, but it wil= l annoy enough people to make it worth the effort. Books are the shoes wit= h which we tread the footsteps of great minds. What contemptible scoundrel= has stolen the cork to my lunch? You can't be a real country unless you h= ave a beer and an airline. It helps if you have some kind of a football te= am, or some nuclear weapons, but at the very least you need a beer. A book= may lie dormant for fifty years or for two thousand years in a forgotten = corner of a library, only to reveal, upon being opened, the marvels or the= abysses that it contains, or the line that seems to have been written for= me alone. In this respect the writer is not different from any other huma= n being: whatever we say or do can have far-reaching consequences. A book = may lie dormant for fifty years or for two thousand years in a forgotten c= orner of a library, only to reveal, upon being opened, the marvels or the = abysses that it contains, or the line that seems to have been written for = me alone. In this respect the writer is not different from any other human= being: whatever we say or do can have far-reaching consequences. Compassi= on alone stands apart from the continuous traffic between good and evil pr= oceeding within us. When I read about the evils of drinking, I gave up rea= ding. Reduce the complexity of life by eliminating the needless wants of l= ife, and the labors of life reduce themselves. What contemptible scoundrel= has stolen the cork to my lunch? All love shifts and changes. I don't kno= w if you can be wholeheartedly in love all the time. Compassion alone stan= ds apart from the continuous traffic between good and evil proceeding with= in us. Give me a woman who loves beer and I will conquer the world. The gr= eat thing about a computer notebook is that no matter how much you stuff i= nto it, it doesn't get bigger or heavier.=20 ------=0_00XA_04L2314ZW_02P.961D17J0-- ------=0GU_01N2816YL_09O.291P12N0 Content-Type: image/jpeg; name="ld.jpg" Content-Transfer-Encoding: base64 Content-ID: <082752c4d3c0$2180fea0$346aa5c0@EOZEPFFNQ> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAACQAA/+4AIUFkb2JlAGTAAAAAAQMA EAMCAwYAAAtUAAAZrAAANLH/2wCEABQRERoTGioZGSo1KCEoNTEpKCgpMUE4ODg4OEFERERERERE REREREREREREREREREREREREREREREREREREREQBFhoaIh0iKRoaKTkpIik5RDktLTlEREREOERE RERERERERERERERERERERERERERERERERERERERERERERERERP/CABEIAQUBkAMBIgACEQEDEQH/ xADOAAABBQEBAAAAAAAAAAAAAAADAAECBAUGBwEAAwEBAQAAAAAAAAAAAAAAAAECAwQFEAACAgIB BAEDBQEAAwEBAAABAgADEQQFECESEzEgFCUwMhUGFiJBMzRANREAAgECAwMIBAsHAwUBAQAAAQIR AAMhMRJBURMQIGFxgSIyBJGhQqIw8LHB0VKS4iMzQ+FicoLC0hTxsgVTY3MkNEAVEgABAgMGBQQB BQEAAAAAAAAAAREhMUEQIDBAgbFRoQISQvBhcSLBkeEyUmKi/9oADAMBAAIRAxEAAADkXZMdJBKZ Nuax+qe1lqHWxZOT8b0/KaRWezWBOmaSi4ndpMISKaJ6P5f2Evp5xoDJPJx507GPI1h9tPjXDro8 1MXSvytcfX2/PO3citcWdV1o+ZzQ7hcxXDsJ8HYH2Y+YOT0M8A7XAM6ebSe4qtdBT0ObpvQadTWy NzlWtQErEMOX0cI040W5jdXNBOrzU4FZNphahsZOmn3V3nejDOfQxE7EqZgNGruhmJhBZi9QLdsS FF6sAsuOuM8rmeBhpxTanoDI9hC8gYoxz1czey2t2KcMNd6GKtI0eS6rLVD18HWSvyqaMXk8x3mD rnzTkF0c5DR3U8YNyjUivUnDou88r9UQqNvCDWDnWwJpclqgdVagbobWYGjXxbQaEq1ENV6tQN+g BBfWLqhOObvBNJB59Q6CHJ3c70lK44jG9ZmqNsw6mpYqVIujoY3YaZ4t4kou9OBnOTkdQ1Tl2ZSj TF5voMHo5ws61yf2Dx72FCrWeTDqVzdgNmfNwDpwZow36OWg3mw64b8Y5ob0ccAdDQ0efDShRsBe Lz7h0iSDEz71Tm6asSiz0IQBAKwk0LK1c2qn1nCa7jaOF8rtTrGuHhIDKoCwioZG3WucCO9ZuOd9 Qwd7TNJK8wyrvRUNoIIyo02tpJQ0lRZeVFMvBrmCwlCSapXWJJISSDnM+YOTrJNg56WBjNcggwGW cw8m6N4iV6diB4kkqwHNypnRHZNXsxc5EsOK5LhLjN6LL1NsklDbGtcrWaEA/HUo2anSdC0Ulx1H zH07zHtmw+vY0WBX7WMupWw3pH6fn64eioZPOtJIOSVl+DupivMPOJeEMCkMExpjqNbQRKEIq+Xt NpGFsqoPYNl7+TmcZHJWCHSB9Dh7muaSW2NGwKVrnw9BhdCno5/Rw5TS53HzL03geyb9LuudDJME uqzj3tZAOU1ky51uVq8dJJZPlNKL8PaWbvWYKGsw8WM5LSuVQQZMyEmSFCUBxrWQNy2qtsUlIjgB C09EDpOX6bTOSCtMjVCpqtnbT2UdMSkKhpBENgKq0kzqDtSUUKSZMdMgdJBzGjRvcPaiDckjO9Tm jKEuLFqyysIqE7RHIE4AMDhqukJCcSQkJXFcklRR3eb6O4hn280kpasA0Y5J0X4LNa0tHA3mqtE9 Tm2aDJvR1at3r54RLkXGoqBGXFJgZ8nRueYM0/M9G5PMK50JxdxLI2AWsiKSoJYSmjPBJsAoR1LI 9BvQJAkzIkZ6ZvVtU2s/pc7V0mvn6icZLa6CjW13Zjy1kLOvzTMuj0IMdMjWsvpDQI+kBY6YCFtN AR0FYpUHMEETz+5BNEZrmVoVNlAkRUz93IogUNibUovDYBQjFfp6QEnGdSSUZaZtXaxSKcL9GAmz obYaqxbgX3o1B7SxLKNN8jWHIkZKnjALDEx9ppnUM6ImcHdkm7xQcmbmdbj7dFgNLk+azfRlyNKV ZjEjjHWpklGkIkUwiDAtwZQkSBLiTsG5rbFK5rlMcltlk1Nge2GOPYMGGPoIBgm3GDD1LjDcQwWy jiW1LaqvzaWcu08VWkdgtNXcM7RRrnyq/Tv8ncQoz46QmcyVbRrOi8akUVsTzc4xL2WUdw2pZyDK yU4K4mJS0ztkBHXM1qgak7AWlnQXEZBcDITiKhOgkWZy0gs4uOOU1NRcJJkiSZxJ2cPOW1Y4dFQ4 iYdFicCwlJ3CBoDZdLTMKzUOzMXUqXlU5xdxKLZFyS3xV3bPsC5uuk5Qm1WPTOLbasO4MqtZnMKU LhlnU1ql91oRGRckLUhokUJJb0blURUJBcUWCvaz7dzhTO/N0Z1TYy8tXLWLloZ4TQ8JRCB6ZWXC VTCYkXYVhiqW5vRo06IbVLfDp9/m93OrWhnS0xM2crz0nzEGm+Whaj5SRrLJQrV/GTnZfFSe02Mg 2VjINpYqFtrEQbhOfsDmxIR1CztOnF5TuXDoU3kkneaVetfptlPk26NBqruS1BzaDXuVyqFDUzts tPquH6VLcrsF8lGYRrzrUa0gV2iyNmoCNXaozrznZtUzOj1WYL9OEAvSoTHeelBu/VqHU2bOZadb cEn6w6aU1lmS5+ickkPJISAkzPSWhYCk1aKlCFWSVVc9LabF5JXu7SWnEFJXzpJAkkCSQJJAkkCS QJJAkkCSQJJAiJD/AP/aAAgBAgABBQDoWxGOYjTIgIP1GZmZmZmYDMmZmZmZme8JxPLvnMUd7DFY iK2R9B/V+ZYQIATPgK0sExEOJmFgsyCP1gxUuQYDD8AGPnGRB3gJEOZX2H6zDI6CKe7joOhOIrT2 RW8umO2RAhIgBM8GhVh0II6s2ID1BUQtnpnoYDAJX0b5rTyLsFWa3x5PkW4YVAMyrYvTEA+kQMBC Q0IxBMyroe8RlJfwzNcgCu4lyEybFwoRJaQzdcTH0iHvAJnArM8hA+ILcQv5HInkJ5CZmfrP0gdo IIvwT3JwQxhJyGyCcnEQdsdXQoZnriGZ6Z7CCYzEU48TPGeM8ZiGo5WsD68dMzMP0CCCJMTBmJgw gjoAYy4H0FCOmIe3Q/QOijET5z2zPKeXbyzAonYRyWPV3Ll4TCZn6RBFEzF7/qt3B+owQCY7DvEn bHads/8AgkT4+p/HJjD9ARe8z3U4nmJ5ieYnmJ5iewTzE8xPMTzE8xPIQxh26iYgHTMQxsZHx2mR ntMiHE7Q4hImRMiEiZGTD8H6B8Q9E6J+r//aAAgBAwABBQDoFzFGI6wAmFSPqAyQoJFYgrECiCsR lAhRZ6xnwGDWIUAhUeMC5mO3xG+KxD3jLg/TkzJmTMmZPXMyZmZ6EYlYMJxPmFYhmYw8hjECkwgg /rOFcIMAiYhIi4ziGEAwYxYO/wCspwehnYBeh6CEZnrGXXx/VVZiEGYniTFXxhOTiBehhMsOepg6 HpiZnx1zMzPTMz0IzAuITDPGW/QOhhE7zHQdDO8DTP0iGEz5NoxPEzxM8Z4zEwZ4mY+kw9B9P/iG Zj/MxCJiYgGOjHv1Vg3TEMB6DoIYYYI7AnImZmZmYHELZ+vMInj0H0GGGOZkTyGMiZEBB6ZgOfpB B6Y6Yg+g9GOY3x45PjPGePdVxCei9voVfGV/GPo+Op6McTExk+tZ4LPATwE8RConaATEx1Q4OfpH Q9D8ntB89vElZlfI/DlSD3gEP0LmCIf0MR+0MscJPukn3ST7pJ9yk+5Se+ufcVz7iue+ue+ue+uC 5CRFPf6xLB28SBsYCkrjyXyyohZISsBWMVMZlMDIJ5JhmUwFS4g+fpPQR4fi34/THz//2gAIAQEA AQUA6iCLSWjazVDUBZKQE2FsxNy/0Nu7jXsCZnPXPUCJC017317NS4bFXxCQAvK6rTb5HX0ztbtO mjb+uo2+R19KbO5Tq11cjRa9nJ69Vu3v0aS37tOvU3I661MwULzWmwG5S11O5TdYnI67328jRTav Jaz0jkNc0V7lNlOpu07q2cnro9fI69ltO7TsP9FFBsajjgh19INPDBuU5q3yz8h47FSaxZrdVqx4 kdD1EHaKY5gbE/qu55L8zm1d9Hi7Kn1OQ8t/Z2dv7rjHNutbus3IbF+4djiuSYum9aW5Hk3+92m2 ms4u/wBmtK2La2jRbt6im2vkNTaOttA2VDb2WPIa7BtJXs+3G044/jLW0tz+vtheb11GvwWv4VdM QdjrKGbWTzgjLHr7P/8AaSAKahhtfI2tM5ZSJjqIvaAkQ/8AUM/rlhXeTZCuRmLxlVb18albHiaZ bxldqVcbXWW4mnNPGJSL+Josg45Az8VSzPxldldNIrSjQShrtFLLLeNqsdeNr8F4qtYeLq8142vx HE1rLONrcWcZVYx1lsr1dca69FAmrrF2opCCo+MU+UbsLGAXX2w23ae1K9gO1lKuu/qZh/56YgER TPHAcTy8x/Xf/wCjy2wNROle5uNv6+xsnf8A5pE1z/YETpRyV22G5xTR9/bVf/Po7aG8m/TubLa4 0+YXZerlr7dV+UDNRfsNymzsJq1Pyd9VDcm7bKb72zU5F9fQ++89npjpW2DrXZlbdq8mVYWW7lYm z5W1svqK2+yUr2AhXttr22FKtBBEzAwMsSZweKu9W5/YQXu6WccrXU6SU3fxVBQUq6xeLWqfxGuK 79NL7V44VFFTUq2OPr2rauNSu2rj66tQ8ZWBTxy1bF1SXoeIRq10a12BoVi0aQo1OL49ePo6WVNU ZRUbXo1FqBda5/IBY33OwqUdqLDWOW0isorLom2tVdW+thrsSwXayuNziXEupasgGUUta1HBrjd0 m1YzGHvK7DU25vvumWMUXX2b9nS/kNnYeq66neS5qOI2Lr35BNy/Xuq29+/W17DZUtt9+9tbdt2n tWbGlq7e15bFXJ7J1XbYr0tnY29fjty3Y0Wt22utXmdgceKrFI5TYVa1ZE6O6vNvRNM1HFdijIbV DEVGqBbrgawq+UTDLvUNTZxlROubjTZr7TMUcsCmZvcet0TgQzU6lWodO9A/PAJUc4PQfHR9DWd2 qRm9SF/tafD1J5ipA7cfquwAUNxWtZd9vV671pFXp1d9QuolhqQo1FT12VJZNluNFtezoJVqnjQ9 epXVdTfVsL0fjxPXkfx1KMpxEcYrIENglj5B8qzdyL0yzZs27NbWFNOxrB5RV4ytcdLBmKksT2Qa VdU5ZW23sBUzE+Ot28lyXblj0VXD73T2KHVr9ttTk0fUUXqNp92/jX3hs6i6d9n3C21WaXD/APw7 5qHJ6oa7YTY27iq+I11ublOf801N/d0dmq+zZGqjnjdvpYMrdSay0HeAEQORBbHvFYa5mG2TOBpW zYb488sgxAcdDPLEaxg9jWOr+KV26vtLaLhdbQv2zZw+3WetutXcz3JW2taao3INXAwP6NOtXQ36 CPldiyEBoylYrzzEJEYhi/xfR4iq56LNHbuusWsKFfEFhEBhMtaO4jLkeIIsIWK2ZS5pKb1dn0be yazq6gpHTdpCjR5pdg9Pify+lP5fSn8vpT+X0pRu6+wZbalKjlNM/VW2G2bQ7qcBLFaNrZhqYRlY T2FI20oG3s+yU0kypAGpRsKjJAwI9gEa0CWXZhtyVyQvY+hCU1hkaamNx1Tdfiabm7rtbVWpXvbp 3Rx1Is3Oln7dUUJQBSR40zxpmNa1uB5i2yz+w7jb2xY9W6v9c5T72j6LbSLFr7+PZ18YlpENjENY 7EpaxOpkrqKsCAAqRNclk8YTiWXBZZu+RUPbFTxlfeIkSuKsAljBetn7NEg09N/YF2wtV52OM4uv j16WftprezUr/se4i3f2S6mvQ5ltvd/sehVsattz1oS2rr73B2cfqptnUvptW5OoqxDgQuojZeGl pWxrl9IYUpkFf+mSeuGsyi8VS3cRRfycuttvlYek6162gd5q19lWKIoltgrFrM56fM0CtY2dmrVr r5Tc3H5PjbNTj9fdq1eQP9i0letxYss/bRdZTqJwPJOvM6t2qupyNXHcpynOtyiiuu6zQsW2+z+0 6Fq69tQs/rG5ZVZ1VPJTUhja7KKFFsaplDAQgqFLQLiYhXMxgMgjaqmDVUQ0LGpEsoxNTZZmrXxA gOJ7yS3eN4gddlHQ621XtLtcTqbc3+P2OMq43UXZts16rT0cZVeD3hrUgrX/AGbj9ncZ9HlHavhe S2hyfDbCJscc2rx/2XIz7LkZxOm9S9aLXodqwwWsiPWrzxZJdqtXBGGJ3iHMBxCcgGEQ4EKiMoli zj9cNYBBLASNM+suPJtq/wAPpu0a7GNW3WNzV5BtjR4inUf/APCES5KK/UA2YJmEZAUo2BGHYMck YhGIO57tGyATmBsyztNOsJWBBAJjE2NiVV4LMFHtM9pntM9hnsM9hnsM9hnmZ5meZjXBZ92gg2Ua eU8pmZmZmZ+inVv1mJgMB6EGbagOO8evyip4QtklTApEJnjmMMyx/XFt9pTsBBBNi0iNrIEY+sW/ Mu5Wqqfy9Zerka7Ep3PY9W+lll++tNlfLU2Lr8tVe0vuM9hYl+/kZxlrE4M7xH8x3mTMmZMziCU8 gjEYMIinEBnzN1SCDmHtGfBVh5LmeWYxGQJnE2T7F0aSbwIoxF6NSHlh8FWv7+y35v8AL16fh7H+ 386286qdw2rq/v3P/fWVRKvAO/xf/wBMxy3/AJVCx1dca6dOKtyle35P7bPuYxwNXdusuVgrisGV WPTEtVx0WOgdWq9LMSY4Ag7OD3AwI+MucS15xSlrB2iwQdNtgteqrVy35l3FVWz+IrDjh0Ev0VtL cLWy18LXSRwtKrrcZVrkjI2EKM5lWtZcdfVWgRrXE91k9rie14pZX91k91kzYZTSKgsxGUqadzBA nxF7zco9iqSIwzMZA/5gtBhcmYMZGMNGZoV+IAiwCDpsUPssdNFDKGHqM9RnqM9ZnrM9ZnrM9Zng Z4GGvIGhWCEIniZ4zxmJiYmJj6F6HvGUGa1/kAYGxCczaogYiVgMfETwBgQCNgRjGmuviogggjsE GuRZPBQbrCkJJ/TCCeAhUCewL+khghPRgQa7Q6+UBh7zboNZqPbtAYTGjRF8mUYgEEHTcOVrrfxr R1mx+7a2rqrNjfsz99t4v2bfYu8PT99tktyd7Lp71ljPyF0DAhBC4Ea2NdNq4kBDjwMof3V4MwZg zBncRWDBLMwPPIGeWA1mJTd6mUwGAx0Di2k0sr5g6GNNdIIsEEzFY33r/wAAnE2P3b6+M19da7BY BLfZepfFtSsHVmtqDmqeJrt0LfGo2xro1sLkzW1zY3TjtdqpXXaHCE7cbJGprXpclgss1950lO4j gOIz5ltreS2nGhtlwrQNAZbWLBcjUlGyITD3lY8QsAg6bN3qr0qPt0XMAxNhDCAwp16qB/H6uaqK qZXr1VN9jrljrVM9mnRaworCLrVolqmseamFlEoQWlXQA+ZmLZ42zxtgrsE8LZ4Wz1OwRAgoEVe1 ZYQeyCvMGvmV0LWUs8grRWmZbWHFlbUFHDAysZYRRBAZmKotsVfKFgIGzCQAzVZ8qp5VTyqnlXPK uZrma5lJlJlI1dLz1a9cD5IImVmRO07TtO30Cs1MgyE7QEGJ2njmeEX/AIKtEeK0Mtq8hahoK2Ai pcBRB0zHfAqYCe2AliSXOyxz+mzBYflR7Ci+K/o2aWRVlYoixZmCYgPiVMRopnzNmoOKFPtURR0z GbE/k6nsrtgszKyXgwo2P3ck4aalq1hHGqLa0pT01LstWmwy6yCqldb12KqDiFCAv4hFnqOVQIMz xE8Fmhse6tb0ae9PPwWFVEq3arXVjlag0fQzPFkKd4sAmMdCMgMRFaK8DRu4rTxuUQQwticruGtH E1eTes691LQf8qMLNj92zr323WcdbXKtDYLfxuwU+32msOps1Oupt+vx37al0bscfW9Ko3lKQc9l GST8w2oJ7q5rU1a8WmpXUIdn3Vw21kV61FDUh3KUgw14mxR5BRiLAZnq65iPFaK0zCvdZmFsTYvF a3sbGcRP/ZxlqsFvXAtWW1+YNbCeDTwaeDTwaeDTwaeDTxMKEipLKSp7YYnBmDDWDPUs9Kz0rPSs 9KT0pBUq9Fr8RiOMy9fFw0VoGEDAzMJjnBSzIVoGmYDC0sswL3NhsWWCOSrU14lDi1QJyHK/ZWf6 Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6KafM/dXYhE YTbSHMVCYK4BiDvPGWLMmspZFeBoXjWYj2F40cSwS4YPEbwqlNdZhAE5DWW/bWoWPvVpr2byVVV8 br1WHe1/tr9jWrqqGhQBXrJ9qusn22tQNi/YelH2tNDs7mpSH260o2rdXWG5vazUDX0kto0NKlpp cfW63cfVTTt6dVa8lr10bHJa6a71010cmRCI02RlIogmIIIy5lwi2msrbiC6GzAa32FVjrGEtEuG SiduO2PbWLwZzF76+2d9wNjZ+4N+y1617tlVWztPsm/Za8Dk7Vf74msbp9a2FHs2/aTylnsHIXFL dz3PdvG+y7aa1ats1FuSvKW8nbYPvrfDYvbYs2N47DbO4dk8dd7t4wwza/YIsEHQQyyX5mv5+P8A 1hs5r9eBiWRpbjD/AL1xOP8AL3PibH2vl+Pn4+fj5+Pn4+fj5+Pn4+fj5+Pn4+fj5+Pn4+fj5+Pn 4+fj5+Pn4+fj5+Pn4+U/Z+f/2gAIAQICBj8AuNmmzKWRsiOmQdLjLbAcbKd2C6n8Tu6bIISUii2R tbEWxT2GTT1+Zr8WdWg3b/0J09SM/u53pOie43THh8/vhQQjbAWzupUTth7cdSLys6u5eAidTIgn Wq9Lp7/gRvKGlf1FTpr/AKQVU1xWFeyBJB1tnkV7hRE4kaI4jzdlFYcjZG4y4qotkiRKyGVa8i5J rJDEbHuuuG+DHIQxvpLFfMPcXB1xVKFChQoUKFChQoUP/9oACAEDAgY/ALjkCN5iMEQjOInM0XkJ z1EaoqPJzb5YTTma8hVpQ7rrCqRybLdW7HHgMtx0tiMo+ThMa+mK+ImVhbETMOgmLHDZBMCFyFxs FM29jEKZVzVydGHfJtY2Xja1RWE+eQnMVUm9/wC1jYfcsCe5PcnuT3J7k9ye5PcnuT3J7jIu+Knd JyE/XsPQ6mrIl6gdPMV+PAhA6m0EVUlQZtdRWRuHM+v9kbFpqeJ4nieJ4nieJ4nieJ4nif/aAAgB AQEGPwDm4UCMJMfE0C2DRlQfIkaT07R8/p5DcGIK/H49NET3c+2OTHn4VjS3reDKaW6uTiR9HZyS cAKwckE6dWltM/xRp9dKt99Jbw4E/JXEvNpUmJgnHsmrbF8LpC2zBxJ+TtpeO+nV4cCcuoGuLebS kxME59U0LYaHOIV1ZCerUBPZXAYsLhyXhvj1d3EdIoNfbSGMDAn5Jrj3Gi2Y70E55ZUl4v8Ah3CF RoOJPZ0baLHIY0G1kKTAYo4Wf4iseuj5cN+IBq0wcuvKntI0vbwcQcPj0UfLK83RmsH5Yj11wGJ4 katKozGP5QabzCuDbXxGDh2Z+qv8rX+F9aDvjLPPor/IVvwoLaschn00XsNqUGDgRj20yFiWXxaV ZtPXpBjtoWVeXZdaiDiM8DEGnt221NbMPgcD15c0JvoEmdnx9VKzDwj4/wCvxGGQ2VI2VwnziQd9 FZgb6IGQqc/g38qxy769W349PJdFvxRs3SJ9U0hdgEAVP5vpmrulS6oOEhEZjrI2zlsq2GxZbiqe wGrXlm8C3FuWz0E040lxbXhrEeLfiR00FY95HVT2V5cIZvapG8AbasPt4Z/rrhAF0tJpwjxNtxI/ 1FPYfxW2VfX8RS+X/SLrdTo2EeumJ+q3yVwAQqapJkz2CPnqEIDC2olhOGHSK8zdczB1NAiYnZJ+ Wk85pOvWXZ8MQ3bPq20LtoaibQIxia8wQe80m4u4zR8pJ0FeP2aJj7UUnlk8V06QOicaNoAol0So aMx1EjfT2rh0srM1yc+2k87YaDbgoy/Val05HvMd5PNFz6vz0C2zEdPx3cxQPZVmb5Kx241141NS M6g4HnYVhyIo9oMPdJ+atLGJqK4iIurfpE1IAAzhRFEBV0kzGkZ76AYAsuRIyqQABtgRJpoVdLYk aRnRVAqznpAFAhEna2kTWoACcWgRJ6d9EhVhvENIxoI4BgyJGVaDiKJQALuAgULoADbWjH00W0r3 vF3R3uvfRRgCp2RhQIABGAMYxuosFXvCG7ox660EDTlGyN1YKojw90YdW6lMDUuTRjQuMqs37yg0 bdwBlPskYVpGXLjUigMMKw5TNPuc6fRlUdXKZFSMxUHnSKxzFWv5/wDY1M23ZPLesKqMiBCqs+mJ 2yLZMnaNmwmvNW7Y1heFAe4VVZXZg2fQOurt+8pU2XNt1BnvYZHDAz0UpucLSxC/h3w7id66R2wT 28jXPLWg1sEqGe5pLRnA0t6yKs37SFjduCzoJ0lWM9e6rdi/bC8XUEZH1YqJx7qx2TTi1wgqErN6 8LZYjculsOuKF63gDIIOwigw4cYybtzh/wBLT6quWoXVbXXNu4HQj+KB8lf5i2V4ekuQbvegZx3I 9JFWrdhNdy8vEUE6QE3sYPqBo27vdHA1aFcss688QuOzKmvXPCgkxQ81csgWYDGLkuFO3TpA7NVD y1i2H1WheDl9IgmPqk/HKr9l10XbSz3W1CGBIIMKfVXl790F0YAXbhbFZ9o7xvxw6aHlrS64XVce cEB8OzEtuwwx+BxqBTcPcYrDAilnbHMINY8uNSOSRyWn2ao9OHz0zXD3Rgi7z+zlPmLdx7bsAraN OMZYMreqrt9SS17RqnLuiBFXbbgst5uIwOw9EZZVr/yna2DGDW4w2agoPvdfIwsXLlpHMlEKxJzj UpK/ykVatLKrZdbqwc2G+ZmZxq3eYnVaLFYyxEY03AuPaDEuVTQRJ/iVo7MK77kqMS9xvlOVJ5gM y3FEK6aTgf4gw7YmnvF3d7ihGLach1KPo6K/wwW4elkkxqhp6I27qtlGZHtJw0uLGrT0yCp9HVR8 0Xd7hTh97TETOQUfR0UbdwalYQQaFh7txrIj8MlYgbJC64/mr/KEhuHwtPs6Zn441dvSdV5QjboA jDDpr/FsgOApRRcOB/igfIKFoYtm7fWPxwHRy6XEHkCit9d4xXdFFvAm8mgcSY21BrjWxKnOgwMH ZQuNl0VgjR1VAwPTUGiUxG6oYQeQKokndRNy4dW62MvT+yg2oMhmGyy39NY8gcZqZE0HuRqAjDLk LASQCY30fOnzGhoZtAVNCx7JkaveFeTCnhcdbjXBpB8KgiJ9XXjNDyrubiNbNwFwoIIaPZVRHZV6 4kahdaJAP6g2GRS+VS4Utm0XMKpM6o2g/OOivMWWJvC1bF1JADEwcO6AD6KHmU4mthqGFgWurFtc dMz0bKR2ADMoJAMiSN+2r3lxdKIi2yoVVnHPxKfn7K87aduItqFS7AGqcxhhK9FJ5lbpaOGDbKrp hoEeHVt+tRsWXu8RVBZLS24E7Sbg/qrzZY9+xIRiF1ZbdMpPVhTeaN5i4sl40ppnTP1Z96Oil88L xL6bblCiaDqj93Vt+tVh+KXFy6lp0ZViG2iACI6SauJ5d7xNs6XFtbOlT13AD6z6K/yDGvicIuRg omNRAMYdcUs+ZJ1AwGW3jh7MKMs/ao+SInzurQGjulT+rugDMb8KCs2pgMWMCfRhyxcAI6a4i+D5 KB6Y5JNYW56omtJXSu2ayqK0nKigMKcQBRBxEmK0kMBsruyR08uWNYkx0UBAE7emtLLpntFC3ta5 I7Afprq53Ea0hf6xRZ9MUrsoLLOliMROcHZNcTSNYGnVGMbp3UbWhdBMldIgnPLrriaRrjTqjGN0 7qNwKNZEFoxI661tZtls9RRZ9MVAwAp791RcZwoIcBgNO6RXB0Lw8tGkafRlR4qg21GogrIAXHLo pbzIlwMJVnQHA9Ymj5UKga4utkCYMowxwg9tcMqCkadMYRujdXCZFNuANBA0wMsMsKGtQ2khlkTB GRHTRPmDY4oieJo1dGeNHhvaFqYbSy6ZO/ZJr/1uBxP+3o1erGn8ySS7CJb2VGwbhtrVadXWYlCC PVyljgN9aWgiIMVIBEdPNiiTiDUBMN80CfETpAFLb3Csagc1YgwWmdlBlJIzNG4uS+Hq/wBaM864 9om241Qr+buLcBH/AGu8OzLsryNy5cKcQ/isG0z3duyrS+SuNdtEPx/xGuKPq4ktBnceyr3+X5hl YXboUcZlIAOGkAgnqx6BXlOKzo7+YRCw7rMh1RPWN9JwmuC07gX31s7KvRJOnpKirK+QutdVieMv EN1Qu+SW0ndjjup/KHVce4Z8qzYzqPhJP1Djj7NeXs62Ns6uNda4Vlo2vDFF7OiRUWbiMhRpti+9 /vbDqZe71aqdvNXm/wAoo+q3xWUg493hgjDrXpyqx/40+Sk4z8NOC0tr0e19bCPSKu2rNxn8o1sR cFwtpefZeScsczFf/wAwki6h/Evj/pbGH7zZdGJoKNmGONeb4LKuFmdaFvZ6GX56tm8yki9bJZV0 iO1m+Wmt6lvMQdKW++07I0zGMY4VZ/486n8xcX8XSRqW2M8SQJ9nE440ri01ny17TbcMUhXGCnus 2YwM8uFYTB5cOWTXdHprvmTu2UWb2RIrCtPOJgEbKMmAdgo7aLNgorVHooiyuqM8QPlioa3B6x9P MR3EtbOpMTgfjvoKxAZp0rtMbqI8tYbS7FyWaMWxJ73zYT0Y1N20yicx3u3Ls66gHH4F2QQ1w6nM kknt9QyGz4GKx2cnRy4VNYUXYya1WjBr8RsPRUgYmoqDztI9VRuy5JAic99RcienmC1bE3XyHRtP x/YdTnXcPiY/NynzCvw3QE6iTpy9ro+gZxTO/dtPcFqwSMWMfT6Jg8z8639sV+db+2K/Ot/bFfnW /tiotXFc7lYHkL3CFUZk5UALyY5d4c4ioHJDVK1jWFd4VnWlcak0BlUIzR6qxYt11B5mFZxWFSwk nfUgR1ViKxUcxr/e0t4VcREbug9PKbt46VFC95uU8tP4Plx47p2E7h0/ZxxKHzZHGC6rVhfDaUZT 07h2nZHIeo0129bNwh1QDVpzDH5qkeTeP42/tr/47n22/tr/AOO59tv7ahNXl7gPd1NqWeuAV68f oPkvOfmr4WOZjYenaDt+Vf8AjrByPfOyfoUYn9lN5S0Pyh/67Ri8eIHpfxDpw21w3P4tqAeldh+Y /t5rBanliSKwPqrTEGomBWJqeSaB5c67uPVUtlyYfAHqNKQAM8FyGJ3cvmPM3hrt+V0patHwlyYk 78RJ3iBQVfxPPOAzufBYU7umD2eyKMd662Ny42bH6PieU9RpwgLHiJgBPsvQX/GJgAe19FWna0A1 wsCpkRpI+mrvlCgAt6+9OelgtPeIAuWxqVvmry3m1P4gBWf/ABnCeyB2UWbG/wCZ9Itzietz7o6a tebQkXVIa50E5fZyPTVv/kbI7jki4g2N7a9viX7tLcQyrCQfgMK72ValzqTnWFTy6TlUkioQSa7x w3CtS9orDA/V5JOfwLeXEzbJ8W2ccMcvmijdvNpQZmifL3vLqCe6jag0bMxnTcQ63e6Lt519mdww nP8A0p710xb80itbfq2Hp+frrQ7Mp/eRh800HXIiRyHqNObbFSbiYqY9l6DDzOBE+N68tbvvreXO qSdq768xdvTpLXV7onHXPzV/i+TRtLYsTmQPUBvJPopbcz5by6zcce1jJj+JjpXog76b/kvNA8K2 wgKJ73sr1KPmoo6uVYQQVGXpp/Lk/gXTAZvZPst2ZHoJp/8Aj7oMqWK9EeIfRzAdhru+upGNGcCK xGHJAqBhyY8kVHJlyyMCKCN4qjl0p6anbzeNZALDxAASw6+jdWpcxmpzHx2HbR4ttST7QwPpFE2L puWG7hsXMZ1YQsfNBq3e8sWtW7HduJrZgXgFlWScBME7dg20GdFYjIsoMcpA3U1vhHUbiNErkFbp 6aUHMAVaby6atOqcRhlvos3l0LEySUtYk1w7umzaOYUKJ7Ez7aXynkrZNod645Il39OQoeX8tbW4 4IlWEgnaca/+S19hPpr/AOS19hPpo3/MKq33ADBRkq5D6ewbOZwrogHBTsrCu9WUGscRWtfDu3ck 10b+Wag1IqeYbh9nAdvLhRDDA40TkDWhM+brWUeCNS9R+SZ66AR1f+MR8me31ddWfMIEfhzKaoXH CcejrI6aN5AVdsSoclQejKe0ej/8Wxga0ySNk7OayHZyCo5MeSK31G3kyodOPNKJiak4tUn4TEgV nWDD4MFSCu0TzlO/5qio5enkwipro5NIzOA5oUYTRO7KtbGAM+WQCyg6dQKqs9bsoPZNcJUcvHh7 gPvMNW/uzVy4QVFvxA6T/tLCcMpmuGyMjEFhr04xE+Fm30ECsASyq5iCVmds7DmBXBCM7xMLpH+5 lnsmpAbVJAQQSYzxUlduJ1YZHGgoBEnTMownd3GaO3kwwFdBMTUVjumihyiRyZUGXEESDWVZGsjW RqThyQ4K9eVYc1WjDGp5J2cmOysOQ4181SKUnZJ5veqDkKIY9xfZ38jaPFpOnrirWWng9yeyfVFW v8fTHEbVp38N/juq3Z2Ncuu38KXGP+7T66a+SpNm5qGllb8M4GdJPsznuFWf/Je/rqz1XPkFW/aL 29BtzBiTkTAxxwkE7MqW53m0OtopcA1KSREGJwkGCSI3EUaC7Mz1VO7kgYmv3jny2kV9YNoFhh3S NMZYiccD9XrpLervm7dVl26RxI+Ra4E4fmT+5ER9v1chIxoK2IOyMq0DrjdyYYruqVPMg5VpbbUA 0DursqDUipYV0cmFMx2COcWOQrWPEcTywCVUnUVAVlnfDqwHZFC4rurxGruE+8p04Yd2KaLjjVIe NA1T1Jh1iCd+VAhmQgaO7pxXcdQYULZdygMhWW20faQn11qtuytvC2/7IH8sTtk0VDMC3iMJj1ro 0e7mSc6BBLacVnSAOpVCrPTE1FSeqsK7ow3nKt7b+TBZ7a8Hr/ZXg9f7KnR6/wBlNc0Es0DFtg2D CvB6/wBleD1/so6UCk+18RW8nM8upcDWm4I6eZh4hlRJ2EzNY0I2GpNYVA5caPSecqJGkGWruv6q g/Bwa1AY/DxUVoY95fWOZrXtrKss6x5wHNLHIVrWccdR+M0DUDM1j8Hjjy970/DalzFSOWK1Lka6 ecBztH1qiB6a7wkdlDqoqgWFXXBBJbfBkR6DmKJsaSqhPEpOpnyA7wjNd+eVSNOrXw9Gjb18SI6f Vsrh2ioKgFiwLYnZmvxig7DvklNA+sJ9WE9VFgqlAYJCEgRmJ1zhtISKLoFXToGkqWJLR++g2/PS rdjvyFKjTBWZBEtuOINNdTTwlJ7uk6mCnEg6vR3TUjEHKp5hAzrPGs/VS3FODANHWJ31mKzFZ+qs x6K31I5mPJ+6eZBrDLnaudGxcK6ak50OqkvfUMN/C2HyweyltT3Um63yIOz+ihdM6OMXnSfDjjll 00OGGNy43GMAHuiNMyy/u7cxlSXV/Lb8T3dJP+33jQUu+iXPdZ1UCZBDKwXHaDjNXC2LMbWJn92D gQenOg9tTOk2lH/TuExJ39Z/qpWUHg2wLJMCJMbdU7VnunLPOuEc7ZKdns+6R2jm628K5dJ/Z8vb y2wbfDKWtFzLvN3dxxiGxP1uukQoYW7cctIiG1xtn2hswoqPAIun+MjRHox6+QxnWpgQPaO+joyG Z30JxFbjU8nzCu8a0Ns8PSOZBro5kVHNLbdnXWt/GfVWo51JzoNUHEGiLSKgOelQPkrVwrc5zoX6 KPDRVnPSAJouiKrHMqoBNa+Emr62gT8lC4UUuMmKiR21re2jMcJZQTXDCqE+rAj0VotqEXOFED1V JyrAj01iRUkwu/f1fT6KABHpruth2V4/UPorx+ofRXj9Q+iiQ2eeA+ivH6h9FeP1D6Kh3wPRUDKs eTA1sFSxn+EVgI6TnWrNht5sGv3fgQzeFMe2tTejknZWNZeisj8e2sj8e2sjWRrI1kayNZGsqyrv KD1ipCKD0AVkBWI+Cg8/o5sV0c+BnQG7l0LkM6A+E6a7x7xGFDDvbaiSev4LA41pOfwunYMedw1a WmBu9NY8kLntO6tK0OqlsnJpd/4V+kx2TR4Y0pcRioGEOs+v+2lu2gA5WGgROod2d/fA9NKbUAnU rMM2gHM7aKgKuEjSEBy2R359UVau3QHNxH1BlBgqVG0YH6wymkBAbVa4sMF0hjGQjSPjNM1osLgX ZwoxwP5eP2sO2mTy4CiVW6iiBBgzHq6pq6igBQ+AGQ7i1AzNTOO+o9P0/srdU8mQq2LikM1tXkx3 spyyzGcZ9cL3fE72+1dX9taNPe1aPd1T1R68KyFSQK4ayCcjWls/lrAVqGdQwx58c1jvj5+bw08T eocmh+8Nh2/toTcAnZ/rWleQdVNCnS2lQ/dgJtwOM4t7MZVwrQLLIKP3F07wQNOeOS7aDaQulQkO RB6Rp1ZbJiha0+DV3yVhpnLGfSBU8JgpIaDozAIz4hwx+rNDuawNZ7hXNyCfEy5RAw6ZpQ9snSht DSVmMIJl49DeijYdAF0xJAGWWVx/kHXTXwhD6vASslYAO3TOEjH0TVx7qldTagpInBVGwkbN9asp 2isDht6eSTyYsB214h6aX8TUEXhpqK4Lhuichnu65DcTBWZ1WViWmen2jtwpr5IEKEXvZ7Sfm9Ne IemoLCOuuIG1RktcR8PqjdyYGp2/AY8yeZJos2Z5AN9cJxJGVAGRFYVhmKyNZGsjWRrI1kayNZGs jUQahgY2GpAmpNZcmIrKsqyrKsqyrAc08+R8B0csjMUtxcNQDCp28gt6NUrqnVG/oO6vyvf+7X5X v/dr8r3/ALtfle/92vyvf+7X5Xv/AHa/K9/7tfle/wDdr8r3/u1+V7/3a/K9/wC7X5Xv/dr8r3/u 1+V7/wB2vyvf+7X5Xv8A3a/K9/7tfle/92vyvf8Au1+V7/3a/K9/7tfle/8Adr8r3/u0trh6dU46 pyE7uZq5M+d0c7o5vBuiUJ7p3VK4VEE13/ClrWQNsE4Vb1WSiM6ie9BB69+8GiFtppBw75Ldo1z6 hVspbUG4momWw6u98s09y+JtoMes5U1sZAyvUcqtsiISyBmLOQZjYNY+SlLIOHwg7tqOoHqn+mku hFZyxBLvpw+0tLdCIXLMDreBHR3xS2jgGOz5qZFtgBWgHU2Mb8dvRHXVuxaUKGCk4nbnmTlVt7I/ DZtDYnMGPXTIqjQCO6Z+mfXXAICIBh3jiY2kk+qgWQLOTIxKn0zStaC3LhnWrMQR1AEeunbzCwNf DQScG/ZV5Lw76sEVpOBOA9cVbkTc4ircMnbjFXpThhI4bS3e9JM9lcO2IWFwpltogURjr7/o1/00 qWhCgZfynmH4GDl8nMgZc/A99cG+ntrvYGldM9AHWJalVVVVV+JAnxdpPqosyKGJksNXzsR6qRWA hBpEUbVs6ZOosshvTOVKbkSo0ztPXSKwEIukRupXAWUXhxsI6caFpkQoCWA72E9TChZZFZASwnVt 6mFB07pBkRsos1tJJljBx9eE7YiuKFQOF0z3svtVoc64YOC8kgjtriNbTUTJPe/uo3XRCSIOePrw 7IpbcBUXJV6esk+ugQi6lyaDPqMHtFBFbTBLErILE76cQo4mnURPs5RjQtmDD8STMz6aNxoBbdWt 0XV9Yatn80eqi7ous+0NX90eqkbSq+LBBA8J5hjn48uMadld2K/FnT+7l9NdzLmjkHD3d6d3x9fR XTX4/D1R7emY7a/R9yv0fcr9H3K/R9yv0fcr9H3K/R9yv0fcr9H3K/R9yv0fcr9H3K/R9yv0fcr9 H3K/R9yv0fcr9H3K/R9yv0fcr9H3K/R9yv0fcocLha9mnTPqr//Z ------=0GU_01N2816YL_09O.291P12N0-- From simple-bounces@ietf.org Mon Feb 7 10:49:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10766; Mon, 7 Feb 2005 10:49:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyBRg-0003PZ-9y; Mon, 07 Feb 2005 11:09:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyB6R-0001nu-9h; Mon, 07 Feb 2005 10:47:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyB04-0000Ry-MS; Mon, 07 Feb 2005 10:40:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09864; Mon, 7 Feb 2005 10:40:29 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyBJU-0003Cd-1b; Mon, 07 Feb 2005 11:00:36 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-4.cisco.com with ESMTP; 07 Feb 2005 07:40:07 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j17FdqTj026698; Mon, 7 Feb 2005 07:39:52 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-29.cisco.com [10.86.240.29]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHO29982; Mon, 7 Feb 2005 07:39:50 -0800 (PST) Message-ID: <42078BC6.2080608@cisco.com> Date: Mon, 07 Feb 2005 10:39:50 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Simple] substitution groups vs. any elements References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Let me give a use case to motivate the "any" approach. I service provider foo.com has deployed presence services. They have soft clients from vendor X, presence servers from vendor Y, and xcap servers from vendor Z. Xcap servers are provided as part of the database infrastructure and thus separate from the presence server itself. The service provider wishes to roll out a new type of presence permission, proprietary to the service provider, that gives three levels of clearance - , and . The client and presence server are upgraded to allow these new permissions to be understood. But, since the xcap server is from a different vendor, it is not yet upgraded. As such, it doesn't understand these namespaces. With substitution groups, the xcap server will reject any permissions documents that contain these new permissions. With the "any" approach, they will be accepted, and then properly understood by the presence server. In the event that a client places the wrong permission name into the document (for example, the client places into the document), the xcap server will still allow this. However, the permission will be ignored by the presence server and thus the system remains privacy safe. The argument made in the threads to date on this topic were that xcap provided sufficient negotiation techniques that the client could discover that the new permissions were not supported, and then retry the request without them. The use case above highlights that in its role as middleman to the actual application, there are cases where we may not want the xcap server to be the bottleneck. I do hope that permissions is an area of innovation and differentiation amongst providers; this is one of the reasons we have developed the common policy capabilities usages, to allow for dynamic discovery of supported permissions: http://www.jdrosen.net/papers/draft-rosenberg-simple-common-policy-caps-01.txt http://www.jdrosen.net/papers/draft-rosenberg-simple-pres-policy-caps-01.txt Using substitution groups, imho, makes the system less flexible in exactly this area where we want to be flexible. Thanks, Jonathan R. Andrew Newton wrote: > All, > > There remains one last, unresolved issue with > draft-ietf-geopriv-common-policy, and that is with regard to the usage > of substitution groups (requiring derivation of elements) vs. any > element. Many excellent points have been made for both cases, which > leads Allison and I to believe that we are not all on the same page with > respect to usage scenarios. > > Perhaps it would be best if we had some use cases for voice, IM, and > emergency call routing to illustrate the need for one approach vs. the > other. In each use case we should look to see if the using protocol > gives us proper protocol/namespace/schema negotiation as to allow a > sender to understand the capabilities of the receiver (which XML Schemas > the receiver knows about) and if any privacy is compromised should the > sender use elements not understood by the receiver. > > -andy > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 7 10:51:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10970; Mon, 7 Feb 2005 10:51:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyBU6-0003U2-Ni; Mon, 07 Feb 2005 11:11:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyB6X-0001po-43; Mon, 07 Feb 2005 10:47:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyB1a-0000k6-VV for simple@megatron.ietf.org; Mon, 07 Feb 2005 10:42:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10062 for ; Mon, 7 Feb 2005 10:42:04 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyBL0-0003H3-F8 for simple@ietf.org; Mon, 07 Feb 2005 11:02:10 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j17Fg4c18628 for ; Mon, 7 Feb 2005 17:42:04 +0200 (EET) X-Scanned: Mon, 7 Feb 2005 17:52:58 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j17Fqws8013389 for ; Mon, 7 Feb 2005 17:52:58 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00bOru4Z; Mon, 07 Feb 2005 17:52:57 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j17FesU01026 for ; Mon, 7 Feb 2005 17:40:54 +0200 (EET) Received: from agni.research.nokia.com ([172.21.50.36]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 7 Feb 2005 17:40:51 +0200 Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.11/8.12.11) with ESMTP id j17FemEo021827 for ; Mon, 7 Feb 2005 17:40:48 +0200 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.11/8.12.11/Submit) id j17Femp7021826; Mon, 7 Feb 2005 17:40:48 +0200 To: simple@ietf.org X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G; ~L}uZ\JfD\"IG#G{j`hZI; =DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi Date: Mon, 07 Feb 2005 17:40:48 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 07 Feb 2005 15:40:51.0566 (UTC) FILETIME=[672CA0E0:01C50D2B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Simple] More ABNF issues with MSRP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Hello all, I've been fiddling with message-sessions-09 grammar again... 1) "_" is not allowed in ABNF names, it looks like ABNF is defined by some Lisp hackers. So, use instead of . 2) There has been discussion on SIP list about TLS over SCTP, for instance. Now the grammar defines the transport parameter as 1*ALPHANUM, not very nice if you want to use tls-sctp between relays. Use transport = 1*unreserved, for instance? 3) Proposed grammar for the path attribute allows only MSRP URLs, however, and can have non-MSRP URLs in them. It looks like the current and grammar, is an oversight, they should allow only MSRP-urls. 4) is but can only contain ASCII. Again, an oversight, allow in , too? 5) utf8text allows invalid UTF-8 sequences (they were allowed in RFC 2279, but not in 3629). Use grammar with only 2, 3 or 4 byte sequences: UTF8-NONASCII = %xC2-DF 1UTF8-CONT / %xE0-EF 2UTF8-CONT / %xF0-F7 3UTF8-CONT UTF8-CONT = %x80-BF Alternatively, use UTF8 grammar from RFC 3629. 6) Reference [14] should have RFC 3629, *not* 3269. 7) Section 7.1 talks about request contents. It would be nice to mention that there is no empty line between headers and closing sequence if there is no body in the request. --Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 7 10:57:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11687; Mon, 7 Feb 2005 10:57:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyBa3-0003ft-0h; Mon, 07 Feb 2005 11:17:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyBFG-0003aT-IO; Mon, 07 Feb 2005 10:56:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyB7Y-00021V-SI for simple@megatron.ietf.org; Mon, 07 Feb 2005 10:48:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10721 for ; Mon, 7 Feb 2005 10:48:14 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyBQy-0003OZ-7L for simple@ietf.org; Mon, 07 Feb 2005 11:08:20 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-4.cisco.com with ESMTP; 07 Feb 2005 07:47:52 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j17FlfTj000950; Mon, 7 Feb 2005 07:47:42 -0800 (PST) Received: from cisco.com (watson.cisco.com [161.44.79.130]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOX13285; Mon, 7 Feb 2005 10:47:40 -0500 (EST) Message-ID: <42078D9B.8030304@cisco.com> Date: Mon, 07 Feb 2005 10:47:39 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] Three dimensions of service References: <200502071427.JAA02924@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" , "'Henning Schulzrinne'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: 7bit Brian Rosen wrote: > Henning > > I'm not sure I understand the difference between D2 and D3, unless you > somehow think that D2 can be specified in some way that without additional > knowledge you can automatically determine how to interact with it. > > I think there are only two dimensions: > D1, which are those characteristics that a service has that map into defined > protocol mechanisms > > D2, which are those characteristics that a service has that don't map into > precise SIP/SIMPLE protocol mechanisms and depend more on the specification > of the service itself Brian, that definition of D2 is entirely circular, and hence useless. We can argue about the precise difference between D2 and D3, and whether there is a difference or not. But as defined by Henning they are both related to the semantic content of the resulting session, rather than to the syntax of the session. I get the impression that you don't agree with that distinction. I think it is an important one to make. > I think you can enumerate services defined by D2 characteristics, and you > can have a specification for each of them that defines how they work, but > that's about it. I think that's sufficient. For presence, we need a > registry, and nothing else. For an IANA registry I think it is necessary to provide a template for the elements that must go into a specification for each one. What kinds of things would you expect to be in that, in order to describe "how they work"? > For D1, we have prescaps, as you observe. > > I think that's enough, but I think we need a notion of service and a > registry of services so that a presentity and its watchers have the same > characteristics in mind when they see the service in the tuple. We have to ban that word "service"! We currently have a definition of service, that doesn't include this. And at the very least, what you are talking about, which is roughly what Henning is talking about, is another dimension or two in the description of a service. Call it D2 if you like, but not "service", or we will continue to tie ourselves in knots. > With respect to PTT, you can argue all you want about whether there is some > kind of generic meaning to PTT, but I claim it doesn't matter; no one will > ever precisely define it, and no one needs a generic PTT to be defined. So Sprint PTT, Nextel PTT, and OMA PTT will all continue forever to be different "services" that cannot interoperate? On the contrary, I think the world needs for these to converge. Helping them to diverge is not a good way forward. Making everybody carefully think through exactly what is unique about what they are doing has got to help. > The > OMA guys can define their version of PTT, and someone else could define > their own notion of PTT. I don't want someone trying to guess what the > combination of, say, half duplex and floor control implies. It implies > nothing other than there is a floor and the media streams are half duplex. In the case of half-duplex, I agree there is a problem. But it is a problem to be fixed, by defining what it means, for by declaring it useless and obsolete. It is quite possible tht half-duplex is the wrong way to describe PTT. Because of the conference work, I think we have a better understanding of floor control. To the extent that PTT follows that model of floor control I don't think there is a problem. To the extent that this or that "PTT" uses some other mechanism for floor control, it may be that PTTs won't interoperate. This seems a lot to me like incompatibilities in supported codecs. We choose not to expose codecs in presence, even though incompatibilities there may prevent communication. I believe that is because it is assumed not to be a problem in practice - that there will almost always be some codec in common, or else a transcoder will be involved. In the case of floor control we may need to revisit that kind of assumption. Perhaps there needs to be a presence attribute that describes floor control, including the floor control protocol(s) supported. But I think if we can properly define floor control, then that is the only new thing needed to describe PTT. PTT is all about syntax of the signaling, not about the semantics of the media content. Paul > Brian > > >>-----Original Message----- >>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf >>Of Henning Schulzrinne >>Sent: Sunday, February 06, 2005 10:05 PM >>To: Simple WG >>Subject: [Simple] Three dimensions of service >> >>I think it might be helpful to dis-entangle describing a service into >>(at least) three dimensions: >> >>(D1) Protocol and network capabilities, describing what is necessary so >>that two devices can exchange messages. This encompasses most of >>prescaps. Knowing this won't guarantee that the service does what a >>human expect. For example, a user might be surprised to be connected to >>a robot when expecting a human to answer. >> >>(D2) Interaction capabilities: how does the service act - is it a human? >>does it only announce or only record? This applies across a range of >>protocols and media. >> >>(D3) Content - what gets conveyed by the media exchange. Am I talking to >>a flight reservation system or a Doom character or the game audio >>background music? This clarly applies to a range of media, protocol >>capabilities and even interaction styles. (Flight information can be >>delivered by a human or multiple kinds of robots.) >> >>PTT is mostly a media signaling and floor control mechanism and doesn't >>really affect D2 and D3. >> >>There seems to be some hierarchy, with D1 as the lowest level, but I >>don't think that particularly matters for the discussion. In some cases, >>only one or two of the three dimensions may be known or relevant. >> >>D1 and D2 seem to be more amenable to enumeration, while it seems to >>require a full-blown ontology to do justice to D3, so that we may simply >>have to live with free text and maybe rendering hints (e.g., icons). >> >>A service tuple should have a unique combination of these dimensions, >>which includes the "I don't know", "can be any one of a subset of them - >>call and you'll find out" and "I won't tell you" cases for any one of >>them. >> >>Henning >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 7 13:22:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26515; Mon, 7 Feb 2005 13:22:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyDqk-0007Pi-S8; Mon, 07 Feb 2005 13:43:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyDUr-0007Au-Fy; Mon, 07 Feb 2005 13:20:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyDPc-0006CJ-KF for simple@megatron.ietf.org; Mon, 07 Feb 2005 13:15:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25766 for ; Mon, 7 Feb 2005 13:15:01 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyDj3-0007El-06 for simple@ietf.org; Mon, 07 Feb 2005 13:35:10 -0500 Received: from lion.cs.columbia.edu (IDENT:7kNvo0R7agRcAHxRWXrp/r+LOIrFRYuI@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j17IDvir012736 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 7 Feb 2005 13:13:58 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id j17IDvRn018019 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 7 Feb 2005 13:13:57 -0500 Message-ID: <4207AFE0.9050203@cs.columbia.edu> Date: Mon, 07 Feb 2005 13:13:52 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] Three dimensions of service References: <200502071427.JAA02924@ietf.org> <42078D9B.8030304@cisco.com> In-Reply-To: <42078D9B.8030304@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit > We can argue about the precise difference between D2 and D3, and whether > there is a difference or not. But as defined by Henning they are both > related to the semantic content of the resulting session, rather than to > the syntax of the session. I made the distinction for somewhat pragmatic reasons: The D2 differences are observable pretty much by looking at bit flows and boxes. You can tell an answering service by the box it uses, regardless of whether it returns the weather or sports scores. (From a presence perspective, there is also the idea that some kinds of OPEN are more useful for deriving person-level presence. The availability of answering services, for example, is pretty useless for that.) I don't think it is strictly necessary to make the distinction between D2 and D3, but it seems helpful, as the entities knowing the difference are likely different. An answering service or (VoiceXML) IVR service, say, can report itself as such without having to worry about what messages the owner records or what precise VoiceXML interaction is being offered. In summary: D1, D2 and D3 are all reported by different layers in a typical implementation. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 7 14:41:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04068; Mon, 7 Feb 2005 14:41:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyF4h-0000kC-UR; Mon, 07 Feb 2005 15:01:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyEgU-00038V-GL; Mon, 07 Feb 2005 14:36:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyEfO-0002ug-Az for simple@megatron.ietf.org; Mon, 07 Feb 2005 14:35:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03549 for ; Mon, 7 Feb 2005 14:35:22 -0500 (EST) Message-Id: <200502071935.OAA03549@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyEyo-0000a5-0e for simple@ietf.org; Mon, 07 Feb 2005 14:55:30 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1CyEfE-0004bL-T0; Mon, 07 Feb 2005 13:35:17 -0600 From: "Brian Rosen" To: "'Paul Kyzivat'" Subject: RE: [Simple] Three dimensions of service Date: Mon, 7 Feb 2005 14:35:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <42078D9B.8030304@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUNLF7KwTu8GOywRmWQsUX+X12FywAGfBwg X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" , "'Henning Schulzrinne'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Content-Transfer-Encoding: 7bit I'm sorry to be so difficult here, but you seem to be talking a language I don't understand, or at least, you seem to think things are a lot more standardizable than they are now, or I think they could be. See in-line > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, February 07, 2005 10:48 AM > To: Brian Rosen > Cc: 'Henning Schulzrinne'; 'Simple WG' > Subject: Re: [Simple] Three dimensions of service > > > > Brian Rosen wrote: > > Henning > > > > I'm not sure I understand the difference between D2 and D3, unless you > > somehow think that D2 can be specified in some way that without > additional > > knowledge you can automatically determine how to interact with it. > > > > I think there are only two dimensions: > > D1, which are those characteristics that a service has that map into > defined > > protocol mechanisms > > > > D2, which are those characteristics that a service has that don't map > into > > precise SIP/SIMPLE protocol mechanisms and depend more on the > specification > > of the service itself > > Brian, that definition of D2 is entirely circular, and hence useless. We must be talking past each other. I'm saying that we can't define a service by its protocol characteristics; two services may have the same protocol offer/answer/capabilities, and one service might, in different sessions have different protocol offer/answer/capabilities. I'm suggesting that you can write a specification defining a service, and you can have a registry that allows you to use a name (as an ID) in a protocol mechanism to precisely differentiate one service from another. > > We can argue about the precise difference between D2 and D3, and whether > there is a difference or not. But as defined by Henning they are both > related to the semantic content of the resulting session, rather than to > the syntax of the session. Here is an example of where I am lost. I haven't the faintest idea of what you mean. The "semantic content of a resulting session" can't be known to anyone but the humans; not even the automatons know what the semantic content is. The semantic content of the protocol mechanisms used to establish the session might be specifiable, but I don't get that we are arguing about that exactly, although we are discussing what the semantic content of a tuple is. I know we aren't arguing about syntax of protocol mechanisms, at least yet. > > I get the impression that you don't agree with that distinction. I think > it is an important one to make. Well, if I understood it, maybe I would agree. > > > I think you can enumerate services defined by D2 characteristics, and > you > > can have a specification for each of them that defines how they work, > but > > that's about it. I think that's sufficient. For presence, we need a > > registry, and nothing else. > > For an IANA registry I think it is necessary to provide a template for > the elements that must go into a specification for each one. Not necessarily, and I'm not really sure if that is needed here. What we need really is just to make sure that when a service is called out in a tuple, both ends understand what it means, and for that, a unique ID, which is bound to some kind of document, is sufficient. > > What kinds of things would you expect to be in that, in order to > describe "how they work"? What media streams are supported, and how they relate to one another, what kinds of control mechanisms (such as floor control) are supported, and how they relate to the media streams. Things like that. > > > For D1, we have prescaps, as you observe. > > > > I think that's enough, but I think we need a notion of service and a > > registry of services so that a presentity and its watchers have the same > > characteristics in mind when they see the service in the tuple. > > We have to ban that word "service"! Not hung up on names. Suggest another. > > We currently have a definition of service, that doesn't include this. > And at the very least, what you are talking about, which is roughly what > Henning is talking about, is another dimension or two in the description > of a service. Call it D2 if you like, but not "service", or we will > continue to tie ourselves in knots. Not sure if the word service is the source of the problem. I think its that you expect to be able to recognize a particular set of protocol "settings" as implying a specific set of endpoint behaviors (such as voice+floor control+half duplex = someone's definition of PTT). I don't think that is possible. > > > With respect to PTT, you can argue all you want about whether there is > some > > kind of generic meaning to PTT, but I claim it doesn't matter; no one > will > > ever precisely define it, and no one needs a generic PTT to be defined. > > So Sprint PTT, Nextel PTT, and OMA PTT will all continue forever to be > different "services" that cannot interoperate? OMA can define a service, and Nextel or Sprint could choose to implement it. If they did, their services would be interoperable. If they didn't they wouldn't be. No one is going to be able to claim that OMA has defined PTT. They have defined one possible implementation of a service called PTT. Sprint can, if it wants to, define another service, which Nextel might now have to implement. We care, in presence, that an endpoint tell us what service it supports, which could be the Sprint PTT, the OMA PTT, both, neither, ... There is no one, universally agreed definition of PTT, and I don't think there is going to be. Like conferencing, we COULD create a generic kind of service definition with options, but, like conferencing, we would have to create or extend the available protocol mechanisms to enable or distinguish the options. > > On the contrary, I think the world needs for these to converge. Helping > them to diverge is not a good way forward. Making everybody carefully > think through exactly what is unique about what they are doing has got > to help. Oh, I'd prefer if we all settle on one definition, for sure. I just don't think there is any way that we can state that whenever you see audio+floor control+half duplex, you can infer that you have that commonly agreed definition of PTT. > > > The > > OMA guys can define their version of PTT, and someone else could define > > their own notion of PTT. I don't want someone trying to guess what the > > combination of, say, half duplex and floor control implies. It implies > > nothing other than there is a floor and the media streams are half > duplex. > > In the case of half-duplex, I agree there is a problem. But it is a > problem to be fixed, by defining what it means, for by declaring it > useless and obsolete. It is quite possible tht half-duplex is the wrong > way to describe PTT. Maybe so. Not really the issue; it's a symptom of the problem we are having, not the cause of it. > > Because of the conference work, I think we have a better understanding > of floor control. To the extent that PTT follows that model of floor > control I don't think there is a problem. To the extent that this or > that "PTT" uses some other mechanism for floor control, it may be that > PTTs won't interoperate. This seems a lot to me like incompatibilities > in supported codecs. I don't agree with this. The problem we are having with "service" is roughly analogous to the "media flow graph" problem in conferencing. I think you believe it is possible to infer what service is provided by what protocol mechanisms & capabilities are available. I think it's impossible to do that. > > We choose not to expose codecs in presence, even though > incompatibilities there may prevent communication. I believe that is > because it is assumed not to be a problem in practice - that there will > almost always be some codec in common, or else a transcoder will be > involved. Yes, I understand that. I don't really see the connection to the problem at hand, because there are no equivalent assumptions. Here, we are trying to discover if you can infer from the "knobs" what the "service" is. If there were a small number of possible services, and we had a sufficient number of knobs, that should be possible. I don't think we have that case. > > In the case of floor control we may need to revisit that kind of > assumption. Perhaps there needs to be a presence attribute that > describes floor control, including the floor control protocol(s) > supported. But I think if we can properly define floor control, then > that is the only new thing needed to describe PTT. PTT is all about > syntax of the signaling, not about the semantics of the media content. Nope. Unless you extend floor control to define EXACTLY how the floor affects the media stream, and you define in SIP how you relate a specific floor to a specific media stream, or set of streams, then I think you can't get where you seem to want to go. I'll take that back because there is no assumption that a floor has to affect a media stream. It could, but it doesn't have to. I have this black box. I tell you that the black box has one audio channel, one floor, and the audio is half duplex. You want to say "ah ha, you must support PTT. I support PTT, therefore if I initiate a session with you, we'll all be happy". I think you are dreaming, and that there are several services that can be constructed with those parts. I want to say "here is a document that defines a service called Foo. Endpoints that support foo must support audio, one floor and either half or full duplex. When you have the floor, you may send audio. When you don't have the floor, any audio sent will be ignored, ..." If you implement Foo, and I say in my presence that I can support Foo, when you call me on the contact in that tuple, we'll be able to interoperate. Again, sorry to be a pain here. I know I'm holding up progress. Brian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 7 16:29:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22478; Mon, 7 Feb 2005 16:29:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyGl8-0005mA-3O; Mon, 07 Feb 2005 16:49:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyGGp-0000BC-GW; Mon, 07 Feb 2005 16:18:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyFgF-0004HF-Ss for simple@megatron.ietf.org; Mon, 07 Feb 2005 15:40:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11534 for ; Mon, 7 Feb 2005 15:40:21 -0500 (EST) Message-Id: <200502072040.PAA11534@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyFzh-00029d-Jm for simple@ietf.org; Mon, 07 Feb 2005 16:00:30 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1CyFgC-00089u-7S; Mon, 07 Feb 2005 14:40:20 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Paul Kyzivat'" Subject: RE: [Simple] Three dimensions of service Date: Mon, 7 Feb 2005 15:40:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <4207AFE0.9050203@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUNQMvoT8uUqYmqRSuZIJ1sH4MlWgADN/Cw X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit The problem I have here is that while for something like an IVR service, the difference between one that gives weather and one that gives sports scores is not implementation of the client dependent. So I agree that we don't need to define them differently with respect to presence. Using Paul's PTT example is better, because we can definitely have two services that have the same protocol characteristics and thus won't be differentiateable by looking at prescaps and other defined mechanisms. That's why I don't see the usefulness of differentiating between D2 and D3 if the only difference is that you can observe protocol mechanisms/capabilities etc for D2 and not for D3. Services are not in general differentiateable from each other by such things. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, February 07, 2005 1:14 PM > To: Paul Kyzivat > Cc: Brian Rosen; 'Simple WG' > Subject: Re: [Simple] Three dimensions of service > > > We can argue about the precise difference between D2 and D3, and whether > > there is a difference or not. But as defined by Henning they are both > > related to the semantic content of the resulting session, rather than to > > the syntax of the session. > > I made the distinction for somewhat pragmatic reasons: The D2 > differences are observable pretty much by looking at bit flows and > boxes. You can tell an answering service by the box it uses, regardless > of whether it returns the weather or sports scores. (From a presence > perspective, there is also the idea that some kinds of OPEN are more > useful for deriving person-level presence. The availability of answering > services, for example, is pretty useless for that.) > > I don't think it is strictly necessary to make the distinction between > D2 and D3, but it seems helpful, as the entities knowing the difference > are likely different. An answering service or (VoiceXML) IVR service, > say, can report itself as such without having to worry about what > messages the owner records or what precise VoiceXML interaction is being > offered. > > In summary: D1, D2 and D3 are all reported by different layers in a > typical implementation. > > Henning > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 7 17:43:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08132; Mon, 7 Feb 2005 17:43:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyHvK-0002GU-Oa; Mon, 07 Feb 2005 18:04:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyHWd-000478-OV; Mon, 07 Feb 2005 17:38:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyHLO-0008Ni-HI for simple@megatron.ietf.org; Mon, 07 Feb 2005 17:26:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06688 for ; Mon, 7 Feb 2005 17:26:55 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyHep-0001rF-2S for simple@ietf.org; Mon, 07 Feb 2005 17:47:06 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 07 Feb 2005 14:26:35 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j17MQMwN022807 for ; Mon, 7 Feb 2005 14:26:22 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-94.cisco.com [10.86.242.94]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHO64574; Mon, 7 Feb 2005 14:26:21 -0800 (PST) Message-ID: <4207EB0D.8090607@cisco.com> Date: Mon, 07 Feb 2005 17:26:21 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit Subject: [Simple] updated XCAP spec X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Folks, I just submitted an update to the xcap spec. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-simple-xcap-06.txt The draft assumes the query-string based approach for conveying the namespace bindings, per my note this morning. There are numerous other changes to the document based on comments on other issues that have come up in last call. Here is the list: * removed incorrect example of URI scheme constraint purportedly present in the xcap-list doc * removed old "todo" in the document, which had been resolved by using the xcap-diff format in 200 ok responses to DELETE * changed several of the xcap-error elements to and added the missing "phrase" attribute that is supposed to be common for all error types * fixed HTTP example messages, which should have been using the absolute path version of the request URI and include the Host header field. Added a comment in the section on URI about how the appearance of the URI in the request-URI needed to follow 2616 procedures which define what forms to use. * specification now requires XML documents to be UTF-8 encoded. Server behaviors are defined to check for this. A new XML error-response is defined for cases where a document is PUT to the server with a non-UTF-8 encoding, or where a PUT contains an element or attribute containing non UTF-8 characters. * escaping rules have been spceified for converting XML element names containing non-ascii UTF-8 characters into HTTP URL. * added example in section 6.2 * changed all instances of "URL" to "URI" * reworded section 7.10 on conditional operations to make it clear that, if you want to do a conditional insert, it means you need to modify the enclosing parent element conditionally. If you don't need conditioning, you can just do the insert and then use the xcap-diff in the response to check if your cached copy is up to date. * currently, xcap says that for dynamic xcap content, clients should use a low max-age cache directive. But really, if its going to be dynamic, it should be no-cache. So, the draft now only recommends a no-cache directive with SHOULD strength. * changed MIME registrations so that the .xml extension is not listed as valid for the body types we are using * added default namespace for URIs as part of the app usage definition * noted that scope of default namespace is to expand URIs, this includes URIs on request line but also ones embedded in an xcap document itself * changed matching rules for node selectors, so that namespace bindings for the URI are taken from the query string, and the default from the value defined for the app usage. Interestingly, this repairs a limitation that we formerly had, which made it impossible to select between two children of the same parent by element name, when they shared the same local name and prefix, but different namespace URI: this case now works. * added a section on the structure of XCAP URI which talks about the query component. It is a valid xpointer expression after escape coding. It SHOULD only contain xmlns() expressions, other xpointer expression types MUST be ignored. This gives us some flexibility to add other xpointer expression types down the road in the query string. * updated examples to show matching rules using query components and namespace bindings * updated client behavior to discuss when query component needs to be included. * updated server behavior - requests containing a prefix in a node selector that is not defined by an xmlns() expression in the query component are rejected with a 400 * the "field" attribute of the xcap-error is now an HTTP URI, as it may need to contain a query component to define namespace bindings. * updated references to rfc2396 to rfc3986 * xcap root URI section now talks about the fact that the xcap root can be a relative reference. In that case, the application usage has to define the base URI. The retrieval URI will not work, and this is mentioned. Also, the application usage section states that the application usages have to define base URI whenever they make use of a relative URI reference for an xcap resource. * updated AUID grammar to be an exact match for 1*pchar from RFC 3986 Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 7 17:45:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08286; Mon, 7 Feb 2005 17:45:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyHxI-0002JL-6a; Mon, 07 Feb 2005 18:06:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyHWe-00047T-Dk; Mon, 07 Feb 2005 17:38:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyHMx-0000Qx-DX for simple@megatron.ietf.org; Mon, 07 Feb 2005 17:28:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06795 for ; Mon, 7 Feb 2005 17:28:32 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyHgR-0001tC-7B for simple@ietf.org; Mon, 07 Feb 2005 17:48:43 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 07 Feb 2005 14:29:42 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j17MRuwN023609 for ; Mon, 7 Feb 2005 14:27:56 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-94.cisco.com [10.86.242.94]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHO64688; Mon, 7 Feb 2005 14:27:54 -0800 (PST) Message-ID: <4207EB6A.5070508@cisco.com> Date: Mon, 07 Feb 2005 17:27:54 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [Simple] updated XCAP list spec X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Folks, I've just submitted a minor update to the xcap resource list usage spec. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-simple-xcap-list-usage-05.txt The changes are: * added definitions of default namespace URIs * minor rewordings based on comments from GEN-ART review * updated references from rfc 2396 to rfc 3986 * replaced URL with URI * removed .xml from filename registrations Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 7 18:37:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16293; Mon, 7 Feb 2005 18:37:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyIl8-0004OQ-6D; Mon, 07 Feb 2005 18:57:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyIIt-0004Qp-Fq; Mon, 07 Feb 2005 18:28:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyI9b-0007IE-E5; Mon, 07 Feb 2005 18:18:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14639; Mon, 7 Feb 2005 18:18:48 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyIT4-0003zp-BA; Mon, 07 Feb 2005 18:38:59 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 07 Feb 2005 15:26:41 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j17NICq8001724; Mon, 7 Feb 2005 15:18:12 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-94.cisco.com [10.86.242.94]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHO69034; Mon, 7 Feb 2005 15:18:15 -0800 (PST) Message-ID: <4207F737.8070509@cisco.com> Date: Mon, 07 Feb 2005 18:18:15 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Geopriv] Re: [Simple] substitution groups vs. any elements References: <42078BC6.2080608@cisco.com> <98051BC2-7921-11D9-BC8F-000D9358DFD8@hxr.us> In-Reply-To: <98051BC2-7921-11D9-BC8F-000D9358DFD8@hxr.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit inline. Andrew Newton wrote: > For clarification, questions in-line: > > On Feb 7, 2005, at 10:39 AM, Jonathan Rosenberg wrote: > >> With substitution groups, the xcap server will reject any permissions >> documents that contain these new permissions. With the "any" approach, >> they will be accepted, and then properly understood by the presence >> server. In the event that a client places the wrong permission name >> into the document (for example, the client places >> into the document), the xcap server will still allow this. However, >> the permission will be ignored by the presence server and thus the >> system remains privacy safe. > > > To be it differently, the client would have sent the data anyway so no > loss of privacy. Correct? Yes. The error case I am talking about here is where a mis-configured or erroneous client tries to set a permission, but they have used the wrong name for the permission. If the xcap server was aware of the permission namespace, it would have rejected the clients request as invalid. But, here, it won't. As such, it will go to the presence server, where it will be ignored. The net result is that, in both cases, the same information gets sent. > >> The argument made in the threads to date on this topic were that xcap >> provided sufficient negotiation techniques that the client could >> discover that the new permissions were not supported, and then retry >> the request without them. The use case above highlights that in its >> role as middleman to the actual application, there are cases where we >> may not want the xcap server to be the bottleneck. > > > Or in other words, the negotiation is point-to-point not end-to-end. > Correct? I'm suggesting that there is a use case for that, yes. The end-to-end case isn't really "negotiation", in that the presence server never gets a chance to tell the client that the permission it tried to use is unknown. But, the argument is effectively that the permissions may need to be interpreted end-to-end, so to speak. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 7 22:38:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05117; Mon, 7 Feb 2005 22:38:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyMWf-0000dr-1H; Mon, 07 Feb 2005 22:58:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyMBw-0001Wk-7u; Mon, 07 Feb 2005 22:37:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyMB7-0001NP-TO; Mon, 07 Feb 2005 22:36:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05042; Mon, 7 Feb 2005 22:36:39 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyMUe-0000bv-Bh; Mon, 07 Feb 2005 22:56:52 -0500 Received: from razor.cs.columbia.edu (IDENT:U2FsdGVkX1+Zp8J51GUbpQAUzsvPqbmTnL76N2TQvCA@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j183aZir027511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Feb 2005 22:36:36 -0500 (EST) Received: from [127.0.0.1] (IDENT:U2FsdGVkX19EcJ/xwSycG9YWU4oPjNcEjZseOVUKvMs@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j183aYfG013247; Mon, 7 Feb 2005 22:36:34 -0500 Message-ID: <420833BE.6030706@cs.columbia.edu> Date: Mon, 07 Feb 2005 22:36:30 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Geopriv] Re: [Simple] substitution groups vs. any elements References: <42078BC6.2080608@cisco.com> In-Reply-To: <42078BC6.2080608@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Simple WG , Andrew Newton X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit To add in agreement: The notion that a submitter of a policy will inspect the response from XCAP and then clean up the document by removing bits and pieces, for no particularly good reason, seems rather optimistic. Doing this requires a fair amount of DOM manipulation. Many clients will probably have XML templates that they fill with values based on user input, rather than doing a full-bore DOM implementation. I certainly could imagine better places to spend my development resources than document trimming. Since the capabilities of the XCAP server can change at any time, particularly in the situation you describe, the client would have to re-discover these capabilities, i.e., retry and fail each time. There's an additional wrinkle: There may well be other means of getting policy on a server, beyond XCAP. Thus, you could easily wind up with a situation where the same document gets rejected one way and accepted the other. Not a good situation if you're doing customer support... A more general design principle lurks here: with two entities looking at an XML document, having the entity that only knows syntax check for extensions is asking for trouble. I suppose another version of the end-to-end principle :-) Henning Jonathan Rosenberg wrote: > Let me give a use case to motivate the "any" approach. > > I service provider foo.com has deployed presence services. They have > soft clients from vendor X, presence servers from vendor Y, and xcap > servers from vendor Z. Xcap servers are provided as part of the database > infrastructure and thus separate from the presence server itself. > > The service provider wishes to roll out a new type of presence > permission, proprietary to the service provider, that gives three levels > of clearance - , and . The > client and presence server are upgraded to allow these new permissions > to be understood. But, since the xcap server is from a different vendor, > it is not yet upgraded. As such, it doesn't understand these namespaces. > > With substitution groups, the xcap server will reject any permissions > documents that contain these new permissions. With the "any" approach, > they will be accepted, and then properly understood by the presence > server. In the event that a client places the wrong permission name into > the document (for example, the client places into the > document), the xcap server will still allow this. However, the > permission will be ignored by the presence server and thus the system > remains privacy safe. > > > The argument made in the threads to date on this topic were that xcap > provided sufficient negotiation techniques that the client could > discover that the new permissions were not supported, and then retry the > request without them. The use case above highlights that in its role as > middleman to the actual application, there are cases where we may not > want the xcap server to be the bottleneck. > > I do hope that permissions is an area of innovation and differentiation > amongst providers; this is one of the reasons we have developed the > common policy capabilities usages, to allow for dynamic discovery of > supported permissions: > > http://www.jdrosen.net/papers/draft-rosenberg-simple-common-policy-caps-01.txt > > http://www.jdrosen.net/papers/draft-rosenberg-simple-pres-policy-caps-01.txt > > > Using substitution groups, imho, makes the system less flexible in > exactly this area where we want to be flexible. > > Thanks, > Jonathan R. > > Andrew Newton wrote: > >> All, >> >> There remains one last, unresolved issue with >> draft-ietf-geopriv-common-policy, and that is with regard to the usage >> of substitution groups (requiring derivation of elements) vs. any >> element. Many excellent points have been made for both cases, which >> leads Allison and I to believe that we are not all on the same page >> with respect to usage scenarios. >> >> Perhaps it would be best if we had some use cases for voice, IM, and >> emergency call routing to illustrate the need for one approach vs. the >> other. In each use case we should look to see if the using protocol >> gives us proper protocol/namespace/schema negotiation as to allow a >> sender to understand the capabilities of the receiver (which XML >> Schemas the receiver knows about) and if any privacy is compromised >> should the sender use elements not understood by the receiver. >> >> -andy >> >> >> _______________________________________________ >> 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 Feb 7 22:59:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06531; Mon, 7 Feb 2005 22:59:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyMqg-00012S-Am; Mon, 07 Feb 2005 23:19:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyMVS-0008J8-73; Mon, 07 Feb 2005 22:57:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyMUd-00087W-SH for simple@megatron.ietf.org; Mon, 07 Feb 2005 22:56:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06329 for ; Mon, 7 Feb 2005 22:56:49 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyMoA-0000zb-Ii for simple@ietf.org; Mon, 07 Feb 2005 23:17:02 -0500 Received: from razor.cs.columbia.edu (IDENT:U2FsdGVkX194in8i5yWM/PVJKJIOsJHNJV8ZJ4cTFuM@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j183ubir001577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Feb 2005 22:56:38 -0500 (EST) Received: from [127.0.0.1] (IDENT:U2FsdGVkX1/Kco7Qsvrh6ZoszIfrD0n99Aq9qbpqaqY@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j183uaXw013280; Mon, 7 Feb 2005 22:56:37 -0500 Message-ID: <42083874.60408@cs.columbia.edu> Date: Mon, 07 Feb 2005 22:56:36 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] Three dimensions of service References: <200502071935.j17JZIir000054@cs.columbia.edu> In-Reply-To: <200502071935.j17JZIir000054@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: "'Paul Kyzivat'" , "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit > Here is an example of where I am lost. I haven't the faintest idea of what > you mean. The "semantic content of a resulting session" can't be known to Obviously, for many normal conversations, the semantic content is not defined beyond "human-to-human conversation". But for many of the services that have been used as examples, they are precisely distinguished by the fact that they don't lead to normal human conversation, but instead to talking to a Doom game engine or other services. For some human-to-human communications, semantic content can be described to the extent that it is useful to distinguish tuples; see my airline information example. While the Delta airlines rep may be willing to talk about the weather and your new startup company if pressed, they may still want to advertise the service as "flight information". > anyone but the humans; not even the automatons know what the semantic > content is. The semantic content of the protocol mechanisms used to > establish the session might be specifiable, but I don't get that we are > arguing about that exactly, although we are discussing what the semantic > content of a tuple is. > > > Not necessarily, and I'm not really sure if that is needed here. What we > need really is just to make sure that when a service is called out in a > tuple, both ends understand what it means, and for that, a unique ID, which > is bound to some kind of document, is sufficient. We discussed indirection before (it was offered by somebody else) and there seemed to be agreement that indirection simply defers the problem to agreeing on what this document might contain. A description in unstructured English prose isn't any more useful than a notes field. > > >>What kinds of things would you expect to be in that, in order to >>describe "how they work"? > > What media streams are supported, and how they relate to one another, what > kinds of control mechanisms (such as floor control) are supported, and how > they relate to the media streams. Things like that. That's all D1 and D2 stuff. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From dtew.QRJJFXTNE@the-mathclub.net Tue Feb 8 06:01:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26240; Tue, 8 Feb 2005 06:01:01 -0500 (EST) Received: from [222.78.13.252] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CyTQi-00013u-B4; Tue, 08 Feb 2005 06:21:18 -0500 Received: from mundo718.trialarts.com (222.78.13.252) by 222.78.13.252 with Microsoft SMTP11834(3[1-2.1359.952.92); Tue, 08 Feb 2005 16:58:16 +0600 Received: from 222.78.13.252 (hasen[222.78.13.252]) by chambers230.trialarts.com (jefgaglh5354) with SMTP id <4790431bgev7008uu>;Tue, 08 Feb 2005 07:58:16 -0300 Message-ID: Reply-To: "trudi dolginof" From: "trudi dolginof" To: esg@ietf.org Cc: mailman-admin@ietf.org, l-admin@ietf.org, manet-admin@ietf.org, rip-admin@ietf.org, hc-admin@ietf.org, cna@ietf.org, simple-archive@ietf.org, imrg-request@ietf.org, seamoby-web-archive@ietf.org Subject: Online Notification: You've Been Approved Date: Tue, 08 Feb 2005 09:55:16 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--60194_91860302.t7481" X-Spam-Score: 6.2 (++++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----60194_91860302.t7481 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Hello Account #0152312, Your application was approved. You are eligible for $400,000 with a 3.7 % rate. Please confirm your information here: http://citric.wexvd.info:443/azwmlbranch We look forward to hearing from you. Regards, trudi dolginof, Senior Account Manager KNM Financial Group r*mv. -> http://feliks.wexvd.info:443/index.php ----60194_91860302.t7481-- From simple-bounces@ietf.org Tue Feb 8 08:32:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08404; Tue, 8 Feb 2005 08:32:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyVnj-0004eg-0P; Tue, 08 Feb 2005 08:53:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyVSu-0002YH-IV; Tue, 08 Feb 2005 08:31:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyVQY-000281-E1 for simple@megatron.ietf.org; Tue, 08 Feb 2005 08:29:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08177 for ; Tue, 8 Feb 2005 08:29:13 -0500 (EST) Message-Id: <200502081329.IAA08177@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyVk9-0004aM-VQ for simple@ietf.org; Tue, 08 Feb 2005 08:49:30 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1CyVQQ-0005zI-4P; Tue, 08 Feb 2005 07:29:06 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Simple] Three dimensions of service Date: Tue, 8 Feb 2005 08:28:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <42083874.60408@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUNkjQTRShmJxP7TN6gEbtYeRWu5AAS2nqw X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: "'Paul Kyzivat'" , "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit I still can't fathom what you are talking about, but I don't think it matters. You, and Paul, think you can infer the end device requirements to initiate a session to a service by the protocol visible characteristics that a presence tuple would give you, and you believe that it should be possible to describe services in terms of (presumably unique) sets of these characteristics. I think you are dreaming, and most services cannot be so simply defined. The most common services could be (basic telephony, instant messages, and the like). I think all the other examples we have used, including Doom and PTT cannot. If Doom supplies audio out, but not audio in, what device would be suitable? If you call it with a telephone, would anything useful happen? How would you know? Suppose it has two audio outputs with labels "Left" and "Right"? You, as a human, can guess what that means. How would an arbitrary client that had ways to handle multiple input streams (i.e. local mixing capability). Suppose doom supports audio in and out. Now what devices are suitable? Suppose it has a floor control. Does that floor control the audio in? How do you know? You know only if you know what "Doom" means. Doom is a service. You cannot tell from the presence visible characteristics. Some other document has to tell a client what Doom means. The same is true of PTT. Sprint PTT and OMA PTT are different services. They work differently. You can't tell the difference from the presence visible characteristics. I think this is an unsolvable problem; we will never be able to infer how a service works, and thus how to make a good endpoint, if all we have are the presence visible characteristics. I think services are always defined by a document that describes the service with sufficient detail that an excellent client could be built. It may be possible for a general purpose device to initiate a session with a service it was not built for, and get an acceptable enough user experience, but if you wanted a good user experience, you need to know how the service works. I think we need to uniquely name services, and have the name be associated with a document. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, February 07, 2005 10:57 PM > To: Brian Rosen > Cc: 'Paul Kyzivat'; 'Simple WG' > Subject: Re: [Simple] Three dimensions of service > > > > Here is an example of where I am lost. I haven't the faintest idea of > what > > you mean. The "semantic content of a resulting session" can't be known > to > > Obviously, for many normal conversations, the semantic content is not > defined beyond "human-to-human conversation". But for many of the > services that have been used as examples, they are precisely > distinguished by the fact that they don't lead to normal human > conversation, but instead to talking to a Doom game engine or other > services. For some human-to-human communications, semantic content can > be described to the extent that it is useful to distinguish tuples; see > my airline information example. While the Delta airlines rep may be > willing to talk about the weather and your new startup company if > pressed, they may still want to advertise the service as "flight > information". > > > > anyone but the humans; not even the automatons know what the semantic > > content is. The semantic content of the protocol mechanisms used to > > establish the session might be specifiable, but I don't get that we are > > arguing about that exactly, although we are discussing what the semantic > > content of a tuple is. > > > > > > Not necessarily, and I'm not really sure if that is needed here. What > we > > need really is just to make sure that when a service is called out in a > > tuple, both ends understand what it means, and for that, a unique ID, > which > > is bound to some kind of document, is sufficient. > > We discussed indirection before (it was offered by somebody else) and > there seemed to be agreement that indirection simply defers the problem > to agreeing on what this document might contain. A description in > unstructured English prose isn't any more useful than a notes field. > > > > > > > >>What kinds of things would you expect to be in that, in order to > >>describe "how they work"? > > > > What media streams are supported, and how they relate to one another, > what > > kinds of control mechanisms (such as floor control) are supported, and > how > > they relate to the media streams. Things like that. > > That's all D1 and D2 stuff. > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 8 09:19:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11747; Tue, 8 Feb 2005 09:19:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyWWh-0005cv-70; Tue, 08 Feb 2005 09:39:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyWBG-0000BI-M6; Tue, 08 Feb 2005 09:17:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyW6N-00020W-Tp for simple@megatron.ietf.org; Tue, 08 Feb 2005 09:12:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11297 for ; Tue, 8 Feb 2005 09:12:26 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyWPw-0005Uk-VY for simple@ietf.org; Tue, 08 Feb 2005 09:32:44 -0500 Received: from razor.cs.columbia.edu (IDENT:U2FsdGVkX18xnij4nuRhx4MI2H2tRvtM9HObXuJATwY@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j18ECJir009489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Feb 2005 09:12:20 -0500 (EST) Received: from [127.0.0.1] (IDENT:U2FsdGVkX19Z7e3IE6+q6vOW7YUus/ohTB5/rb7H/Vs@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j18ECJxM015158; Tue, 8 Feb 2005 09:12:19 -0500 Message-ID: <4208C8C1.6080808@cs.columbia.edu> Date: Tue, 08 Feb 2005 09:12:17 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] Three dimensions of service References: <200502081329.j18DT7ir001520@cs.columbia.edu> In-Reply-To: <200502081329.j18DT7ir001520@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: "'Paul Kyzivat'" , "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Brian, you still haven't answered what this magic document you describe would contain that could not be contained in a presence document. I agree that while you can get basic interoperability using presence descriptions, this may not be sufficient for more than getting bits to flow and initiating the right software components. But in many cases, that's sufficient - the software application doesn't have to know that the left and right channel of audio refer to the moderator and speaker, respectively. Through either in-band (notes) or out of band (I know I'm connecting to a particular session), the user can figure this out. I have no hope of conveying in a structured document the meaning of Doom - and I see little point of trying. In my D3, you would simply indicate "Game/Doom" or something of that nature. You'd basically need the user's manual to tell the recipient what to do with the information and what user interactions make sense. Henning Brian Rosen wrote: > I still can't fathom what you are talking about, but I don't think it > matters. > > You, and Paul, think you can infer the end device requirements to initiate a > session to a service by the protocol visible characteristics that a presence > tuple would give you, and you believe that it should be possible to describe > services in terms of (presumably unique) sets of these characteristics. > > I think you are dreaming, and most services cannot be so simply defined. > The most common services could be (basic telephony, instant messages, and > the like). I think all the other examples we have used, including Doom and > PTT cannot. > > If Doom supplies audio out, but not audio in, what device would be suitable? > If you call it with a telephone, would anything useful happen? How would > you know? Suppose it has two audio outputs with labels "Left" and "Right"? > You, as a human, can guess what that means. How would an arbitrary client > that had ways to handle multiple input streams (i.e. local mixing > capability). Suppose doom supports audio in and out. Now what devices are > suitable? Suppose it has a floor control. Does that floor control the > audio in? How do you know? > > You know only if you know what "Doom" means. Doom is a service. You cannot > tell from the presence visible characteristics. Some other document has to > tell a client what Doom means. > > The same is true of PTT. Sprint PTT and OMA PTT are different services. > They work differently. You can't tell the difference from the presence > visible characteristics. > > I think this is an unsolvable problem; we will never be able to infer how a > service works, and thus how to make a good endpoint, if all we have are the > presence visible characteristics. I think services are always defined by a > document that describes the service with sufficient detail that an excellent > client could be built. It may be possible for a general purpose device to > initiate a session with a service it was not built for, and get an > acceptable enough user experience, but if you wanted a good user experience, > you need to know how the service works. > > I think we need to uniquely name services, and have the name be associated > with a document. > > Brian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 8 09:56:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14229; Tue, 8 Feb 2005 09:56:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyX6G-0006Ny-Sn; Tue, 08 Feb 2005 10:16:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyWlL-0008QT-A0; Tue, 08 Feb 2005 09:54:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyWhP-0007UW-Ec for simple@megatron.ietf.org; Tue, 08 Feb 2005 09:50:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13929 for ; Tue, 8 Feb 2005 09:50:41 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyX10-0006G9-Dz for simple@ietf.org; Tue, 08 Feb 2005 10:10:59 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2005 08:01:41 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j18Eo4uE024802; Tue, 8 Feb 2005 06:50:08 -0800 (PST) Received: from cisco.com ([161.44.79.182]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOX90445; Tue, 8 Feb 2005 09:50:04 -0500 (EST) Message-ID: <4208D19B.60603@cisco.com> Date: Tue, 08 Feb 2005 09:50:03 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] Three dimensions of service References: <3q25r4$1ui3ff@sj-inbound-a.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" , "'Henning Schulzrinne'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Content-Transfer-Encoding: 7bit Brian Rosen wrote: > I still can't fathom what you are talking about, but I don't think it > matters. > > You, and Paul, think you can infer the end device requirements to initiate a > session to a service by the protocol visible characteristics that a presence > tuple would give you, and you believe that it should be possible to describe > services in terms of (presumably unique) sets of these characteristics. > > I think you are dreaming, and most services cannot be so simply defined. > The most common services could be (basic telephony, instant messages, and > the like). I think all the other examples we have used, including Doom and > PTT cannot. Maybe we aren't so far apart. I think the fundamental "thing" that we are describing in presence is availability to communicate - presentity to presentity. By that I mean unstructured communications between humans. Perhaps in your terms that would be considered a service. Absent some evidence to the contrary, when I "call" you that is what I expect. It isn't necessarily what I will get, but it is what I seek. For instance I may call you, but get your answering system, which gives me a kind of structured communication with an automaton rather than unstructured communication with you. I think 90% of what people want presence for is focused around that unstructured communication. We are getting hung up on the other 10%. Doom is probably a far fetched hypothetical, so we probably shouldn't give it so much emphasis in our discussions. Answering systems are of much more significance. At least we have them covered, in that we have a way to describe that a tuple represents one rather than a real human. I think there is indeed value in discussing how to broaden our ability to describe other structured forms of communication. But I don't think basic telephone, instant messaging, video, or real time text are different {services / whatever}. They are simply different media that may used for the same basic purpose of communication. I can have an unstructured communication session with you using any combination of these. Or, I can use combinations of these for various forms of structured communications - e.g. I could have an IM or RTT session with an answering system. Of course some specialized applications may not be so flexible in the media they are capable of using. But that isn't unusual either. Some humans also aren't so flexible. How accurately we need to describe those limitations is something we can discuss. But for the most part I think this is a limitation of an instance rather than a characteristic of a type. > If Doom supplies audio out, but not audio in, what device would be suitable? > If you call it with a telephone, would anything useful happen? How would > you know? Suppose it has two audio outputs with labels "Left" and "Right"? > You, as a human, can guess what that means. How would an arbitrary client > that had ways to handle multiple input streams (i.e. local mixing > capability). Suppose doom supports audio in and out. Now what devices are > suitable? Suppose it has a floor control. Does that floor control the > audio in? How do you know? > > You know only if you know what "Doom" means. Doom is a service. You cannot > tell from the presence visible characteristics. Some other document has to > tell a client what Doom means. *If* Doom requires the "caller" to use multiple media streams is very specialized ways, then I agree with you. But if Doom is really all about a single "Doom-control-protocol", accompanied by other streams that are used in the same way they are in normal unstructured communications, then I think we can expect the caller to figure it out well enough. > The same is true of PTT. Sprint PTT and OMA PTT are different services. > They work differently. You can't tell the difference from the presence > visible characteristics. The reason they work differently is because they are still emerging services. I still think this is all about the floor control, and is otherwise just unstructured communication. If they can claim to be sip based at all, the differences between them should be representable in signaling, and we should be able to represent that as capabilities. They may indeed be incompatible at the moment. I would expect that to be reflected as different features that can be negotiated, or not, such as different floor control protocols, different sorts of media streams, or something like that. If they are more radically different than that, then maybe they shouldn't be claiming to be sip at all. (As Jonathan has suggested.) As best I can tell, from the perspective of an endpoint, multi-party PTT is just a conference call where one-speaker-at-a-time is being enforced with floor control. The floor controller happens to have a special goal in mind as it manages the floor - to limit the bandwidth to each of the endpoints, but this need not be known by the endpoints. And 2-party PTT is just a special case of the multi-party version. So I don't see why it is rocket science for a UA to figure out what it should do when PTT is presented as a decomposed set of capabilities. > I think this is an unsolvable problem; we will never be able to infer how a > service works, and thus how to make a good endpoint, if all we have are the > presence visible characteristics. I think we can for the 90% of the cases involving unstructured human communication. If you like, consider that as a default "service description". I have no problem moving on to discuss how to represent the other 10%. And we've already made a start at the rest, by being able to describe answering services (message-taker), attendants, and automata. Clearly this isn't complete, and there is some doubt about how many dimensions are required to do the description, but it is still a start. We have a gap in that AFAIK we don't yet have a way to describe in a tuple that floor control is available and/or required, and what that means. There is of course considerable overlap with the conferencing work in this regard. It should be possible to provide presence for a conference. Perhaps you would consider a conference to be another kind of service - different from unstructured conversation with a human. But often that is an *optional* capability. (I can call a conference without knowing that is what it is, and have a satisfactory experience.) > I think services are always defined by a > document that describes the service with sufficient detail that an excellent > client could be built. It may be possible for a general purpose device to > initiate a session with a service it was not built for, and get an > acceptable enough user experience, but if you wanted a good user experience, > you need to know how the service works. As above, *if* you can have an acceptable experience without understanding this, then the rest is all *optional*, and can simply be another attribute or capability. What you are describing doesn't sound all that different to me than a resume of the person who will answer the call, or a description of the screen size of the video screen at the far end. > I think we need to uniquely name services, and have the name be associated > with a document. I think more than anything we have a terminology problem, and solving that might go at least half way to solving our other disagreements. The problem is with the term "service". In the presence model Jonathan has defined it, and it is what a tuple describes. You are using the term differently. It seems that you consider a service to be a "type" described by one of these documents. And then presumably you associate each tuple with one of these types. So in your terms there could be several tuples in a presence document, each being a distinct instance of the same service. We can't use the same term both ways. I suggest you choose a new term. We had a couple of bad names used earlier in this thread - D2 and D3. But I think it would be best if you choose a term and define it the way you think it should be defined, but in a way that is consistent with the presence model. Paul > Brian > > > > >>-----Original Message----- >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>Sent: Monday, February 07, 2005 10:57 PM >>To: Brian Rosen >>Cc: 'Paul Kyzivat'; 'Simple WG' >>Subject: Re: [Simple] Three dimensions of service >> >> >> >>>Here is an example of where I am lost. I haven't the faintest idea of >> >>what >> >>>you mean. The "semantic content of a resulting session" can't be known >> >>to >> >>Obviously, for many normal conversations, the semantic content is not >>defined beyond "human-to-human conversation". But for many of the >>services that have been used as examples, they are precisely >>distinguished by the fact that they don't lead to normal human >>conversation, but instead to talking to a Doom game engine or other >>services. For some human-to-human communications, semantic content can >>be described to the extent that it is useful to distinguish tuples; see >>my airline information example. While the Delta airlines rep may be >>willing to talk about the weather and your new startup company if >>pressed, they may still want to advertise the service as "flight >>information". >> >> >> >>>anyone but the humans; not even the automatons know what the semantic >>>content is. The semantic content of the protocol mechanisms used to >>>establish the session might be specifiable, but I don't get that we are >>>arguing about that exactly, although we are discussing what the semantic >>>content of a tuple is. >>> >>> >>>Not necessarily, and I'm not really sure if that is needed here. What >> >>we >> >>>need really is just to make sure that when a service is called out in a >>>tuple, both ends understand what it means, and for that, a unique ID, >> >>which >> >>>is bound to some kind of document, is sufficient. >> >>We discussed indirection before (it was offered by somebody else) and >>there seemed to be agreement that indirection simply defers the problem >>to agreeing on what this document might contain. A description in >>unstructured English prose isn't any more useful than a notes field. >> >> >> >>> >>>>What kinds of things would you expect to be in that, in order to >>>>describe "how they work"? >>> >>>What media streams are supported, and how they relate to one another, >> >>what >> >>>kinds of control mechanisms (such as floor control) are supported, and >> >>how >> >>>they relate to the media streams. Things like that. >> >>That's all D1 and D2 stuff. >> >> >> > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 8 13:21:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01771; Tue, 8 Feb 2005 13:21:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyaJW-0002eN-V1; Tue, 08 Feb 2005 13:42:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyZyy-0005c1-BP; Tue, 08 Feb 2005 13:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyZy5-0005QI-P8 for simple@megatron.ietf.org; Tue, 08 Feb 2005 13:20:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01625 for ; Tue, 8 Feb 2005 13:20:06 -0500 (EST) Message-Id: <200502081820.NAA01625@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyaHk-0002bl-0K for simple@ietf.org; Tue, 08 Feb 2005 13:40:28 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1CyZxk-0001fq-KC; Tue, 08 Feb 2005 12:19:49 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Simple] Three dimensions of service Date: Tue, 8 Feb 2005 13:19:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <4208C8C1.6080808@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUN6DTWULuzlwSRS/WknFmk+H+ZmwAIH6qA X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: "'Paul Kyzivat'" , "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit The magic document contains human understandable text that tells the reader how the service works. It probably also specifies what protocol mechanisms are employed, which are required and which are optional. I'm not arguing with what capabilities a service presents in the presence document that already have been defined. They are necessary. I don't think they are sufficient. It's always possible that if you have a somewhat congruent set of capabilities, you can create a session and try it. It might work. For that, you don't need a notion of service beyond some simple display of the name of the service for the human. I think you would like to know the name of the service. I agree that: > I have no hope of conveying in a structured document the meaning of Doom > - and I see little point of trying. In my D3, you would simply indicate > "Game/Doom" or something of that nature. > > You'd basically need the user's manual to tell the recipient what to do > with the information and what user interactions make sense. I would only add that you may need a document to create a high quality user experience; it's not just the human that could understand what Game/Doom means, the client might. The human that wrote the client code may interpret the document to figure out how to create an excellent user experience. So, maybe we are in fact converging. We need no new mechanisms to get your D1/D2 stuff done. All we need for D3 is a name, which implies a registry. The registry would point to a document that describes Game/Doom, which could be the "user manual", but might be something more spec like. That's all I've asked for: services have names, and names are registered. Services have some set of (existing) capabilities. If you don't know what the name means, you support the capabilities, and you want to try establishing a session, go for it. Brian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 8 13:40:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03096; Tue, 8 Feb 2005 13:40:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyabU-00032D-0Z; Tue, 08 Feb 2005 14:00:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyaGd-0000RR-Ma; Tue, 08 Feb 2005 13:39:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyaCW-000803-Rv for simple@megatron.ietf.org; Tue, 08 Feb 2005 13:35:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02691 for ; Tue, 8 Feb 2005 13:35:02 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyaWB-0002tp-BS for simple@ietf.org; Tue, 08 Feb 2005 13:55:23 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 08 Feb 2005 13:34:34 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j18IYVhF020735; Tue, 8 Feb 2005 13:34:31 -0500 (EST) Received: from cisco.com ([161.44.79.182]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOY13443; Tue, 8 Feb 2005 13:34:30 -0500 (EST) Message-ID: <42090636.5090302@cisco.com> Date: Tue, 08 Feb 2005 13:34:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] Three dimensions of service References: <3q2adl$1a3ipn@sj-inbound-e.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" , "'Henning Schulzrinne'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Comment down near the end. Paul Brian Rosen wrote: > The magic document contains human understandable text that tells the reader > how the service works. It probably also specifies what protocol mechanisms > are employed, which are required and which are optional. > > I'm not arguing with what capabilities a service presents in the presence > document that already have been defined. They are necessary. I don't think > they are sufficient. > > It's always possible that if you have a somewhat congruent set of > capabilities, you can create a session and try it. It might work. > For that, you don't need a notion of service beyond some simple display of > the name of the service for the human. I think you would like to know the > name of the service. > > I agree that: > >>I have no hope of conveying in a structured document the meaning of Doom >>- and I see little point of trying. In my D3, you would simply indicate >>"Game/Doom" or something of that nature. >> >>You'd basically need the user's manual to tell the recipient what to do >>with the information and what user interactions make sense. > > I would only add that you may need a document to create a high quality user > experience; it's not just the human that could understand what Game/Doom > means, the client might. The human that wrote the client code may interpret > the document to figure out how to create an excellent user experience. > > So, maybe we are in fact converging. We need no new mechanisms to get your > D1/D2 stuff done. All we need for D3 is a name, which implies a registry. > The registry would point to a document that describes Game/Doom, which could > be the "user manual", but might be something more spec like. > > That's all I've asked for: services have names, and names are registered. > Services have some set of (existing) capabilities. If you don't know what > the name means, you support the capabilities, and you want to try > establishing a session, go for it. We are getting closer. What you suggest seems relatively benign. But it depends on exactly how we spin it, and how it ends up being used. Used wrong, it could result in huge and unnecessary difficulties in communicating. If going this way I think we need at least a very generic "unstructured communications" type, and it SHOULD be used for all "regular" voice, video, and IM communications. I am concerned that, e.g., MS will decide that its type is "MS-RTC" and then not talk to anything else. And lots of other implementations do likewise. If that happens, and maybe if it doesn't, it may be necessary to allow declaring multiple types for the same service instance. What we don't need is gratuitous balkanization. Paul > Brian > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 8 14:00:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04906; Tue, 8 Feb 2005 14:00:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyaub-0003Vr-9i; Tue, 08 Feb 2005 14:20:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyaVQ-0003g0-Sc; Tue, 08 Feb 2005 13:54:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyaUo-0003Wt-03 for simple@megatron.ietf.org; Tue, 08 Feb 2005 13:53:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04377 for ; Tue, 8 Feb 2005 13:53:57 -0500 (EST) Message-Id: <200502081853.NAA04377@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyaoS-0003Mv-LH for simple@ietf.org; Tue, 08 Feb 2005 14:14:16 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1CyaUW-00045r-3t; Tue, 08 Feb 2005 12:53:40 -0600 From: "Brian Rosen" To: "'Paul Kyzivat'" Subject: RE: [Simple] Three dimensions of service Date: Tue, 8 Feb 2005 13:53:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <42090636.5090302@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUODNxmKHtlMdJRRpKedixfKr2wowAAkEzg X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" , "'Henning Schulzrinne'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit I understand the caution. I certainly don't mind defining "telephony", and "instant messaging" as services and encouraging their use whenever possible. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, February 08, 2005 1:34 PM > To: Brian Rosen > Cc: 'Henning Schulzrinne'; 'Simple WG' > Subject: Re: [Simple] Three dimensions of service > > Comment down near the end. > > Paul > > Brian Rosen wrote: > > The magic document contains human understandable text that tells the > reader > > how the service works. It probably also specifies what protocol > mechanisms > > are employed, which are required and which are optional. > > > > I'm not arguing with what capabilities a service presents in the > presence > > document that already have been defined. They are necessary. I don't > think > > they are sufficient. > > > > It's always possible that if you have a somewhat congruent set of > > capabilities, you can create a session and try it. It might work. > > For that, you don't need a notion of service beyond some simple display > of > > the name of the service for the human. I think you would like to know > the > > name of the service. > > > > I agree that: > > > >>I have no hope of conveying in a structured document the meaning of Doom > >>- and I see little point of trying. In my D3, you would simply indicate > >>"Game/Doom" or something of that nature. > >> > >>You'd basically need the user's manual to tell the recipient what to do > >>with the information and what user interactions make sense. > > > > I would only add that you may need a document to create a high quality > user > > experience; it's not just the human that could understand what Game/Doom > > means, the client might. The human that wrote the client code may > interpret > > the document to figure out how to create an excellent user experience. > > > > So, maybe we are in fact converging. We need no new mechanisms to get > your > > D1/D2 stuff done. All we need for D3 is a name, which implies a > registry. > > The registry would point to a document that describes Game/Doom, which > could > > be the "user manual", but might be something more spec like. > > > > That's all I've asked for: services have names, and names are > registered. > > Services have some set of (existing) capabilities. If you don't know > what > > the name means, you support the capabilities, and you want to try > > establishing a session, go for it. > > We are getting closer. What you suggest seems relatively benign. But it > depends on exactly how we spin it, and how it ends up being used. Used > wrong, it could result in huge and unnecessary difficulties in > communicating. > > If going this way I think we need at least a very generic "unstructured > communications" type, and it SHOULD be used for all "regular" voice, > video, and IM communications. > > I am concerned that, e.g., MS will decide that its type is "MS-RTC" and > then not talk to anything else. And lots of other implementations do > likewise. If that happens, and maybe if it doesn't, it may be necessary > to allow declaring multiple types for the same service instance. > > What we don't need is gratuitous balkanization. > > Paul > > > Brian > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 8 18:12:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15704; Tue, 8 Feb 2005 18:12:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyeqI-0007FR-7b; Tue, 08 Feb 2005 18:32:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyeHv-0003S9-C1; Tue, 08 Feb 2005 17:56:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cydww-0004fo-Mj for simple@megatron.ietf.org; Tue, 08 Feb 2005 17:35:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08491 for ; Tue, 8 Feb 2005 17:35:12 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyeGc-0005Bm-6l for simple@ietf.org; Tue, 08 Feb 2005 17:55:35 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 08 Feb 2005 17:34:42 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j18MYdhF024924; Tue, 8 Feb 2005 17:34:40 -0500 (EST) Received: from cisco.com ([161.44.79.182]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AOY40184; Tue, 8 Feb 2005 17:34:38 -0500 (EST) Message-ID: <42093E7E.3080708@cisco.com> Date: Tue, 08 Feb 2005 17:34:38 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] Three dimensions of service References: <200502081853.NAA04377@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" , "'Henning Schulzrinne'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: 7bit Brian Rosen wrote: > I understand the caution. I certainly don't mind defining "telephony", and > "instant messaging" as services and encouraging their use whenever possible. Hey, we're making some progress! But I don't agree that "telephony" and "instant messaging" are different D3s. They are both "real time, unstructured, IP media communication", or something like that. The specific media involved are a separate dimension. (RTUIPMC - much more convenient than "telephony" :-) Paul > Brian > > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Tuesday, February 08, 2005 1:34 PM >>To: Brian Rosen >>Cc: 'Henning Schulzrinne'; 'Simple WG' >>Subject: Re: [Simple] Three dimensions of service >> >>Comment down near the end. >> >> Paul >> >>Brian Rosen wrote: >> >>>The magic document contains human understandable text that tells the >> >>reader >> >>>how the service works. It probably also specifies what protocol >> >>mechanisms >> >>>are employed, which are required and which are optional. >>> >>>I'm not arguing with what capabilities a service presents in the >> >>presence >> >>>document that already have been defined. They are necessary. I don't >> >>think >> >>>they are sufficient. >>> >>>It's always possible that if you have a somewhat congruent set of >>>capabilities, you can create a session and try it. It might work. >>>For that, you don't need a notion of service beyond some simple display >> >>of >> >>>the name of the service for the human. I think you would like to know >> >>the >> >>>name of the service. >>> >>>I agree that: >>> >>> >>>>I have no hope of conveying in a structured document the meaning of Doom >>>>- and I see little point of trying. In my D3, you would simply indicate >>>>"Game/Doom" or something of that nature. >>>> >>>>You'd basically need the user's manual to tell the recipient what to do >>>>with the information and what user interactions make sense. >>> >>>I would only add that you may need a document to create a high quality >> >>user >> >>>experience; it's not just the human that could understand what Game/Doom >>>means, the client might. The human that wrote the client code may >> >>interpret >> >>>the document to figure out how to create an excellent user experience. >>> >>>So, maybe we are in fact converging. We need no new mechanisms to get >> >>your >> >>>D1/D2 stuff done. All we need for D3 is a name, which implies a >> >>registry. >> >>>The registry would point to a document that describes Game/Doom, which >> >>could >> >>>be the "user manual", but might be something more spec like. >>> >>>That's all I've asked for: services have names, and names are >> >>registered. >> >>>Services have some set of (existing) capabilities. If you don't know >> >>what >> >>>the name means, you support the capabilities, and you want to try >>>establishing a session, go for it. >> >>We are getting closer. What you suggest seems relatively benign. But it >>depends on exactly how we spin it, and how it ends up being used. Used >>wrong, it could result in huge and unnecessary difficulties in >>communicating. >> >>If going this way I think we need at least a very generic "unstructured >>communications" type, and it SHOULD be used for all "regular" voice, >>video, and IM communications. >> >>I am concerned that, e.g., MS will decide that its type is "MS-RTC" and >>then not talk to anything else. And lots of other implementations do >>likewise. If that happens, and maybe if it doesn't, it may be necessary >>to allow declaring multiple types for the same service instance. >> >>What we don't need is gratuitous balkanization. >> >> Paul >> >> >>>Brian >>> >>> >> > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 8 23:39:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22793; Tue, 8 Feb 2005 23:39:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyjwn-0005Yd-UM; Tue, 08 Feb 2005 23:59:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyjcA-0000Ve-Rz; Tue, 08 Feb 2005 23:38:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyBKv-0004Zb-Rz; Mon, 07 Feb 2005 11:02:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12201; Mon, 7 Feb 2005 11:02:03 -0500 (EST) Received: from [64.151.105.12] (helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyBeK-0003nN-VK; Mon, 07 Feb 2005 11:22:10 -0500 Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Mon, 07 Feb 2005 11:02:02 -0500 id 002136E2.420790FA.00001C56 In-Reply-To: <42078BC6.2080608@cisco.com> References: <42078BC6.2080608@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <98051BC2-7921-11D9-BC8F-000D9358DFD8@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Geopriv] Re: [Simple] substitution groups vs. any elements Date: Mon, 7 Feb 2005 11:01:57 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 08 Feb 2005 23:38:05 -0500 Cc: "'geopriv@ietf.org'" , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit For clarification, questions in-line: On Feb 7, 2005, at 10:39 AM, Jonathan Rosenberg wrote: > With substitution groups, the xcap server will reject any permissions > documents that contain these new permissions. With the "any" approach, > they will be accepted, and then properly understood by the presence > server. In the event that a client places the wrong permission name > into the document (for example, the client places > into the document), the xcap server will still allow this. However, > the permission will be ignored by the presence server and thus the > system remains privacy safe. To be it differently, the client would have sent the data anyway so no loss of privacy. Correct? > The argument made in the threads to date on this topic were that xcap > provided sufficient negotiation techniques that the client could > discover that the new permissions were not supported, and then retry > the request without them. The use case above highlights that in its > role as middleman to the actual application, there are cases where we > may not want the xcap server to be the bottleneck. Or in other words, the negotiation is point-to-point not end-to-end. Correct? -andy _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 9 05:48:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18967; Wed, 9 Feb 2005 05:48:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cypic-0003xG-M1; Wed, 09 Feb 2005 06:09:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CypNc-0001Wj-SX; Wed, 09 Feb 2005 05:47:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CypLY-0000jv-SL; Wed, 09 Feb 2005 05:45:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18835; Wed, 9 Feb 2005 05:45:22 -0500 (EST) Received: from il-tlv-firewall-main.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout1.icomverse.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CypfL-0003ud-FE; Wed, 09 Feb 2005 06:05:52 -0500 Received: from il-tlv-bridge02.comverse.com (il-tlv-bridge02.comverse.com [10.115.242.50]) by il-tlv-smtpout1.icomverse.com (8.13.1/8.11.6) with ESMTP id j19AMkXV026534; Wed, 9 Feb 2005 12:22:46 +0200 Received: from il-tlv-mail02.comverse.com ([10.115.242.26]) by il-tlv-bridge02.comverse.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Feb 2005 12:45:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Feb 2005 12:45:14 +0200 Message-ID: <522B9797154BD549B17BA4EAF1DF200C108340@il-tlv-mail02.comverse.com> Thread-Topic: draft-ietf-simple-event-list-07: Subscribe for list of resources Thread-Index: AcUOlHAigJ+vwoh+TWqmYG4rCE3TkA== From: "Nevo Oded" To: , X-OriginalArrivalTime: 09 Feb 2005 10:45:15.0588 (UTC) FILETIME=[7088A840:01C50E94] X-Spam-Score: 0.5 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Simple] draft-ietf-simple-event-list-07: Subscribe for list of resources 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="===============0267884808==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. --===============0267884808== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50E94.701108B7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C50E94.701108B7 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi Can I assume that the "eventlist" option in the "Supported" header Defines a subscrption to list of resources? When the "Supported" header is valid with the "eventlist" value the URI = represent a list of resources, And when the "Supported" header is not valid or valid with the = "eventlist" value not valid the URI represent a single resource? 10x Oded ------_=_NextPart_001_01C50E94.701108B7 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable draft-ietf-simple-event-list-07: Subscribe for list of = resources

Hi

Can I = assume that the "eventlist" option in the = "Supported" header

Defines = a subscrption to list of resources?

When the = "Supported" header is valid with the "eventlist" = value the URI represent a list of resources,

And when = the "Supported" header is not valid or valid with the = "eventlist" value not valid the URI represent a single = resource?

10x = Oded

------_=_NextPart_001_01C50E94.701108B7-- --===============0267884808== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0267884808==-- From Oneillxac@digdat.com Wed Feb 9 08:02:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27247; Wed, 9 Feb 2005 08:02:07 -0500 (EST) Received: from [222.233.212.178] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cyrnf-0006Hq-33; Wed, 09 Feb 2005 08:22:37 -0500 Received: from 217.72.195.42 by 222.233.212.178; Wed, 09 Feb 2005 12:01:15 -0100 Message-ID: From: "Carson Marin" Reply-To: "Carson Marin" To: nvjtkrddp@ietf.org, gsmp-admin@ietf.org, simple-archive@ietf.org, echsc-web-archive@ietf.org, b-archive@ietf.org, iswigmmusic@ietf.org, -outbound.10@ietf.org, f@ietf.org, sg-secretary@ietf.org, nd.10@ietf.org, toips@ietf.org, ipv6@ietf.org, r-wg@ietf.org, tcpm-admin@ietf.org, ipv6-admin@ietf.org, ipcdn-admin@ietf.org, smith.barney@ietf.org, munzsxcon@ietf.org, yeekunsis-admin@ietf.org, listadm@ietf.org Subject: Fat boy needs to talk to a girl Date: Wed, 09 Feb 2005 14:01:15 +0100 X-Mailer: The Bat! (v1.52f) Business MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--1-566739235-3020159847=:07476" X-Priority: 5 X-MSMail-Priority: Low X-Spam-Score: 35.1 (+++++++++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d6b246023072368de71562c0ab503126 ----1-566739235-3020159847=:07476 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable




Goodbye




attica carbonaceoushermeneutic collet chatcrouch dissipate deployclark diplomacy descentcarbonyl melbourne commoditydempsey nuthatch counterpartcourteous crow condescensionear dietrich airflowreceipt petersburg frankfairway ----1-566739235-3020159847=:07476-- From simple-bounces@ietf.org Wed Feb 9 16:32:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26121; Wed, 9 Feb 2005 16:32:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyzlz-0006iE-8C; Wed, 09 Feb 2005 16:53:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyyoq-0001nM-5m; Wed, 09 Feb 2005 15:52:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyyVU-00054N-AT; Wed, 09 Feb 2005 15:32:16 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10558; Wed, 9 Feb 2005 15:32:14 -0500 (EST) Message-Id: <200502092032.PAA10558@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 09 Feb 2005 15:32:14 -0500 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-list-usage-05.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Extensible Markup Language (XML) Formats for Representing Resource Lists Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-list-usage-05.txt Pages : 32 Date : 2005-2-9 In multimedia communications, presence and instant messaging systems, there is a need to define Uniform Resource Identifiers (URIs) that represent services which are associated with a group of users. One example is a resource list service. If a user sends a Session Initiation Protocol (SIP) SUBSCRIBE message to the URI representing the resource list service, the server will obtain the state of the users in the associated group, and provide it to the sender. To facilitate definition of these services, this specification defines two Extensible Markup Language (XML) documents. One document contains service URIs, along with their service definition and a reference to the associated group of users. The second document contains the user lists which are referenced from the first. Both documents can be created and managed with the XML Configuration Access Protocol (XCAP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-xcap-list-usage-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-xcap-list-usage-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-9150440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-list-usage-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-list-usage-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-9150440.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Wed Feb 9 16:35:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26794; Wed, 9 Feb 2005 16:35:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyzor-0006vy-Gj; Wed, 09 Feb 2005 16:56:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyyou-0001pk-Lr; Wed, 09 Feb 2005 15:52:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyyVe-0005C7-Q8; Wed, 09 Feb 2005 15:32:26 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10622; Wed, 9 Feb 2005 15:32:24 -0500 (EST) Message-Id: <200502092032.PAA10622@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 09 Feb 2005 15:32:24 -0500 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-06.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-06.txt Pages : 61 Date : 2005-2-9 This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-xcap-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-xcap-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-9150452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-9150452.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From shaumil295kadlecik@x5b.com Thu Feb 10 04:48:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12487; Thu, 10 Feb 2005 04:48:11 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzBFc-00074L-3u; Thu, 10 Feb 2005 05:08:53 -0500 Received: from [221.153.39.114] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CzAvR-0007fH-W9; Thu, 10 Feb 2005 04:47:55 -0500 Received: from mundo062.namebank.com (220.117.73.173) by 220.117.73.173 with Microsoft SMTP9037(07.99.54.50); Thu, 10 Feb 2005 03:42:43 -0600 Received: from 220.117.73.173 (groff[220.117.73.173]) by chambers51820.namebank.com (ygm0158) with SMTP id <52095xbyp87882rz>;Thu, 10 Feb 2005 14:44:43 +0500 Message-ID: Reply-To: "keller general" From: "keller general" To: l-admin@ietf.org Cc: manet-admin@ietf.org, rip-admin@ietf.org, hc-admin@ietf.org, cna@ietf.org, simple-archive@ietf.org, imrg-request@ietf.org, seamoby-web-archive@ietf.org, pim-request@ietf.org Subject: Read: This email will change your life Date: Thu, 10 Feb 2005 08:39:43 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--04425_3416728.3O055" X-Spam-Score: 16.5 (++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d6b246023072368de71562c0ab503126 ----04425_3416728.3O055 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Hello Account #3453043, Your application was approved. You are eligible for $500,000 with a 3.7 % rate. Please confirm your information here: http://collamer.dfgsgs.info:443/ajrmlflook We look forward to hearing from you. Regards, keller general, Senior Account Manager SLP Financial Group r*mv. -> http://gualteri.dfgsgs.info:443/index.php ----04425_3416728.3O055-- From banana@myoplex-muscletech-klein-becker-eas-xenadrine-supplements.com Fri Feb 11 00:00:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02547; Fri, 11 Feb 2005 00:00:42 -0500 (EST) Received: from [211.195.129.60] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CzTFG-0004uF-Be; Fri, 11 Feb 2005 00:21:35 -0500 Subject: Nice to see you again Message-ID: <%CUSTOM_MESSAGEID> From: "Ella kilgore" To: rserpool@ietf.org Date: Thu, 10 Feb 2005 21:00:39 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--Next_XNQVuf5O0.kOFgsDDsNM3" X-Spam-Score: 8.6 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ----Next_XNQVuf5O0.kOFgsDDsNM3 Content-Type: text/plain; format=flowed; charset=iso-8859-15 Content-Transfer-Encoding: 7Bit ----Next_XNQVuf5O0.kOFgsDDsNM3 Content-Type: text/html; format=flowed; charset=iso-8859-15 Content-Transfer-Encoding: 7Bit Your the greatest,
While searching google I found a great website that offers quality generic and brand name me-dications at very affordable prices. Shipping is even faster than ever right to your doorstep. Promised savings up to 80% off all prescription drugs. Today Americans pay out over 20 billion dollars yearly in medication costs. Not including doctor fees. The tragedy is that most can not afford to pay these ridiculously high prices. We deliver the same quality drugs you are used to buying from your local pharmacy. The real difference is you don't have to see a doctor and you can save tons of money and start saving for more important things in your life. Feel free to take a look at what could help you greatly. Thank you for your time.

http://bigtabl.info/in.php?aid=19

Thanks for being part of the team, Louisa smith | Community Advisor

This isn't something I'm interested in recieving - http://uhviagra.info/fgh.php ----Next_XNQVuf5O0.kOFgsDDsNM3-- From HoltTDJWMNTWZLUW@mx2.redestb.es Fri Feb 11 00:53:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06732 for ; Fri, 11 Feb 2005 00:53:00 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzU3o-00061w-CR for simple-archive@ietf.org; Fri, 11 Feb 2005 01:13:54 -0500 Received: from [211.155.251.253] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CzTjZ-0008Sb-SZ for simple-archive@ietf.org; Fri, 11 Feb 2005 00:52:57 -0500 X-Message-Info: 184WA2H41jquTlnzpkpze9BRLFuKXntxM4qJQNIM34DXGD Received: from acquittal0elideaberdeen (DE.F9.C08.89) by mail7D0.stud.uni-rostock.de (Bluewin JI C.1.F34) id CA8B3S8BWNF6FPHVDF for simple-archive@ietf.org; Fri, 11 Feb 2005 06:51:48 -0700 Message-ID: <1CF66D59DDC35A.05288@stud.uni-rostock.de> Reply-To: "Kenny french" From: "Kenny french" To: "Simple-archive" Subject: earn your educational credentials without going to class Date: Fri, 11 Feb 2005 11:48:48 -0200 MIME-Version: 1.0 X-knuckle-key: HoltTDJWMNTWZLUW@mx2.redestb.es-85.i Content-Type: multipart/alternative; boundary="--DAA0A7A8218F03D0ABA2" X-Spam-Score: 25.8 (+++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ----DAA0A7A8218F03D0ABA2 Content-Type: text/html; charset="iso-0A27-0" Content-Transfer-Encoding: quoted-printable

Are you going to be stuck at that same job forever? Well if you don't = have the proper education you will. Let us help you with that...

Browse our Site.

 

to access our discard list= =20 Minsky modified and altered in any way. A homepage manifest itself as a represent= ation of information in virtual worlds Thus when, in 1766, Buffon wrote the fourteenth volume of his great work, = he was personally familiar with the young of one kind of African man-like = Ape, and with the adult of an Asiatic species=96while the Orang-Utan and t= he Mandrill of Smith were known to him by report. Furthermore, the Abb=E9 = Prevost had translated a good deal of Purchas' "Pilgrims" into French, in = his "Histoire g=E9n=E9rale des Voyages" (1748), and there Buffon found a v= ersion of Andrew Battell's account of the Pongo and the Engeco. All these = data Buffon attempts to weld together into harmony in this chapter entitle= d "Les Orang-outangs ou le Pongo et le Jocko." To this title the following= note is appended:=96 ----DAA0A7A8218F03D0ABA2-- From Murdock@Fastmail.ca Fri Feb 11 12:12:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16307; Fri, 11 Feb 2005 12:12:23 -0500 (EST) Message-Id: <200502111712.MAA16307@ietf.org> Received: from [61.85.185.215] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CzefQ-0003qK-JI; Fri, 11 Feb 2005 12:33:22 -0500 Received: from [182.92.224.226] by catheter%DIGITS.bramble.61.85.185.215 via HTTP; Fri, 11 Feb 2005 09:12:06 -0800 Reply-To: "hajmail.com" From: "hajmail.com" To: Subject: Hi, me again Date: Fri, 11 Feb 2005 09:12:06 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--8272931348cbxe8442" X-Spam-Score: 3.3 (+++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c ----8272931348cbxe8442 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable How would you like to keep me some company? My Husband is out of town and I'm a little lonely. Safe way to contact me: http://www.dohernow.com/d/1.php Sincerely Yours, Victoria y ----8272931348cbxe8442-- From ynrqqypnrafvt@chollian.net Fri Feb 11 16:45:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25246; Fri, 11 Feb 2005 16:45:58 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cziw8-0007Ln-KP; Fri, 11 Feb 2005 17:06:58 -0500 Received: from adsl-68-77-42-98.dsl.emhril.ameritech.net ([68.77.42.98]) by mx2.foretec.com with smtp (Exim 4.24) id 1Czibl-0005ZI-WA; Fri, 11 Feb 2005 16:45:50 -0500 Received: from 133.154.164.144 by qi64-uj749.jhcoe82.prodigy.com with DAV; Fri, 11 Feb 2005 17:38:41 -0400 Reply-To: "Online University " From: "Online University " To: Subject: Online University Degree Program x 8 ew Date: Fri, 11 Feb 2005 17:42:41 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--iiuiuvbnoava478966448148499ukzkhzeta" Message-Id: X-Spam-Score: 15.2 (+++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab ----iiuiuvbnoava478966448148499ukzkhzeta Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable A Genuine College Degree in 2 weeks! Have you ever thought that the only thing stopping you from a great job an= d better pay was a few letters behind your name? Well now you can get them! BA BSc MA MSc MBA PhD Within 2 weeks! No Study Required! 100% Verifiable! These are real, genuine degrees that include Bachelors, Masters and Doctor= ate degrees. They are verifiable and student records and transcripts are = also available. This little known secret has been kept quiet for years. The opportunity e= xists due to a legal loophole allowing some established colleges to award = degrees at their discretion. With all of the attention that this news has been generating, I wouldn't b= e surprised to see this loophole closed very soon. Order yours today. Call us on 1-206-600-6376 TODAY, & GIVE YOUR FUTURE A CHANCE! If you prefer not to receive such offers go here: ----iiuiuvbnoava478966448148499ukzkhzeta-- From Guywdzn@netport.com Fri Feb 11 18:08:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08808; Fri, 11 Feb 2005 18:08:41 -0500 (EST) Received: from ip-212-166.sn1.eutelia.it ([62.94.212.166]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CzkEE-0002J5-V9; Fri, 11 Feb 2005 18:29:43 -0500 Received: from instuttgart.de ([64.15.205.182]) by prow.mediasoft.net (InterMail vK.4.04.00.00 356-129-903 license 4vi902dr4569p7hg8i3oli1551q6cac1) with ESMTP id <09066393055687.GMKI193.highwayman@instuttgart.de> for ; Sat, 12 Feb 2005 00:08:01 +0100 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 11 Feb 2005 17:06:01 -0600 Received: from 216.52.245.163 by pearlite.roach.hotmail.msn.com with HTTP; Sat, 12 Feb 2005 00:10:01 +0100 GMT X-Originating-IP: [66.146.0.10] X-Originating-Email: [bathroom@instuttgart.de] From: "Zachery Vigil" To: pm@ietf.org Subject: Personals : Don't you need someone to love Date: Sat, 12 Feb 2005 02:04:01 +0300 Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: X-OriginalArrivalTime: Fri, 11 Feb 2005 17:11:01 -0600 (UTC) FILETIME=[6Z8UFY00:06Y4[5 X-Spam-Score: 21.6 (+++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 Content-Transfer-Encoding: quoted-printable From JeriqbfqwEdelgard@nab.com Sat Feb 12 06:39:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20582; Sat, 12 Feb 2005 06:39:34 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czvwz-0000C1-Hv; Sat, 12 Feb 2005 07:00:42 -0500 Received: from [220.186.142.169] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CzvcN-0001XG-33; Sat, 12 Feb 2005 06:39:21 -0500 Received: from mail.oztecgroup.net (220.186.142.169) by 220.186.142.169 (photov.337) with SMTP id <612996293v88j> (Authid: 691); Sat, 12 Feb 2005 08:29:40 -0300 Reply-To: "Liu.Hui Isa.Moeller" From: "Liu.Hui Isa.Moeller" To: sic@ietf.org Cc: sigtran@ietf.org, sigtran-admin@ietf.org, simple@ietf.org, simple-admin@ietf.org, simple-archive@ietf.org, simple-request@ietf.org, simple-web-archive@ietf.org, sip@ietf.org, sip-admin@ietf.org, sip-request@ietf.org, sip-security@ietf.org Subject: Read: You are approved Date: Sat, 12 Feb 2005 16:30:40 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--3032545_445643.jS33" Message-Id: X-Spam-Score: 6.5 (++++++) X-Spam-Flag: YES X-Scan-Signature: 93238566e09e6e262849b4f805833007 ----3032545_445643.jS33 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Applicant, Your application was processed and approved. This means that you're eligible for $ 475,000 with a 3.1% rate. Take a few minutes to see what you can save! Please verify your information here: http://dividend.gsvdvs.info:443/azdrg We look forward to hearing from you. Liu.Hui Isa.Moeller, Account Manager TJK Associates r.mv - http://gsvdvs.info:443/index.php ----3032545_445643.jS33-- From RicardchqSneed@buyersrealty.com Sat Feb 12 15:30:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28800; Sat, 12 Feb 2005 15:30:12 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D04Ea-0001zR-KM; Sat, 12 Feb 2005 15:51:25 -0500 Received: from [61.32.61.78] (helo=8-JFTI1PFQ914W) by mx2.foretec.com with smtp (Exim 4.24) id 1D03td-0005xW-MZ; Sat, 12 Feb 2005 15:29:42 -0500 Received: from mail.az.com (61.32.61.78) by 61.32.61.78 (autocratv.779) with SMTP id <27475837f78c> (Authid: 06917); Sat, 12 Feb 2005 21:28:27 +0100 Reply-To: "Sisse Uriela" From: "Sisse Uriela" To: secretariat@ietf.org Cc: secretary@ietf.org, sg@ietf.org, sic@ietf.org, sigtran@ietf.org, sigtran-admin@ietf.org, simple@ietf.org, simple-admin@ietf.org, simple-archive@ietf.org, simple-request@ietf.org, simple-web-archive@ietf.org, sip@ietf.org, sip-admin@ietf.org Subject: Put an end to paying high prices Date: Sat, 12 Feb 2005 22:26:27 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--7367611_7124117.eA55" Message-Id: X-Spam-Score: 2.2 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ----7367611_7124117.eA55 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Applicant, Your application was processed and approved. This means that you're eligible for $ 435,000 with a 3.1% rate. Takes a few minutes to see what you can save! Please verify your information here: http://scrutable.masfre.info:443/ajrrg We look forward to hearing from you. Sisse Uriela, Account Manager TJK Associates r*mv - http://masfre.info:443/index.php ----7367611_7124117.eA55-- From support@citizensbank.com Sat Feb 12 19:30:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13497; Sat, 12 Feb 2005 19:30:22 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D07z8-0006TP-2i; Sat, 12 Feb 2005 19:51:38 -0500 Received: from [222.99.7.156] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D07eY-00049r-AL; Sat, 12 Feb 2005 19:30:22 -0500 To: simple-archive@ietf.org Subject: Important Online Banking Alert From: Citizens Bank MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--114442669871554628" Message-Id: Date: Sat, 12 Feb 2005 19:30:22 -0500 X-Spam-Score: 13.9 (+++++++++++++) X-Spam-Flag: YES X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 ----114442669871554628 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Citizens Bank Online

   Dear valued Citizens Bank member,

   Due to concerns, for the safety and integrity of the onl= ine banking community we have issued the following warning message.

   It has come to our attention that your account informati= on needs to be confirmed due to inactive customers, fraud and spoof report= s.
   If you could please take 5-10 minutes out of your online= experience and renew your records you will not run into any future proble= ms with the online service.
   However, failure to confirm your records may result in y= our account suspension.

   Once you have confirmed your account records your intern= et banking service will not be interrupted and will continue as normal.

   To confirm your bank account records please click here.

   Thank you for your time,
   Citizens Financial Group.

3D"" 3D"" 3D""
3D"" 3D"" 3D""
3D""
Privacy | Security © 2004 Citizens Financial Grou= p. All rights reserved. Terms of Use | Site Map
----114442669871554628-- From simple-bounces@ietf.org Mon Feb 14 03:41:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05084; Mon, 14 Feb 2005 03:41:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0c7q-00044K-Iw; Mon, 14 Feb 2005 04:02:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0bkb-0003GG-J1; Mon, 14 Feb 2005 03:38:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0bis-00035V-G5 for simple@megatron.ietf.org; Mon, 14 Feb 2005 03:36:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04566 for ; Mon, 14 Feb 2005 03:36:48 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0c3f-0003pM-5i for simple@ietf.org; Mon, 14 Feb 2005 03:58:20 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 14 Feb 2005 00:36:23 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1E8aEYO005424; Mon, 14 Feb 2005 00:36:15 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-192.cisco.com [10.86.240.192]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHS41234; Mon, 14 Feb 2005 00:36:13 -0800 (PST) Message-ID: <421062FC.4050801@cisco.com> Date: Mon, 14 Feb 2005 03:36:12 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] Three dimensions of service References: <200502081853.NAA04377@ietf.org> <42093E7E.3080708@cisco.com> In-Reply-To: <42093E7E.3080708@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: "'Henning Schulzrinne'" , "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Sorry for jumping into this thread late. Its an important one, and a topic we have touched on many times already. I think that whether you need some kind of D3 indicator depends entirely on the answer to this question - "if a caller had no information on the service besides the prescaps information, would they be able to make a successful communications attemtp that did something sensible"? In most cases, I think the answer is yes. In such cases, I don't think you gain much by conveying this parameter. But then we have these anomaly cases like doom where, if you don't generate the SIP INVITE from your doom app, you're not going to get something that makes sense. If Doom has prescaps of audio and video, just connecting to it from my generic sip softphone is NOT going to do the right thing. Thus, to me, this D3 flag feels more like an application launcher. If you click on that tuple in a presence document, the D3 value tells you what application on your PC to launch. In this case, it would launch the doom game. That would argue for something that is a name bound to a registry, much like MIME types launch viewers on my PC. If that parameter is not provided, then the URI scheme provides the indicator of what application to launch. Thats why I don't think we need to define values for "IM" or "telephony" - those should work from a generic sip client. -Jonathan R. Paul Kyzivat wrote: > > > Brian Rosen wrote: > >> I understand the caution. I certainly don't mind defining >> "telephony", and >> "instant messaging" as services and encouraging their use whenever >> possible. > > > Hey, we're making some progress! > > But I don't agree that "telephony" and "instant messaging" are different > D3s. They are both "real time, unstructured, IP media communication", or > something like that. The specific media involved are a separate dimension. > > (RTUIPMC - much more convenient than "telephony" :-) > > Paul > >> Brian -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From conspire.67859linda@teenpro.com Mon Feb 14 05:57:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15667; Mon, 14 Feb 2005 05:57:19 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0eFc-0006jB-4m; Mon, 14 Feb 2005 06:18:53 -0500 Received: from [211.53.51.6] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D0due-0006iX-T8; Mon, 14 Feb 2005 05:57:10 -0500 Received: from server651.jwtek.com (211.53.51.6) by 211.53.51.6 (Sun Java System Messaging Server 9.2 HotFix 0.65) with SMTP id ; Mon, 14 Feb 2005 03:52:22 -0700 Reply-To: "barnie shamblin" From: "barnie shamblin" To: routing-discussion@ietf.org Cc: rserpool@ietf.org, esg@ietf.org, mailman-admin@ietf.org, l-admin@ietf.org, manet-admin@ietf.org, rip-admin@ietf.org, hc-admin@ietf.org, cna@ietf.org, simple-archive@ietf.org, imrg-request@ietf.org Subject: Goods News. Application was accepted Date: Mon, 14 Feb 2005 04:52:22 -0600 MIME-Version: 1.0 X-Scanned: Symantec Scan Engine v6.8 Content-Type: multipart/alternative; boundary="--68626_66156745.lX64" Message-Id: X-Spam-Score: 13.0 (+++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----68626_66156745.lX64 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Hello Account #0863777, Your application was approved. You are eligible for $400,000 with a 3.7 % rate. Please confirm your information here: http://macrostructure.lpjsjfv.info:443/ajrmlfaizal We look forward to hearing from you. Regards, barnie shamblin, Senior Account Manager FTK Financial Group r*mv. -> http://alkane.lpjsjfv.info:443/index.php ----68626_66156745.lX64-- From simple-bounces@ietf.org Mon Feb 14 09:44:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09182; Mon, 14 Feb 2005 09:44:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0hnY-00040d-Ch; Mon, 14 Feb 2005 10:06:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0hJB-0002U4-7F; Mon, 14 Feb 2005 09:34:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0hHo-0002F2-RV for simple@megatron.ietf.org; Mon, 14 Feb 2005 09:33:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07908 for ; Mon, 14 Feb 2005 09:33:14 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0hce-0003eL-Ni for simple@ietf.org; Mon, 14 Feb 2005 09:54:50 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 14 Feb 2005 06:42:24 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1EEWeq8018729; Mon, 14 Feb 2005 06:32:41 -0800 (PST) Received: from cisco.com ([161.44.79.182]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APB65528; Mon, 14 Feb 2005 09:32:40 -0500 (EST) Message-ID: <4210B688.8010009@cisco.com> Date: Mon, 14 Feb 2005 09:32:40 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Three dimensions of service References: <200502081853.NAA04377@ietf.org> <42093E7E.3080708@cisco.com> <421062FC.4050801@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: "'Henning Schulzrinne'" , "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Sorry for jumping into this thread late. Its an important one, and a > topic we have touched on many times already. > > I think that whether you need some kind of D3 indicator depends entirely > on the answer to this question - "if a caller had no information on the > service besides the prescaps information, would they be able to make a > successful communications attemtp that did something sensible"? > > In most cases, I think the answer is yes. In such cases, I don't think > you gain much by conveying this parameter. I would go further, and propose that implementors should bend over backwards to make this be the case. Situations where it is not the case should be rare. > But then we have these anomaly cases like doom where, if you don't > generate the SIP INVITE from your doom app, you're not going to get > something that makes sense. If Doom has prescaps of audio and video, > just connecting to it from my generic sip softphone is NOT going to do > the right thing. That depends on how it is done. AFAIK there hasn't been any real engineering done on sip-for-doom, but based on the informal conversation we had on the subject in this thread, it seems plausible to me that just calling somebody's doom game from a regular phone could indeed provide a passable communications experience, even if not one the operator of the doom machine might prefer. > Thus, to me, this D3 flag feels more like an application launcher. If > you click on that tuple in a presence document, the D3 value tells you > what application on your PC to launch. In this case, it would launch the > doom game. > > That would argue for something that is a name bound to a registry, much > like MIME types launch viewers on my PC. That does seem like roughly what Brian is proposing. > If that parameter is not provided, then the URI scheme provides the > indicator of what application to launch. > > Thats why I don't think we need to define values for "IM" or "telephony" > - those should work from a generic sip client. I think this is just a matter of style in the way an optional attribute is handled: - when the attribute is missing, a particular default value. The same effect can be obtained by specifying the default value. - absence implies a certain default behavior. But there is no value for the attribute corresponding to the default behavior. While I don't object to defaults, I tend to prefer the first approach, where the same behavior can be specified explicitly. But this is a matter fo taste. What is more important is that the default behavior be the one used in the vast majority of cases. Paul > -Jonathan R. > > > Paul Kyzivat wrote: > >> >> >> Brian Rosen wrote: >> >>> I understand the caution. I certainly don't mind defining >>> "telephony", and >>> "instant messaging" as services and encouraging their use whenever >>> possible. >> >> >> >> Hey, we're making some progress! >> >> But I don't agree that "telephony" and "instant messaging" are >> different D3s. They are both "real time, unstructured, IP media >> communication", or something like that. The specific media involved >> are a separate dimension. >> >> (RTUIPMC - much more convenient than "telephony" :-) >> >> Paul >> >>> Brian >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 14 21:25:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16223; Mon, 14 Feb 2005 21:25:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0sk0-00075P-9B; Mon, 14 Feb 2005 21:47:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0sMb-0003yk-P2; Mon, 14 Feb 2005 21:22:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0sLD-0003sY-UB for simple@megatron.ietf.org; Mon, 14 Feb 2005 21:21:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15882 for ; Mon, 14 Feb 2005 21:21:29 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0sgA-0006zm-Tv for simple@ietf.org; Mon, 14 Feb 2005 21:43:11 -0500 Received: from razor.cs.columbia.edu (IDENT:U2FsdGVkX1+/gSOETDHkwdPNQmlahZ/S515WfvFUb4o@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j1F2KRir008619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Feb 2005 21:20:27 -0500 (EST) Received: from [127.0.0.1] (IDENT:U2FsdGVkX18j19guigpOeBrAVNdSfrl1aNJafrilymc@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j1F2KQbC028562; Mon, 14 Feb 2005 21:20:26 -0500 Message-ID: <42115C6E.4030402@cs.columbia.edu> Date: Mon, 14 Feb 2005 21:20:30 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Three dimensions of service References: <200502081853.NAA04377@ietf.org> <42093E7E.3080708@cisco.com> <421062FC.4050801@cisco.com> In-Reply-To: <421062FC.4050801@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > I think that whether you need some kind of D3 indicator depends entirely > on the answer to this question - "if a caller had no information on the > service besides the prescaps information, would they be able to make a > successful communications attemtp that did something sensible"? > > In most cases, I think the answer is yes. In such cases, I don't think > you gain much by conveying this parameter. There are two aspects to communication and to choosing communication options? (1) Will the bits flow correctly? (Sound comes out of the speaker, video pops up, etc.) (2) Will these bits make sense to the human? By the principle that presence should reduce the surprise factor, knowing that clicking that SIP URL will connect to the sounds of machine gun fire and exploding monsters instead of a "hello" is a useful thing, in rather limited circumstances. I fully agree that D3 should *never* be necessary for aspect (1). It should only facilitate a human to choose an appropriate communication service based on its content. Clearly, it is not necessary for the default human-to-human generic and unconstrained communication, i.e., in almost all cases. I should note that information about whether a device is an answering machine (D2), for example, is not necessary to "make a successful communication attempt". > > But then we have these anomaly cases like doom where, if you don't > generate the SIP INVITE from your doom app, you're not going to get > something that makes sense. If Doom has prescaps of audio and video, > just connecting to it from my generic sip softphone is NOT going to do > the right thing. > > Thus, to me, this D3 flag feels more like an application launcher. If > you click on that tuple in a presence document, the D3 value tells you > what application on your PC to launch. In this case, it would launch the > doom game. In most cases. In some cases, a generic application will work sufficiently well to be useful, e.g., if you just want to listen to the Doom background music or record a game session remotely. > > That would argue for something that is a name bound to a registry, much > like MIME types launch viewers on my PC. That was my example (game/doom), although I don't think the current MIME apps registry works as is. > > If that parameter is not provided, then the URI scheme provides the > indicator of what application to launch. Not necessarily. This can be a SIP URI. > > Thats why I don't think we need to define values for "IM" or "telephony" > - those should work from a generic sip client. I fully agree that there is no need for those. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 14 21:40:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17183; Mon, 14 Feb 2005 21:40:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0syf-0007Mi-1s; Mon, 14 Feb 2005 22:02:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0sZ1-0005G5-C4; Mon, 14 Feb 2005 21:35:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0sWT-0004z6-MS for simple@megatron.ietf.org; Mon, 14 Feb 2005 21:33:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16773 for ; Mon, 14 Feb 2005 21:33:07 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0srR-0007Di-2K for simple@ietf.org; Mon, 14 Feb 2005 21:54:49 -0500 Received: from razor.cs.columbia.edu (IDENT:U2FsdGVkX1/xEQbfa5R1JEsizFwdwjAP9Ma4TFrSWaM@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j1F2W0ir011275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Feb 2005 21:32:01 -0500 (EST) Received: from [127.0.0.1] (IDENT:U2FsdGVkX18a33RckB6/5YjF8YXv0oWi88XBDjG9oXM@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j1F2VxDx028582; Mon, 14 Feb 2005 21:32:00 -0500 Message-ID: <42115F1F.2030008@cs.columbia.edu> Date: Mon, 14 Feb 2005 21:31:59 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] Three dimensions of service References: <200502081853.NAA04377@ietf.org> <42093E7E.3080708@cisco.com> <421062FC.4050801@cisco.com> <4210B688.8010009@cisco.com> In-Reply-To: <4210B688.8010009@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > I would go further, and propose that implementors should bend over > backwards to make this be the case. Situations where it is not the case > should be rare. Fully agreed. > That depends on how it is done. AFAIK there hasn't been any real > engineering done on sip-for-doom, but based on the informal conversation > we had on the subject in this thread, it seems plausible to me that just > calling somebody's doom game from a regular phone could indeed provide a > passable communications experience, even if not one the operator of the > doom machine might prefer. There are other scenarios that prescaps can't quite capture, namely special media types and special event types. The D3 label can provide some hint that there might be more than classical audio and presence events involved. I can picture various scientific remote monitoring applications or even a home control application with PUB/SUB/NOT. Definitely the exception, however. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Feb 15 00:37:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00273; Tue, 15 Feb 2005 00:37:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0vjc-0002lS-KE; Tue, 15 Feb 2005 00:58:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0vNQ-0006xX-9f; Tue, 15 Feb 2005 00:36:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzNUF-00048f-64; Thu, 10 Feb 2005 18:12:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05455; Thu, 10 Feb 2005 18:12:36 -0500 (EST) Received: from [64.151.105.12] (helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzNoC-0006BA-Fo; Thu, 10 Feb 2005 18:33:22 -0500 Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 10 Feb 2005 18:12:28 -0500 id 000E434E.420BEA5C.0000476B Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3A631168-7BB9-11D9-BC8F-000D9358DFD8@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Thu, 10 Feb 2005 18:12:26 -0500 To: "'geopriv@ietf.org'" , Simple WG X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 15 Feb 2005 00:35:59 -0500 Subject: [Simple] Re: [Geopriv] substitution groups vs. any elements X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Are there any more comments regarding this issue? I'd really like to move this draft forward. -andy On Jan 25, 2005, at 3:07 PM, Andrew Newton wrote: > All, > > There remains one last, unresolved issue with > draft-ietf-geopriv-common-policy, and that is with regard to the usage > of substitution groups (requiring derivation of elements) vs. any > element. Many excellent points have been made for both cases, which > leads Allison and I to believe that we are not all on the same page > with respect to usage scenarios. > > Perhaps it would be best if we had some use cases for voice, IM, and > emergency call routing to illustrate the need for one approach vs. the > other. In each use case we should look to see if the using protocol > gives us proper protocol/namespace/schema negotiation as to allow a > sender to understand the capabilities of the receiver (which XML > Schemas the receiver knows about) and if any privacy is compromised > should the sender use elements not understood by the receiver. > > -andy > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From Mercadoogvw@neptune.net Tue Feb 15 03:00:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03665; Tue, 15 Feb 2005 03:00:50 -0500 (EST) Date: Tue, 15 Feb 2005 03:00:50 -0500 (EST) From: Mercadoogvw@neptune.net Message-Id: <200502150800.DAA03665@ietf.org> Received: from [220.121.145.38] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D0xya-0005gb-B7; Tue, 15 Feb 2005 03:22:34 -0500 Received: from precocity.i95.com ([194.221.111.140]) by avertive.godmail.com (InterMail vK.4.04.00.00 269-697-844 license 8rw570ew3334j6he2a3iiy6527h9mgs1) with ESMTP id <24512280367025.FRYU677.ammonia@precocity.i95.com> for ; Tue, 15 Feb 2005 10:57:02 +0300 Received: from yorwilighp (inherit.chinanew.com [206.71.161.24]) by precocity.i95.com (Mirapoint Messaging Server MOS 3.7.5-GR) with SMTP id H[3 X-Spam-Score: 8.5 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From Evangelina@kasnia.com Tue Feb 15 17:53:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23409 for ; Tue, 15 Feb 2005 17:53:07 -0500 (EST) Message-Id: <200502152253.RAA23409@ietf.org> Received: from midcoast01822243.midcoast.com.au ([203.18.222.43] helo=kasnia.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D1BuE-0004Rf-K8 for simple-archive@ietf.org; Tue, 15 Feb 2005 18:15:00 -0500 From: "Mstislav Barrow" To: "Jae Beckwith" Subject: Online Pharmmacy for u Date: Tue, 15 Feb 2005 17:49:33 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_0E4D835A.BAB61185" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 1.1 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 This is a multi-part message in MIME format. ------=_NextPart_000_0008_0E4D835A.BAB61185 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Have a nice day. ------=_NextPart_000_0008_0E4D835A.BAB61185 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello,  Welcome = to the best=20 online ST0RE
 
Vi ra  al Xa x  cod
ag (109$ / 30p) = Ci is (324$ /=20 90p)  na (299$ / 90p) = Vi in (178$ /=20 90p)
 
With each purchase you get:
 
>Top quality medicationn.
>Low=20 prices.
>Reputable manufacturers.
>Secure pay=20 system.
>Discreet packaging.
>Home delivery.
>Total=20 confidentiality.
>24 toll-free customer service = hotline.
 
Have a nice day.
------=_NextPart_000_0008_0E4D835A.BAB61185-- From simple-bounces@ietf.org Tue Feb 15 22:04:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22179; Tue, 15 Feb 2005 22:04:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Fp9-0003bu-RP; Tue, 15 Feb 2005 22:26:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1FRS-00072R-Mh; Tue, 15 Feb 2005 22:01:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1FNm-000603-LB for simple@megatron.ietf.org; Tue, 15 Feb 2005 21:57:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21601 for ; Tue, 15 Feb 2005 21:57:40 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Fiv-0003R1-PD for simple@ietf.org; Tue, 15 Feb 2005 22:19:35 -0500 Received: from [192.168.1.102] (c-24-23-89-57.client.comcast.net [24.23.89.57]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j1G2vV9a048992 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 15 Feb 2005 20:57:32 -0600 (CST) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Message-Id: <8f12cfa580e6460c35da2d02af977fd7@nostrum.com> From: Ben Campbell Date: Tue, 15 Feb 2005 20:57:26 -0600 To: "derek" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: Cullen Jennings , Simple WG Subject: [Simple] Re: [Sipping] MSRP BNF issues 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="===============1975760596==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 --===============1975760596== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-62--781055823; protocol="application/pkcs7-signature" --Apple-Mail-62--781055823 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Derek, BTW, MSRP is a SIMPLE draft, rather than a SIPPING draft. Specific comments inline: On Feb 14, 2005, at 9:01 PM, derek wrote: > I'm implementing MSRP parsers & started with MSRP_url, and I've=20 > noticed that the BNF described in the msrp draft does not match the=20 > examples in the sessions draft. > > =A0 > > A snippet from sessions-09: > > =A0 > > =A0=A0 To-Path =3D "To-Path:" SP MSRP-url *( SP URL ) > > =A0 > > =A0=A0 MSRP_url =3D msrp-scheme "://" [userinfo "@"] hostport > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ["/" session-id] ";" transport > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ; userinfo as defined in RFC2396, except > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ; limited to unreserved. > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ; hostport as defined in RFC3261 > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ; [Todo: update with RFC number for 2396bis] > > =A0 > > and an example from draft-ietf-simple-msrp-relays-02.txt: > > =A0 > > =A0=A0=A0 To-Path: msrps:bob.example.net:8145/foo > > =A0=A0=A0 From-Path: msrps:example.net:9000/aeiug \ > > =A0=A0=A0=A0 msrps:example.org:9000/kjfjan \ > > > =A0 > > Issues: > > =A0 > > 1. What is the '\' between path segments, and what is the line=20 > separator after it? We definitely shouldn't allow a CRLF after the=20 > '\'. > The "\" characters are merely a stylistic convention to say that there=20= are really no line breaks, but the lines were too long for the draft=20 format. Neither the "\" or the subsequent line break are really part of=20= the message. I believe there is a comment to that effect in the draft. > 2. Should session-id really be optional (may be a more fundamental=20 > MSRP question). > Yes. A MSRP URL with no session ID refers to an MSRP device, just not a=20= particular session. This format is useful for configuring an MSRP=20 client to use a particular relay. > 3. What happened to transport? Is it deprecated or just optional now? > Transport is required. This is a bug in the relay draft, which should=20 be fixed in the next version. > =A0 > > --Derek > > =A0 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP= --Apple-Mail-62--781055823 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGEjCCAssw ggI0oAMCAQICAwwdSDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwNDEyMjA0NTUyWhcNMDUwNDEyMjA0NTUyWjBBMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR4wHAYJKoZIhvcNAQkBFg9iZW5Abm9zdHJ1bS5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGFv8c1i8a9NXiEohMEryzypOcyz39k8PN WxTS4F45JSYwQ0/RAZ4vaemHCyJaUc7tc5DN3o7zl2oaqQuOIrvnjk79ILGJVfRgwt+uGDIGyaSM YmBeKXSdawFiJdk5jGtMzlgF8tzJzc4do5Mzl5YS39AR8mj8PF4zEgIlYYkKXBByHQ2jPA0qVfm/ Aj71RdYZyDAD4P7TyW9jKvZCl7KCfajar1llEQVj+kWMvt/3AE6mwAHXfkU7nL9XzLvGSnMUJvYx hq3UDju4IacXsYFw2oLb4LQdvwP4Lbg6qdp08h59+TkHlV6WNdt3ggM9C/cGQTDCa0CVJsr+76Dm mPorAgMBAAGjLDAqMBoGA1UdEQQTMBGBD2JlbkBub3N0cnVtLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBAUAA4GBAApFAg5tsI2OhByoUglTZ+ip3M/1xfWDsCNsDB4+HtnH9fZfKkrkGp4e JQyuvl5VhvW67qYU6wEPMD0EKoWDU3v7l1huzR7Cpkf7n21y4LLG+VxldYiA3SEkv7RBPhhVhdMl sHwNZAYyVXFCdnvuVjfeytdAeXK6vzcaUvo9EwkHMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0B AQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv biBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAw MDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoT zyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GU MIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3 dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQi MCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQ g+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsA xRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXe JLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMMHUgwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMDUwMjE2MDI1NzI3WjAjBgkqhkiG9w0BCQQxFgQUSd+Gp3IVuCc4e0vq K/J2e3Cj7w8weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0ECAwwdSDB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMHUgwDQYJKoZIhvcNAQEBBQAEggEAhtQ0t7O05rky4t0O 7waXMGDq8OJikcz3w839DvSepaNmNphvgX+/MKwwpvZVnFSXd+Q5s3FIG1WMx0l42rfCtASeZJkr gV/xyMoTaMXnbpaI6bQNPxvQVWwvem0YbYzfMCC6KDHDrHNTQWbsRiXzlk6ggJmyMjkmPujLjG47 KsTa3qoMzK5mWsAhmmj6fRSF+aObSMovtvE0vL/TO4iTwADM+ss7Ttwa8pHli76e0bUJroOBXV7W aZxJAov0PCYCvYE4sgXv7VulXZpz12wj9ccbulRj5pu8dkYaifENgr/sCbzkalhdFCE8iI0TKLCY 2x9f/RSzhPQRFJhgsoOY3wAAAAAAAA== --Apple-Mail-62--781055823-- --===============1975760596== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1975760596==-- From glwthxpr@blueyonder.co.uk Wed Feb 16 00:22:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20242; Wed, 16 Feb 2005 00:22:47 -0500 (EST) Received: from [222.118.89.126] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D1HzP-0007a3-I7; Wed, 16 Feb 2005 00:44:44 -0500 Received: from seismography-wm11.emmett.industrialac.com (120.148.105.194) by k5-sbs60.industrialac.com with Microsoft SMTPSVC(5.0.2195.6824); Wed, 16 Feb 2005 00:13:43 -0500 From: OnlinePharmacy To: simple-archive@ietf.org Subject: OnlinePharmacyCheap Date: Wed, 16 Feb 2005 00:18:43 -0500 EST Message-ID: <0043950404871135.248944.1662@chaste-ur6.industrialac.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--ueyotmtibzqxxe2270170972lqd" X-Spam-Score: 5.6 (+++++) X-Spam-Flag: YES X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d ----ueyotmtibzqxxe2270170972lqd Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable Get all the medication you need at incredible discounts. http://ruojrxor.com/index.php?news Choose it yourself and save big on Doctor visits and Retail prices, in jus= t 2 simple steps! What condition are you seeking treatment for? Anti Depressant Anxiety Cholesterol Diabetes Muscle Relaxant Men's Health Pain Relief Sexual Health & many more, http://ruojrxor.com/index.php?news Not Interested? http://bfijdeacghkl.comcities.info/go.php?egjkbdxyclzafhim ----ueyotmtibzqxxe2270170972lqd-- From simple-bounces@ietf.org Wed Feb 16 03:12:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10447; Wed, 16 Feb 2005 03:12:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Kdp-0003gZ-T5; Wed, 16 Feb 2005 03:34:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1KEi-0002RX-Mr; Wed, 16 Feb 2005 03:08:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1KD0-0001OB-Mj for simple@megatron.ietf.org; Wed, 16 Feb 2005 03:06:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09924 for ; Wed, 16 Feb 2005 03:06:52 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1KY9-0003Vx-Lz for simple@ietf.org; Wed, 16 Feb 2005 03:28:47 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 16 Feb 2005 00:06:45 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1G86GYO017050; Wed, 16 Feb 2005 00:06:17 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-22.cisco.com [10.86.242.22]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHT97326; Wed, 16 Feb 2005 00:06:16 -0800 (PST) Message-ID: <4212FEF7.3050504@cisco.com> Date: Wed, 16 Feb 2005 03:06:15 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] Three dimensions of service References: <200502081853.NAA04377@ietf.org> <42093E7E.3080708@cisco.com> <421062FC.4050801@cisco.com> <42115C6E.4030402@cs.columbia.edu> In-Reply-To: <42115C6E.4030402@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > >> I think that whether you need some kind of D3 indicator depends >> entirely on the answer to this question - "if a caller had no >> information on the service besides the prescaps information, would >> they be able to make a successful communications attemtp that did >> something sensible"? >> >> In most cases, I think the answer is yes. In such cases, I don't think >> you gain much by conveying this parameter. > > > There are two aspects to communication and to choosing communication > options? > > (1) Will the bits flow correctly? (Sound comes out of the speaker, video > pops up, etc.) > > (2) Will these bits make sense to the human? > > By the principle that presence should reduce the surprise factor, > knowing that clicking that SIP URL will connect to the sounds of machine > gun fire and exploding monsters instead of a "hello" is a useful thing, > in rather limited circumstances. Right. > > I fully agree that D3 should *never* be necessary for aspect (1). We have, though, in the past, considered issues which could rightfully be issue (1) but are not yet covered by prescaps. In particular, cases where the caller has to support a particular non-standard behavior that may or may not even show up as an extension. For example, the OMA PTT is really a set of behaviors that aren't easily listed as an extension per se, but i will not be able to make a call from my xten phone to an OMA PTT client and get anything to work. I have argued that these implementations aren't sip and shouldnt even use the sip URI. Rather, they should define their own URI schemes. There didnt seem to be consensus around that view though. Stepping back for a moment, though, is this whole thing here something we feel needs addressing in the data model or rpid somewhere? I don't think that an "app launcher" attribute really changes the MODEL in any way; if we decide we want it or something similar it could be defined by a pidf extension as a new service attribute. I also don't think its something we should address in the current rpid. In that case, this discussion is interesting but not relevant for completing the work at hand unless someone can bring some requirements forward that demonstrate otherwise. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 16 06:47:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28230; Wed, 16 Feb 2005 06:47:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Nzk-00016o-MG; Wed, 16 Feb 2005 07:09:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1NVq-0005rZ-UJ; Wed, 16 Feb 2005 06:38:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1NS3-0004mk-Rr for simple@megatron.ietf.org; Wed, 16 Feb 2005 06:34:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26803 for ; Wed, 16 Feb 2005 06:34:36 -0500 (EST) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1NnI-0000ei-LT for simple@ietf.org; Wed, 16 Feb 2005 06:56:37 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1GBYN928572; Wed, 16 Feb 2005 13:34:24 +0200 (EET) X-Scanned: Wed, 16 Feb 2005 13:33:37 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j1GBXb9o028767; Wed, 16 Feb 2005 13:33:37 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00twR4dn; Wed, 16 Feb 2005 13:33:36 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1GBWiM12824; Wed, 16 Feb 2005 13:32:44 +0200 (EET) Received: from [172.21.39.180] ([172.21.39.180]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 16 Feb 2005 13:32:27 +0200 Message-ID: <42132F4A.4080909@nokia.com> Date: Wed, 16 Feb 2005 13:32:26 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Simple] Three dimensions of service References: <200502081853.NAA04377@ietf.org> <42093E7E.3080708@cisco.com> <421062FC.4050801@cisco.com> <42115C6E.4030402@cs.columbia.edu> <4212FEF7.3050504@cisco.com> In-Reply-To: <4212FEF7.3050504@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Feb 2005 11:32:27.0936 (UTC) FILETIME=[31A2EA00:01C5141B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit Sorry for jumping in late to this thread. I think this discussion has been productive. Inline. ext Jonathan Rosenberg wrote: > inline. > > Henning Schulzrinne wrote: > >> Jonathan Rosenberg wrote: >> >>> I think that whether you need some kind of D3 indicator depends >>> entirely on the answer to this question - "if a caller had no >>> information on the service besides the prescaps information, would >>> they be able to make a successful communications attemtp that did >>> something sensible"? >>> >>> In most cases, I think the answer is yes. In such cases, I don't >>> think you gain much by conveying this parameter. >> >> >> >> There are two aspects to communication and to choosing communication >> options? >> >> (1) Will the bits flow correctly? (Sound comes out of the speaker, >> video pops up, etc.) >> >> (2) Will these bits make sense to the human? >> >> By the principle that presence should reduce the surprise factor, >> knowing that clicking that SIP URL will connect to the sounds of >> machine gun fire and exploding monsters instead of a "hello" is a >> useful thing, in rather limited circumstances. > > > Right. > >> >> I fully agree that D3 should *never* be necessary for aspect (1). > > > We have, though, in the past, considered issues which could rightfully > be issue (1) but are not yet covered by prescaps. In particular, cases > where the caller has to support a particular non-standard behavior that > may or may not even show up as an extension. For example, the OMA PTT is > really a set of behaviors that aren't easily listed as an extension per > se, but i will not be able to make a call from my xten phone to an OMA > PTT client and get anything to work. Non-standard is kind of a misnomer here. Surely you don't expect the feature set offered by SIP phones to remain static forever. SIP is not only voice and video, it can be used for rendezvous and session initiation of any medium, standard or non-standard. E.g., comedia gives tools for doing just that. Still, I regard this business as usual. You calling my OMA PTT phone with an xten phone would probably fail, as it should. But that is a valid outcome of a session initiation attempt -- the phones didn't have a commonly supported medium to establish. The same would happen if I had a standard MSRP client that you happened to call with a voice-only softphone. This only becomes a problem with presence, where you would want to know if this is likely to happen *before* the attempt is made. More on that below. > I have argued that these implementations aren't sip and shouldnt even > use the sip URI. Rather, they should define their own URI schemes. There > didnt seem to be consensus around that view though. I don't understand what is non-SIP about an INVITE-20O-ACK that establishes a session? Rather, I think this is a problem caused because of the limitations imposed to us by PIDF, which has a rather simplistic view of what a contact element indicates. There a SIP contact indicates that the tuple is a SIP service, and presumably negotiation (that happens within SIP) will determine what type of service specifically will result by selecting that contact. But to know beforehand, for any service (standard, non-standard, fictional, etc.), we would need some service-type indication that goes beyond the standard prescaps markup along with a "require-to-understand" flag, so that the watcher could determine whether it understands the service, and consequently decide whether even should even render the tuple to the user. Surely defining a new URI scheme would hack around this problem in terms of representation in PIDF, but in more general terms it is exactly what we want to avoid. I don't want half a dozen or more URIs printed on my business card, vCard, web page or anywhere else. This is what we are currently faced with e.g., by having multiple IM systems, and we should not go there in SIP. After all, we don't have a new URI scheme for MSRP for the purpose of sticking it in presence documents. Presumably, one would still initiate MSRP by calling a SIP URI, even though a voice-only phone would not accept the call. > Stepping back for a moment, though, is this whole thing here something > we feel needs addressing in the data model or rpid somewhere? I don't > think that an "app launcher" attribute really changes the MODEL in any > way; if we decide we want it or something similar it could be defined by > a pidf extension as a new service attribute. I also don't think its > something we should address in the current rpid. In that case, this > discussion is interesting but not relevant for completing the work at > hand unless someone can bring some requirements forward that demonstrate > otherwise. I agree. The "app launcher" doesn't make or break the model, but the model has to accomodate such extensions that may be unknown to the composer. So assuming the existance of such unknown extensions, the composer MUST be allowed to pass tuples along intact, and the watcher MUST be able to handle this. I think this means "many tuples" instead of "single tuple". Cheers, Aki > -Jonathan R. > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 16 08:38:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08681; Wed, 16 Feb 2005 08:38:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Pj4-00045P-9x; Wed, 16 Feb 2005 09:00:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1PJ5-0004Bq-FM; Wed, 16 Feb 2005 08:33:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1PFM-0003D6-Ac for simple@megatron.ietf.org; Wed, 16 Feb 2005 08:29:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07976 for ; Wed, 16 Feb 2005 08:29:38 -0500 (EST) Message-Id: <200502161329.IAA07976@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Pac-0003sn-2m for simple@ietf.org; Wed, 16 Feb 2005 08:51:38 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1D1PF5-0000uB-8t; Wed, 16 Feb 2005 07:29:24 -0600 From: "Brian Rosen" To: "'Aki Niemi'" , "'ext Jonathan Rosenberg'" Subject: RE: [Simple] Three dimensions of service Date: Wed, 16 Feb 2005 08:29:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <42132F4A.4080909@nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUUHUvnrJHjMVQ3Q+SrCrH1O1M+zwAC51XA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" , "'Henning Schulzrinne'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: 7bit Sorry for being away from this for a couple of days; busy on other things. I was with Aki right until the end. I think that we need a "service" indication in the tuple to cover all of those things that are discussed that mean the difference between being able to predict whether a "call" will "succeed". That's in the human sense; will I get what I expected to happen? Presence is all about providing information to predict what will happen if you (a human) launch a session establishment request. The result of presence is not an INVITE. The result is some kind of display to a human. The human then makes a decision to initiate session establishment. If he doesn't get what he expected, we've failed. It is foolish, I think, to believe that you will always be able to make that kind of prediction within the limitations of prescaps and similar mechanical things. They may allow devices to have some kind of media flow, but that isn't interesting. What I want to know is will it "work", that is, does it meet my expectations? Multiple tuples won't answer the question. We would have to make a large variety of capabilities we can individually define such that a specific set of them is unique enough that the human believes that it "worked". Even if that worked in the mechanical sense, there isn't any way to make that work in a presence system because we can't reasonably show the human what is happening; too much detail, not enough big picture. We need a more abstract way to do that. A name (with a registry) is the easiest thing I can think of that will provide the human with the right sense. If I say I'm "open" for "Doom", then if your "Doom" client calls me, its going to work the way I expect it will. If your "Asheron" client calls me, it probably wont. Same for OMA PTT Same for anything else. Brian > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Aki Niemi > Sent: Wednesday, February 16, 2005 6:32 AM > To: ext Jonathan Rosenberg > Cc: 'Simple WG'; Henning Schulzrinne > Subject: Re: [Simple] Three dimensions of service > > Sorry for jumping in late to this thread. I think this discussion has > been productive. > > Inline. > > ext Jonathan Rosenberg wrote: > > inline. > > > > Henning Schulzrinne wrote: > > > >> Jonathan Rosenberg wrote: > >> > >>> I think that whether you need some kind of D3 indicator depends > >>> entirely on the answer to this question - "if a caller had no > >>> information on the service besides the prescaps information, would > >>> they be able to make a successful communications attemtp that did > >>> something sensible"? > >>> > >>> In most cases, I think the answer is yes. In such cases, I don't > >>> think you gain much by conveying this parameter. > >> > >> > >> > >> There are two aspects to communication and to choosing communication > >> options? > >> > >> (1) Will the bits flow correctly? (Sound comes out of the speaker, > >> video pops up, etc.) > >> > >> (2) Will these bits make sense to the human? > >> > >> By the principle that presence should reduce the surprise factor, > >> knowing that clicking that SIP URL will connect to the sounds of > >> machine gun fire and exploding monsters instead of a "hello" is a > >> useful thing, in rather limited circumstances. > > > > > > Right. > > > >> > >> I fully agree that D3 should *never* be necessary for aspect (1). > > > > > > We have, though, in the past, considered issues which could rightfully > > be issue (1) but are not yet covered by prescaps. In particular, cases > > where the caller has to support a particular non-standard behavior that > > may or may not even show up as an extension. For example, the OMA PTT is > > really a set of behaviors that aren't easily listed as an extension per > > se, but i will not be able to make a call from my xten phone to an OMA > > PTT client and get anything to work. > > Non-standard is kind of a misnomer here. Surely you don't expect the > feature set offered by SIP phones to remain static forever. SIP is not > only voice and video, it can be used for rendezvous and session > initiation of any medium, standard or non-standard. E.g., comedia gives > tools for doing just that. > > Still, I regard this business as usual. You calling my OMA PTT phone > with an xten phone would probably fail, as it should. But that is a > valid outcome of a session initiation attempt -- the phones didn't have > a commonly supported medium to establish. The same would happen if I had > a standard MSRP client that you happened to call with a voice-only > softphone. > > This only becomes a problem with presence, where you would want to know > if this is likely to happen *before* the attempt is made. More on that > below. > > > I have argued that these implementations aren't sip and shouldnt even > > use the sip URI. Rather, they should define their own URI schemes. There > > didnt seem to be consensus around that view though. > > I don't understand what is non-SIP about an INVITE-20O-ACK that > establishes a session? > > Rather, I think this is a problem caused because of the limitations > imposed to us by PIDF, which has a rather simplistic view of what a > contact element indicates. There a SIP contact indicates that the tuple > is a SIP service, and presumably negotiation (that happens within SIP) > will determine what type of service specifically will result by > selecting that contact. > > But to know beforehand, for any service (standard, non-standard, > fictional, etc.), we would need some service-type indication that goes > beyond the standard prescaps markup along with a "require-to-understand" > flag, so that the watcher could determine whether it understands the > service, and consequently decide whether even should even render the > tuple to the user. > > Surely defining a new URI scheme would hack around this problem in terms > of representation in PIDF, but in more general terms it is exactly what > we want to avoid. I don't want half a dozen or more URIs printed on my > business card, vCard, web page or anywhere else. This is what we are > currently faced with e.g., by having multiple IM systems, and we should > not go there in SIP. > > After all, we don't have a new URI scheme for MSRP for the purpose of > sticking it in presence documents. Presumably, one would still initiate > MSRP by calling a SIP URI, even though a voice-only phone would not > accept the call. > > > Stepping back for a moment, though, is this whole thing here something > > we feel needs addressing in the data model or rpid somewhere? I don't > > think that an "app launcher" attribute really changes the MODEL in any > > way; if we decide we want it or something similar it could be defined by > > a pidf extension as a new service attribute. I also don't think its > > something we should address in the current rpid. In that case, this > > discussion is interesting but not relevant for completing the work at > > hand unless someone can bring some requirements forward that demonstrate > > otherwise. > > I agree. The "app launcher" doesn't make or break the model, but the > model has to accomodate such extensions that may be unknown to the > composer. So assuming the existance of such unknown extensions, the > composer MUST be allowed to pass tuples along intact, and the watcher > MUST be able to handle this. I think this means "many tuples" instead of > "single tuple". > > Cheers, > Aki > > > -Jonathan R. > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 16 14:47:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10423; Wed, 16 Feb 2005 14:47:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1VUN-0006yE-6v; Wed, 16 Feb 2005 15:09:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1TW2-0008G3-Ip; Wed, 16 Feb 2005 13:03:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1RqR-0002o7-SP for simple@megatron.ietf.org; Wed, 16 Feb 2005 11:16:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07821 for ; Wed, 16 Feb 2005 11:16:04 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1SBi-0003lK-PK for simple@ietf.org; Wed, 16 Feb 2005 11:38:07 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 16 Feb 2005 08:25:57 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1GGFgqA023139; Wed, 16 Feb 2005 08:15:44 -0800 (PST) Received: from cisco.com ([161.44.79.182]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APE17995; Wed, 16 Feb 2005 11:15:47 -0500 (EST) Message-ID: <421371B3.6070505@cisco.com> Date: Wed, 16 Feb 2005 11:15:47 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] Three dimensions of service References: <200502161329.IAA07976@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Content-Transfer-Encoding: 7bit Cc: "'Henning Schulzrinne'" , "'Aki Niemi'" , "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Content-Transfer-Encoding: 7bit Brian Rosen wrote: > Sorry for being away from this for a couple of days; busy on other things. > > I was with Aki right until the end. I think that we need a "service" > indication in the tuple to cover all of those things that are > discussed that mean the difference between being able to predict > whether a "call" will "succeed". That's in the human sense; > will I get what I expected to happen? Presence is all about > providing information to predict what will happen if you (a human) > launch a session establishment request. The result of presence is > not an INVITE. The result is some kind of display to a human. > The human then makes a decision to initiate session establishment. > If he doesn't get what he expected, we've failed. > > It is foolish, I think, to believe that you will always be able to > make that kind of prediction within the limitations of prescaps and > similar mechanical things. They may allow devices to have some kind > of media flow, but that isn't interesting. What I want to know is > will it "work", that is, does it meet my expectations? I'm not buying this. I think it just means you are trying to avoid the work of understanding what it is that "won't work". I do buy the value in describing the kinds of semantic content that I might experience - but that is not the same thing as "won't work". For instance if I want to talk to you, and a particular tuple will take me to a VM server or assistant, the call to that will "work" and provide a plausible call experience, but may not be what I desire. > Multiple tuples won't answer the question. We would have to make > a large variety of capabilities we can individually > define such that a specific set of them is unique enough that the human > believes that it "worked". Even if that worked in the mechanical > sense, there isn't any way to make that work in a presence system > because we can't reasonably show the human what is happening; > too much detail, not enough big picture. I'm not convinced of that. The individual capabilities MAY each be represented as an ICON. That may be great in some cases, or an overwhelming amount of detail in others. But a UA with limitied capabilities can bound this, not bothering to represent capabilities that it has no way of exploiting, and perhaps recognizing groupings of capabilities are are of note to it and representing them specially. > We need a more abstract way to do that. That just puts off a problem. We need to have some notion of how this is will be useful operationally. > A name (with a registry) is the easiest thing I can think of that > will provide the human with the right sense. If I say I'm "open" > for "Doom", then if your "Doom" client calls me, its going to work the > way I expect it will. If your "Asheron" client calls me, it probably > wont. I still don't get this. We went through several scenarios of how doom might be integrated with sip. The only plausible ones had a special protocol for control of game play, with other media simply being gratuitous. As long as there is a unique prescaps representation for each game protocol stream, one game will know what to look for to find another instance of the same game, and callers that support only the gratuitous media should get some kind of meaningful result. > Same for OMA PTT It is putting PTT into this category that bothers me the most. I want to know how, without any changes, that PTT would be represented in presence, what that would lead watchers to erroneously conclude, and what the end result would be. If PTT is enough like regular voice that it could be mistaken as such by a watcher, then it seems to me that it would be far better for it to work in a degraded mode when one of the clients is a regular voice client. (E.g. maybe the regular voice client can't request the floor, and so is always in receive-only mode.) Worst case would be that the PTT uses a special codec that is not supported by normal voice clients. But that is no different than any case where there is no codec in common. Paul > Same for anything else. > > Brian > > >>-----Original Message----- >>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf >>Of Aki Niemi >>Sent: Wednesday, February 16, 2005 6:32 AM >>To: ext Jonathan Rosenberg >>Cc: 'Simple WG'; Henning Schulzrinne >>Subject: Re: [Simple] Three dimensions of service >> >>Sorry for jumping in late to this thread. I think this discussion has >>been productive. >> >>Inline. >> >>ext Jonathan Rosenberg wrote: >> >>>inline. >>> >>>Henning Schulzrinne wrote: >>> >>> >>>>Jonathan Rosenberg wrote: >>>> >>>> >>>>>I think that whether you need some kind of D3 indicator depends >>>>>entirely on the answer to this question - "if a caller had no >>>>>information on the service besides the prescaps information, would >>>>>they be able to make a successful communications attemtp that did >>>>>something sensible"? >>>>> >>>>>In most cases, I think the answer is yes. In such cases, I don't >>>>>think you gain much by conveying this parameter. >>>> >>>> >>>> >>>>There are two aspects to communication and to choosing communication >>>>options? >>>> >>>>(1) Will the bits flow correctly? (Sound comes out of the speaker, >>>>video pops up, etc.) >>>> >>>>(2) Will these bits make sense to the human? >>>> >>>>By the principle that presence should reduce the surprise factor, >>>>knowing that clicking that SIP URL will connect to the sounds of >>>>machine gun fire and exploding monsters instead of a "hello" is a >>>>useful thing, in rather limited circumstances. >>> >>> >>>Right. >>> >>> >>>>I fully agree that D3 should *never* be necessary for aspect (1). >>> >>> >>>We have, though, in the past, considered issues which could rightfully >>>be issue (1) but are not yet covered by prescaps. In particular, cases >>>where the caller has to support a particular non-standard behavior that >>>may or may not even show up as an extension. For example, the OMA PTT is >>>really a set of behaviors that aren't easily listed as an extension per >>>se, but i will not be able to make a call from my xten phone to an OMA >>>PTT client and get anything to work. >> >>Non-standard is kind of a misnomer here. Surely you don't expect the >>feature set offered by SIP phones to remain static forever. SIP is not >>only voice and video, it can be used for rendezvous and session >>initiation of any medium, standard or non-standard. E.g., comedia gives >>tools for doing just that. >> >>Still, I regard this business as usual. You calling my OMA PTT phone >>with an xten phone would probably fail, as it should. But that is a >>valid outcome of a session initiation attempt -- the phones didn't have >>a commonly supported medium to establish. The same would happen if I had >>a standard MSRP client that you happened to call with a voice-only >>softphone. >> >>This only becomes a problem with presence, where you would want to know >>if this is likely to happen *before* the attempt is made. More on that >>below. >> >> >>>I have argued that these implementations aren't sip and shouldnt even >>>use the sip URI. Rather, they should define their own URI schemes. There >>>didnt seem to be consensus around that view though. >> >>I don't understand what is non-SIP about an INVITE-20O-ACK that >>establishes a session? >> >>Rather, I think this is a problem caused because of the limitations >>imposed to us by PIDF, which has a rather simplistic view of what a >>contact element indicates. There a SIP contact indicates that the tuple >>is a SIP service, and presumably negotiation (that happens within SIP) >>will determine what type of service specifically will result by >>selecting that contact. >> >>But to know beforehand, for any service (standard, non-standard, >>fictional, etc.), we would need some service-type indication that goes >>beyond the standard prescaps markup along with a "require-to-understand" >>flag, so that the watcher could determine whether it understands the >>service, and consequently decide whether even should even render the >>tuple to the user. >> >>Surely defining a new URI scheme would hack around this problem in terms >>of representation in PIDF, but in more general terms it is exactly what >>we want to avoid. I don't want half a dozen or more URIs printed on my >>business card, vCard, web page or anywhere else. This is what we are >>currently faced with e.g., by having multiple IM systems, and we should >>not go there in SIP. >> >>After all, we don't have a new URI scheme for MSRP for the purpose of >>sticking it in presence documents. Presumably, one would still initiate >>MSRP by calling a SIP URI, even though a voice-only phone would not >>accept the call. >> >> >>>Stepping back for a moment, though, is this whole thing here something >>>we feel needs addressing in the data model or rpid somewhere? I don't >>>think that an "app launcher" attribute really changes the MODEL in any >>>way; if we decide we want it or something similar it could be defined by >>>a pidf extension as a new service attribute. I also don't think its >>>something we should address in the current rpid. In that case, this >>>discussion is interesting but not relevant for completing the work at >>>hand unless someone can bring some requirements forward that demonstrate >>>otherwise. >> >>I agree. The "app launcher" doesn't make or break the model, but the >>model has to accomodate such extensions that may be unknown to the >>composer. So assuming the existance of such unknown extensions, the >>composer MUST be allowed to pass tuples along intact, and the watcher >>MUST be able to handle this. I think this means "many tuples" instead of >>"single tuple". >> >>Cheers, >>Aki >> >> >>>-Jonathan R. >>> >>> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 16 15:27:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18686; Wed, 16 Feb 2005 15:27:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1W76-0000a8-51; Wed, 16 Feb 2005 15:49:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1VMi-0004tR-2K; Wed, 16 Feb 2005 15:01:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Uea-0006IO-QL for simple@megatron.ietf.org; Wed, 16 Feb 2005 14:16:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01132 for ; Wed, 16 Feb 2005 14:16:02 -0500 (EST) Message-Id: <200502161916.OAA01132@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Uzt-0004GA-KH for simple@ietf.org; Wed, 16 Feb 2005 14:38:06 -0500 Received: from acs-24-154-127-163.zoominternet.net ([24.154.127.163] helo=BROSENLT) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1D1UeT-00005r-4R; Wed, 16 Feb 2005 13:15:57 -0600 From: "Brian Rosen" To: "'Paul Kyzivat'" Subject: RE: [Simple] Three dimensions of service Date: Wed, 16 Feb 2005 14:15:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <421371B3.6070505@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUUQsoKRXyzxdz5Qv6vWeWzFMOgZAAFklZQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Cc: "'Henning Schulzrinne'" , "'Aki Niemi'" , "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit > I'm not buying this. I think it just means you are trying to avoid the > work of understanding what it is that "won't work". > > I do buy the value in describing the kinds of semantic content that I > might experience - but that is not the same thing as "won't work". For > instance if I want to talk to you, and a particular tuple will take me > to a VM server or assistant, the call to that will "work" and provide a > plausible call experience, but may not be what I desire. Actually, I think that is part of the disconnect we are having. The point of presence is to prevent this very thing. I don't need presence if I call and maybe I get you and maybe I get VM and maybe I get an assistant. The point of presence is to tell you what you will get. .... > I'm not convinced of that. The individual capabilities MAY each be > represented as an ICON. That may be great in some cases, or an > overwhelming amount of detail in others. But a UA with limitied > capabilities can bound this, not bothering to represent capabilities > that it has no way of exploiting, and perhaps recognizing groupings of > capabilities are are of note to it and representing them specially. Yep, I understand that you think this is possible. I don't. Try to think of what it is that the icon would look like that would show you the difference between, say, a PTT that was half duplex and another that was full duplex. Is that what you want to see? > > > We need a more abstract way to do that. > > That just puts off a problem. We need to have some notion of how this is > will be useful operationally. I don't agree that it pushes the problem off. It recognizes that the problem is so hard, that we will never solve it. It offers a reasonable way to deal with a hard problem. We will invent services faster than we will invent ways to classify services such that you can tell, from an icon, whether two services are compatible enough that your expectation when you initiate a session matches what you expected to happen. A human isn't bad at that sort of thing, and most are quick learners. Presence systems are unlikely to be good, and are very slow learners, unless you are expecting the user to "score" the presence server after each session attempt. > > > A name (with a registry) is the easiest thing I can think of that > > will provide the human with the right sense. If I say I'm "open" > > for "Doom", then if your "Doom" client calls me, its going to work the > > way I expect it will. If your "Asheron" client calls me, it probably > > wont. > > I still don't get this. We went through several scenarios of how doom > might be integrated with sip. The only plausible ones had a special > protocol for control of game play, with other media simply being > gratuitous. As long as there is a unique prescaps representation for > each game protocol stream, one game will know what to look for to find > another instance of the same game, and callers that support only the > gratuitous media should get some kind of meaningful result. Maybe a poor example because the Doom game stream is different from the Asheron game stream. Maybe a better example is team Doom and solo Doom, where the game stream is the same protocol, although used somewhat differently, and the audio/video mechanisms are different. > > > Same for OMA PTT > > It is putting PTT into this category that bothers me the most. I want to > know how, without any changes, that PTT would be represented in > presence, what that would lead watchers to erroneously conclude, and > what the end result would be. I'm sorry, I don't understand the question. There are in fact several variants of PTT. While we may evolve to one winner and a bunch of losers, I wouldn't hold my breath. I'm sure some variants might be recognizable from the prescaps, but I doubt it will work for all of them. > > If PTT is enough like regular voice that it could be mistaken as such by > a watcher, then it seems to me that it would be far better for it to > work in a degraded mode when one of the clients is a regular voice > client. (E.g. maybe the regular voice client can't request the floor, > and so is always in receive-only mode.) Worst case would be that the PTT > uses a special codec that is not supported by normal voice clients. But > that is no different than any case where there is no codec in common. A human can decide to initiate a session when the services don't match. That's up to him. His expectation in that case would be shaped by his prior experience. If he had none, he would have low expectations - might work, might not. Next time, he would know - doesn't work, works okay, works great. Having the presence system try to intuit what that experience will be based on things like prescaps is, to my way of thinking, crazy, and it won't improve over time unless the programming team is kept very busy. Too much possible variation, and I don't WANT to see a lot of variables. Brian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 16 18:14:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09468; Wed, 16 Feb 2005 18:14:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1YiT-0006Tz-7F; Wed, 16 Feb 2005 18:36:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1YFY-0007wT-UQ; Wed, 16 Feb 2005 18:06:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Y8c-0004GL-8K for simple@megatron.ietf.org; Wed, 16 Feb 2005 17:59:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07346 for ; Wed, 16 Feb 2005 17:59:15 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1YTx-00061d-0h for simple@ietf.org; Wed, 16 Feb 2005 18:21:21 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 16 Feb 2005 15:02:09 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,91,1107763200"; d="scan'208"; a="161863379:sNHT25218636" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1GMwhwN024460; Wed, 16 Feb 2005 14:58:44 -0800 (PST) Received: from cisco.com ([161.44.79.182]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APE58110; Wed, 16 Feb 2005 17:58:42 -0500 (EST) Message-ID: <4213D022.80206@cisco.com> Date: Wed, 16 Feb 2005 17:58:42 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Simple] Three dimensions of service References: <200502161916.OAA01132@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" , "'Aki Niemi'" , "'Henning Schulzrinne'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: 7bit Brian Rosen wrote: >>I'm not buying this. I think it just means you are trying to avoid the >>work of understanding what it is that "won't work". >> >>I do buy the value in describing the kinds of semantic content that I >>might experience - but that is not the same thing as "won't work". For >>instance if I want to talk to you, and a particular tuple will take me >>to a VM server or assistant, the call to that will "work" and provide a >>plausible call experience, but may not be what I desire. > > Actually, I think that is part of the disconnect we are having. > The point of presence is to prevent this very thing. > > I don't need presence if I call and maybe I get you and maybe I get > VM and maybe I get an assistant. The point of presence is to tell you what > you will get. > > .... I think the disconnect is that there are a multitude of potential use cases out there. We are both trying to figure out how to describe them with some finite number of attributes. But we are disagreeing on what the dimensions are, and the kinds of attributes needed to describe them. I think you are trying to declare a big "other" category with a single registry used to accumulate names for the cases. Henning and I, and I think Jonathan as well, agree that there is an "other" category, but include less in it than you do. There are more things that we think can be identified by other attributes. I don't think that "voicemail", "attendant", "Doom", "Asheron", and "Acme-brand-PTT" are all just different "service types". >>I'm not convinced of that. The individual capabilities MAY each be >>represented as an ICON. That may be great in some cases, or an >>overwhelming amount of detail in others. But a UA with limitied >>capabilities can bound this, not bothering to represent capabilities >>that it has no way of exploiting, and perhaps recognizing groupings of >>capabilities are are of note to it and representing them specially. > > Yep, I understand that you think this is possible. I don't. > Try to think of what it is that the icon would look like that would > show you the difference between, say, a PTT that was half duplex and another > that was full duplex. Is that what you want to see? I don't know how to answer that, because I don't have the data about what id different about these things. I suspect some variants are just broken, and shouldn't be accomodated at all. This seems no different than if Motorolla sip phones couldn't talk to Cisco sip phones. Should we just declare them to be different "service types" and write it off as an acceptable incompatibility? >>>We need a more abstract way to do that. >> >>That just puts off a problem. We need to have some notion of how this is >>will be useful operationally. > > I don't agree that it pushes the problem off. It recognizes that the > problem is so hard, that we will never solve it. It offers a reasonable > way to deal with a hard problem. We will invent services faster than we > will invent ways to classify services such that you can tell, from an icon, > whether two services are compatible enough that your expectation when you > initiate a session matches what you expected to happen. A human isn't > bad at that sort of thing, and most are quick learners. Presence systems > are unlikely to be good, and are very slow learners, unless you are > expecting the user to "score" the presence server after each session > attempt. It seems to me you are talking about *tunneling* of another protocol via sip and a set of negotiated media streams. As opposed to what sip is intended for, which is *initiating* protocols. I am inclined to declare representation of that out of scope. >>>A name (with a registry) is the easiest thing I can think of that >>>will provide the human with the right sense. If I say I'm "open" >>>for "Doom", then if your "Doom" client calls me, its going to work the >>>way I expect it will. If your "Asheron" client calls me, it probably >>>wont. >> >>I still don't get this. We went through several scenarios of how doom >>might be integrated with sip. The only plausible ones had a special >>protocol for control of game play, with other media simply being >>gratuitous. As long as there is a unique prescaps representation for >>each game protocol stream, one game will know what to look for to find >>another instance of the same game, and callers that support only the >>gratuitous media should get some kind of meaningful result. > > Maybe a poor example because the Doom game stream is different from the > Asheron game stream. Exactly. > Maybe a better example is team Doom and solo Doom, > where the game stream is the same protocol, although used somewhat > differently, and the audio/video mechanisms are different. Bad design. They can find a better way to do it - different variants of the Doom protocol. But still orthogonal from other potential capabilities of the same endpoint. For instance, I may not have a sip-enabled Doom machine anyway. What I may have is a sip-enabled game machine, that can support both Doom and Asheron, as well as voice. So I may well be able to see that, call from my comparable machine, using just voice, and discuss whether to play Doom or Asheron. When that is decided we just reinvite to initiate the proper protocol for game control. >>>Same for OMA PTT >> >>It is putting PTT into this category that bothers me the most. I want to >>know how, without any changes, that PTT would be represented in >>presence, what that would lead watchers to erroneously conclude, and >>what the end result would be. > > I'm sorry, I don't understand the question. There are in fact several > variants of PTT. While we may evolve to one winner and a bunch of losers, I > wouldn't hold my breath. I'm sure some variants might be recognizable from > the prescaps, but I doubt it will work for all of them. Maybe having some sort of rational integration with presence should play a part in which is the winner and which are the losers. I would find it at least weird and annoying if every cell phone showed up as two distinct tuples - one for regular audio, one for PTT. Ever worse if there is yet another one for audio+video. Functionally they are just modalities, not different devices. >>If PTT is enough like regular voice that it could be mistaken as such by >>a watcher, then it seems to me that it would be far better for it to >>work in a degraded mode when one of the clients is a regular voice >>client. (E.g. maybe the regular voice client can't request the floor, >>and so is always in receive-only mode.) Worst case would be that the PTT >>uses a special codec that is not supported by normal voice clients. But >>that is no different than any case where there is no codec in common. > > A human can decide to initiate a session when the services don't match. > That's up to him. His expectation in that case would be shaped by his prior > experience. If he had none, he would have low expectations - might work, > might not. Next time, he would know - doesn't work, works okay, works > great. > > Having the presence system try to intuit what that experience will be based > on things like prescaps is, to my way of thinking, crazy, and it won't > improve over time unless the programming team is kept very busy. Too much > possible variation, and I don't WANT to see a lot of variables. I'm not suggesting that there be no difference in the descriptions of a PTT device and a regular voice device. But AFAIK PTT is a modality, or option. It ought to look like that. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 16 18:44:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13147; Wed, 16 Feb 2005 18:44:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1ZC7-0007PI-Cm; Wed, 16 Feb 2005 19:06:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Yl8-0003zK-0T; Wed, 16 Feb 2005 18:39:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1YdR-0000re-31 for simple@megatron.ietf.org; Wed, 16 Feb 2005 18:31:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11338 for ; Wed, 16 Feb 2005 18:31:05 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Yym-0006tn-7A for simple@ietf.org; Wed, 16 Feb 2005 18:53:12 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 16 Feb 2005 18:30:38 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1GNUUhJ001286; Wed, 16 Feb 2005 18:30:34 -0500 (EST) Received: from cisco.com ([161.44.79.182]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APE60187; Wed, 16 Feb 2005 18:30:30 -0500 (EST) Message-ID: <4213D796.4020200@cisco.com> Date: Wed, 16 Feb 2005 18:30:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] Three dimensions of service References: <200502081853.NAA04377@ietf.org> <42093E7E.3080708@cisco.com> <421062FC.4050801@cisco.com> <42115C6E.4030402@cs.columbia.edu> <4212FEF7.3050504@cisco.com> <42132F4A.4080909@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit Aki Niemi wrote: >>> I fully agree that D3 should *never* be necessary for aspect (1). >> >> We have, though, in the past, considered issues which could rightfully >> be issue (1) but are not yet covered by prescaps. In particular, cases >> where the caller has to support a particular non-standard behavior >> that may or may not even show up as an extension. For example, the OMA >> PTT is really a set of behaviors that aren't easily listed as an >> extension per se, but i will not be able to make a call from my xten >> phone to an OMA PTT client and get anything to work. > > Non-standard is kind of a misnomer here. Surely you don't expect the > feature set offered by SIP phones to remain static forever. SIP is not > only voice and video, it can be used for rendezvous and session > initiation of any medium, standard or non-standard. E.g., comedia gives > tools for doing just that. > > Still, I regard this business as usual. You calling my OMA PTT phone > with an xten phone would probably fail, as it should. But that is a > valid outcome of a session initiation attempt -- the phones didn't have > a commonly supported medium to establish. The same would happen if I had > a standard MSRP client that you happened to call with a voice-only > softphone. > > This only becomes a problem with presence, where you would want to know > if this is likely to happen *before* the attempt is made. More on that > below. But "MSRP client" and "voice-only softphone" aren't "service types". I can have a device that does both MSRP and voice. Then both your "MSRP client" and your "voice-only softphone" can call it, and it can call them, successfully. If we made these all "service types" then their users would think they were incompatible. Or else they would have to know all the other service types they were compatible with. We might just as well drop all presence capabilities in favor of just a single attribute which is the brand/model of the device. Then I can see that you have a Nokia-9999, while I have a Motorola-8888, and I can just "know" whether those are compatible. Yuck! I am lacking data because I don't know much about your OMA PTT. What is there that can't be described with capabilities, assuming we can add additional capabilities if needed? Apparently it has an audio capability, but not one that will interwork with any other kind of device with an audio capability. If so, then I would conclude that it just doesn't have what the audio capability describes, so it shouldn't claim that. It has some other capability (e.g. ptt-audio), so invent that and use it like any other prescap. >> I have argued that these implementations aren't sip and shouldnt even >> use the sip URI. Rather, they should define their own URI schemes. >> There didnt seem to be consensus around that view though. > > > I don't understand what is non-SIP about an INVITE-20O-ACK that > establishes a session? > > Rather, I think this is a problem caused because of the limitations > imposed to us by PIDF, which has a rather simplistic view of what a > contact element indicates. There a SIP contact indicates that the tuple > is a SIP service, and presumably negotiation (that happens within SIP) > will determine what type of service specifically will result by > selecting that contact. > > But to know beforehand, for any service (standard, non-standard, > fictional, etc.), we would need some service-type indication that goes > beyond the standard prescaps markup along with a "require-to-understand" > flag, so that the watcher could determine whether it understands the > service, and consequently decide whether even should even render the > tuple to the user. capabilities. > Surely defining a new URI scheme would hack around this problem in terms > of representation in PIDF, but in more general terms it is exactly what > we want to avoid. I don't want half a dozen or more URIs printed on my > business card, vCard, web page or anywhere else. This is what we are > currently faced with e.g., by having multiple IM systems, and we should > not go there in SIP. I don't think I agree with Jonathan that this isn't sip. (Maybe if I knew more of the details I would.) But I think this isn't regular audio. Paul > After all, we don't have a new URI scheme for MSRP for the purpose of > sticking it in presence documents. Presumably, one would still initiate > MSRP by calling a SIP URI, even though a voice-only phone would not > accept the call. > >> Stepping back for a moment, though, is this whole thing here something >> we feel needs addressing in the data model or rpid somewhere? I don't >> think that an "app launcher" attribute really changes the MODEL in any >> way; if we decide we want it or something similar it could be defined >> by a pidf extension as a new service attribute. I also don't think its >> something we should address in the current rpid. In that case, this >> discussion is interesting but not relevant for completing the work at >> hand unless someone can bring some requirements forward that >> demonstrate otherwise. > > > I agree. The "app launcher" doesn't make or break the model, but the > model has to accomodate such extensions that may be unknown to the > composer. So assuming the existance of such unknown extensions, the > composer MUST be allowed to pass tuples along intact, and the watcher > MUST be able to handle this. I think this means "many tuples" instead of > "single tuple". > > Cheers, > Aki > >> -Jonathan R. >> >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 16 22:04:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01642; Wed, 16 Feb 2005 22:04:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1cJ7-00043k-Kt; Wed, 16 Feb 2005 22:26:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1bt7-00035O-RC; Wed, 16 Feb 2005 21:59:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1biL-0007Pi-5i for simple@megatron.ietf.org; Wed, 16 Feb 2005 21:48:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29057 for ; Wed, 16 Feb 2005 21:48:22 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1c3i-0003Y0-84 for simple@ietf.org; Wed, 16 Feb 2005 22:10:30 -0500 Received: from razor.cs.columbia.edu (IDENT:U2FsdGVkX1+nJvsi3PN6JBE+pB29gXrivONHRKBLMcE@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j1H2mKir023140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Feb 2005 21:48:21 -0500 (EST) Received: from [127.0.0.1] (IDENT:U2FsdGVkX18TOEvdevO5pt4RuzWv/0YhhYwy6k0X65c@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j1H2mKLR009055; Wed, 16 Feb 2005 21:48:20 -0500 Message-ID: <421405D2.3030909@cs.columbia.edu> Date: Wed, 16 Feb 2005 21:47:46 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Three dimensions of service References: <200502081853.NAA04377@ietf.org> <42093E7E.3080708@cisco.com> <421062FC.4050801@cisco.com> <42115C6E.4030402@cs.columbia.edu> <4212FEF7.3050504@cisco.com> In-Reply-To: <4212FEF7.3050504@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > We have, though, in the past, considered issues which could rightfully > be issue (1) but are not yet covered by prescaps. In particular, cases > where the caller has to support a particular non-standard behavior that > may or may not even show up as an extension. For example, the OMA PTT is > really a set of behaviors that aren't easily listed as an extension per > se, but i will not be able to make a call from my xten phone to an OMA > PTT client and get anything to work. Why precisely will this fail? I would rather extend prescaps if it can't do the right thing now, i.e., describe composable protocol behavior elements rather than just lump everything into a label. Labels are either: (1) essentially a cop-out if there isn't structured data to describe the behavior in simpler terms - "you know it when you see it"; OR (2) a reference to a set of structured data, where the point of the reference is to avoid including the description repeatedly. (1) works reasonably well in the "app-launcher" case if there is essentially a single application that can deal with this. Doom is the canonical example. (2) suffers from combinatorial explosion - I need to create a label for each new set of capabilities. In the degenerate case, it just becomes a URL or URN pointing to the description document. > > I have argued that these implementations aren't sip and shouldnt even > use the sip URI. Rather, they should define their own URI schemes. There > didnt seem to be consensus around that view though. This is a separate topic. There are other more realistic examples that are probably closer, such as the earlier work on device control using message-like behavior, which combines possibly a new SIP method with PUB/SUB (and maybe INVITE, e.g., for a remote-controlled camera). > > Stepping back for a moment, though, is this whole thing here something > we feel needs addressing in the data model or rpid somewhere? I don't > think that an "app launcher" attribute really changes the MODEL in any > way; if we decide we want it or something similar it could be defined by > a pidf extension as a new service attribute. I also don't think its > something we should address in the current rpid. In that case, this > discussion is interesting but not relevant for completing the work at > hand unless someone can bring some requirements forward that demonstrate > otherwise. At best, this is an RPID issue, similar to the 'status-icon' mechanism that's already there. One purpose of this discussion (for me...) was to see if we could distill a set of characteristics or needs into such a descriptor that I could characterize and delineate from existing descriptors in a paragraph that we could all understand. I don't think we're close enough to that. > > -Jonathan R. > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 17 04:00:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26060; Thu, 17 Feb 2005 04:00:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1hrk-0004Yf-6v; Thu, 17 Feb 2005 04:22:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1hRl-0006Vl-Oq; Thu, 17 Feb 2005 03:55:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1hOP-00058p-CL for simple@megatron.ietf.org; Thu, 17 Feb 2005 03:52:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25158 for ; Thu, 17 Feb 2005 03:52:11 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1hjp-0004Kz-Al for simple@ietf.org; Thu, 17 Feb 2005 04:14:21 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 17 Feb 2005 01:01:54 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1H8pduC016883; Thu, 17 Feb 2005 00:51:39 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-155.cisco.com [10.86.242.155]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHU81023; Thu, 17 Feb 2005 00:51:37 -0800 (PST) Message-ID: <42145B19.3000206@cisco.com> Date: Thu, 17 Feb 2005 03:51:37 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] Three dimensions of service References: <200502081853.NAA04377@ietf.org> <42093E7E.3080708@cisco.com> <421062FC.4050801@cisco.com> <42115C6E.4030402@cs.columbia.edu> <4212FEF7.3050504@cisco.com> <421405D2.3030909@cs.columbia.edu> In-Reply-To: <421405D2.3030909@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > >> We have, though, in the past, considered issues which could rightfully >> be issue (1) but are not yet covered by prescaps. In particular, cases >> where the caller has to support a particular non-standard behavior >> that may or may not even show up as an extension. For example, the OMA >> PTT is really a set of behaviors that aren't easily listed as an >> extension per se, but i will not be able to make a call from my xten >> phone to an OMA PTT client and get anything to work. > > > Why precisely will this fail? Others know OMA PTT better than I, but I'll take a stab. The OMA client assumes that both sides support the floor control protocol they are using. It also assumes that PTT calls have passed through a network with specific topologies that invokes the PTT arbiter in the right places. There is nothing in the protocol messages that conveys the latter assumption. I am not sure if OMA is using SDP to signal the floor control. I will note that, I believe that OMA may have defined a callee-cap that decalres OMA support, i.e., ";oma-v1.1=true" in order to allow caller prefs to route a call to a PTT phone instead of a regular SIP phone with the same AOR. That happens to play well with prescaps, where you more or less end up with the label Brian is asking for as a capability. I've heard of other PTT implementations that use RTP tricks for floor control; in those models there is no new protocol to signal, just assumed behaviors that the PTT arbiter makes on the way in which the clients send RTP packets. > > I would rather extend prescaps if it can't do the right thing now, i.e., > describe composable protocol behavior elements rather than just lump > everything into a label. To be frank, I think we are sorely missing requirements here. We can posit all kinds of theoretical applications that can or cannot be represented with prescaps. I would rather someone come to IETF and say, "hey, I want to use simple for my application but I can't do it in prescaps because of A,B,C". We are simply not seeing that now. Until we have that, this discussion is all interesting but theoretical. > > Labels are either: > > (1) essentially a cop-out if there isn't structured data to describe the > behavior in simpler terms - "you know it when you see it"; > > OR > > (2) a reference to a set of structured data, where the point of the > reference is to avoid including the description repeatedly. > > (1) works reasonably well in the "app-launcher" case if there is > essentially a single application that can deal with this. Doom is the > canonical example. Or so we think. Since no one has come forward with requirements on using Doom we are just guessing. I'll also note that Half Life 2 is far better than doom and we should be considering that instead ;) >> >> I have argued that these implementations aren't sip and shouldnt even >> use the sip URI. Rather, they should define their own URI schemes. >> There didnt seem to be consensus around that view though. > > > This is a separate topic. There are other more realistic examples that > are probably closer, such as the earlier work on device control using > message-like behavior, which combines possibly a new SIP method with > PUB/SUB (and maybe INVITE, e.g., for a remote-controlled camera). My argument here is based on the view that the whole point of a URI is that it provides complete context. You should be able to take a URI, pass it to an application that knows the scheme, and it should be able to invoke it and have the right thing happen. We are having proposed cases where that isn't the case, and its because the implementations are using SIP but are layering additional semantics and behaviors which make it distinctly non-SIP and break interop. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 17 04:39:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29124; Thu, 17 Feb 2005 04:39:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1iTY-0005R2-UQ; Thu, 17 Feb 2005 05:01:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1hze-0002sg-BV; Thu, 17 Feb 2005 04:30:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1htG-0000Jw-OG; Thu, 17 Feb 2005 04:24:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27798; Thu, 17 Feb 2005 04:24:05 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1iEh-00053q-4u; Thu, 17 Feb 2005 04:46:15 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 17 Feb 2005 01:33:48 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1H9NVuC029342; Thu, 17 Feb 2005 01:23:31 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-155.cisco.com [10.86.242.155]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHU82108; Thu, 17 Feb 2005 01:23:31 -0800 (PST) Message-ID: <42146290.5090209@cisco.com> Date: Thu, 17 Feb 2005 04:23:28 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG , "'geopriv@ietf.org'" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Subject: [Simple] presence authorization issue: anonymous, authenticated, etc. X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit Folks, We've had a few stalled discussions and stalled threads (most recently on the geopriv list) on the issue of what the common policy and/or presence authorization specications should provide in terms of conditions that match any authenticated identity, and whether or not an unauthenticated identity counts as anonymous or not. For background material, check out the meeting minutes from the last SIMPLE session: http://www.softarmor.com/simple/meets/ietf61/proceedings/simple61-session1-minutes.html and a recent thread on geopriv: http://www.ietf.org/mail-archive/web/geopriv/current/msg00519.html We need to resolve this issue. It is a gating factor for common policy and the presence authorization work. Dean put up a slide during the SIMPLE session last time which attempted to figure out whether the concepts of anonymous and unauthenticated were really separable. Some further thoughts on when such combinations can occur: Unauthenticated, Anonymous: this would happen when the From field is present with the value of anonymous and there is no P-A-ID or Identity header field. Unauthenticated, Not Anonymous: From field is present, but with a value that is not anonymous Authenticated, Anonymous: There is a P-A-ID which a value like sip:anonymous@foo.invalid, or a From field that is sip:anonymous@provider.com and an Identity field signed by provider.com. Seems reasonable. Authenticated, not anonymous: the normal case I think its fair to say that if a request is NOT authenticated, there is really no difference between anonymous and not anonymous from a policy perspective; in either case the originating identity is as good as useless. Thus, we'd like to be able to specify policies for three cases: unauthenticated, authenticated and anonymous, and authenticated and not anonymous. However, it is also reasonable to say that one would provide different access to presence for anonymous and authenticated users than unauthenticated users. Indeed, the permissions one would apply for unauthenticated users really represent the 'baseline' permissions - no one would ever receive fewer permissions than those guys. Indeed, the question is whether unauthenticated users would ever get any permissions beyond the minimum. I would propose that the answer is no, and then make the following concrete proposal: 1. An unauthenticated request never matches any rules, and thus never has any permissions granted 2. A rule with no conditions matches any authenticated request. Thus, to specify permissions that go to any authenticated request, you would have rules with no conditions. 3. A rule with some conditions matches if those rules match and the request is authenticated. This means that the permission assumes the request is authenticated. I believe this proposal meets the requirements outlined by Aki; that is, to be able to define a baseline permission of "confirm" for any authenticated user, and then for users that get granted, provide a permission of "allow". It also allows for expression of policies separately for the three main cases above. This proposal would require the following changes: 1. the geopriv common policy needs to be explicit on the meaning of a rule with no conditions, that it means it applies to any authenticated request 2. the presence auth rules needs to update the definition of the condition Can we agree on this and move forward? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 17 06:07:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07745; Thu, 17 Feb 2005 06:07:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1jqk-0007bB-AQ; Thu, 17 Feb 2005 06:29:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1jSq-0004Wr-Rh; Thu, 17 Feb 2005 06:04:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1jKo-0000x0-28 for simple@megatron.ietf.org; Thu, 17 Feb 2005 05:56:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06879 for ; Thu, 17 Feb 2005 05:56:36 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1jgC-0007K7-0v for simple@ietf.org; Thu, 17 Feb 2005 06:18:47 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1HAuTD27925; Thu, 17 Feb 2005 12:56:29 +0200 (EET) X-Scanned: Thu, 17 Feb 2005 12:55:43 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j1HAtgxk011075; Thu, 17 Feb 2005 12:55:43 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00t3htDD; Thu, 17 Feb 2005 12:55:41 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1HAtfJ24363; Thu, 17 Feb 2005 12:55:41 +0200 (EET) Received: from [172.21.39.180] ([172.21.39.180]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 17 Feb 2005 12:55:07 +0200 Message-ID: <42147809.3040008@nokia.com> Date: Thu, 17 Feb 2005 12:55:05 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Paul Kyzivat Subject: Re: [Simple] Three dimensions of service References: <200502081853.NAA04377@ietf.org> <42093E7E.3080708@cisco.com> <421062FC.4050801@cisco.com> <42115C6E.4030402@cs.columbia.edu> <4212FEF7.3050504@cisco.com> <42132F4A.4080909@nokia.com> <4213D796.4020200@cisco.com> In-Reply-To: <4213D796.4020200@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Feb 2005 10:55:07.0166 (UTC) FILETIME=[24724BE0:01C514DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Inline. ext Paul Kyzivat wrote: >> Non-standard is kind of a misnomer here. Surely you don't expect the >> feature set offered by SIP phones to remain static forever. SIP is not >> only voice and video, it can be used for rendezvous and session >> initiation of any medium, standard or non-standard. E.g., comedia >> gives tools for doing just that. >> >> Still, I regard this business as usual. You calling my OMA PTT phone >> with an xten phone would probably fail, as it should. But that is a >> valid outcome of a session initiation attempt -- the phones didn't >> have a commonly supported medium to establish. The same would happen >> if I had a standard MSRP client that you happened to call with a >> voice-only softphone. >> >> This only becomes a problem with presence, where you would want to >> know if this is likely to happen *before* the attempt is made. More on >> that below. > > > But "MSRP client" and "voice-only softphone" aren't "service types". I > can have a device that does both MSRP and voice. Then both your "MSRP > client" and your "voice-only softphone" can call it, and it can call > them, successfully. If we made these all "service types" then their > users would think they were incompatible. Or else they would have to > know all the other service types they were compatible with. I'm not sure I understand. My point was that in any case, you will have user agents, addressed by SIP URIs that don't share commonly supported communications medium. I don't think it makes any difference whether this medium is "standard" or "non-standard". > We might just as well drop all presence capabilities in favor of just a > single attribute which is the brand/model of the device. Then I can see > that you have a Nokia-9999, while I have a Motorola-8888, and I can just > "know" whether those are compatible. Yuck! That's not what I'm talking about at all. Simply knowing about capabilities gives no indication of what the current availability or willingness of the presentity is regarding those capabilities. > I am lacking data because I don't know much about your OMA PTT. What is > there that can't be described with capabilities, assuming we can add > additional capabilities if needed? This is easy. For one, the OMA PoC client has more states than a simple on/off. It can be in Do-not-disturb mode, available mode, and session-active mode at least. I believe OMA has currently specified extensions to the element that communicate these different statuses. Secondly, an OMA PoC client can receive other SIP requests as well, i.e., MESSAGEs that I believe are either like off-line invitations to join a group, or alerts to say "please call back". Having said that though, this might be representable in prescaps as well, since those requests do have a special MIME type. > Apparently it has an audio > capability, but not one that will interwork with any other kind of > device with an audio capability. If so, then I would conclude that it > just doesn't have what the audio capability describes, so it shouldn't > claim that. It has some other capability (e.g. ptt-audio), so invent > that and use it like any other prescap. OMA already seems to have gone the other route, which means they have some sort of service-id element that indicates OMA PoC, including version. Howerer, this part *could* as easily be done using prescaps. > I don't think I agree with Jonathan that this isn't sip. (Maybe if I > knew more of the details I would.) But I think this isn't regular audio. Agreed. For one, it requires a controlled floor, even in one-to-one sessions. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 17 06:25:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09037; Thu, 17 Feb 2005 06:25:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1k8H-000837-8d; Thu, 17 Feb 2005 06:47:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1jjM-00036t-VY; Thu, 17 Feb 2005 06:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1jhW-0002Cv-Ni for simple@megatron.ietf.org; Thu, 17 Feb 2005 06:20:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08633 for ; Thu, 17 Feb 2005 06:20:04 -0500 (EST) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1k2y-0007u5-2U for simple@ietf.org; Thu, 17 Feb 2005 06:42:16 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1HBJsP02866; Thu, 17 Feb 2005 13:19:54 +0200 (EET) X-Scanned: Thu, 17 Feb 2005 13:31:27 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j1HBVRES004953; Thu, 17 Feb 2005 13:31:27 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00wq295O; Thu, 17 Feb 2005 13:30:53 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1HBIPJ18997; Thu, 17 Feb 2005 13:18:25 +0200 (EET) Received: from [172.21.39.180] ([172.21.39.180]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 17 Feb 2005 13:17:55 +0200 Message-ID: <42147D62.40304@nokia.com> Date: Thu, 17 Feb 2005 13:17:54 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Simple] Three dimensions of service References: <200502081853.NAA04377@ietf.org> <42093E7E.3080708@cisco.com> <421062FC.4050801@cisco.com> <42115C6E.4030402@cs.columbia.edu> <4212FEF7.3050504@cisco.com> <421405D2.3030909@cs.columbia.edu> <42145B19.3000206@cisco.com> In-Reply-To: <42145B19.3000206@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Feb 2005 11:17:55.0840 (UTC) FILETIME=[543D6000:01C514E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Inline. ext Jonathan Rosenberg wrote: >> Why precisely will this fail? > > > Others know OMA PTT better than I, but I'll take a stab. > > The OMA client assumes that both sides support the floor control > protocol they are using. It also assumes that PTT calls have passed > through a network with specific topologies that invokes the PTT arbiter > in the right places. There is nothing in the protocol messages that > conveys the latter assumption. I am not sure if OMA is using SDP to > signal the floor control. I believe they do signal it in SDP. That is the sanest thing to do anyway, because when floor control is explicitly signaled, then you can also upgrade or change that protocol to something else in the future and clients can handle legacy gracefully. > I will note that, I believe that OMA may have defined a callee-cap that > decalres OMA support, i.e., ";oma-v1.1=true" in order to allow caller > prefs to route a call to a PTT phone instead of a regular SIP phone with > the same AOR. That happens to play well with prescaps, where you more or > less end up with the label Brian is asking for as a capability. Agreed. That solves the capability description needs. > I've heard of other PTT implementations that use RTP tricks for floor > control; in those models there is no new protocol to signal, just > assumed behaviors that the PTT arbiter makes on the way in which the > clients send RTP packets. This is clearly not a desireable way to implement things. Something you can get away with in closed environments, but not in the real world. Clearly in these cases, if everything is based on assumptions, then using a SIP URI makes no sense either. >> I would rather extend prescaps if it can't do the right thing now, >> i.e., describe composable protocol behavior elements rather than just >> lump everything into a label. > > > To be frank, I think we are sorely missing requirements here. We can > posit all kinds of theoretical applications that can or cannot be > represented with prescaps. I would rather someone come to IETF and say, > "hey, I want to use simple for my application but I can't do it in > prescaps because of A,B,C". We are simply not seeing that now. Until we > have that, this discussion is all interesting but theoretical. I've tried, several times. Let me try again. The requirement from my point of view is: One needs to be able to indicate finer grained status for a "service" than a simple on/off. Capabilities can only go as far as indicating on/off status, but that's not enough. For example, even with a "game/doom capability", you'd still need to be able to indicate things like whether you're hosting, in deathmatch, idle, or practicing at the moment. Each state would be represented to the user in the form of a different icon, for example, all very much dependant on the "service". But again, we don't need to define anything except to say that such extensions (I believe D3 in Henning's terminology) may exist, and probably should go under the element. The only thing where the model is affected is that if you have two tuples that have the same extension that is unknown to the composer, but known to the watcher, and one has value foo and one has value baz, the composer *cannot* merge the states (tuples) because it doesn't know whether to choose foo, baz, or put both in. ...snip... >> This is a separate topic. There are other more realistic examples that >> are probably closer, such as the earlier work on device control using >> message-like behavior, which combines possibly a new SIP method with >> PUB/SUB (and maybe INVITE, e.g., for a remote-controlled camera). > > > My argument here is based on the view that the whole point of a URI is > that it provides complete context. You should be able to take a URI, > pass it to an application that knows the scheme, and it should be able > to invoke it and have the right thing happen. What do you mean by "invoke it"? Do you mean a voice call, a video call, or what? And what do you mean by "the right thing"? Is receiving a 415 such a case? > We are having proposed > cases where that isn't the case, and its because the implementations are > using SIP but are layering additional semantics and behaviors which make > it distinctly non-SIP and break interop. You may have a different example in mind, but adding new media in SDP IMHO doesn't constitute layering additional semantics to SIP, but to SDP, and I can't see that having anything to do with whether SIP can be used to offer such SDP or not. Cheers, Aki > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 17 09:00:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25119; Thu, 17 Feb 2005 09:00:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1mXn-0003qr-5O; Thu, 17 Feb 2005 09:22:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1m8q-0003wK-Mm; Thu, 17 Feb 2005 08:56:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1lyC-0007zr-Cu; Thu, 17 Feb 2005 08:45:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23693; Thu, 17 Feb 2005 08:45:27 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1mJe-0003Qg-0P; Thu, 17 Feb 2005 09:07:39 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 17 Feb 2005 08:57:33 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,93,1107752400"; d="scan'208"; a="37328733:sNHT9245856300" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1HDim1j021114; Thu, 17 Feb 2005 08:44:48 -0500 (EST) Received: from cisco.com (che-vpn-cluster-1-8.cisco.com [10.86.240.8]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APE88680; Thu, 17 Feb 2005 08:44:47 -0500 (EST) Message-ID: <42149FCF.9040204@cisco.com> Date: Thu, 17 Feb 2005 08:44:47 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] presence authorization issue: anonymous, authenticated, etc. References: <42146290.5090209@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Folks, > > We've had a few stalled discussions and stalled threads (most recently > on the geopriv list) on the issue of what the common policy and/or > presence authorization specications should provide in terms of > conditions that match any authenticated identity, and whether or not an > unauthenticated identity counts as anonymous or not. > > For background material, check out the meeting minutes from the last > SIMPLE session: > > http://www.softarmor.com/simple/meets/ietf61/proceedings/simple61-session1-minutes.html > > > and a recent thread on geopriv: > > http://www.ietf.org/mail-archive/web/geopriv/current/msg00519.html > > We need to resolve this issue. It is a gating factor for common policy > and the presence authorization work. > > Dean put up a slide during the SIMPLE session last time which attempted > to figure out whether the concepts of anonymous and unauthenticated were > really separable. Some further thoughts on when such combinations can > occur: > > Unauthenticated, Anonymous: this would happen when the From field is > present with the value of anonymous and there is no P-A-ID or Identity > header field. > > Unauthenticated, Not Anonymous: From field is present, but with a value > that is not anonymous > > Authenticated, Anonymous: There is a P-A-ID which a value like > sip:anonymous@foo.invalid, or a From field that is > sip:anonymous@provider.com and an Identity field signed by provider.com. > Seems reasonable. > > Authenticated, not anonymous: the normal case > > > I think its fair to say that if a request is NOT authenticated, there is > really no difference between anonymous and not anonymous from a policy > perspective; in either case the originating identity is as good as > useless. Thus, we'd like to be able to specify policies for three cases: > unauthenticated, authenticated and anonymous, and authenticated and not > anonymous. > > However, it is also reasonable to say that one would provide different > access to presence for anonymous and authenticated users than > unauthenticated users. Indeed, the permissions one would apply for > unauthenticated users really represent the 'baseline' permissions - no > one would ever receive fewer permissions than those guys. Indeed, the > question is whether unauthenticated users would ever get any permissions > beyond the minimum. > > I would propose that the answer is no, and then make the following > concrete proposal: > > 1. An unauthenticated request never matches any rules, and thus never > has any permissions granted If I follow you, this means that an unauthenticated user gets no presence information at all. That seems too strong. I may well be willing to provide *some* information to *anybody*, and shouldn't be prevented from specifying such a policy. Paul > 2. A rule with no conditions matches any authenticated request. Thus, to > specify permissions that go to any authenticated request, you would have > rules with no conditions. > > 3. A rule with some conditions matches if those rules match and the > request is authenticated. This means that the permission > assumes the request is authenticated. > > I believe this proposal meets the requirements outlined by Aki; that is, > to be able to define a baseline permission of "confirm" for any > authenticated user, and then for users that get granted, provide a > permission of "allow". It also allows for expression of policies > separately for the three main cases above. > > This proposal would require the following changes: > > 1. the geopriv common policy needs to be explicit on the meaning of a > rule with no conditions, that it means it applies to any authenticated > request > > 2. the presence auth rules needs to update the definition of the > condition > > > Can we agree on this and move forward? > > Thanks, > Jonathan R. > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 17 09:17:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26877; Thu, 17 Feb 2005 09:17:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1moc-0004L0-O8; Thu, 17 Feb 2005 09:39:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1mNQ-0001jP-0a; Thu, 17 Feb 2005 09:11:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1mFr-0006qw-Aq for simple@megatron.ietf.org; Thu, 17 Feb 2005 09:03:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25516 for ; Thu, 17 Feb 2005 09:03:42 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1mbK-0003xk-Dp for simple@ietf.org; Thu, 17 Feb 2005 09:25:54 -0500 Received: from razor.cs.columbia.edu (IDENT:U2FsdGVkX19kV2BXiUeZ9j451q+B+UBW+VSYrAmF3TU@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j1HE3cir029865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Feb 2005 09:03:39 -0500 (EST) Received: from [127.0.0.1] (IDENT:U2FsdGVkX1/qGJUfjqUvnxzdn5TkKZHB6LKoRhsQT2Y@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j1HE3XZb012645; Thu, 17 Feb 2005 09:03:38 -0500 Message-ID: <4214A431.6090906@cs.columbia.edu> Date: Thu, 17 Feb 2005 09:03:29 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] Three dimensions of service References: <200502081853.NAA04377@ietf.org> <42093E7E.3080708@cisco.com> <421062FC.4050801@cisco.com> <42115C6E.4030402@cs.columbia.edu> <4212FEF7.3050504@cisco.com> <421405D2.3030909@cs.columbia.edu> <42145B19.3000206@cisco.com> <42147D62.40304@nokia.com> In-Reply-To: <42147D62.40304@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Aki Niemi wrote: > The requirement from my point of view is: One needs to be able to > indicate finer grained status for a "service" than a simple on/off. > Capabilities can only go as far as indicating on/off status, but that's > not enough. If I understand you correctly, this is much more closely related to activities than to a capability. > > For example, even with a "game/doom capability", you'd still need to be > able to indicate things like whether you're hosting, in deathmatch, > idle, or practicing at the moment. Each state would be represented to > the user in the form of a different icon, for example, all very much > dependant on the "service". The game state indication seems like a natural extension to the 'activities' element in RPID. This, along with other RPID element, provides context to the open/closed status and thus qualifies it to the watcher. RPID already has a 'status-icon', which seems rather close to what you're proposing. > > But again, we don't need to define anything except to say that such > extensions (I believe D3 in Henning's terminology) may exist, and > probably should go under the element. I don't think this is a capability necessary to ensure connectivity (which is what I meant D1 through D3 to describe at various layers). _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 17 09:37:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29134; Thu, 17 Feb 2005 09:37:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1n7w-0004ux-Bk; Thu, 17 Feb 2005 09:59:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1mkF-0003Ok-UK; Thu, 17 Feb 2005 09:35:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1ma6-0007Cp-ES for simple@megatron.ietf.org; Thu, 17 Feb 2005 09:24:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27723 for ; Thu, 17 Feb 2005 09:24:37 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1mvZ-0004Ws-JH for simple@ietf.org; Thu, 17 Feb 2005 09:46:49 -0500 Received: from razor.cs.columbia.edu (IDENT:U2FsdGVkX19OECdwUxsEQJHnrBaMNafKXoFk9gsvfyY@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j1HENOir004840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Feb 2005 09:23:24 -0500 (EST) Received: from [127.0.0.1] (IDENT:U2FsdGVkX186VuolfZqkIV5uobzHJoDLAhuaJ/r1spo@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j1HENN5X012700; Thu, 17 Feb 2005 09:23:23 -0500 Message-ID: <4214A8D5.5010200@cs.columbia.edu> Date: Thu, 17 Feb 2005 09:23:17 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] Three dimensions of service References: <200502081853.NAA04377@ietf.org> <42093E7E.3080708@cisco.com> <421062FC.4050801@cisco.com> <42115C6E.4030402@cs.columbia.edu> <4212FEF7.3050504@cisco.com> <42132F4A.4080909@nokia.com> <4213D796.4020200@cisco.com> <42147809.3040008@nokia.com> In-Reply-To: <42147809.3040008@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: ext Paul Kyzivat , "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Aki Niemi wrote: > This is easy. For one, the OMA PoC client has more states than a simple > on/off. It can be in Do-not-disturb mode, available mode, and > session-active mode at least. I believe OMA has currently specified > extensions to the element that communicate these different > statuses. Just to highlight this, as it seems hint at the source of the confusion: We seem to be talking here about two different indications: (1) relatively static capabilities (Brian's labels, my D1-D3) that indicate how to get the bits flowing and what they might mean. This is the domain of prescaps, for example. (2) the state of a device, elaborating beyond the simple "is available for communication or not". RPID extensions, not prescaps, are the responsible for that type of information. For extensions to (2) which are not currently handled by RPID, we need to decide in each case whether they describe activities of the person, for example, or are device-specific or service-specific state. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 17 10:10:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03725; Thu, 17 Feb 2005 10:10:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1neM-0005wo-KQ; Thu, 17 Feb 2005 10:33:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1n25-0003Od-8s; Thu, 17 Feb 2005 09:53:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1muV-0008SR-4a; Thu, 17 Feb 2005 09:45:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00220; Thu, 17 Feb 2005 09:45:41 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1nFu-0005Ba-VV; Thu, 17 Feb 2005 10:07:54 -0500 Received: from razor.cs.columbia.edu (IDENT:U2FsdGVkX185VuuNp1SwtAniVNF/1REh/OykZ8u+qbc@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j1HEiZir010064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Feb 2005 09:44:35 -0500 (EST) Received: from [127.0.0.1] (IDENT:U2FsdGVkX1+HI4M1SjO7YRrK9NoGwicwISnfC4U3nrs@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j1HEiYV0012736; Thu, 17 Feb 2005 09:44:34 -0500 Message-ID: <4214ADD0.3070101@cs.columbia.edu> Date: Thu, 17 Feb 2005 09:44:32 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] presence authorization issue: anonymous, authenticated, etc. References: <42146290.5090209@cisco.com> In-Reply-To: <42146290.5090209@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 1.1 (+) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Unauthenticated, Anonymous: this would happen when the From field is > present with the value of anonymous and there is no P-A-ID or Identity > header field. > > Unauthenticated, Not Anonymous: From field is present, but with a value > that is not anonymous > > Authenticated, Anonymous: There is a P-A-ID which a value like > sip:anonymous@foo.invalid, or a From field that is > sip:anonymous@provider.com and an Identity field signed by provider.com. > Seems reasonable. A different way of saying the same thing is that this is domain-level authentication. I don't think it matters if it says alice@example.com or anon1234@example.com, but only example.com can be authenticated (e.g., via TLS certs). The important part about this "anonymous" authentication is that the authenticating domain may have some way to hold the party responsible, even if the PA doesn't know who it is and has no direct relationship with that party. > > Authenticated, not anonymous: the normal case Authenticated (in general) would presumably also include other mechanisms, such as a Digest-authenticated SUBSCRIBE or maybe even TLS. > > > I think its fair to say that if a request is NOT authenticated, there is > really no difference between anonymous and not anonymous from a policy > perspective; in either case the originating identity is as good as > useless. Thus, we'd like to be able to specify policies for three cases: > unauthenticated, authenticated and anonymous, and authenticated and not > anonymous. > > However, it is also reasonable to say that one would provide different > access to presence for anonymous and authenticated users than > unauthenticated users. Indeed, the permissions one would apply for > unauthenticated users really represent the 'baseline' permissions - no > one would ever receive fewer permissions than those guys. Indeed, the > question is whether unauthenticated users would ever get any permissions > beyond the minimum. I agree with Paul that unauthenticated users may on occasion get access to data and that we would want to be able to specify this access. Think of a bus tracking application or other public data. Another contrived example: anonymous/unauthenticated users can subscribe to get flight tracker information to within a few miles (insufficient for missile-aiming), but certain authenticated users (e.g., the FAA) get precise location. > > I would propose that the answer is no, and then make the following > concrete proposal: > > 1. An unauthenticated request never matches any rules, and thus never > has any permissions granted Disagree, as per above. > > 2. A rule with no conditions matches any authenticated request. Thus, to > specify permissions that go to any authenticated request, you would have > rules with no conditions. > > 3. A rule with some conditions matches if those rules match and the > request is authenticated. This means that the permission > assumes the request is authenticated. > > I believe this proposal meets the requirements outlined by Aki; that is, > to be able to define a baseline permission of "confirm" for any > authenticated user, and then for users that get granted, provide a > permission of "allow". It also allows for expression of policies > separately for the three main cases above. > > This proposal would require the following changes: > > 1. the geopriv common policy needs to be explicit on the meaning of a > rule with no conditions, that it means it applies to any authenticated > request > > 2. the presence auth rules needs to update the definition of the > condition > > > Can we agree on this and move forward? > > Thanks, > Jonathan R. > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 17 13:15:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12039; Thu, 17 Feb 2005 13:15:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1qWs-0000wJ-J4; Thu, 17 Feb 2005 13:37:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1nPZ-0004g4-5i; Thu, 17 Feb 2005 10:17:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1nCq-0007m2-OS for simple@megatron.ietf.org; Thu, 17 Feb 2005 10:04:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02553 for ; Thu, 17 Feb 2005 10:04:39 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1nYJ-0005gz-UV for simple@ietf.org; Thu, 17 Feb 2005 10:26:52 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 17 Feb 2005 08:17:27 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,94,1107734400"; d="scan'208"; a="226250663:sNHT22067964" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1HF46Tj002568; Thu, 17 Feb 2005 07:04:06 -0800 (PST) Received: from cisco.com ([161.44.79.182]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APE94627; Thu, 17 Feb 2005 10:04:05 -0500 (EST) Message-ID: <4214B265.405@cisco.com> Date: Thu, 17 Feb 2005 10:04:05 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] Three dimensions of service References: <200502081853.NAA04377@ietf.org> <42093E7E.3080708@cisco.com> <421062FC.4050801@cisco.com> <42115C6E.4030402@cs.columbia.edu> <4212FEF7.3050504@cisco.com> <42132F4A.4080909@nokia.com> <4213D796.4020200@cisco.com> <42147809.3040008@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit Aki, I think I have been lumping together your arguments and Brian's, and arguing against that combination. It now is becoming more evident to me that the two of you don't have the same position. So I apologize if I attributed something incorrectly to your position. More inline. Paul Aki Niemi wrote: > Inline. > > ext Paul Kyzivat wrote: > >>> Non-standard is kind of a misnomer here. Surely you don't expect the >>> feature set offered by SIP phones to remain static forever. SIP is >>> not only voice and video, it can be used for rendezvous and session >>> initiation of any medium, standard or non-standard. E.g., comedia >>> gives tools for doing just that. >>> >>> Still, I regard this business as usual. You calling my OMA PTT phone >>> with an xten phone would probably fail, as it should. But that is a >>> valid outcome of a session initiation attempt -- the phones didn't >>> have a commonly supported medium to establish. The same would happen >>> if I had a standard MSRP client that you happened to call with a >>> voice-only softphone. >>> >>> This only becomes a problem with presence, where you would want to >>> know if this is likely to happen *before* the attempt is made. More >>> on that below. >> >> But "MSRP client" and "voice-only softphone" aren't "service types". I >> can have a device that does both MSRP and voice. Then both your "MSRP >> client" and your "voice-only softphone" can call it, and it can call >> them, successfully. If we made these all "service types" then their >> users would think they were incompatible. Or else they would have to >> know all the other service types they were compatible with. > > I'm not sure I understand. My point was that in any case, you will have > user agents, addressed by SIP URIs that don't share commonly supported > communications medium. I don't think it makes any difference whether > this medium is "standard" or "non-standard". This argument should have been addressed to Brian. Perhaps you and I do not disagree here. >> We might just as well drop all presence capabilities in favor of just >> a single attribute which is the brand/model of the device. Then I can >> see that you have a Nokia-9999, while I have a Motorola-8888, and I >> can just "know" whether those are compatible. Yuck! > > That's not what I'm talking about at all. Simply knowing about > capabilities gives no indication of what the current availability or > willingness of the presentity is regarding those capabilities. Here I think we may differ. And it is a point worth discussion. Lets assume for a moment that I have a softphone with capability for voice, video, and MSRP. But it has a bunch of controls in its UI that enable/disable each of the media. If I am in a meeting I might disable voice and video but leave MSRP enabled. If I am doing something graphically intensive I may disable MSRP. And if I am in my underwear I may disable video. How does that affect presence? I think that as I change these settings, my presence capabilities will also be changed. So while I am in that meeting with voice and video disabled, the tuple describing this softphone will show that it is open, and capable of msrp, but not capable for voice or video. And when the meeting is over that one tuple will get updated, indicating that it is open and capable of MSRP *and* voice and video. >> I am lacking data because I don't know much about your OMA PTT. What >> is there that can't be described with capabilities, assuming we can >> add additional capabilities if needed? > > This is easy. For one, the OMA PoC client has more states than a simple > on/off. It can be in Do-not-disturb mode, available mode, and > session-active mode at least. I believe OMA has currently specified > extensions to the element that communicate these different > statuses. OK. There is a subtle line between capability and status. As you say, we have other forms of status. It seems like there is sufficient expressiveness here for PTT, and if not some small addition should deal with it. > Secondly, an OMA PoC client can receive other SIP requests as well, > i.e., MESSAGEs that I believe are either like off-line invitations to > join a group, or alerts to say "please call back". Having said that > though, this might be representable in prescaps as well, since those > requests do have a special MIME type. These MESSAGEs are not content that is displayed to the user - but rather are a way to tunnel some other proprietary signaling protocol? This probably requires further discussion if we are to achieve a meaningful and open representation of presence. >> Apparently it has an audio capability, but not one that will interwork >> with any other kind of device with an audio capability. If so, then I >> would conclude that it just doesn't have what the audio capability >> describes, so it shouldn't claim that. It has some other capability >> (e.g. ptt-audio), so invent that and use it like any other prescap. > > OMA already seems to have gone the other route, which means they have > some sort of service-id element that indicates OMA PoC, including > version. Howerer, this part *could* as easily be done using prescaps. Well then, maybe I appologized too soon. This is exactly what I was complaining about. If 'audio' capability is being advertised, but it will only interwork with the audio of those who have the 'OMA-PoC-inside' sticker, then I think they are non-standard, regardless of how you encode the sticker. If that is the way it has to be, just lose the claim of support for audio. (More - explicitly state that audio is *not* supported.) Then people won't be deceived. >> I don't think I agree with Jonathan that this isn't sip. (Maybe if I >> knew more of the details I would.) But I think this isn't regular audio. > > Agreed. For one, it requires a controlled floor, even in one-to-one > sessions. > > Cheers, > Aki > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 17 13:30:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15671; Thu, 17 Feb 2005 13:30:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1qlt-00024D-HY; Thu, 17 Feb 2005 13:53:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1nPr-0004mL-Sy; Thu, 17 Feb 2005 10:18:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1nEj-0008Lf-IC; Thu, 17 Feb 2005 10:06:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02999; Thu, 17 Feb 2005 10:06:35 -0500 (EST) Message-Id: <200502171506.KAA02999@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 17 Feb 2005 10:06:35 -0500 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-diff-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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : An Extensible Markup Language (XML) Document Format for Indicating Changes in XML Configuration Access Protocol (XCAP) Resources Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-diff-00.txt Pages : 12 Date : 2005-2-16 This specification defines a document format that can be used to describe the differences between versions of resources managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). Documents of this format can be delivered to clients using a number of means, including the Session Initiation Protocol (SIP) event package for configuration data. By subscribing to this event package, clients can learn about document changes made by other clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-diff-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-xcap-diff-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-xcap-diff-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-17102556.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-diff-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-diff-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-17102556.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From Janetta@gbst.com Thu Feb 17 14:52:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26813 for ; Thu, 17 Feb 2005 14:52:37 -0500 (EST) Message-Id: <200502171952.OAA26813@ietf.org> Received: from [195.174.89.131] (helo=gbst.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D1s2z-0005Xk-4n for simple-archive@ietf.org; Thu, 17 Feb 2005 15:14:52 -0500 From: "Jacklyn Cullen" To: "Kaede Gardiner" Subject: Mega Pharmmacy Date: Thu, 17 Feb 2005 14:32:39 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_055C1A62.7B667E25" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 6.0 (++++++) X-Spam-Flag: YES X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 This is a multi-part message in MIME format. ------=_NextPart_000_0006_055C1A62.7B667E25 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Have a nice day. ------=_NextPart_000_0006_055C1A62.7B667E25 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello,  Welcome = to the best=20 online ST0RE
 
Vi ra  al Xa x  cod
ag (109$ / 30p) = Ci is (324$ /=20 90p)  na (299$ / 90p) = Vi in (178$ /=20 90p)
 
With each purchase you get:
 
>Top quality medicationn.
>Low=20 prices.
>Reputable manufacturers.
>Secure pay=20 system.
>Discreet packaging.
>Home delivery.
>Total=20 confidentiality.
>24 toll-free customer service = hotline.
 
Have a nice day.
------=_NextPart_000_0006_055C1A62.7B667E25-- From simple-bounces@ietf.org Thu Feb 17 15:24:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01070; Thu, 17 Feb 2005 15:24:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1sYE-0006S8-81; Thu, 17 Feb 2005 15:47:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1qYo-00065V-BT; Thu, 17 Feb 2005 13:39:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1nXU-0008Lw-BH; Thu, 17 Feb 2005 10:26:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05786; Thu, 17 Feb 2005 10:25:58 -0500 (EST) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1nsw-0006Lb-NG; Thu, 17 Feb 2005 10:48:12 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j1HFPnFF015013; Thu, 17 Feb 2005 16:25:49 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j1HFPniQ005180; Thu, 17 Feb 2005 16:25:49 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <1XNRKLGH>; Thu, 17 Feb 2005 16:25:49 +0100 Message-ID: From: Tschofenig Hannes To: "'Jonathan Rosenberg'" , Simple WG , "'geopriv@ietf.org'" Date: Thu, 17 Feb 2005 16:24:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Subject: [Simple] AW: [Geopriv] presence authorization issue: anonymous, authentica ted, etc. X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de hi jonathan, > Folks, > > We've had a few stalled discussions and stalled threads (most recently > on the geopriv list) on the issue of what the common policy and/or > presence authorization specications should provide in terms of > conditions that match any authenticated identity, and whether > or not an > unauthenticated identity counts as anonymous or not. that's more than true. > > For background material, check out the meeting minutes from the last > SIMPLE session: > > http://www.softarmor.com/simple/meets/ietf61/proceedings/simpl > e61-session1-minutes.html > > and a recent thread on geopriv: > > http://www.ietf.org/mail-archive/web/geopriv/current/msg00519.html > > We need to resolve this issue. It is a gating factor for > common policy > and the presence authorization work. > > Dean put up a slide during the SIMPLE session last time which > attempted > to figure out whether the concepts of anonymous and > unauthenticated were > really separable. Some further thoughts on when such > combinations can occur: > > Unauthenticated, Anonymous: this would happen when the From field is > present with the value of anonymous and there is no P-A-ID or > Identity > header field. > > Unauthenticated, Not Anonymous: From field is present, but > with a value > that is not anonymous additionally you might want to add that this identifier is not authenticated or asserted. > Authenticated, Anonymous: There is a P-A-ID which a value like > sip:anonymous@foo.invalid, or a From field that is > sip:anonymous@provider.com and an Identity field signed by > provider.com. > Seems reasonable. the latter one makes more sense then the former one. i think you always need to provide an assertion to justify your claim that you have been authenticated to some entity. > > Authenticated, not anonymous: the normal case > > > I think its fair to say that if a request is NOT > authenticated, there is > really no difference between anonymous and not anonymous from > a policy > perspective; in either case the originating identity is as good as > useless. Thus, we'd like to be able to specify policies for > three cases: > unauthenticated, authenticated and anonymous, and > authenticated and not > anonymous. > > However, it is also reasonable to say that one would provide > different > access to presence for anonymous and authenticated users than > unauthenticated users. Indeed, the permissions one would apply for > unauthenticated users really represent the 'baseline' > permissions - no > one would ever receive fewer permissions than those guys. Indeed, the > question is whether unauthenticated users would ever get any > permissions > beyond the minimum. > > I would propose that the answer is no, and then make the following > concrete proposal: > > 1. An unauthenticated request never matches any rules, and thus never > has any permissions granted > > 2. A rule with no conditions matches any authenticated > request. Thus, to > specify permissions that go to any authenticated request, you > would have > rules with no conditions. > > 3. A rule with some conditions matches if those rules match and the > request is authenticated. This means that the permission > assumes the request is authenticated. > > I believe this proposal meets the requirements outlined by > Aki; that is, > to be able to define a baseline permission of "confirm" for any > authenticated user, and then for users that get granted, provide a > permission of "allow". It also allows for expression of policies > separately for the three main cases above. > > This proposal would require the following changes: > > 1. the geopriv common policy needs to be explicit on the meaning of a > rule with no conditions, that it means it applies to any > authenticated > request true. basically it needs to contain the content of this mail. > > 2. the presence auth rules needs to update the definition of the > condition > to reflect the argument by paul we might want to introduce another condition . this would allow unauthenticated users to obtain some information. ciao hannes > > Can we agree on this and move forward? > > Thanks, > Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 17 15:26:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01220; Thu, 17 Feb 2005 15:26:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1sZg-0006Uk-IK; Thu, 17 Feb 2005 15:48:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1qYu-0006Av-Et; Thu, 17 Feb 2005 13:39:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1naE-0000or-FM; Thu, 17 Feb 2005 10:28:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06014; Thu, 17 Feb 2005 10:28:48 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1nvh-0006QB-4f; Thu, 17 Feb 2005 10:51:02 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 17 Feb 2005 10:40:50 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,94,1107752400"; d="scan'208"; a="37345145:sNHT21413216" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1HFS51j018681; Thu, 17 Feb 2005 10:28:05 -0500 (EST) Received: from cisco.com ([161.44.79.182]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APE96883; Thu, 17 Feb 2005 10:28:03 -0500 (EST) Message-ID: <4214B803.7070304@cisco.com> Date: Thu, 17 Feb 2005 10:28:03 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] presence authorization issue: anonymous, authenticated, etc. References: <42146290.5090209@cisco.com> <4214ADD0.3070101@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: >> I think its fair to say that if a request is NOT authenticated, there >> is really no difference between anonymous and not anonymous from a >> policy perspective; in either case the originating identity is as good >> as useless. Thus, we'd like to be able to specify policies for three >> cases: unauthenticated, authenticated and anonymous, and authenticated >> and not anonymous. >> >> However, it is also reasonable to say that one would provide different >> access to presence for anonymous and authenticated users than >> unauthenticated users. Indeed, the permissions one would apply for >> unauthenticated users really represent the 'baseline' permissions - no >> one would ever receive fewer permissions than those guys. Indeed, the >> question is whether unauthenticated users would ever get any >> permissions beyond the minimum. > > I agree with Paul that unauthenticated users may on occasion get access > to data and that we would want to be able to specify this access. Think > of a bus tracking application or other public data. Another contrived > example: anonymous/unauthenticated users can subscribe to get flight > tracker information to within a few miles (insufficient for > missile-aiming), but certain authenticated users (e.g., the FAA) get > precise location. I was thinking of much more mundane cases. For instance any address that corresponds to a public information source - for instance the Chamber of Commerce, or just an enterprise. I hope I will be able to check the presence status of sip:chamber--of-commerce@boxboro.ma.us.gov, and at least find out if they are open or closed. They have no reason to be secretive, so may well expose even more info to everybody - even anonymous watchers. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 17 16:43:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08615; Thu, 17 Feb 2005 16:43:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1tm2-0000Mi-4P; Thu, 17 Feb 2005 17:05:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1rA1-000498-6v; Thu, 17 Feb 2005 14:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1pja-0003XO-4z for simple@megatron.ietf.org; Thu, 17 Feb 2005 12:46:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04173 for ; Thu, 17 Feb 2005 12:46:35 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1q54-00070R-So for simple@ietf.org; Thu, 17 Feb 2005 13:08:51 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 17 Feb 2005 12:59:12 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,95,1107752400"; d="scan'208"; a="37369203:sNHT21282570" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1HHkPhF021500; Thu, 17 Feb 2005 12:46:25 -0500 (EST) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Feb 2005 12:46:24 -0500 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] Three dimensions of service X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 17 Feb 2005 12:46:23 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E379E1@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Simple] Three dimensions of service Thread-Index: AcUU+4+ruvhLFma+QpGrMDtQvcTVswAHF8ow From: "Michael Hammer \(mhammer\)" To: "Henning Schulzrinne" , "Aki Niemi" X-OriginalArrivalTime: 17 Feb 2005 17:46:24.0821 (UTC) FILETIME=[99799E50:01C51518] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable At what point has one crossed over the line to being notified of what communications capabilities are possible and actually being already involved in the communications? The example of the status of the Doom game below has parallels to conference control: who is chair at this moment, who is speaking, etc. I can see how presence could be used to do floor control. Perhaps the subscriber only want to know that you are capable of doing Doom or conferencing, but not interested in any of the blow-by-blow action in progress. Mike >-----Original Message----- >From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]=20 >On Behalf Of Henning Schulzrinne >Sent: Thursday, February 17, 2005 9:03 AM >To: Aki Niemi >Cc: 'Simple WG' >Subject: Re: [Simple] Three dimensions of service > >Aki Niemi wrote: > >> The requirement from my point of view is: One needs to be able to=20 >> indicate finer grained status for a "service" than a simple on/off. >> Capabilities can only go as far as indicating on/off status, but=20 >> that's not enough. > >If I understand you correctly, this is much more closely=20 >related to activities than to a capability. > > >>=20 >> For example, even with a "game/doom capability", you'd still=20 >need to be=20 >> able to indicate things like whether you're hosting, in deathmatch,=20 >> idle, or practicing at the moment. Each state would be=20 >represented to=20 >> the user in the form of a different icon, for example, all very much=20 >> dependant on the "service". > >The game state indication seems like a natural extension to the=20 >'activities' element in RPID. This, along with other RPID element,=20 >provides context to the open/closed status and thus qualifies=20 >it to the=20 >watcher. > >RPID already has a 'status-icon', which seems rather close to what=20 >you're proposing. > > >>=20 >> But again, we don't need to define anything except to say that such=20 >> extensions (I believe D3 in Henning's terminology) may exist, and=20 >> probably should go under the element. > >I don't think this is a capability necessary to ensure connectivity=20 >(which is what I meant D1 through D3 to describe at various layers). > >_______________________________________________ >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 Feb 17 17:00:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12512; Thu, 17 Feb 2005 17:00:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1u2L-0001Su-5s; Thu, 17 Feb 2005 17:22:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1s2O-00033p-QP; Thu, 17 Feb 2005 15:14:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1qWy-0005X5-9u for simple@megatron.ietf.org; Thu, 17 Feb 2005 13:37:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17232 for ; Thu, 17 Feb 2005 13:37:37 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1qsT-0002WC-Fi for simple@ietf.org; Thu, 17 Feb 2005 13:59:53 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 17 Feb 2005 10:47:43 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1HIbNq8002629 for ; Thu, 17 Feb 2005 10:37:23 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-134.cisco.com [10.86.242.134]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHV07058; Thu, 17 Feb 2005 10:37:22 -0800 (PST) Message-ID: <4214E462.1090702@cisco.com> Date: Thu, 17 Feb 2005 13:37:22 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Subject: [Simple] Determination of in presence authorization X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit One of the issues I have raised in the past about the presence authorization work was how to determine the value of the condition. This interacts substantially with the data modeling work, and composition in particular. The difficulty, if you'll recall, was that the value of itself depends on composition and authorization policies. Furthermore, if we allow documents with multiple person elements (as there appears to be consensus to allow), the value is ambiguous. Yet, we need that value to be computed in order to determine if an authorization policy matches in the first place. The current version of the document suggests that the value is computed based on the default composition policy. We have two problems with that: 1. we are pushing out the composition policy work based on Robert's proposal, so the default will be ill defined for some time 2. the presence document can have multiple values of person I would suggest the following solution to this conundrum. Along the lines of Robert's general proposal, we should punt this problem. I'd like to state that the authorization spec does not define how to arrive at a single value of , and that it be a matter of local implementation and policy, and that we expect future standardization work to provide further guidance on this topic. In the short term, real world deployments where we aren't likely to see multiple elements publishing , or we won't see complex authorization policies that restrict who gets to see , there isn't really a problem. The presence doc has a single value for sphere and their is no ambiguity. As we see more complex systems getting used, we can address this via the composition work. Is this workable? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 17 17:20:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15853; Thu, 17 Feb 2005 17:20:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1uLn-0002NZ-7B; Thu, 17 Feb 2005 17:42:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1thR-00055F-OT; Thu, 17 Feb 2005 17:00:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1sDh-0005nv-KL; Thu, 17 Feb 2005 15:25:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01164; Thu, 17 Feb 2005 15:25:52 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1sZD-0006Ss-MI; Thu, 17 Feb 2005 15:48:08 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 17 Feb 2005 12:37:06 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,95,1107763200"; d="scan'208"; a="615474208:sNHT273133556" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1HKP7uC004089; Thu, 17 Feb 2005 12:25:07 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-134.cisco.com [10.86.242.134]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHV17761; Thu, 17 Feb 2005 12:25:07 -0800 (PST) Message-ID: <4214FDA3.3060701@cisco.com> Date: Thu, 17 Feb 2005 15:25:07 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] presence authorization issue: anonymous, authenticated, etc. References: <42146290.5090209@cisco.com> <4214ADD0.3070101@cs.columbia.edu> <4214B803.7070304@cisco.com> In-Reply-To: <4214B803.7070304@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Simple WG , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit OK, looks like my original proposal is not going to cut it. Let me make the following alternative proposal that allows users to set policies for unauthenticated users: 1. a rule with no condiitons matches any subscription, authenticated or not, anonymous or not 2. a rule with an element assumes that the identity listed is authenticated; unauthenticated identities don't match those conditions. 3. a rule with an element assumes that the anonymous request is authenticated; unauthenticated identities don't match the condition. 4. we define an condition that matches any authenticated identity. It becomes a valid child of . This is similar to hennings proposal of using a wildcard in the value of . However, I prefer doing this, so that we can keep the grammar of defined to always be a URI, rather than allowing either a URI or *. i.e., the two approaches are identical semantically but I prefer this more explicit syntax. The definition of "authenticated" can be based on provider policies about what authentication strengths suffice. We won't try to allow users to control that. The document changes needed to support this are: 1. common policy defines the meaning of a rule with no conditions, as matching any request 2. common policy makes it clear that the element matches only for authenticated identities with that value 3. common policy defines an additional value for called per above 4. presence policy updates the definition of anonymous to reflect that it means authenticated 5. presence policy has a discussion on how the is not useful for black lists, but rather for setting "baseline" policies that get applied to a broad set of users representing a minimum level of permissions. If you but the argument in item 5 above, it is not needed to add an kind of clause for , I believe. That is, any kind of permission that applies for any authenticated user should also apply to any user in particular. That is, if I set my permissions for to put subscriptins in the pending state, then every other authenticated user ought to have a permission which is at least that permissive. This means that I couldn't specify that any authenticated user gets put in pending, but bob gets blocked. Is this more workable? I'd love to close on this before the -00 deadline so it can be reflected in the respective docs. Thanks, -Jonathan R. Paul Kyzivat wrote: > > > Henning Schulzrinne wrote: > >>> I think its fair to say that if a request is NOT authenticated, there >>> is really no difference between anonymous and not anonymous from a >>> policy perspective; in either case the originating identity is as >>> good as useless. Thus, we'd like to be able to specify policies for >>> three cases: unauthenticated, authenticated and anonymous, and >>> authenticated and not anonymous. >>> >>> However, it is also reasonable to say that one would provide >>> different access to presence for anonymous and authenticated users >>> than unauthenticated users. Indeed, the permissions one would apply >>> for unauthenticated users really represent the 'baseline' permissions >>> - no one would ever receive fewer permissions than those guys. >>> Indeed, the question is whether unauthenticated users would ever get >>> any permissions beyond the minimum. >> >> >> I agree with Paul that unauthenticated users may on occasion get >> access to data and that we would want to be able to specify this >> access. Think of a bus tracking application or other public data. >> Another contrived example: anonymous/unauthenticated users can >> subscribe to get flight tracker information to within a few miles >> (insufficient for missile-aiming), but certain authenticated users >> (e.g., the FAA) get precise location. > > > I was thinking of much more mundane cases. For instance any address that > corresponds to a public information source - for instance the Chamber of > Commerce, or just an enterprise. I hope I will be able to check the > presence status of sip:chamber--of-commerce@boxboro.ma.us.gov, and at > least find out if they are open or closed. They have no reason to be > secretive, so may well expose even more info to everybody - even > anonymous watchers. > > Paul > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 17 17:37:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18767; Thu, 17 Feb 2005 17:37:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1ud4-000383-GJ; Thu, 17 Feb 2005 18:00:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1tl4-0008ED-Mb; Thu, 17 Feb 2005 17:04:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1tNe-0002K2-Sa; Thu, 17 Feb 2005 16:40:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08152; Thu, 17 Feb 2005 16:40:13 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1tjA-0000Ef-V7; Thu, 17 Feb 2005 17:02:30 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 17 Feb 2005 13:50:01 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1HLdeTj027434; Thu, 17 Feb 2005 13:39:40 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-134.cisco.com [10.86.242.134]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHV23637; Thu, 17 Feb 2005 13:39:38 -0800 (PST) Message-ID: <42150F19.2090901@cisco.com> Date: Thu, 17 Feb 2005 16:39:37 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] presence authorization issue: anonymous, authenticated, etc. References: <42146290.5090209@cisco.com> <4214ADD0.3070101@cs.columbia.edu> In-Reply-To: <4214ADD0.3070101@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > >> Unauthenticated, Anonymous: this would happen when the From field is >> present with the value of anonymous and there is no P-A-ID or Identity >> header field. > > > > >> >> Unauthenticated, Not Anonymous: From field is present, but with a >> value that is not anonymous >> >> Authenticated, Anonymous: There is a P-A-ID which a value like >> sip:anonymous@foo.invalid, or a From field that is >> sip:anonymous@provider.com and an Identity field signed by >> provider.com. Seems reasonable. > > > A different way of saying the same thing is that this is domain-level > authentication. Well, for the Identity case, yes, since its fundamentally built on a domain authentication model. P-A-ID, since you are not validating the assertions, allows you to assert domain-less identities, like sip:anonymous@anonymous.invalid which is a non-existent domain by definition. I don't think it matters if it says alice@example.com or > anon1234@example.com, but only example.com can be authenticated (e.g., > via TLS certs). We aren't normally authenticating the identity of the message originator by TLS certs. We have P-A-ID, which uses inter-domain TLS but not to verify the identity or domain of the sender, but rather to validate the identity of the peer provider. For draft-ietf-sip-identity, there is no TLS, the From field is verified by using the domain cert obtained from the reference in the Identity header. The important part about this "anonymous" authentication > is that the authenticating domain may have some way to hold the party > responsible, even if the PA doesn't know who it is and has no direct > relationship with that party. Thats true assuming it had records of who the caller was, yes. > >> >> Authenticated, not anonymous: the normal case > > > Authenticated (in general) would presumably also include other > mechanisms, such as a Digest-authenticated SUBSCRIBE or maybe even TLS. Yes. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 17 17:39:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19157; Thu, 17 Feb 2005 17:39:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1uel-0003FQ-Of; Thu, 17 Feb 2005 18:02:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1toP-0001uJ-Q5; Thu, 17 Feb 2005 17:07:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1tbH-0000W3-HV for simple@megatron.ietf.org; Thu, 17 Feb 2005 16:54:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10639 for ; Thu, 17 Feb 2005 16:54:17 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1two-0000rS-50 for simple@ietf.org; Thu, 17 Feb 2005 17:16:34 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 17 Feb 2005 13:53:55 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,96,1107763200"; d="scan'208"; a="162081139:sNHT32143316" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1HLrSYO020576; Thu, 17 Feb 2005 13:53:28 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-134.cisco.com [10.86.242.134]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHV24792; Thu, 17 Feb 2005 13:53:26 -0800 (PST) Message-ID: <42151256.6000701@cisco.com> Date: Thu, 17 Feb 2005 16:53:26 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] Three dimensions of service References: <200502081853.NAA04377@ietf.org> <42093E7E.3080708@cisco.com> <421062FC.4050801@cisco.com> <42115C6E.4030402@cs.columbia.edu> <4212FEF7.3050504@cisco.com> <421405D2.3030909@cs.columbia.edu> <42145B19.3000206@cisco.com> <42147D62.40304@nokia.com> In-Reply-To: <42147D62.40304@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: 7bit Cc: "'Simple WG'" , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: 7bit inline. Aki Niemi wrote: > Inline. > > ext Jonathan Rosenberg wrote: > >>> Why precisely will this fail? >> >> >> >> Others know OMA PTT better than I, but I'll take a stab. >> >> The OMA client assumes that both sides support the floor control >> protocol they are using. It also assumes that PTT calls have passed >> through a network with specific topologies that invokes the PTT >> arbiter in the right places. There is nothing in the protocol messages >> that conveys the latter assumption. I am not sure if OMA is using SDP >> to signal the floor control. > > > I believe they do signal it in SDP. That is the sanest thing to do > anyway, because when floor control is explicitly signaled, then you can > also upgrade or change that protocol to something else in the future and > clients can handle legacy gracefully. Right. The issue that makes it non-SIP in this regard is that there is no fallback if that SDP stream is not present in the INVITE request. > >> I will note that, I believe that OMA may have defined a callee-cap >> that decalres OMA support, i.e., ";oma-v1.1=true" in order to allow >> caller prefs to route a call to a PTT phone instead of a regular SIP >> phone with the same AOR. That happens to play well with prescaps, >> where you more or less end up with the label Brian is asking for as a >> capability. > > > Agreed. That solves the capability description needs. > >> I've heard of other PTT implementations that use RTP tricks for floor >> control; in those models there is no new protocol to signal, just >> assumed behaviors that the PTT arbiter makes on the way in which the >> clients send RTP packets. > > > This is clearly not a desireable way to implement things. Something you > can get away with in closed environments, but not in the real world. > > Clearly in these cases, if everything is based on assumptions, then > using a SIP URI makes no sense either. > >>> I would rather extend prescaps if it can't do the right thing now, >>> i.e., describe composable protocol behavior elements rather than just >>> lump everything into a label. >> >> >> >> To be frank, I think we are sorely missing requirements here. We can >> posit all kinds of theoretical applications that can or cannot be >> represented with prescaps. I would rather someone come to IETF and >> say, "hey, I want to use simple for my application but I can't do it >> in prescaps because of A,B,C". We are simply not seeing that now. >> Until we have that, this discussion is all interesting but theoretical. > > > I've tried, several times. Let me try again. What I mean is, folks keep talking about doom and other random apps that don't actually get signaled with SIP, and for which we don't have anyone that really implementing them. We do appear to have a concrete app in the form of OMA PTT. > > The requirement from my point of view is: One needs to be able to > indicate finer grained status for a "service" than a simple on/off. Umm, isnt that what RPID is for? > Capabilities can only go as far as indicating on/off status, but that's > not enough. > > For example, even with a "game/doom capability", you'd still need to be > able to indicate things like whether you're hosting, in deathmatch, > idle, or practicing at the moment. Each state would be represented to > the user in the form of a different icon, for example, all very much > dependant on the "service". Sure, so go ahead and bring some requirements forward about states you want to see in Doom. What part of the model doesn't support this? > > But again, we don't need to define anything except to say that such > extensions (I believe D3 in Henning's terminology) may exist, and > probably should go under the element. I fear there is some perception here that the data model is saying that presence states aren't extensible. I don't know what in the document would convey that impression though. > > The only thing where the model is affected is that if you have two > tuples that have the same extension that is unknown to the composer, but > known to the watcher, and one has value foo and one has value baz, the > composer *cannot* merge the states (tuples) because it doesn't know > whether to choose foo, baz, or put both in. This is fodder for the presence processing draft that I just submitted (which is basically the tail end of the former data model draft). It needs to address merging rules for unknown attributes. That is a reasonable thing. However, there are problems. If the compositor doesnt know the extension, the only outputs it can produce which have a chance of being compliant to that extension are to pick one. I don't think it can put both in, since the schema may not allow it. >> >> My argument here is based on the view that the whole point of a URI is >> that it provides complete context. You should be able to take a URI, >> pass it to an application that knows the scheme, and it should be able >> to invoke it and have the right thing happen. > > > What do you mean by "invoke it"? Do you mean a voice call, a video call, > or what? And what do you mean by "the right thing"? Is receiving a 415 > such a case? Invoke it means that any remaining context is derived from local information. In the case of SIP, you would include the full set of media capabilities that the user had set as the default to use. Same is true for http. If I get an http URI, I can "invoke it". The browser might include extra headers, cookies for example, or Accept-Content or whatever, based on local information, but no additional data is needed about the remote side to connect. > >> We are having proposed cases where that isn't the case, and its >> because the implementations are using SIP but are layering additional >> semantics and behaviors which make it distinctly non-SIP and break >> interop. > > > You may have a different example in mind, but adding new media in SDP > IMHO doesn't constitute layering additional semantics to SIP, but to > SDP, and I can't see that having anything to do with whether SIP can be > used to offer such SDP or not. See above on fallback behavior. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 17 17:41:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19434; Thu, 17 Feb 2005 17:41:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1ugS-0003Kk-T6; Thu, 17 Feb 2005 18:03:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1tvp-0005Dq-3h; Thu, 17 Feb 2005 17:15:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1tfB-0003CB-2U; Thu, 17 Feb 2005 16:58:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11748; Thu, 17 Feb 2005 16:58:18 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1u0d-0001Ff-Fe; Thu, 17 Feb 2005 17:20:34 -0500 Received: from lion.cs.columbia.edu (IDENT:rBB29WLjd9q7/Br+fGFPFaqT+A7nkenm@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j1HLuuir002386 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 17 Feb 2005 16:56:56 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id j1HLutRn031973 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 17 Feb 2005 16:56:56 -0500 Message-ID: <42151323.4060309@cs.columbia.edu> Date: Thu, 17 Feb 2005 16:56:51 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] presence authorization issue: anonymous, authenticated, etc. References: <42146290.5090209@cisco.com> <4214ADD0.3070101@cs.columbia.edu> <42150F19.2090901@cisco.com> In-Reply-To: <42150F19.2090901@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit > We aren't normally authenticating the identity of the message originator > by TLS certs. We have P-A-ID, which uses inter-domain TLS but not to > verify the identity or domain of the sender, but rather to validate the > identity of the peer provider. For draft-ietf-sip-identity, there is no > TLS, the From field is verified by using the domain cert obtained from > the reference in the Identity header. I agree that there may be multiple layers in-between, but the basic premise is that - some domain knows an individual at some level, but hides the "real" identity - it then contacts the PA, who believes the peer domain identity A truly anonymous identity, i.e., where some random IP address sends a self-signed cert, doesn't strike me as any different from the unauthenticated case. > > > The important part about this "anonymous" authentication > >> is that the authenticating domain may have some way to hold the party >> responsible, even if the PA doesn't know who it is and has no direct >> relationship with that party. > > > Thats true assuming it had records of who the caller was, yes. If not, I don't see the practical difference to unauthenticated. If I can't hold the party responsible, it doesn't matter if it authenticated or not. It is not even clear that I know what such authentication-without-identity (at the origin) would mean. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 17 19:10:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28823; Thu, 17 Feb 2005 19:10:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1w4g-0005bc-7e; Thu, 17 Feb 2005 19:32:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1vP7-0007Qv-UG; Thu, 17 Feb 2005 18:49:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1vAL-00089a-SL; Thu, 17 Feb 2005 18:34:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24185; Thu, 17 Feb 2005 18:34:34 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1vVs-0004S0-4l; Thu, 17 Feb 2005 18:56:52 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 17 Feb 2005 16:47:27 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,96,1107734400"; d="scan'208"; a="226317531:sNHT27482240" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1HNY1Tj006264; Thu, 17 Feb 2005 15:34:01 -0800 (PST) Received: from cisco.com ([161.44.79.182]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APF45173; Thu, 17 Feb 2005 18:34:00 -0500 (EST) Message-ID: <421529E8.8020701@cisco.com> Date: Thu, 17 Feb 2005 18:34:00 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] presence authorization issue: anonymous, authenticated, etc. References: <42146290.5090209@cisco.com> <4214ADD0.3070101@cs.columbia.edu> <4214B803.7070304@cisco.com> <4214FDA3.3060701@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Simple WG , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > OK, looks like my original proposal is not going to cut it. > > Let me make the following alternative proposal that allows users to set > policies for unauthenticated users: > > 1. a rule with no condiitons matches any subscription, authenticated or > not, anonymous or not > > 2. a rule with an element assumes that the identity listed is > authenticated; unauthenticated identities don't match those conditions. > > 3. a rule with an element assumes that the anonymous request > is authenticated; unauthenticated identities don't match the > condition. Functionally these three are fine. I'm inclined to quibble about the precise terminology used, because I think this is less than intuitive. Would be clearer if it was or something like that. But I'm not going to argue as long as the meaning is well documented. > 4. we define an condition that matches any authenticated > identity. It becomes a valid child of . This is similar to > hennings proposal of using a wildcard in the value of . However, I > prefer doing this, so that we can keep the grammar of defined to > always be a URI, rather than allowing either a URI or *. i.e., the two > approaches are identical semantically but I prefer this more explicit > syntax. Does match the things that matches? I hope not. > The definition of "authenticated" can be based on provider policies > about what authentication strengths suffice. We won't try to allow users > to control that. Sounds good. > The document changes needed to support this are: > > 1. common policy defines the meaning of a rule with no conditions, as > matching any request While I have no problem with using rule with no conditions for this purpose, if it is easier, it would also be ok to provide a special rule (e.g. ) for this. > 2. common policy makes it clear that the element matches only for > authenticated identities with that value > > 3. common policy defines an additional value for called > per above > > 4. presence policy updates the definition of anonymous to reflect that > it means authenticated > > 5. presence policy has a discussion on how the is not > useful for black lists, but rather for setting "baseline" policies that > get applied to a broad set of users representing a minimum level of > permissions. > > > > If you but the argument in item 5 above, it is not needed to add an > kind of clause for , I believe. That is, any kind > of permission that applies for any authenticated user should also apply > to any user in particular. That is, if I set my permissions for > to put subscriptins in the pending state, then every > other authenticated user ought to have a permission which is at least > that permissive. > This means that I couldn't specify that any authenticated user gets put > in pending, but bob gets blocked. I'm not sure about that one. I know logically if somebody can get a result by using some random phone then it makes no sense to give them less if they call from their own phone. But I am also pretty sure that complaints about it will come up constantly and we will be cursed until we "fix" it. So I think we need a way to say this. I know this is pretty unreasonable. So please convince me that we won't be hounded to death if we don't provide it. > Is this more workable? Otherwise yes. Paul > I'd love to close on this before the -00 deadline so it can be reflected > in the respective docs. > > Thanks, > -Jonathan R. > > Paul Kyzivat wrote: > >> >> >> Henning Schulzrinne wrote: >> >>>> I think its fair to say that if a request is NOT authenticated, >>>> there is really no difference between anonymous and not anonymous >>>> from a policy perspective; in either case the originating identity >>>> is as good as useless. Thus, we'd like to be able to specify >>>> policies for three cases: unauthenticated, authenticated and >>>> anonymous, and authenticated and not anonymous. >>>> >>>> However, it is also reasonable to say that one would provide >>>> different access to presence for anonymous and authenticated users >>>> than unauthenticated users. Indeed, the permissions one would apply >>>> for unauthenticated users really represent the 'baseline' >>>> permissions - no one would ever receive fewer permissions than those >>>> guys. Indeed, the question is whether unauthenticated users would >>>> ever get any permissions beyond the minimum. >>> >>> >>> >>> I agree with Paul that unauthenticated users may on occasion get >>> access to data and that we would want to be able to specify this >>> access. Think of a bus tracking application or other public data. >>> Another contrived example: anonymous/unauthenticated users can >>> subscribe to get flight tracker information to within a few miles >>> (insufficient for missile-aiming), but certain authenticated users >>> (e.g., the FAA) get precise location. >> >> >> >> I was thinking of much more mundane cases. For instance any address >> that corresponds to a public information source - for instance the >> Chamber of Commerce, or just an enterprise. I hope I will be able to >> check the presence status of >> sip:chamber--of-commerce@boxboro.ma.us.gov, and at least find out if >> they are open or closed. They have no reason to be secretive, so may >> well expose even more info to everybody - even anonymous watchers. >> >> Paul >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 17 19:37:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01393; Thu, 17 Feb 2005 19:37:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1wUT-0006Nt-TJ; Thu, 17 Feb 2005 19:59:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1vqZ-0007fA-1s; Thu, 17 Feb 2005 19:18:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1vQK-0007nv-G3 for simple@megatron.ietf.org; Thu, 17 Feb 2005 18:51:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26573 for ; Thu, 17 Feb 2005 18:51:06 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1vlr-00051H-RH for simple@ietf.org; Thu, 17 Feb 2005 19:13:25 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 17 Feb 2005 19:03:23 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,96,1107752400"; d="scan'208"; a="37425347:sNHT19991276" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1HNoXhF024636; Thu, 17 Feb 2005 18:50:34 -0500 (EST) Received: from cisco.com ([161.44.79.182]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APF46138; Thu, 17 Feb 2005 18:50:32 -0500 (EST) Message-ID: <42152DC8.6010900@cisco.com> Date: Thu, 17 Feb 2005 18:50:32 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Three dimensions of service References: <200502081853.NAA04377@ietf.org> <42093E7E.3080708@cisco.com> <421062FC.4050801@cisco.com> <42115C6E.4030402@cs.columbia.edu> <4212FEF7.3050504@cisco.com> <421405D2.3030909@cs.columbia.edu> <42145B19.3000206@cisco.com> <42147D62.40304@nokia.com> <42151256.6000701@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: Henning Schulzrinne , Aki Niemi , "'Simple WG'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Trimming - only want to comment on one point. Paul Jonathan Rosenberg wrote: >> The only thing where the model is affected is that if you have two >> tuples that have the same extension that is unknown to the composer, >> but known to the watcher, and one has value foo and one has value baz, >> the composer *cannot* merge the states (tuples) because it doesn't >> know whether to choose foo, baz, or put both in. > > This is fodder for the presence processing draft that I just submitted > (which is basically the tail end of the former data model draft). It > needs to address merging rules for unknown attributes. That is a > reasonable thing. However, there are problems. If the compositor doesnt > know the extension, the only outputs it can produce which have a chance > of being compliant to that extension are to pick one. I don't think it > can put both in, since the schema may not allow it. Perhaps we need to create a special element, whose only purpose is to contain unreconciled conflicts. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 17 21:18:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12122; Thu, 17 Feb 2005 21:18:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1y4A-0000vC-Q8; Thu, 17 Feb 2005 21:40:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1xfw-0008Is-Q6; Thu, 17 Feb 2005 21:15:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1xYw-0004m1-C7 for simple@megatron.ietf.org; Thu, 17 Feb 2005 21:08:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11146 for ; Thu, 17 Feb 2005 21:08:08 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1xuJ-0000fQ-JR for simple@ietf.org; Thu, 17 Feb 2005 21:30:15 -0500 Received: from razor.cs.columbia.edu (IDENT:U2FsdGVkX18+eqLUWLvBF4KdxhvMO9OSMH/5rtU7BCw@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j1I27mir011159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Feb 2005 21:07:49 -0500 (EST) Received: from [127.0.0.1] (IDENT:U2FsdGVkX1+ld0dztk6cOjBEowt119wjX7XlQpzkS40@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j1I27mx1014911; Thu, 17 Feb 2005 21:07:48 -0500 Message-ID: <42154DF2.5020102@cs.columbia.edu> Date: Thu, 17 Feb 2005 21:07:46 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Determination of in presence authorization References: <4214E462.1090702@cisco.com> In-Reply-To: <4214E462.1090702@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Agreed. In reality, this gets even messier since one could easily imagine systems that set through some out-of-band, non-PUBLISH means (e.g., a web page or some time-based logic). While it would be nice if different systems arrived at the same sphere value given the same inputs, this seems like a minor consistency issue in practice. It doesn't affect interoperability; there are any number of places (e.g., even in basic call routing and forking) where we don't specify exactly what should happen under all possible circumstances and inputs. Henning Jonathan Rosenberg wrote: > One of the issues I have raised in the past about the presence > authorization work was how to determine the value of the > condition. This interacts substantially with the data modeling work, and > composition in particular. The difficulty, if you'll recall, was that > the value of itself depends on composition and authorization > policies. Furthermore, if we allow documents with multiple person > elements (as there appears to be consensus to allow), the value is > ambiguous. Yet, we need that value to be computed in order to determine > if an authorization policy matches in the first place. > > The current version of the document suggests that the value is computed > based on the default composition policy. We have two problems with that: > > 1. we are pushing out the composition policy work based on Robert's > proposal, so the default will be ill defined for some time > > 2. the presence document can have multiple values of person > > I would suggest the following solution to this conundrum. > > Along the lines of Robert's general proposal, we should punt this > problem. I'd like to state that the authorization spec does not define > how to arrive at a single value of , and that it be a matter of > local implementation and policy, and that we expect future > standardization work to provide further guidance on this topic. > > In the short term, real world deployments where we aren't likely to see > multiple elements publishing , or we won't see complex > authorization policies that restrict who gets to see , there > isn't really a problem. The presence doc has a single value for sphere > and their is no ambiguity. As we see more complex systems getting used, > we can address this via the composition work. > > Is this workable? > > Thanks, > Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 17 22:20:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17523; Thu, 17 Feb 2005 22:20:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1z2j-0002Lw-Pn; Thu, 17 Feb 2005 22:43:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1yfp-0003ch-Qf; Thu, 17 Feb 2005 22:19:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1ybD-0001MY-8F; Thu, 17 Feb 2005 22:14:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17114; Thu, 17 Feb 2005 22:14:33 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1ywn-0002Do-3P; Thu, 17 Feb 2005 22:36:53 -0500 Received: from razor.cs.columbia.edu (IDENT:U2FsdGVkX1+GguaMqh0nHXGhCyaa+e5q5xPAeTt3HnM@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j1I3EUir026486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Feb 2005 22:14:30 -0500 (EST) Received: from [127.0.0.1] (IDENT:U2FsdGVkX19Z4MNmPDpvRhAl/HsF/w2sjJpXcJc94zM@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j1I3ETGT015132; Thu, 17 Feb 2005 22:14:29 -0500 Message-ID: <42155D96.8050303@cs.columbia.edu> Date: Thu, 17 Feb 2005 22:14:30 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] presence authorization issue: anonymous, authenticated, etc. References: <42146290.5090209@cisco.com> <4214ADD0.3070101@cs.columbia.edu> <4214B803.7070304@cisco.com> <4214FDA3.3060701@cisco.com> In-Reply-To: <4214FDA3.3060701@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Paul Kyzivat , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > 1. a rule with no condiitons matches any subscription, authenticated or > not, anonymous or not I think this has to be true. I don't see what else could work according to the basic design. > > 2. a rule with an element assumes that the identity listed is > authenticated; unauthenticated identities don't match those conditions. Agreed. The text should probably at least provide examples of what 'authenticated' means. > > 3. a rule with an element assumes that the anonymous request > is authenticated; unauthenticated identities don't match the > condition. Does the rule engine have to know which URL instances are actually anonymous? This increases the assumption on the type of matching needed. Do we really need 'any anonymous user', as opposed to 'anonymous users from a particular domain'? > > 4. we define an condition that matches any authenticated > identity. It becomes a valid child of . This is similar to > hennings proposal of using a wildcard in the value of . However, I > prefer doing this, so that we can keep the grammar of defined to > always be a URI, rather than allowing either a URI or *. i.e., the two > approaches are identical semantically but I prefer this more explicit > syntax. Can you give an example how this would be used? Is this to address the 'anybody within a domain' case or something else? > > > The definition of "authenticated" can be based on provider policies > about what authentication strengths suffice. We won't try to allow users > to control that. > > > The document changes needed to support this are: > > 1. common policy defines the meaning of a rule with no conditions, as > matching any request > > 2. common policy makes it clear that the element matches only for > authenticated identities with that value > > 3. common policy defines an additional value for called > per above > > 4. presence policy updates the definition of anonymous to reflect that > it means authenticated > > 5. presence policy has a discussion on how the is not > useful for black lists, but rather for setting "baseline" policies that > get applied to a broad set of users representing a minimum level of > permissions. > > > > If you but the argument in item 5 above, it is not needed to add an > kind of clause for , I believe. That is, any kind > of permission that applies for any authenticated user should also apply > to any user in particular. That is, if I set my permissions for > to put subscriptins in the pending state, then every > other authenticated user ought to have a permission which is at least > that permissive. > > This means that I couldn't specify that any authenticated user gets put > in pending, but bob gets blocked. > > > Is this more workable? > > I'd love to close on this before the -00 deadline so it can be reflected > in the respective docs. > > Thanks, > -Jonathan R. > > Paul Kyzivat wrote: > >> >> >> Henning Schulzrinne wrote: >> >>>> I think its fair to say that if a request is NOT authenticated, >>>> there is really no difference between anonymous and not anonymous >>>> from a policy perspective; in either case the originating identity >>>> is as good as useless. Thus, we'd like to be able to specify >>>> policies for three cases: unauthenticated, authenticated and >>>> anonymous, and authenticated and not anonymous. >>>> >>>> However, it is also reasonable to say that one would provide >>>> different access to presence for anonymous and authenticated users >>>> than unauthenticated users. Indeed, the permissions one would apply >>>> for unauthenticated users really represent the 'baseline' >>>> permissions - no one would ever receive fewer permissions than those >>>> guys. Indeed, the question is whether unauthenticated users would >>>> ever get any permissions beyond the minimum. >>> >>> >>> >>> I agree with Paul that unauthenticated users may on occasion get >>> access to data and that we would want to be able to specify this >>> access. Think of a bus tracking application or other public data. >>> Another contrived example: anonymous/unauthenticated users can >>> subscribe to get flight tracker information to within a few miles >>> (insufficient for missile-aiming), but certain authenticated users >>> (e.g., the FAA) get precise location. >> >> >> >> I was thinking of much more mundane cases. For instance any address >> that corresponds to a public information source - for instance the >> Chamber of Commerce, or just an enterprise. I hope I will be able to >> check the presence status of >> sip:chamber--of-commerce@boxboro.ma.us.gov, and at least find out if >> they are open or closed. They have no reason to be secretive, so may >> well expose even more info to everybody - even anonymous watchers. >> >> Paul >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 18 06:45:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21498; Fri, 18 Feb 2005 06:45:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D26vh-0005la-7M; Fri, 18 Feb 2005 07:08:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D26Uq-0004Mx-Et; Fri, 18 Feb 2005 06:40:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D26Qb-0002ni-0O for simple@megatron.ietf.org; Fri, 18 Feb 2005 06:36:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20726 for ; Fri, 18 Feb 2005 06:36:06 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D26mF-0005Xg-53 for simple@ietf.org; Fri, 18 Feb 2005 06:58:31 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1IBZwc08504; Fri, 18 Feb 2005 13:35:58 +0200 (EET) X-Scanned: Fri, 18 Feb 2005 13:34:29 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j1IBYTHL023631; Fri, 18 Feb 2005 13:34:29 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00R5qKXI; Fri, 18 Feb 2005 13:30:33 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1IBUXJ28596; Fri, 18 Feb 2005 13:30:33 +0200 (EET) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 18 Feb 2005 13:30:33 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 18 Feb 2005 13:30:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Three dimensions of service Date: Fri, 18 Feb 2005 13:30:32 +0200 Message-ID: Thread-Topic: [Simple] Three dimensions of service Thread-Index: AcUVQfChTb245/pMSJSo8j7EYH0QtAAUbsbw To: , X-OriginalArrivalTime: 18 Feb 2005 11:30:33.0420 (UTC) FILETIME=[4234A8C0:01C515AD] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org, hgs@cs.columbia.edu X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable Hi, Commenting only to a couple of points in the discussion. (I'm not sure = whose comments all originally were.) Jonathan Rosenberg wrote: >=20 > inline. >=20 > Aki Niemi wrote: >=20 > > Inline. > >=20 > > ext Jonathan Rosenberg wrote: > >=20 > >>> Why precisely will this fail? > >> > >> > >> > >> Others know OMA PTT better than I, but I'll take a stab. > >> > >> The OMA client assumes that both sides support the floor control=20 > >> protocol they are using. It also assumes that PTT calls=20 > have passed=20 > >> through a network with specific topologies that invokes the PTT=20 > >> arbiter in the right places. There is nothing in the=20 > protocol messages=20 > >> that conveys the latter assumption. I am not sure if OMA=20 > is using SDP=20 > >> to signal the floor control. > >=20 > >=20 > > I believe they do signal it in SDP. That is the sanest thing to do=20 > > anyway, because when floor control is explicitly signaled,=20 > then you can=20 > > also upgrade or change that protocol to something else in=20 > the future and=20 > > clients can handle legacy gracefully. >=20 > Right. The issue that makes it non-SIP in this regard is that=20 > there is=20 > no fallback if that SDP stream is not present in the INVITE request. >=20 To my understanding these type of issues, e.g. what to do when some = media streams are present or not present, are part of the application = logic. Usually that type of logic is left to the implementation. In case = of OMA PoC some parts of the application logic have been "standardized" = too. That still does not make it non-SIP. Also, I don't think there is = anything that would really prevent a PoC conference server to accept an = INVITE without the floor control. However, that might lead to a strange = user experience especially in a one-to-one call (which is still done as = a conference), depending on how the other party's application has been = implemented. My conclusion on this is that whether we want it or not, there will be = this type of weird application logics/limitations on topic of SIP in any = case, and we just have to have a way in presence to cope with those. = Presence should be aiding users/applications, not dictating what they = are allowed to do. If I happen to have a PoC application that works in a way that it does = not *want* to fall back in case there is no floor control, I would need = to express that I have an application which can be contacted succesfully = only if the caller has certain capabilities (that can work together). = Since prescaps does not allow that, it makes it easier to just say = "org.oma.poc-1.0" than "half-duplex" & "voice" & "floor-control" & = "PoC-feature-tag". Contact would be sip: or sips: in any case. If I have an application that can do VoIP in addition to PoC I would say = "org.oma.poc-1.0" & "voice", but of course that could be in the same = tuple only if those two have the same status. > >=20 > >>> I would rather extend prescaps if it can't do the right=20 > thing now,=20 > >>> i.e., describe composable protocol behavior elements=20 > rather than just=20 > >>> lump everything into a label. > >> This is a desirable property, but it really assumes that there would be = a fallback even in cases where certain set of the componets is not = supported. Surely SIP itself works like that, but all the applications = do NOT. In Presence we are somewhat describing the application in = addition to the protocol capabilities too. I don't know where we are with prescaps, but I think the only way to = prevent labels would the capability of expressing "you have to support = all of these components to interact with my application". > >=20 > I fear there is some perception here that the data model is=20 > saying that=20 > presence states aren't extensible. I don't know what in the document=20 > would convey that impression though. > Right. I think that in the model discussion we merely need to understand = what the extension points are and how such extensions interact with the = composition. =20 > >=20 > > The only thing where the model is affected is that if you have two=20 > > tuples that have the same extension that is unknown to the=20 > composer, but=20 > > known to the watcher, and one has value foo and one has=20 > value baz, the=20 > > composer *cannot* merge the states (tuples) because it doesn't know=20 > > whether to choose foo, baz, or put both in. >=20 > This is fodder for the presence processing draft that I just=20 > submitted=20 > (which is basically the tail end of the former data model draft). It=20 > needs to address merging rules for unknown attributes. That is a=20 > reasonable thing. However, there are problems. If the=20 > compositor doesnt=20 > know the extension, the only outputs it can produce which=20 > have a chance=20 > of being compliant to that extension are to pick one. I don't=20 > think it=20 > can put both in, since the schema may not allow it. >=20 Again the problem seems to be that it is impossible to determine what = the intention is: replace or append. That is why I thought it to be = valuable to have some sort of identifier in the tuple itself for this = (and since we determined that the contact URI can't be used for this, it = would need to be something else).=20 Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 18 09:04:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03845; Fri, 18 Feb 2005 09:04:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D296B-0000iS-S5; Fri, 18 Feb 2005 09:27:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D28cH-0006sn-5p; Fri, 18 Feb 2005 08:56:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D28W5-0004aF-4p for simple@megatron.ietf.org; Fri, 18 Feb 2005 08:49:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02672 for ; Fri, 18 Feb 2005 08:49:55 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D28rk-0000LN-FO for simple@ietf.org; Fri, 18 Feb 2005 09:12:21 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 18 Feb 2005 05:50:26 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,98,1107763200"; d="scan'208"; a="162180079:sNHT22235736" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1IDnMwN024977; Fri, 18 Feb 2005 05:49:22 -0800 (PST) Received: from cisco.com (che-vpn-cluster-2-131.cisco.com [10.86.242.131]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APF72980; Fri, 18 Feb 2005 08:49:20 -0500 (EST) Message-ID: <4215F260.3090207@cisco.com> Date: Fri, 18 Feb 2005 08:49:20 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: Re: [Simple] Three dimensions of service References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Cc: hgs@cs.columbia.edu, aki.niemi@nokia.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Hi Markus, I think it is looking productive to look in detail at POC. I think as we do so we will be able to find a way to describe this and keep the presence system rational. Comments inline. Paul Markus.Isomaki@nokia.com wrote: [trimming] (the below refers to floor control) >>Right. The issue that makes it non-SIP in this regard is that >>there is >>no fallback if that SDP stream is not present in the INVITE request. > > To my understanding these type of issues, e.g. what to do when > some media streams are present or not present, are part of the > application logic. Usually that type of logic is left to the > implementation. In case of OMA PoC some parts of the application > logic have been "standardized" too. That still does not make it > non-SIP. I think this may be part of a larger problem. That is: what should happen when all the media in an offer are not supported by the answerer? The specification in the offer/answer rfc is that those which are not accepted should be refused by setting the port number to zero. In practice, it is common for a UAS to refuse the call if the result would be a call with no media. That makes reasonable sense in the case of a UA that only supports one medium (audio), especially when in the vast majority of cases audio is the only medium that will ever be seen. We need to start thinking of how this should work in a world where there are serveral media in common use, and devices that are flexible in their use of media - with the possibility to enable and disable the use of particular media. It seems reasonable to me that UAs should be more tolerant in how they handle media mismatches - perhaps at least alerting and letting the user decide. In some cases it may be reasonable to accept the call even without the exact media configuration that the UA prefers - operating in degraded mode, and possibly hoping that reconfiguration of one or the other of the parties in the call will make things better. > Also, I don't think there is anything that would really prevent a > PoC conference server to accept an INVITE without the floor control. > However, that might lead to a strange user experience especially in > a one-to-one call (which is still done as a conference), depending > on how the other party's application has been implemented. That's exactly the kind of thing I was talking about above. It might not be great, but it might be better than nothing. > My conclusion on this is that whether we want it or not, there will be this type of weird application logics/limitations on topic of SIP in any case, and we just have to have a way in presence to cope with those. Presence should be aiding users/applications, not dictating what they are allowed to do. I think we need to strike a balance here. We don't want to be unreasonable. But neither do we want to encourage balkanization of services. It might be easier for a particular endpoint to simply advertise its brand and model, and expect to talk only to others the same. Then it could be confident there are no incompatibilities. But we don't want to encourage that either. > If I happen to have a PoC application that works in a way that it > does not *want* to fall back in case there is no floor control, > I would need to express that I have an application which can be > contacted succesfully only if the caller has certain capabilities > (that can work together). I agree it would be good to be able to express that. I think that can be a subject of future work. > Since prescaps does not allow that, it makes it easier to just say > "org.oma.poc-1.0" than "half-duplex" & "voice" & "floor-control" & > "PoC-feature-tag". Contact would be sip: or sips: in any case. Well, I agree it is "better" than the alternative you list, in the sense that it doesn't make claims that can be misinterpretted. But it is not "good". I especially think that treating this as a unique "capability", that could be combined with others, is preferable to introducing a "service type" that each tuple has exactly one of. > If I have an application that can do VoIP in addition to PoC I would say "org.oma.poc-1.0" & "voice", but of course that could be in the same tuple only if those two have the same status. Agree. >>>>>I would rather extend prescaps if it can't do the right >>>>>thing now, >>>>>i.e., describe composable protocol behavior elements >>>>>rather than just >>>>>lump everything into a label. > > This is a desirable property, but it really assumes that there would be a fallback even in cases where certain set of the componets is not supported. Surely SIP itself works like that, but all the applications do NOT. In Presence we are somewhat describing the application in addition to the protocol capabilities too. > > I don't know where we are with prescaps, but I think the only way to prevent labels would the capability of expressing "you have to support all of these components to interact with my application". I think this is something we should pursue. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From jinsheng@acninc.net Fri Feb 18 10:16:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14092 for ; Fri, 18 Feb 2005 10:16:26 -0500 (EST) Received: from bzq-84-109-145-197.red.bezeqint.net ([84.109.145.197]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D2ADS-0003Ds-VJ for simple-archive@ietf.org; Fri, 18 Feb 2005 10:38:52 -0500 Message-ID: From: "Paul A. Davis" To: simple-archive@ietf.org Subject: =?iso-8859-1?B?Q2lhbGlzIC0gd2hvbGVzYWxlIHByaWNl?= Date: Fri, 18 Feb 2005 15:10:49 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_29B9CA24.71B2E07F" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 4.3 (++++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0000_29B9CA24.71B2E07F Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_C8F5C657.42F8ECD2" ------=_NextPart_001_0001_C8F5C657.42F8ECD2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Fast & easy erections Long effects No prescription required Only $2.99/$1.99 per dose (2 doses in each pill): Cialis - http://www.platinummed.biz/sv/ Viagra - http://www.platinummed.biz/vt/ Select the manufacturer you can trust! _________________________________________________________________________ To change your mail preferences, go here: http://www.platinummed.biz/uns.htm _________________________________________________________________________ ------=_NextPart_001_0001_C8F5C657.42F8ECD2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit

Fast & easy erections
Long effects duration
No prescription required

Give it a try!
CIALIS - http://www.platinummed.biz/sv/
VIAGRA - http://www.platinummed.biz/vt/

Discreet packaging


_________________________________________________________________________
To stop further mailings, go here: http://www.platinummed.biz/uns.htm
_________________________________________________________________________

------=_NextPart_001_0001_C8F5C657.42F8ECD2-- ------=_NextPart_000_0000_29B9CA24.71B2E07F-- From Saugar@columnist.com Fri Feb 18 13:43:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20861; Fri, 18 Feb 2005 13:43:31 -0500 (EST) Received: from [201.2.56.158] (helo=casino.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D2DRq-00053Q-2r; Fri, 18 Feb 2005 14:06:00 -0500 From: "Bastone Daniela" To: "Gonzales Daniel" Subject: Re[6]: talk about your health Date: Fri, 18 Feb 2005 11:42:20 -0200 Message-ID: <74b901c515e9$29cc1ed9$9e3802c9@casino.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0123_456789AB.CDEF0123" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 1.0 (+) X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86 This is a multi-part message in MIME format. ------=_NextPart_000_0123_456789AB.CDEF0123 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of ------=_NextPart_000_0123_456789AB.CDEF0123 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
SP -M  The  we and  Saf Wa Ph acy 
UR is  Ne st  The  est  y of  arm

Inc e Yo xual Des Spe ume by  %
reas ur Se ire and  rm vol 500
<= /TABLE>

100 ural and  de Eff - in con t to wel wn bra
% Nat No Si ects  tras l-kno nds.
Expe ce thr es lon gas
rien ee tim ger or ms

































arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ------=_NextPart_000_0123_456789AB.CDEF0123-- From simple-bounces@ietf.org Fri Feb 18 14:02:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24243; Fri, 18 Feb 2005 14:02:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Dk6-0005lT-JB; Fri, 18 Feb 2005 14:24:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2D4B-0006Wt-Hg; Fri, 18 Feb 2005 13:41:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Cwg-0002vv-LL for simple@megatron.ietf.org; Fri, 18 Feb 2005 13:33:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19191 for ; Fri, 18 Feb 2005 13:33:39 -0500 (EST) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2DIN-0004iG-D2 for simple@ietf.org; Fri, 18 Feb 2005 13:56:08 -0500 Received: from [131.161.248.87] (open-131-161-248-87.cliq.com [131.161.248.87]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j1IIX5m31425; Fri, 18 Feb 2005 10:33:05 -0800 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <98e7431c35cb9031307559570a199aaf@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Fri, 18 Feb 2005 08:45:24 -0800 To: Simple WG X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy Subject: [Simple] WebDAV alternative to XCAP draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Hi Folks, Sometime in December or January, I started to hear fragmented reports that verifying idempotency during PUT and DELETE operations in early implementations of XCAP made the performance of these XCAP server drop considerably. I can think of two reasonable explanations for these reports: 1) These implementations where written inefficiently. When optimized the actual performance of idempotency checks is fine for production systems. or 2) There is something inherent about the flexibility of XCAP that makes it hard to quickly verify the idempotency requirement. Currently SIMPLE is using XCAP for resource-lists and auth-lists. While the arbitrary depth functionality of XCAP is useful for some applications (ex: I understand that this was particularly attractive for Joel's application), our applications don't require the complete flexibility of XCAP. Consequently, I wrote an "Escape Hatch" proposal that sketches the possibility of using ordinary WebDAV to get the functionality we are using. I quite like this approach and if we were starting over again, this would be my first choice. However, the working group has invested a lot of energy in XCAP and it promises a lot of flexibility for future IETF application configuration work. So, I would like to quickly find out what kind of PUT and DELETE performance folks are getting from XCAP implementations when idempotency checks are turned on. Folks with implementations, please speak up. It would be nice to verify that everything is fine and go back to our regularly scheduled program. If something is really wrong, I'd like folks to consider my proposal, which is at: http://www.ietf.org/internet-drafts/draft-mahy-simple-xcap- alternative-00.txt many thanks, -rohan _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From kyagjplrbhfrr@mzima.net Fri Feb 18 16:11:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16334; Fri, 18 Feb 2005 16:11:05 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Fkj-0003Y2-OK; Fri, 18 Feb 2005 16:33:35 -0500 Received: from c-67-163-182-11.client.comcast.net ([67.163.182.11]) by mx2.foretec.com with smtp (Exim 4.24) id 1D2FZH-0007Ar-KT; Fri, 18 Feb 2005 16:21:47 -0500 Received: from GMLBS-ZK72 (67.163.182.11) by 67.163.182.11; Fri, 18 Feb 2005 13:10:06 -0800 From: "St. Esperanza Osp." To: simple@ietf.org, simple-admin@ietf.org, simple-archive@ietf.org, simple-web-archive@ietf.org, sip@ietf.org Subject: Prompt V1@gra, X@NAX, Valiu/m/ Date: Fri, 18 Feb 2005 13:10:06 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=0UM_08T0919RP_04O.814H78D0" X-Priority: 3 X-Mailer: HGLRU Mailer v5.1.4 Message-Id: X-Spam-Score: 23.8 (+++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 57b3d456dc4730784e7070d5c6b7d14f This is a multi-part message in MIME format. ------=0UM_08T0919RP_04O.814H78D0 Content-Type: multipart/alternative; boundary="----=0_00DM_08X5778PD_07S.018V69H0" ------=0_00DM_08X5778PD_07S.018V69H0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit http://dtecnxth.becaibba.com/?oZqHqVUpYYvc4oomkrhmbwo An inconvenience is only an adventure wrongly considered; an adventure is an inconvenience rightly considered. Books are the shoes with which we tread the footsteps of great minds. There is more stupidity than hydrogen in the universe, and it has a longer shelf life. I would like to believe when I die that I have given myself away like a tree that sows seed every spring and never counts the loss, because it is not loss, it is adding to future life. It is the tree's way of being. Strongly rooted perhaps, but spilling out its treasure on the wind. The problem with the world is that everyone is a few drinks behind. When I read about the evils of drinking, I gave up reading. Distance between two hearts is not an obstacle; rather a great reminder of just how strong true love can be. Too often we give our children answers to remember rather than problems to solve. Not all chemicals are bad. Without chemicals such as hydrogen and oxygen, for example, there would be no way to make water, a vital ingredient in beer. Touch is the most fundamental sense. A baby experiences it, all over, before he is born and long after he learns to use sight, hearing, or taste, and no human ever ceases to need it. Keep your children short on pocket money - but long on hugs. Before I got married I had six theories about bringing up children; now I have six children and no theories. If you ever reach total enlightenment while drinking beer, I bet it makes beer shoot out your nose. I'm living so far beyond my income that we may almost be said to be living apart. I feel sorry for people who don't drink. When they wake up in the morning, that's as good as they're going to feel all day. Always remember that I have taken more out of alcohol than alcohol has taken out of me. When ideas fail, words come in very handy. Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Love is always bestowed as a gift - freely, willingly and without expectation. We don't love to be loved; we love to love. W hen ideas fail, words come in very handy. While we are postponing, life speeds by. Luck is the residue of design. Grove giveth and Gates taketh away. Very little is needed to make a happy life. It is all within yourself, in your way of thinking. Obstacles are those frightful things you see when you take your eyes off your goal. God, please save me from your followers! It has become appallingly obvious that our technology has exceeded our humanity. Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. While we are postponing, life speeds by. Obstacles are those frightful things you see when you take your eyes off your goal. The great thing about television is that if something important happens anywhere in the world, day or night, you can always change the channel. I would have made a good Pope. I feel sorry for people who don't drink. When they wake up in the morning, that's as good as they're going to feel all day. Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. Forgive your enemies, but never forget their names. It is better to have a permanent income than to be fascinating. Reduce the complexity of life by eliminating the needless wants of life, and the labors of life reduce themselves. I'd rather have a bottle in front of me than a ... brain operation. A happy person is not a person in a certain set of circumstances, but rather a person with a certain set of attitudes. Try not to become a man of success but rather to become a man of value. I begin by taking. I shall find scholars later to demonstrate my perfect right. Love takes up where knowledge leaves off. Love is composed of a single soul inhabiting two bodies. I do not consider it an insult, but rather a compliment to be called an agnostic. I do not pretend to know where many ignorant men are sure -- that is all that agnosticism means. Always listen to experts. They'll tell you what can't be done, and why. Then do it. The quality of the moment is mor e important than the number of our days. Many a man's reputation would not know his character if they met on the street. When you're in love you never really know whether your elation comes from the qualities of the one you love, or if it attributes them to her; whether the light which surrounds her like a halo comes from you, from her, or from the meeting of your sparks. My advice to you is get married: if you find a good wife you'll be happy; if not, you'll become a philosopher. The instinct of nearly all societies is to lock up anybody who is truly free. First, society begins by trying to beat you up. If this fails, they try to poison you. If this fails too, the finish by loading honors on your head. Hope is like a road in the country: there was never a road, but when many people walk on it, the road comes into existence. When solving problems, dig at the roots instead of just hacking at the leaves. I do not fear computers. I fear the lack of them. Yesterday is a dream, tomorrow but a vision. But today well lived makes every yesterday a dream of happiness, and every tomorrow a vision of hope. Look well, therefore to this day. We have art to save ourselves from the truth. Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Hatch a dream and then believe it. The opposite of a correct statement is a false statement. The opposite of a profound truth may well be another profound truth. Education is a progressive discovery of our own ignorance. Try not to become a man of success but rather to become a man of value. How wrong it is for a woman to expect the man to build the world she wants, rather than to create it herself. The game of life is not so much in holding a good hand as playing a poor hand well. The true measure of a man is how he treats someone who can do him absolutely no good. Beer is proof that God loves us and wants us to be happy. I heard someone tried the monkeys-on-typewriters bit trying for the plays of W. Shakespeare, but all they got was t he collected works of Francis Bacon. Egotist: a person more interested in himself than in me. You can widen your life by yourself, but to deepen it you need a friend. Each encounter that becomes a friendship turns into a lifeline. One can never have too many, only too many to properly take care of. There are people in the world so hungry, that God cannot appear to them except in the form of bread. Thank you for sending me a copy of your book - I'll waste no time reading it. Everyone is a genius at least once a year; a real genius has his original ideas closer together. This book fills a much-needed gap. You can only find truth with logic if you have already found truth without it. He is one of those people who would be enormously improved by death. I've had a wonderful time, but this wasn't it. Fill what's empty, empty what's full, and scratch where it itches. In the End, we will remember not the words of our enemies, but the silence of our friends. Reduce the complexity of life by eliminating the needless wants of life, and the labors of life reduce themselves. I think 'Hail to the Chief' has a nice ring to it. I do not consider it an insult, but rather a compliment to be called an agnostic. I do not pretend to know where many ignorant men are sure -- that is all that agnosticism means. Victory goes to the player who makes the next-to-last mistake. I am ready to meet my Maker. Whether my Maker is prepared for the great ordeal of meeting me is another matter. Memory is a child walking along a seashore. You never can tell what small pebble it will pick up and store away among its treasured things. Opportunity is missed by most people because it is dressed in overalls and looks like work. The quality of the moment is more important than the number of our days. The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'. Yesterday is a dream, tomorrow but a vision. But today well lived makes every yesterday a dream of happiness, and e very tomorrow a vision of hope. Look well, therefore to this day. Nothing splendid has ever been achieved except by those who dared believe that something inside them was superior to circumstances. Don't be so humble - you are not that great. I find that the harder I work, the more luck I seem to have. Education is a progressive discovery of our own ignorance. Friends are as companions on a journey, who ought to aid each other to persevere in the road to a happier life. All love shifts and changes. I don't know if you can be wholeheartedly in love all the time. If we had no winter, the spring would not be so pleasant; if we did not sometimes taste of adversity, prosperity would not be so welcome. Touch is the most fundamental sense. A baby experiences it, all over, before he is born and long after he learns to use sight, hearing, or taste, and no human ever ceases to need it. Keep your children short on pocket money - but long on hugs. Wit is educated insolence. It is much more comfortable to be mad and know it, than to be sane and have one's doubts. Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. Compassion alone stands apart from the continuous traffic between good and evil proceeding within us. A clever man commits no minor blunders. Compassion alone stands apart from the continuous traffic between good and evil proceeding within us. Before I got married I had six theories about bringing up children; now I have six children and no theories. ------=0_00DM_08X5778PD_07S.018V69H0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 3D= An inconvenience is only an adventure wrongly considere= d; an adventure is an inconvenience rightly considered. Books are the shoe= s with which we tread the footsteps of great minds. There is more stupidit= y than hydrogen in the universe, and it has a longer shelf life. I would l= ike to believe when I die that I have given myself away like a tree that s= ows seed every spring and never counts the loss, because it is not loss, i= t is adding to future life. It is the tree's way of being. Strongly root= ed perhaps, but spilling out its treasure on the wind. The problem with th= e world is that everyone is a few drinks behind. When I read about the evi= ls of drinking, I gave up reading. Distance between two hearts is not an o= bstacle; rather a great reminder of just how strong true love can be. Too = often we give our children answers to remember rather than problems to sol= ve. Not all chemicals are bad. Without chemicals such as hydrogen and oxyg= en, for example, there would be no way to make water, a vital ingredient i= n beer. Touch is the most fundamental sense. A baby experiences it, all ov= er, before he is born and long after he learns to use sight, hearing, or t= aste, and no human ever ceases to need it. Keep your children short on poc= ket money - but long on hugs. Before I got married I had six theories abou= t bringing up children; now I have six children and no theories. If you ev= er reach total enlightenment while drinking beer, I bet it makes beer shoo= t out your nose. I'm living so far beyond my income that we may almost be = said to be living apart. I feel sorry for people who don't drink. When the= y wake up in the morning, that's as good as they're going to feel all day.= Always remember that I have taken more out of alcohol than alcohol has ta= ken out of me. When ideas fail, words come in very handy. Perfection is ac= hieved, not when there is nothing more to add, but when there is nothing l= eft to take away. Love is always bestowed as a gift - freely, willingly an= d without expectation. We don't love to be loved; we love to love. When id= eas fail, words come in very handy. While we are postponing, life speeds b= y. Luck is the residue of design. Grove giveth and Gates taketh away. Very= little is needed to make a happy life. It is all within yourself, in your= way of thinking. Obstacles are those frightful things you see when you ta= ke your eyes off your goal. God, please save me from your followers! It ha= s become appallingly obvious that our technology has exceeded our humanity= Perfection is achieved, not when there is nothing more to add, but when = there is nothing left to take away. While we are postponing, life speeds b= y. Obstacles are those frightful things you see when you take your eyes of= f your goal. The great thing about television is that if something importa= nt happens anywhere in the world, day or night, you can always change the = channel. I would have made a good Pope. I feel sorry for people who don't = drink. When they wake up in the morning, that's as good as they're going t= o feel all day. Only two things are infinite, the universe and human stupi= dity, and I'm not sure about the former. Forgive your enemies, but never f= orget their names. It is better to have a permanent income than to be fasc= inating. Reduce the complexity of life by eliminating the needless wants o= f life, and the labors of life reduce themselves. I'd rather have a bottle= in front of me than a ... brain operation. A happy person is not a person= in a certain set of circumstances, but rather a person with a certain set= of attitudes. Try not to become a man of success but rather to become a m= an of value. I begin by taking. I shall find scholars later to demonstrate= my perfect right. Love takes up where knowledge leaves off. Love is compo= sed of a single soul inhabiting two bodies. I do not consider it an insult= , but rather a compliment to be called an agnostic. I do not pretend to kn= ow where many ignorant men are sure -- that is all that agnosticism means.= Always listen to experts. They'll tell you what can't be done, and why. T= hen do it. The quality of the moment is more important than the number of = our days. Many a man's reputation would not know his character if they met= on the street. When you're in love you never really know whether your ela= tion comes from the qualities of the one you love, or if it attributes the= m to her; whether the light which surrounds her like a halo comes from you= , from her, or from the meeting of your sparks. My advice to you is get ma= rried: if you find a good wife you'll be happy; if not, you'll become a ph= ilosopher. The instinct of nearly all societies is to lock up anybody who = is truly free. First, society begins by trying to beat you up. If this fai= ls, they try to poison you. If this fails too, the finish by loading honor= s on your head. Hope is like a road in the country: there was never a road= , but when many people walk on it, the road comes into existence. When sol= ving problems, dig at the roots instead of just hacking at the leaves. I d= o not fear computers. I fear the lack of them. Yesterday is a dream, tomor= row but a vision. But today well lived makes every yesterday a dream of ha= ppiness, and every tomorrow a vision of hope. Look well, therefore to this= day. We have art to save ourselves from the truth. Perfection is achieved= , not when there is nothing more to add, but when there is nothing left to= take away. Hatch a dream and then believe it. The opposite of a correct s= tatement is a false statement. The opposite of a profound truth may well b= e another profound truth. Education is a progressive discovery of our own = ignorance. Try not to become a man of success but rather to become a man o= f value. How wrong it is for a woman to expect the man to build the world = she wants, rather than to create it herself. The game of life is not so mu= ch in holding a good hand as playing a poor hand well. The true measure of= a man is how he treats someone who can do him absolutely no good. Beer is= proof that God loves us and wants us to be happy. I heard someone tried t= he monkeys-on-typewriters bit trying for the plays of W. Shakespeare, but = all they got was the collected works of Francis Bacon. Egotist: a person m= ore interested in himself than in me. You can widen your life by yourself,= but to deepen it you need a friend. Each encounter that becomes a friends= hip turns into a lifeline. One can never have too many, only too many to p= roperly take care of. There are people in the world so hungry, that God ca= nnot appear to them except in the form of bread. Thank you for sending me = a copy of your book - I'll waste no time reading it. Everyone is a genius = at least once a year; a real genius has his original ideas closer together= This book fills a much-needed gap. You can only find truth with logic if= you have already found truth without it. He is one of those people who wo= uld be enormously improved by death. I've had a wonderful time, but this w= asn't it. Fill what's empty, empty what's full, and scratch where it itche= s. In the End, we will remember not the words of our enemies, but the sile= nce of our friends. Reduce the complexity of life by eliminating the needl= ess wants of life, and the labors of life reduce themselves. I think 'Hail= to the Chief' has a nice ring to it. I do not consider it an insult, but = rather a compliment to be called an agnostic. I do not pretend to know whe= re many ignorant men are sure -- that is all that agnosticism means. Victo= ry goes to the player who makes the next-to-last mistake. I am ready to me= et my Maker. Whether my Maker is prepared for the great ordeal of meeting = me is another matter. Memory is a child walking along a seashore. You neve= r can tell what small pebble it will pick up and store away among its trea= sured things. Opportunity is missed by most people because it is dressed i= n overalls and looks like work. The quality of the moment is more importan= t than the number of our days. The difference between 'involvement' and 'c= ommitment' is like an eggs-and-ham breakfast: the chicken was 'involved' -= the pig was 'committed'. Yesterday is a dream, tomorrow but a vision. But= today well lived makes every yesterday a dream of happiness, and every to= morrow a vision of hope. Look well, therefore to this day. Nothing splendi= d has ever been achieved except by those who dared believe that something = inside them was superior to circumstances. Don't be so humble - you are no= t that great. I find that the harder I work, the more luck I seem to have.= Education is a progressive discovery of our own ignorance. Friends are as= companions on a journey, who ought to aid each other to persevere in the = road to a happier life. All love shifts and changes. I don't know if you c= an be wholeheartedly in love all the time. If we had no winter, the spring= would not be so pleasant; if we did not sometimes taste of adversity, pro= sperity would not be so welcome. Touch is the most fundamental sense. A ba= by experiences it, all over, before he is born and long after he learns to= use sight, hearing, or taste, and no human ever ceases to need it. Keep y= our children short on pocket money - but long on hugs. Wit is educated ins= olence. It is much more comfortable to be mad and know it, than to be sane= and have one's doubts. Programming today is a race between software engin= eers striving to build bigger and better idiot-proof programs, and the Uni= verse trying to produce bigger and better idiots. So far, the Universe is = winning. Compassion alone stands apart from the continuous traffic between= good and evil proceeding within us. A clever man commits no minor blunder= s. Compassion alone stands apart from the continuous traffic between good = and evil proceeding within us. Before I got married I had six theories abo= ut bringing up children; now I have six children and no theories.=20 ------=0_00DM_08X5778PD_07S.018V69H0-- ------=0UM_08T0919RP_04O.814H78D0 Content-Type: image/jpeg; name="mwkxgmg.jpg" Content-Transfer-Encoding: base64 Content-ID: <870983c4d3c0$2180fea0$246aa8c0@JPTAP> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAACQAA/+4AIUFkb2JlAGTAAAAAAQMA EAMCAwYAABD9AAAnuAAAS5L/2wCEABQRERoTGioZGSo1KCEoNTEpKCgpMUE4ODg4OEFERERERERE REREREREREREREREREREREREREREREREREREREQBFhoaIh0iKRoaKTkpIik5RDktLTlEREREOERE RERERERERERERERERERERERERERERERERERERERERERERERERP/CABEIAfQBTgMBIgACEQEDEQH/ xADVAAABBQEBAAAAAAAAAAAAAAADAAECBAUGBwEBAQEBAQEAAAAAAAAAAAAAAAECAwQFEAACAgIB BAEDBAIDAAMAAAABAgADEQQSECETBTEgFBUwQSIGMiMzJDRAUBYRAAEDAgMFBgIGCAUCBwEAAAEA EQIhMUESAxBRYXEiIIGRoTITscHw0UJSYgQw4XKCorLCI/GSM9MUQHNQ0lNjg5OjwxIAAQMCAggE BQMFAQAAAAAAAQARAiExQRIQIDBAUWGBIlDwcaGR0TJCA2CxweFSYsITU//aAAwDAQACEQMRAAAA 6dxLydiuNIRhsFkJBWHVkvyx7ultsqtJvNSsWlVMhYakCTVQgatyVV7DKmDN1HGLUtOKOoeGPpZp iO+oydqdJVDmLOZtOnOnb28pS8m3hNkZpOQU0Qq3c/CiTPfnl79UW1yVB8rsgBzdjOuZel6pEEly dXX7C5t7F5W7OiKS/ATdF184h1khE9UdMhZdnmKgp1OgddoSegTUvJ1ippIINPLTauSiMLOS/Oje iURn1Rjs1Yyj6UUsDcaljKnZcLmaNSAwYuQqCs0oRLpN8XQkvvRNpZhTpmcNgehCpMclaUUnokhT 8naaiivkbnP4zfCGGJrZezidFmIoc1pq1jTWzLudzph1C6lwQoF0UQh71DU6qMaReRHFUraEWPVW HUNzWJ59rCD55OpgCJ65ARaWpWs0r6dpOT+PuWDukGnGHSLU4wgTZnJNAcGxNhVU06zFoTFqKTBJ hIkSIuoEZ2IydiEpEsrcrs5HaBgSOw2mGA5lqkzK/SuncFCTxdyuBUaEMhdiHKm116MvJWixrcj1 zMJcyZegfmYtdaLnYp0R+M6uZNLmpW9HPk429lkX+QY7V+Pa3tee2+NNuvjlvW2CsPWbs6pt8Y1y 0dcKgpMhbVc53CwDebtuyydLI/P7jTXFk6h965t+ohHI9aK8zy1Xsw28mXqlXGafRKXhuvmVjns3 tAunLNpaVp+d6pZ58hDrh2vzXXNJwz9bidNU2mbryzp2q8rZ1mprkN2khSCmXGGCasWskx2V7guy 4buIcuWnGbmLroMnOBvvev4HQMXVgNHQUOfldde3P1WdJqw7rqq8cbHLo4csTXSzu8wSurhzFdnp 8iixYBZo74lrEr9eQaxgIzsh7NS2TjJTVYopXJNzBu412ciry9R890sbePJ089uV3rs5OWt7c14q 50kreRH17HKy6uaZvN9thzWYTo7WscsPs46vIVuwHLzAtrIGGlcirlD15BEQdzFk5KxKBKcXliGw MeTMnb2+d2fL2uIL4GQiqynCyLqUsXeKPGTkHkw6VvZpKPXCFEGdzqvVm6WXbqVELB1iLRh15tBR uXOGYdoEJJJXnBRBiDs0dnC6Hz9rBIH50cpkgBpOJ0qhKQ5JQJT0uHlPeHZLUQkPPQYSxmq+bYz7 Q0T09ZGCzQ68nUx3LRSJJMTt1bQ6TLNgMlkasSx6XmOl5buEg/HZ0OeU08qgVTSMiT1B0tOPSZ2l h3dy8KcOe2HOqsqb1WgU7PPdMWijl05tn3cyyKZ5EU4ATPIJYgUC05DTUlmmLANnOPnXQmxNTz9L CHPKbwJYrM5dI6aNk2FWlHR0Mjc3R4ps6tgrnm3rnAmdg6+R343C1TalaqmkVgF0VM4Byow8mlQp ieCuzLMg5BJWb2LWlcrykv5W7i27DSpmkgcCxlEGwOapYXQVV5rRqj6ct2OTKb0h0q9kc3RzumJP XdkTJBjjKAi7lh0qd2kCkIkSdiKhFFKTe5qxHUxydDJ7KMaZ8TSlsqA5StVA1cBmhmtCOelqCM2+ NaOq+emFDayt4jn6GfvNdRTKSkWZMwEgjBklTvGZSKOcFmOS29SvqcO/LQ3cjUY9Ra56dzEeToB4 UDsRckdvYpU4TRxQLcBO9ay0fPeXUbLO0cSW8RpXKVlVKTKlKJYjIYKxXsBYpEpjJVGYpwezU0c7 0bQj+b0FrXiHPU+jzLMWOlR68hKzo3OI25blw9C8+NMSKxSxjBc7L0qHXmGJJdclIOdRp2qxUKOy yNkwcRQCPXsE1GQ5BkrPdnievjaWOm9Zz7fm9FudYsGCSdzjYPR8l25h1M9uvLrHx9Xh2UoPlJRR KkUCBozH3wiRlqTlGVCAYKCLF0EyQUJojEtglFZpaJXNWsWZ84yGKNl19HnL3Dv0Js21x6Xa0ed3 itCEvV5kk4tjHnNbypm4dSxGoNm2w6lEcx9ucpCJRFWEloQLBcjelx3gRth64bQCRYWIETKv1LhS s07llSJQyyZmse9RPNaVtwefuHLcfo4Smz3LOkOmRM9R5dJVD8uhhkFnQITH0xFxg3g44PZe2ar8 OtlqIQ9GQeuLER3bNbn+m5OwpJiWpcqFSISilSTWO7I27vN6PLoTJ23MNyC685qMh0oDzZDkig0q 0s7lCT0MrpBymRBKwitC4UpAtQBaedcBUbj2Hzz15RSSpwukinQnUzbHn6C5+mHPzd3ILdxrClbq dMJ4yseUZiSQzM4pxIGMMoKJai2CBsJObygUtTNq9zqrSx1KxKCIsZRNKKBSVkmbQKC6Ikc1PoKO Vaxq6N1zxt2U1zwegdOeLtMZZNFFDE6/l7KMovrLlg4VRXp4PMfVS5djbFw64ZNUMvOVulCc0+4l o17dKWMIxFFNY0ZOis1zGxfhn8g9Gruwzxq3rccFgZVphpwKsU8CXNdFzWsZrwlvE5QcuXamx35Y XVYuzm3BEhy6SeKHYrDDc5XHdos5mDp5fTjWZ25+hkV1EdiS7+c0uWNS8GxeuZojqUOnoQsVW5Em d5yxHaGE5DtOT1nMlEmsoo2Wwzt6vOus5Lreer4bEuPStKxFarmcAdnK9alDt8+vk7mJnvXUn5+p 2mpYyUq0xybhjat5errpEJ4NiiZIFrBKjIkbHVc+i5/T56c6igW6GijCsl6vMus5Trca0kzcOqdI STK7OrKudtZm/Pm4u3grFJufpss65dmk0y20mz5lr5DHULB0OmrzwnqumhU41M/E0MwEOcZmeM1y D9GyhaDNl1L1eddVynVY1oso8Os5hdSoUiaZUsvUx9caOBu4FyyT49Ft5vw9I3moPGDzEmdJGJJy 11acqNdkufK7EotoJc97sLqmjwsrwtC6cpwG3TnY6DnnjtZcTZzrq3567ZpsMtjlGQWVq4++NTA1 s2aC5Wz3sP0mrlw79ujiZdopeNfsVHHv16OSfrFLya6xHJj7BJyL9al5JuuRyC69Vxo+2VnDQ7xa xw0+2U1xS7VRxC7dVxBeyUcvd21qUM/fWufFw7dY68LHvEV7uPh+jl15/P8AV6t1+G2q6CxwPT4a 9ZuJrttLiSnTD5Kr1nbPyefHpI+Oscr18cvmjsScPPTr5cZHU7uPEjze6Py88Ni15xpdXYg4+gnp RPP+2890s4nEV2BOHJ3nTWOA1TotHzbs8UfOdafF4S5vXOjjumr6PJy/c0dODeb+k4ZkUevicNHs afZlZXVWcuK2toxX5rvqeXDz6q10ctPW1+bhQdiTYGb05eTzk/SXurjuhNb5uIs9TR6NrhfRMzDl KnT29MWp2YubnOjLd5sPdSGdIZJDpISSEkhMkJJCSQ6SGdIZ0hnSEkhnSGdIZkiSSGdISSEyR//a AAgBAgABBQDMzCZmEgATPXkM9OQ5Y6Bg0AxMQQDEMxCJiYjrlTUY1Zz4isqALPVyhqYlUwz1ks1T leJ5pWyvmZijP0kgGZAKuGHTIAJxCeIBJDOFV2CA9oHUnIM5KJ+3XM4kulRE4nmKSBXWVln+QqYT xMIaWjqSjVFg1TE2gsBWwhQoGpICghemZmZgJmTMkwnEBM5GZMyZmDv1EVfrHeYE4iEduM4icRCJ iYEHbqJk4U5+goYQRAcTkJyELAzkJkQsMFswGZAmZyEBycrMZAXB6iEAx1x0AgGIfjiJjEKjoAIB MAzAExFOPrYZGIO05CE5GYWnKcoJmdpkdQcj6B0YYPXH0Bcz4hOeoGYBj63HfEx0wJiAZgUCZhPQ CAZgGPr+JYIR1EC5gGIRmHoBAMwDH6LDIII6AZgUCEzMU5BGOgGSBj9ImEQqIAB0IhEBxPkFYB+k TiEdMTGPpzgcjFOf0mbJDTsZiYhWcZgCDEIzOOIBj9FjgEzMBIgbMLYhcQsTDkzvEz+nYOx6AxFz CMgjBmJjMAx9YOYTjqRmMmIREXJAx0ZcwjHRTiA56/ELEEHIPeYx1HRhkYzFGB1IBhUiCCDocsQp gGAB9A+OjLA2IDn6SoMAx0x1x+iVzASsBz+rn6MzlOUzmZmTMmA9QAIxwCc/TgTH6S/PRiwjHI+g DJYADqe31fMUY+iz4+gIBG+JnoYOmZ8zEE5DPQR/j6FJy3TMJMzA2IGB6lgIzmIe+cwCCP8AH0J8 t0JmenaZWchOYgeeSc8wNA0BIjWTkJyHVPlziZE4CcBPGJ4xPEs8SzwrPEJ4hPCs8QnjAgXEKAzx icBOE4wdpwzOMRAQKkZ7K0SWrWgRKyvh5INdeS0KzGoLWtPKs0qpWhHIoygrVrWoUEUKWdAoRAQK Fc+BS71qrV2cQNjDOyEO/OK/FS54edTBaFllxcLaVXz5PlwRsEPW/BhfiM4Zjfla7OIF3E1vwb/4 3//aAAgBAwABBQDExAJj9I9PiE56iZhMBmZnpnpnpmZ6Zmf0CZmZnaZ6ZEyJ2nbp265+siYh6GZ6 56Zg+rPQ/R2hAmJiATAnETAEwIRD2g6GH6TMQDJ8JENUsAWNXxXxHHhbLpwgqJIqzK0VoKcylQ0Z FQlKw1icT15CZzFYqfI0FjCMS05thrGaeRyxOT5WAe0kKxSeRsKxSCx4HILWFlPUwHEBz0ReUWtQ bOIAqyVrXlXVzgQcVUENUFhr7LWHhAVWGYfqU4OYrlTzbJJM5tkOwIsYTm2FsKKXJAscEWPMnEYY P0HoO/15hOJ8wCAQwnEJz9antmZ+gnEJz0A6ZhOITn6/mKfoMzD3ggGIB0JxCcw/oA4gOemYTmYg EYYgOehMJz+kBMwGEzMBghGZnBDCFgYf0QMz46/MAzAIBD2AHI8BCAIf0VGAVhGJnoGxC4ELEwsT FbE5wnMP6CjJAhEIzCuIBmBYFAg6MOp/Qr+ZiER2gOIDnqTiE56n6CMQdQcRXz0ZsAnPQHEBz0Iz CMdMz5nHIIxAMdB0PQHBBxGOT1BxAcz4Bh6DABYQnMJ+g/PQNCAYRj6QxEJzCfoz+iDiEZhGP1cf R+5MAmMTExMQjqSTFGYO3TPXJmevwFH1N1GIvz9DtxWt2ZpiYh+QO30fEJz9CfJEA6tezCkfyxMd QemOmYRM9TE+fotReNI7wiYEx0B65hMHyRiE9E+fou/wpB6ATE8YnjnininiE8QniE4YhEZYQIEn Ewqet3+NIJnGeQzyGeQzytPK08rTymeUzymeZp5TPIYWzA5E8hnMzmYWzGAaCwieQ9Mmd4MzvMzM yZ++e+ZkzM/bMyeuZk//AFn/2gAIAQEAAQUAAgMBnzMZhEzATD36AYgGYBMQjMKwCYzMCcZjEAnG DtGEAxAIDiCAdCMRVgGYZ3g6WOta7Ww2y5xXGtzdnEBzMTMJxCcQHEziGXr5b9TfVEt2665s76NX p7qrZ+Qqi3o6fkKTKdhbZsDy3am8iIbq1Rd6om7droNO5Vc2yvlv1PYIlb311qvsaM37NdAq3abW R2U179NrdoBjrjp7Ld8zGwyxuM5/zAJgSBMgjECiePMFbLCjGCvAsUrs6d96mizhuCx9iu5s743r jaG57Z2rnNd7Lt2N/v0Nq5n0W57Ce0JmrusuvpBhZbn7jTvvUnzDY1WBr19mz7a1b3sZa31da7yX oTjP0e03fGvzGPCOczP8h2hOYDmBegOIDCZnE9h5kc27CslV1I1dez7c/dG3Xrv4Kblc7i+XUu8+ xvrcJrV311a9V6hq7WOzTs+P19ZA9j5q2NuwrVV3UBm21roS+upTZYLKb7LKRs1W1NyXPXd2hrI7 G1mPAO+Za+YD3BIgMzmc8QvAxhaA5hJhXkG1FiUqAtYQtUpIoUSzWSwbPrix0dQVQnIWoKVqUFtZ GPgAFaKksUOPslMTWVQdJSV1gs+zXP26mfbrFTiO8zLLBWu1sNsuSEFj5lrwoxP78BAsKThNx2pq sYaWx92GlOwtp27nrXacaTGtNa6q9XP3fMVWLctzpSrbZQLsoy/cmHYqWv7oiG+vx3t9w3r7VBtv SkfehJspVdfobnHW2Cl1nr7fJTbtLW+5wtWvfyD7FKxRs+Zh7Sub9t2yAVAsfMd8wjEtswYDMk9A cz2WDq+zoxfsrm99sibrCzX3df8A7G0S+zs3Gyn2Oywv0N1rti5ib9eyznS3LerssiWp9/rWPNax Tt6hsY+t7WbFjizWbx2eusDPpWOmg6EJ6g/673cVWoTQNdjXeyGq2201X7IexrPvXtXwsx5QnEc4 lj8nxOQED5nPIBllS2rt6t9lllN4WvXsew0Cyna1Nm2ymjYGx9leJbRsA+v1uDewDBW3bq7NLOzL U2w9OieNibXLW0iEZdtT6miyo72s1herYaHUuCVa19Vd1e01Xq0KLv69qtfVtvXZr7DLbRsBtraO tVQpztbVjMhOfmMcTYtxE7tiG1hEtdiARDZiC3AJVocYrwIWIDKpmMlwDBUGHFa5c6WLd6+gtp1r XMJZBxEfxmVsghStiq1qeSxqa2IrGPEoB11MStVhAM8NcNaANVVjaqrNn/GGSccQnEtfEtbmah/L IhKiBmMKtxRuUNeIVAhXMUYjHnBZiF+M54hv7B8xkzFQAMoSLaRAeRCZhSDMEBijuIcmANPmZxAZ 8z2W3ksxExiEZhGI3abFkMqH8ojZidobFEBUwkGPxVa9mi423or021PLrK6hvb71szLyuuqqlVlb h9uio2X00qbEVRalq0bFdpEOzUjtt1VH7mgNTfVsBRiWe3YWPfWiU31XgnEu9rZZND3fObPt7g1e x5Fr2OVrWlrWMY4lr4FjcjKxg5ENQgOIQBCCYgxPceQPsbJC7u2xO5ZZQbduzYv3UettPLSzbtVv WBlcWPSEubl96a6Us4rbuu80dr7mr2FhW321xDbFzMdm27UsVxtV212WXI7Ftiy3StpuDpxdn13V Vqya1QuwpurmuQqhgyuZsPD3gErHTJaKeEBzM4hbM91VdyvGxat6XPb7Su1n2ababNg7Ns0rCR7C vb5a+vfaWO0X9alnls1L2t3dO29Rr3OdBSq+317lt2W2rhsWHma9jdf14wPZUbOvsWa2zWPDsbra Qyuxr7Xr7NdcljfUdes1i60XXbVnBqSwSxsC1sw/IETscxPbWRPbGU+wqeIAYWwWAcHVWLqiClQG oUAaak0qK1tVbAmpXl9ZHg01BuoRxXWAr6QJSrxx6uYXSE2PTFb6dXAVQktq8oGuoH2agoAgegWh vW1Gb/rnolDq0sBaEEBhiWNmOeijEU98wwOojW4mp7G3WOpvV7YAmRAYBL7q6JRtU3Hc3gyjec0e lve2qzdoqavd17FTepdvYbzhRvUOle9RY27s3JuruOuz5FK/fa4FWzTYh9nrLL92xtx9yio6t1Wz LPZ6tZ9lePttPZ5nZoGUtyGaOcyw5jHoDiKctiAl1B4IGzFOZXa1bam0u1VnEBBiD+Vl7bF22G1W 2kw+9R4T63XWiexucWuqalj7xYbRc13apol92U27S1pP/asbOogfa2Be9ZUndvbFNmsx2nXWt1Rs 75D6uy1tGif4WNLDhmaO8cwmfuTEP8v2E2O8EBxAZ6K/i4wYRkqpM9l6y1bF0rrW2tHZe7f09i59 Ve2/obJ2tz1r7VY09tjvaF7htLaaq/V3bhZqbNlo1Nj7lgftGey6zX07DNDVvqu2PX7S7V3rdiht bQe02aO5SU1rVopVqlZ8wjMcYjmN0JhOZUhLYgMI5AL3JzM5nr7fDeCkBQwYjdx9tXkqhC1VgIiL HrWyLUih9NGJoQAaiCHVSCiufb14ehHrr9OmvYukBK9RVj1KwNKkfbohtrVheqoLSMg5h7B3yXMc 9CYicooCzMUwGWjAEQQHE0rvJUo5ACYBnDEKTDCFGBIIg7QnMJzCwMJAmVEUqZhRETmUQJPiEwvH eW2Ym1bmOSYDiWWwnuz5jHMJzAMxTiZn7CGAwpgntAZ6q/FNd2YHyBZBbiK+YSADZiB8kkQuphAA DgQHMPEAAGJQXiqEEJjvHeF5c+JccxziO8JhfBJhOYTFOIHmcnEEzAMwDMc9564ysMIhzAmIRiAO DljKwSoqcQ0sZ9s0+3h1jDTYsFbvK6AkznoTiOYxzH7xjgXWZlhlr5hOJZdmVjLE5hPQGAwHLY7j t0AgMtGYBNA4toOIgzAxE5wWMYLGEFrGc3gYmYYwggKGEu3vG9NiWJnpnEL5hOYe5PabN+Y7Yl1m IFaybCBUIgQorDHUCGVjJz0EBEIEBEIxNd+FiEiIWgY5AxEGYS0AIiLmIGAKOYEwFqm1rqjVWilg cwnEYkz5jHELYmxdGOJfbwgHkJ7RwHFwCFmJLHMAzPHwBOZiVDpmFsQsTAjSunMCII44HTfmhAMA zByMUGDiYOOQeMJBgHIABZ8x0DiwGt9LY5gkTOYTiWWSy0mNLnwNvYZ3qOQ5lj8VZuRMAyaqwkuf kYoyUGJiDtMcoEgWKMRqOUZHA9U/OpAYDAMxRiDvCMQfyldPGZmcTMLYnsqfKmuzKDaDGuxH2IXz CMRzmbDZOwMPqnKMZtW5ghlCYjnAPeAZiJiKMdAMwDEBExmA9we+CZTa1JT2qCVXB1D5gsxBZmVV myIipMzIEJjPiPYTC7Kl20olHsFdWu5wBjEHGO+Y0d8zZ7PqN2sbgGOSIoyRgS4z5iJmAYg6IYDi fMJxAcwHEJYxNRniU8AOSSvcdZrOuyyaqL0xDCIRDCAJsW4S6kXQkIdewQWKIbczlk3Pit+y7X+W ocTYfMPSkQGWnMQZKiYgHTOYEJgHCZyV7QnE9YVsRKwHdFMKYgGZ6oqEEAhExiEQiERlliBo+uBN weJq71sivYIb2Wfd4lm01hc4XaHep+MtbJ6VDC5xHOZUO47QnMHQDMBxPmAQAiXNialppOvcjQWq Yyo8OviU8qm17luWGZzDD2jOBHtAhszCczbXy2DWGtDa7wpsGObREQg2fG1AYTnqowCcRjKhB0Hz mK0BzBMwnEtqYRSVlb4lOyTKrswWqRWyABuDU7AshOIbQIdgCW7oEfezDt5h2QI22MVWqhU+Zg4E Ly11wxyXm13+gDJjGGVCftB0BxFOYDAZqVeSza1Q6W1cCO0W2JsESrbIibYMGykfe4Gr2q3JZu5l m4Y+1mPt4jb2Id+VXEq92ImwBBtLDtrLL+cEc5mz1AzFHcR4YnYTMHQHMXtBBNOvgAcjb1g0elkh QiBsQPieUiG4iG0mLaywbbEZdoVxAaBFcGG3jLLgSHqYBdcwUpEAEaxXYGOe+z36AZmMRfmOYInY Aw94vzmAxTEM1U5uiYinMCB5dp5lmviWUR0IncwmZzD2mcynQ2LJR6xFlaJXCTA+AalcblFRtdCj FJwyUUIAYTk7HStc9E+T2jmDvF7AGdoOxgMBitievXCJ3iLkoMQjMv1+csp4yyrMdOBq261g0dew L6+gRakSYE/YgCA4nLMut8aVjk1z83JxK1xAYITmbEExxUmL8scRjFgHbMByQMHoDAczTOFr7BID mAzOZbQtg2NUpNu3EJnqtsVnlgF8QkmBzC+YC0yZsObG2H4A94BkgQGZmZsfFS5aww/I+T8EytS0 cFIlmTZWAoOZ+4n7jvNezEqtxEfMB6DvAcz2e4tCOeUFcK4nrdoTIMzAMQdpyxNi3xITwRzmEz4g MBhOBmXnsowHOYehMrq5kotSsnKOME/zqqM/efMAxKreMpulV2Ij5mSIr5m3trrpsXtc4GZnMAzM TU2haAcwtiG1jOZMceRbrGAMDzmBA6mBxHcYJzLu81dVbqtjTZIwx0UcpTWEVyWLpwRxlyMBDhoR gz9+OYj8JRsyq7MR8xrQk3dv7hycQnA+BjEBinBp2/JPJiB4TOeJccyxAYRiIMkhTHrBhTEEr1br ZqUNrpcnNbBglAZTVHbE1a/I+w+DrJ5LnbFE/e3swghMxmaNSvDmmV3ZG/tZjHMXJIGZnJzPiA90 OTVfiByYXMUR4YYBiF1Ea0QuTPX0+RwcQtmZzNsLhHlTYhHKa2p9tp7D5GmOM2AUrY46bBmZnPQT Vt8dhAMspIlrEuTmA4hM+AO8BBOITiKIlhErcPGMY5jGGWAmY6AEylFoQ7SCfkFLNtPbGQCA4Zzg 6yZb3m4hptOYleNbafnZYMzn/G8/TmaGx5EIm7q+WFGQg4gmcQno54xRAeMBxFOIl+IXzCcwnMKk zhkHXQkV8CQSeMCKk44IGQ4wWOZpBOOwGWEFmLqLAeTccz9rjk/TUWDDbbhrbA2Fv1VuF1L0t8zP QHjFGYBmH+XQnEPaA9y+SMGA5grZIXEx2IBgOQqYiahshRkLVEwVkSqohNq3E0Bl3LLWey9Nh+b/ AEAZnq9ambmi2uyE02VbavLUFg2NNqugMxmHvCcQDEAmIDkjtB3JOIteCEBl1eZUcQHMAxBKrLCd irg9SDybe1VqNsbT2sTmCvxVWHyOxzPjoGIhOYegxEfjE2Skp9iZtJTZWrYlF+AOJGxq4mIDAcQD p8TOITgKcxDmCUWdhaMNycMzEg8iigQFVB2LbinradelbOA2LebEmadak2uwVEzGXEYfR+0zMzvE cpDsgrQfKra1wn2+0AdTfM/EbTQelvJX0dkX0ZEHpEn4WubVJosJixBgDvOwJYnovNzr6DmN67Eb StErsbTW7bd2F5WM3OV1ta38eLvzZdzhDtEw3Znk+j1ddVl2zRRTNLTQjcuQQTU08AGAw4MJtwrW Q+WBbo1dhnhsMrQqPak/cE5nwB2i/PX1lSfbmlMHWzDruI9brHrRo/rtZ4/p6zB6eyoX6V6mytxC hhGIRMTGJiAZmmqi2tG2LNu7wpNHV5Qd/pz0CnHX3IHnzAYDgIe+vrPsMfTXEWVPU3rP/NaFM8fC L5IrvnzIx8dTn7ZBDr4BrKxgMbNesZuKEsJmZmA4gaaz/wCzRArS602trVeV5ZYtar7BGKWu1sq2 Tbbru/j8qYDQjoTPdH/eO8E7TODq7J1np9hrMns9qq8esP8A1reQFmwWV7UB5KsVeUZVgQNEBUT2 P/GzGbf/ACEdCJxMCkzWQ+TZ/wBVOJ6+vimJ7AZs44j2cb7UZK9U52qNZr6tRqnb7hwTuYFe4LbA Mz2NrW3AwGDvMcIevrDnWcEwM4FYS2JQKzbS7Qq6lthgVfkBu1537VdSnGbR5WETBgEEBlZPJ73f pqjFc2aUuQa7sG1ai/21TL4KFPg1uOrVVWBr1w1qYuonkxie41hRd8REJmQszG+enrP/ADQJkYUR gDDWJggAtFxxPy/+N/d9gf7JiYExAIg/ldVWrTTPKuFcjCqcISCogcQsZxgQmCsCYhnva8uFUQjM 4TGI3z09Z/5scYT3+kx9Oppu0CgXAM92GfjOIgExiARTgk56eutAPE9Gr5QUgEUiLQBBQuMYljYU uywMDNz2K1Tbd3rBzB3hGAwh+YO89X21s4mf0PaS5u7/AOWZmEYmAZxi19yOgyJqbwfpgTA6CZmY 6hxcNagW7haEASwZoZMRWxAcxzB3mIJ6w/8AWOMqHilszP0GezPeyyOcsTO8BBh6AwzE+OlO7ZVK vZ1tEvrefMxGsRJb7KlJb7G22FMRnz0b/jIzGTEyRPmBSBiE5nrP/M8PeAkQM0NuIHB6me0/yvpN QI79+gEIExmAQ2ieUTyTyCG4Q3iecQbTCHZsaeRzM2QPcJxsnGycWE7iYhEdIiZi3NWvnzOVRHr9 6iqnzLaOGQf4jixhyAWgXMAxDN7vduNmEEzHTjmBMThAkxAMQDM4TgIKxAgE4wKBAJxgAM4ZhqzD TDURChmMQjMKZhWBSYECwqTACJVu31Sr3d6Sv3lRlXsKLRnnMFSO/T2ZIe1i0xMTECGCtpwaAOJh 5/LALQMZyMDTmJzWclnJYWUgACdplYCohYTIhwZxUz7cRqCYKnBWkieMwIRPHmGnMFU8IlZeuVew vrFXtzK/Z1WT2Vq2MwLQ1mGpp4mnq9FLl/EVz8RXPxFc/EVz8RXPxFc/EVz8RXPxFc/EVz8RXPxF c/EVz8RXPxFc/EVz8RXPxFc/EVz8RXPxFc/EVz8RXPxFc/EVz8RXPxFc/EVz8RXPxFc/EVz8RXPx Fc/EVz8RXPxFc/EVz8RXPxFc/EVz8RXPR/4bPtqddqPe61rbnsU1Wb+x0rE/sevYre/rUeu9xR7E 7Xtq9ax/7DUgH9k1mSveqs16veUWR/f1pNf+xa19v/6CgHc301D6/wBpVvzc3V1F0t+vdXV91Rs2 7PtaNc0e91rG3PdU6b7fsa9WU+1ou19D2lW821u16op99r2Pt+wq1Jpe1o3Gu99r0ts+xp16dPbT cqmz7amhtb3Wve+37NNWx/7NRXG95Th/7Nr1z8lT9tq3nW06KRvPt6tdc9lczqPBx9f6rX3qLNfG 16fQGo3svSU7r6tH3F2zpJqLre3Kamtdza0o1nqVobZ2LWdd32jWr/WLSr/2Sw10+o9kdbb09lqL 6kO9bv8ArvtEvsfYo2fYWWjU22p1/wCuFlT+y867bONz7drbG4AdPeutOBZZtj111Vi+0vbX1aaf v339A6c2dx9lM6+PYKKTnXwtCfYaWv8AdamptHSt2tkGbn8KajqcP69fXcl7D8lpAcJ6xg23/ZiF TX9dTZqaOAtR1+ejsa1V9f8AsijzT+uf5/2khdavW56egovv1dltK/2nuBtK2s1Gh6vFu7u/6G9H Txr/ALSHW/etoufYDam2ln3u7vCqijxGqr1O7Yu7vUnd1NLbOld7T2v3s9hV9uNb01Fo/sSmu7W9 NRcF12FHo/8AD2PqadyU+lWk2+lpvRv69SD631/2k2fS67W61fjWH0mvTZt+ro3K9X161qPR69TX f1zXBo9JXS9fo6ainoqapqeor1G3NGndq1PWpQB6Gmi3c9RVtLT6RaGq9enjr9HVr2bvotfYbR1T SNzUr2q6/R1673epq2Ktb1C0Hf8AT1btb+qrvq1fSJqPSnBfY+op2zR6VaDd6Oi8aWt4R7H1Ovun S1vCJ6P/AA69v0e07fodv0u07de31f/aAAgBAgIGPwDUc4aGbTlx05cdJbAtspAXIUjEZe1m4ldg Zoy+JTxochBPPzigRHK0a+tPLqZZ+1o+tU0qhgBanFSkeh6KXbmBiwNKFZOUQ/Fr+QpGUM1XjLgP 3os5rWVOD47ARJqbJsUIk1Nk4PTTRgFWiclA8aozuBwRJ+Gg/wCOKoVUhtaMhg79WUcwHafq4qMh YOD7L8eBi7n1dPK4DPT5fui7F4sKhxfzRCgkMgFcFlpMZctcEY0kDERBOHm6yC7BTYZTIAN1upBg c0nEuC7cCC3HkiQAHkC1KemDqJ+/MSObqIgLC9PcFAG+zrsHO2prgrnsaaaaKp9Vtd9Q7idjXda+ BA6zhPuT6W29dFNyfw2oVNNNwfcWKfTTZU36iY+CN4HRV1W3V9o2yG92VArK2o2iusBr4rFYrFYq 5Vyr6bq5VzovoM5lox4KEYEtLjghmExXFkMuZyAQ7YoylmeN2ZZ/xAmpUx3HK1meqlHujlAuzuV/ 0P1HBH8guDb90TInKACeqgYyOWRIrcFA/eSKciWX/MGjs6ao7TKQNw3zQr2kRI41LeyH9xr0w+KM 50iOCgYE5ZuOYZR/G0ou92/hRiIzDnFvZShIZoyuFGTdsLB12xIPMuo8ogfBSj/cGUYD7X91PNGk yDQtZSyBna5exdEHEjoyiI3jLN7MpZovGTU9LKOQNGJdlKfEM3BCbOhFuwRMWxrzQzfSGDckQRUv /DfBqKUJDNGSGUNGLsPUMs17+4bd/wD/2gAIAQMCBj8A/TlNuyFWcE1wZA5u0jM6hlq4d+qzk+1P isz0cByOPnksv3GRAHpcoPjyZRD/AFDMh3dxjmAUjLCLps3c2YR/qpGWAxt1U5ZaAxAHrj8lP8Yr JyI/6qg7RTNx5/LlrZhdNgzdCg1gGbku7CyyxYcWxRBxqUJvUKwHogA1AwpgoxjhERfHmi2IYpuT Pi3BFrG4KJoc135WRl9xxQieXtbYHAAOVmPdHKZDpxUcg+qrqMQe6Yfog5cMS2NFQ8fbzgnP/m/u pSkWEW90ZGXaBE0/yQkS0RAEsOJKMgewclIXOa/KuyeKd8G6IPhZCT1FlmFD6K/kpnwy9FKIvJkX P1X6K+DdEa3wwTdfE23x94p4JXda7m240TaX8IqnHhDbr6p9jXWMuCrw3QxOKO6OBVSO6fBF9vTV 6hE6+CsFgsFgsFYK2mwVgrBVTAD9A//aAAgBAQEGPwDs07NdjbGKqm212V2htle0/aMpUAus2GA3 BVuond2KbabHC09KRkImOpI5ZSjUGDViQcSjDUMjllOJkYzkABIs8mIs1yg5JzVjkjKbgY9INKhE aUpAm0ssgDvAkzOz4u6m8dWEGgIw1s8p5utyATKTEDD7pVDInEDTmSOYEXj3ss8ZAx3qpk2EjCWU 8izHuKOR3jcSjKJrwkAVp6ZMhGQmTlkY2ytWJBxRhMyOWepF8s5sBOQGaTHBvUV7mYZL5nogHMXs ZwlEHkZAAoiZLgPJoSkIj8RAIj3sskSczO0oyi43jMA45LT0yZCJjqSOWUo1Bg1YkHErLqGRyynE yMZyAAkWeTEWa5XuTkBE2O/lvQBzQfHU05wHjKICB1Cz2FyeQFT3LICRI2E4SgTyzAP3LS1s0s09 WcZPOWVuv7L5RYWCEAS8vSTCQieUiMp8U2HayR9MfM/SyaKrdOqqqp2KbLrTa+TV+OmozlMkSmYS gwYdRFKO4xrvopQj6YDVMRuf2y3i5717upOR6nEKCAaWUYPbiyHD2f8A+ylISyiOtDTyABiJGIJN HfqwItijon0SnGUhgWifmInuR1JEmPuDT9ogZWz5dzvjfuWsD+AfFaR/Bq/0qBMiRqT1IGDBg2cv Z36a1xspQl6dMzlEYOSPhVual/ydXRnpyBBgJg+HTGjbzI8Vrao6iIxAJxEcwB7wHXuEynMhjKWD 3agWk1/b1fjpqM5TJEpmEoMGHURSjuMa76KWn+WYygTlEg8IRkIk/aGWrtSVCwjdasZ6g1QYjNES lMYuc0t+6LANYI/mb6p9vTEjXLFov5ky8Hsvb954moztn5hso5fNQ92WSI1JyPHqmG73UpS9UaQj hGBxHP5Mq9n2oeo3O4Kq49qnYoqqGtoRzmMZxIcD1Zd5G5ZhpR9w1z5+kE45XbNxEX4oS0wdSRE8 5DCssu8inSyOm3Xdv3nUtaUCJPBovF+nPxb7W9TMo/3DqQ1RFx9kwO9vs70dScSNWUwYRDEuIyvV mMXxfdVghP8A4+pHUzDNKYkNPjL7pIFiQDxwWpqCxlEeH+KhqaMc2WM4sCB6m3kblpmMX1ITnMxc P1CfFvtDFZ/TqvIsTcSahZ9yyHSy7jKbxj+yMxy9wClDTBmJxiDJxg93I+eyGroQzGMdSJDgerLv I3LMNKPuGufP0gnHK7ZuIi/FSnp9cphtWrPdm8WRAgSSBEmU45mjYUYNU8d6GWImDGMdTTJuYgBx 3AbrUKOkdMacJeqU5e5PuJMu6tFGGpD+1GUy7hiJZuL47lpvFxHpMyRWPi742vzT9h/tH0hGUqm5 XFOmRTpyqKyttpsYpyEw2OydGMh8vNVnqEbnH/lfzQADAKioE7BPRMqBAKybY2Cdq7WG0zlYXRkb YDcE+O0E0HmexdXR9uupJ46Y/GRS9EPVKMoiMpGT9RkwJcv4Ci/swnqAUJhlA8ZSiD3OsgeMxeMg xH6uIcIR0w+pM5YM25ya7gCfrWtAZss9MNLM/X1u9cznpwbktKWjperTnmGlEBy+mz2G+pKyyEtO YDmM2tvcEhuRWbT09ScPvxEQO7NKMj3Avgs0C4tuIO4g1BWeZYW8dwxKeWlqByBGkak2tLp/eyqU pgwMC0hNnGI9JkKvgU/s6mX7zR/lzZ/4XQ1X6DYjHg134XTy0tQR+80T5CRl/Chqu8ZenLV33LS0 9TRkImbyziJiRkldpSxb1MtSEABEahEQKABhZDM7ypGIDkngPpxWbV056cfvyykd+WUiO8BH3Ix1 IjSzREgJC5qFoxaU5nTgcsb+kVqQBzJC1NTX0vRpxyjVjEtJ529Q3WK0xc5I/Be3GMp6jOYQag4k kRHea4LX1dXTaUYD2/ciHiWl6TUXxiVlhCWpIAZsjUpiZGI83R92E4SwjJnPIiRjz6qXKMDGUJxA JjPLYvXpMhhvUTKMo6cqx1Dlymj4SMuTx+ITR0dT2xV+kPxymWbydP3MqphdbygNlNj7NWX2ownO JFCJCJYhTnImkM0amlb7qXruQ0HMdKMBkjCRjzs3pp4r8tMl9QmQffGvxYSRnYxIlEgsQbYcCy1z OraYlGtnz4WwWnpkyEfbMumRjXpGDHFflZTNdQQE+MZ5c3iiY6soCABaOnqSA4nKREv+IEKeoARC YjUghyOfD4BaINm1JD9oMB5SkoahlL3JakoSjmLM5plt0itnUoyqBKUv3owgB5E+CGsZS906giRm LetsuW3p4P8AadSjEuBEziMPcLRJ8P5jvWnqmUjqTkBMGRavqGWwy8A9FMado+4YDDMRp5vj/Ed6 0pGUs+oSNR5Ej0yJ6bDKQLNuxUx/7kvktecK6kNKPt9+Y+ZH8KgYzlKM4yM80zJwA+atq0owqpN6 IxlGP7InJh3W7kZQLSfSjI4iOWHyL97rW0xKRhGEZDNIyYnNiXNgC31qP7MfgpkExza5jqSFDlzZ RXDpAC/MQzExgKZpGTExqHNd3ihKU20ZSLacoe5nlXAAHeRmMgwchgvy+kHOmZGPVdmlE9zOBwUN SP8AqHN+WmeJoJeIflJPBsmkYx044dJEj8IgbiEZx1zpykcojLNlezCuT+ap5KUJeoHq6sz8XVbJ hZOg2x9rqUJemQMT3qPumEoxIaTdTA8qPjVCMcmpAekawdvKT86L3dSWfUIalIxHBS0pOMwbNuR9 0ws2eL5vhQb6oaurlPTlGUk4jgNyhHWMTCEPbGUl7M9g3mgT7c29MpjqHkfIhGUi8pFywYfTitMa f+pm6JGwLWPMOGo+8Fe5PQhpH7WrmhKUhupUP+981OdQZTzQlyDP8QnPtCVvdEetvD+pAaZMZROb PvOL8DuRf24E0lqRj1keA/mQGkTGUHIkauTd+f1blIj2oTN5Rj1S5nK480RMuSTIshqaUsmpENvB G4/LcpQl7emJeo6UeqXOg+aHsMBlyNIkU8Ch7JAkIxhIS9Msob6XovaidOEXrCEco50FfAIA4ADw UtTQkOv1wn6Tg+OF6F17UTpxhjCAygeAr5IRgQYA5gDKUTE8DHnw3KE5GOTTY9LhgLhv1rUkY5fc EMkSQSZYyoTcZQMaKMXHRVyHD40xqs2XREhaYj1d3T81fMTUkqqdNtfBMFdVVU8mdMwZOAFWy4qg FEHAddQTgLJOLg96eMCf3pEeDsnIZsE7OmAVRVMKKyoFVUCsuKsqJirJmRzWYu+5GWnHkZSlJuTk t3LKKkqt+yNg800QgSmxT7KKipsonF02OwEpwapye5cVVXcKngmZP5Jztp2K7PahYeo/JUuqdhht 702xtjJ5ERAuTRNo6kJS3RkD8ENM6kBM/ZzDN4XRGlOM9QXyyBIQlqSjCP4iB8VKWlqdEZREABEx LxidxOOBVKoe5OMHsJED4rNEiY3guFl1NSETulIBCU5xjGVpGQAK9yUoiIDmRNPFe5CUZAfaiQiN LUjKWOWQl8FXwXtGcc5tEyAl4XWXVnCBNhKQBWQ6kc4vHMHHcj7U4z35ZA/BVUTmhHRM5QriIkh3 sLU+K9yUhGH3iQB4p9KYkN8SD8E6EtOUoiVYx04CUm3l4yw3AMpR1y4jA6gmBUgXpZ9zM+5FtSUT TphEGMXtmJBPmOCFhMyMT4Pm+mKEATKMjlOYB62bK1DRCMDQE7vTG58aBuB7Few4KYJiulOVEwIk wpGrv96zcnMcd6JjIkxrEyy5gf3aD6XU4MDnnE1s+WPzRiZCUtMCUZgM3xQjEtOcpRzkPliHYDuF d5UoSILSHUAzuAbJ0dNsuo59w5Xk78TGm6tmU5meXUMZNEinM4FuFuVyCTFvSQRllxlmAke4De6n OFBBi3CVD/STyUdGX2JGfd9n+In/ACoHUDkx94xOJlSPhGPjIoSL5hUSYDKeHVLxpyUJt1SAJ5qc MPdj8IrWb7QH8q9iIHVqyDmorMrNmzT02MZgM74Y96MSWEot4oflzKgnLTEm+6SLPw3rT0oHqP8A bjOVcsY7ubOeKz5nnBpCYDZhuN9zLO7BnWX8vGRJEpQjGTGMNzvHDDuqpuKyjHJwGaLjw+C/Mccv zWoIljEwI/iohOXSX6ah6Dh90DybFEgCrReUsobAChd7+GKePIjceyAmTnZVcFRS1NIGUJxEZZak M6zHSIBGVoQYBvw3CBySYmErUtHG2COSEjGQFQH/AMEdXSBMScwMQ5iTw+gZDNCXUcxkRfm1rcEW T60JTlhOMRINwDHL4Ar+48QBLLmuSQ1u9SjLTJlIZXMf5ZWD4qcdWEhGccpcMhpakZZQWlNixiOK GrpByBllHhg3KqERpMRbNpxiP5Q/e5TSZwMLOpasImUJkS6akFgPk66oTJnUlu7C3kjGIeR1JZWu +Ysm1RIRfrlMMTyDDyCdkTCMiDOWpCUYv6i+478VHVAMjSXT6oyN6c3sGwT6oMYv1SnQnup8GWWQ oaLoEiwyxnAPTwLfRkTq9IMckRu49yMRGRdny2k1R9KcU0/VIvJe2LDpPCP2vH5BH7uaRjuaQPwf yRe8i/cqp+w6qK711RTE5DxsnBdfWmdXqmFllNkwKvRMyYuq3XFOUxwTCyf4plVOV7wnQSz5W4vd /kgZ4oAJimTqmwiQBCzaMiY4xKbHEJlQsnJ7IGxhbft6T04xNlQtLGJ202AakmOERU+AcpoSrjGQ MS3KQBU9USnkBbTEDKDhhWmUmrtgyMtSU2j6RmIl3y9Ra1/FZtQkvLpcuQOJ570YzJDUJyyIB5gM /B0ZiYAjfMDE14FjXBZIyIJNBKMovyzAP3KZ0ZGI07MPVLnuBpTxwXuiYymgu78rvwZZRIgm2aEo v/mARhGUx1RaWY+3EMKEel+YxCj1yc6k4yGYswlIel8vkjOVIgOSdwXqL/dMJueQyuRxAUtSMg0a yoxHMGoVZSfcdOb+GV242URGcjGU4tISlkyk+lrO1LXWWZObdEGRHMRBIWbTk7XwI5g1Cy5nbGMZ SHjEEea9zTk8TKHVA4GQBqPktQEkxBAjmkZb8S5WeFCmN+2NhgDXBcU+wSiWIQmL4jirJmrsEQTE 6k5CUhcCLsPAeNUQJE5GnAyuD5f4L2wTkEoxD3AIjw4qUIE5Q171Cyx9IOJU9OJYS1PiyORyRAEG e8mXKzU5nemlIFxXqBrw6Yt5niiXNYiZf70nJ8TVZdGReIrmwfF6MS33TayIjQGoGaUu/MflTcpP jPTJ/wAsFH/u6n80lq/9uf8AKV7c5SiBFxlvhv5ouayhqQPEZZfMOsmpIxjGL9N7jeCoxHpjqwbu lFR0jKUYmJnIwvKVN77/AAU9T3XtpkRu0yI13XfmjGJEYgARGYAd4ynyIWvpisWEw33gXPwClLfL 5DY42U7IO0Swx5qu2WmbSqOYXFWqqI6uiHEjmyuxB4HzQlr9MQXMXzSl31+KziPQZRlmccO/DcjK EXhJquNyJe+CziPQZiebMOHf5IaukQJxoxxH0+KEZPFrGWo7cmJbyQnpf3AYiMnLGmO6qd80jSUD KviTXxWeYzSND1RengPBCeXpJgSXDBhEHjhuXuGPQJyk7jEk88dy1X/9Of8AKURo3jF6SylrXcKU 9Rs5jKMI7nDIy1Ys4YVBx4IamX+37kdTM4s72v5LNoDND7LSyyj5jyKf8w0RlMYxjUucX4XxqjEB wbmM2B5hx81KBOaRMSIPRgaiu/wRjMZXLiO7wptYdqmCbYRvTHbCRs9eRTC21jZOspsmVFcJgQsx ZkzpwVcJgyYspaZ9MgYmuBROmZSehzEfIBClU5umKZOqqifHY5TdlsEw2V2ZscexGb3FU+y6p2HO xlW25MLqqfZddJ2V/QMOyybs1TG23K9imPZoqqirRMPJPtqqJzb4phbY+ynZps49oHsse5NslHv2 Mqkp3onTquK9Kqrqsl6qqiZVqfLtum2MNjBPsp2B2XWbx2Ab6IBOgBtrsurp1TZlhU/a3BCUbfPs vtYbKqlkwVE5vKgTfoWKoUxOyMuKpscFOalOqJkxTiirbZVe6Bf1fWn+zL1fXsbsOmGx1Wyoq2VF fa8r7uw3aZMoyVVSqsqq2ymym1ivaJ/WFkPqHw7NFW+xsE+z4ok7GT49qvZ6SxTSFQmf0nYyvyVU 2zKnl2c8fVCvML3fTCOJoOQ3p9r7W7GUd+1z2H2ttfbQp49667/hqhKNQbHZVYJ8N6p2KJkSLrNr SzyfpjhEcE4Pppl4YeFk42VTbCTsZHen2N+grtbb0hyn1JPwFAmC6Sy6g48CssRXiq1Pl23RXVT9 m6bTiYgXMi5P03Jpd2yiqpE7tgRPYf8ARcdlU5UiUAV022kD1O8tjpu1VUT+KYgt5gqtQqxKoFlN tgP/AELJt6eNlmeqqmThCcb7t6zDvGI/RGITk0X9uJPFPlTGKeV92wf9BXY8rqiePgrpymKZ1mgW KY0liNldlD2KGqMjde5P90blTY5RQCHYb9KCbD47Kp1xVdldglG4T/axVFdVKfZULOcaRQCurpnT C2xuCG18P0tEBimVBsdMVXsUV6qz97BdUm4RqrSkV06L9xXXo5RvIKpQYBdcHO9yrzj5rp1fEFPK QPJdPftGyn6RtlbRT7GPYbYx20VmH4k+r1HyVIsqJimkAeYBWWIZrkb1lOxgmG0bHP6V0+J2udtR ty6oePJ2WYRofulenxKaMcvIJ1ZXTvsJxw5rNK15FGQ7uWzj2m/SsmThV7DELgsuOw6UrStufY52 Mm25RYfFZBYerif1fFOe0O3TY0rITHI80O03YpsIuTYJzcp9h09WVT6X+G19lLoyP0de4L2ieP0q qWTDtg9h0wTC6cqi1Bj0t3pj2aqux9lEZHw3lPI1xXFcE5TrLL1/FNsfYYmxQgfs07ttdl1Q7RI0 NVSoVdrrimxTLU3Bq8W2kdi6qr7HJpvRl9kUiE+JsmxTJtji6yy9Xx7FEx2VTkJmVNrAeNEYkueC 4ptjpgnR/Co83RJvKRPyXh2WCqiTcJxZOLL2496rYJ05Tna+xnouCqnPd2b7c5tH47LKy/EUyMfB MpfmJY0iud1PU+7GnMqETuQB2Dsgm2KoiY3Re6ZMmVNrYrKO/Yyp3psOxTbS6yk1+1zVLJhGnNMa R3BZgnTqMjbFQ0NL0xuqqIx1J+Ij9AmwFE6fgh2sp9Q+CdZtMdWPFESodj7GCYJhfY6fFfNVt2KB CllR23IMLI1qVVyrKltoR052lY7jgssvFZRc0TfY0Y5Rzx+pGRVU2CDdp43XEb0cCMFW+9NL/HsP inOxsNoAT7GVCQnj5oZg3FUvgqJkwsssRdGEqSFCqJk8qJgpa8vTpAy78Ex9Uqnvum37cwDDssiN YeqhOIVOqGElmFvJNKkvJNKoWaNY+YVNlU2CbHbVE7CnFwhIWTFNvtzTFMduXSHUnnLNI3Lue9RI FE/5ZnIq4diiTdVUfy/2ptqanACw+ZVLYck+2ir2KJwmkXG5GcKSGGCrZVL8FSqMoW3J0yoq9lkS nCyHccvkfrVK/TwTWHCqqK2dANa6pfdgfpghK4+l17eiGenSKlH3SDrEf5fpvRIuESnKOvqejTq3 3pYBGU/9TUrLl9KLim/ROK8wqQD40ogJadRjlX+k53xCDQYtuVIxRJEQ/FXiO9VnEeKrPwCrM+C9 cvJHTOGwvsZBlXZli5Jwun1CxOAv9ScSY7iiwB5Yrpic5DZmtyRcl9lEIRuUAP8AR06/tS3/ACCM k0R3qyt2SNYAxESapowAlK/4QvclEfhDL29MAAXIA2Z9TuC4baAAv5KoCoyqQqSwXrRBLovRPsZD sQOUORU4phRUksCqgoZ4g816WJxBXRKpwKMYEEy9c+G4fWsoh0CzfFMxG/ZXtA6lY7t+7zVak1Ky R9R8hs9ydvs/oH7D/hHYCyxYNUk2RySjIjAE/UskwRLctPkhmDhMJEVxXqBXVHfZNIMeITBn4Jo+ KYB1ZF7IxjAEnGyIjQMOzZBHUkjI4oRwxTCwRlMsAqRkxxyowMSIgUlv2ammw6LcVm18sS+9ZhIN z2U2j9kdnMA4PqicVWUoSxGHkoxgTIgnqtRafJZo3GG9GYHTENXEpiHIFWwTCTYp5EMnlHwTDNEp iXOwDimsu4bG7AUYDHYZ4nZpRl6CapsFqiciIZcMOSGtpRlED7cpX7lq/iiD5IGJBMJy6ZWKnoy0 xCYrICyyARd2Bws6HSS4B8VkA2EyuCYjkE2yl1x8uxp8l0o5w/zRiI1xTwLS42RYguyGW2JWYDpG 8VKdVLMgxBTHc6J5fDtBk8pOxbZHlsyzsMdyynWOXzRlKTgxykfrWSepKUcAozJlmA9W8cVlIka5 u9E6YbeTdGl64qwXuChVE4tPq2cN6pffsO3T2OaBUDKyoSFRVCoGRR5IvfLvR7QQMAwIB2R5bGKb Lg6bLXcj0gM6sOHJEigw7UCTRj2Tt0/pit53Lj23ZuSpijkFGqpHj+h9s4223ZO9U4Jc3VHTNTY6 ckeKePkVlh1T8gs8qnNU93botNr/AK0w/QxwUzegqjz7Qfa4WTUpLfv/AEGWQcEMQusDkjDRGSJu 1yt5Un+9H5pxtYbeC0/piqllcEJj2xRTj94hE8ey6bssC43FdYMV0yHjt6pAd6ocx4LLDpHC6fUN d2KYUGyXd8VXsVVdmny+auFQU4K571VjuVaKnYDXogbu/iOy/buFfyX6lQyV5FWkV6T4pgG71YeK sNjHa42MZPwwC6oxfw+CDZgcbH6lCE5MQgYyAVgyLunLFVdXHet3ftgOSAbefHtW2NssFZWVtm7b VP2LbHKdME2yt9yqnFF0yJ5rrAkv7kTFdMk8SCCny+CfYCLhkZGrbP1plZWKo+2oVfgreSsrKyss VisfPbV1jtsmKofJUVmT9j/Hb0khM781/cimNF0mjYXW4blZWVinKsrKysrKysrKysrKysrKysrK ysrKysrKysrKysrKysrKysrKysrKysrbDAZpyFxDDmSRHud0ISzacjbOzHviZDxKEDGU5EO0Mtv3 pRCrp6g79P8A3EJQjMkkjL0OGb8TY4FOdLUb/wCP/cUo6YlGUGcSbHkSF7WWU5AAnLlo/wC1KPkn lpagH/x/7iEoxmSc3T0uMrV9TYixdf8AKi/t5TPiwU3jOJhHORICo4NI+bLq0tQd+n/uIaOWcZF6 yykUr9mUlEzhOMJENM5WrjSRPkogxlOUnIjBrBnuQMQpjTEomBAkJNjyJGCjKQlIyOWMYs9icSBY b1IwBBicsoyZx4EjzQ0YxkDIExMmYtyJPiAjCs5C8YYcySIjk7oQnm0yaDOzeMTIeJCMJxmcrZpR ysH5yB8AVEZZTMgZAQy2DVqRvUvzIcRgSJA3BGFCRjvU4QjKMoNmEmx/ZMggZuSfTGIcn6caIacx LTJLDPlYnnGUvNk0nlI1yxu3ewHeUYQeMxXJJnbuJB7imIkYi+pEDL8cx7olD8wTmhJsmX7Th6Ww qo62mCIytmodhgBKco+oQAp3kiPc7oaZeEjYTaveCY+a9rJOcsokcuWgJIHqlHcV1aeoP/r/ANxR MITnmiJ9OUMCSPtSj902dPLT1B/9f+4v+Y59ts1qrU1Y+oDp5mg+KlCUjHS0wKRuX/wJJQOhORgb 54yp3iLEclokzzH2mMxjW6eQkZYtqgP/APkfioyGeLSl9oO9PwthuC/48pSye4YXqwLcn7kZaWbq uZH/AAQ1pGcZsAchFW5gqOnqmWUgmhrbvWnGLgSGqSZfuI/lGh6JQzHUIu9WyHfvX5ki3t0/zBH3 SZbmnlb+CXyXTGYkIyMXmJC37EVDTJoAG8FHUB6hCGn+9eX04LV4mH9S0pi41P6JL3JHonSf193w dR1BeGnLLzylHTMjHSgHk15E/MlRnpmRhIkES5PwWlI3MTpE78hp5S8lCMT1iENHvF/EnyU9I21J QmP3an4RUtTHUl5R/W6jMSYT08vEZSfi48OSjHSGR8sfWT1feeVuS9qZOWWoIy4iPT8kI6RIHuZI 1sJU+a9vUDSjlHIAFx8PBaP5R2jAMTuesj3CnMEYrLoSjKEAIjIQW8FqakaSZgdxkWfudTjOUo6W mwEY3Lv9SiYGRhJ/VcENy3qE5SaXsxiTvyz1AhmjN8W1R/t/NRhpkxj7MGf9qaGaM3xbVH+380dJ j7WW2LXWpoihlEtzw81MakanpnCVLcRbwKyaZOW2V83nkitCGpQjTI73QzaUTICpOtMOd7ZUY6cM kYFmd78bpt2tL+c7YcIn4LQ4x1f6EdXI8hpylmzSuAeLLX/7f9QUvcgNQFmzTlBt9gXQjp6QjKXT mjqSlf8AaARI+zDN/lMX8nUzhAZ/MD5rU5w+a0yfv/0SUfzEA8oGWb9l/l8yvbtmhOP8JARzAZh0 zjLH6ubFRgAA1oxc1OLsO6mKiSOrTkJy/eo3mPBRlhF5/TvKlot6JSA5YeTLTjuiH5mpVfTOERGX J6fND/j6eR4xjlpWXd3cd6E9SrSjqftWJ83UZQDDP7h4AF/q70fzMox930wkYh836r8goa8hTUlI B90frNf3QVpkSfMGlxBi58D8FPTj6pDp5io81LPEOaThKlR4t4FRjEBwMsYxqz3qQHJYYBlp6RuN KL8zKZPxUSNPAH1S+tRgaH2ofzTUSNPAH1S+tGDYM2zNOAJ32PiKr+3AA77nxKA1o5iLVI+BCpp0 /al9abTjlBv9CvfjD+4TmJc33s7eSY7Pc0YZZb3PzKjHXjmMHy1IZ+RCOmYjIRly8CpDTgBGQaVS XHeV06f8UvrQnDTAI4k/EonTgBmBjKpNDzPwRjCAEZeqpL+K/tRyg3qT8V7etHMAXFSK9y9uEQIb ln0YZTzPzKHuQEiMcfG6fTgAd9z5ujp6gzCQYgp9GOUcyfi692UH1CzlzhwdlVZNSIkOKfSgAd9T 8XWTViJN9L3WXTiIjz8TVRjqGQyO2UtfuKGhOPRFsrYMiYOSftSv8AmWacAZb7HxFV/bgI8bnxNU Jasc0wGBcj4FMhqasM0wGBcincU3/hn/2Q== ------=0UM_08T0919RP_04O.814H78D0-- From simple-bounces@ietf.org Fri Feb 18 18:48:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24234; Fri, 18 Feb 2005 18:48:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2IDB-0007DP-ES; Fri, 18 Feb 2005 19:11:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2HHH-0006Lw-MA; Fri, 18 Feb 2005 18:11:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Fx0-000548-BZ for simple@megatron.ietf.org; Fri, 18 Feb 2005 16:46:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27671 for ; Fri, 18 Feb 2005 16:46:12 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2GIh-0007B2-P8 for simple@ietf.org; Fri, 18 Feb 2005 17:08:42 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 18 Feb 2005 13:57:45 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,100,1107763200"; d="scan'208"; a="615765957:sNHT21617948" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1ILjbq8001226; Fri, 18 Feb 2005 13:45:37 -0800 (PST) Received: from [161.44.55.99] (dhcp-161-44-55-99.cisco.com [161.44.55.99]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHW02916; Fri, 18 Feb 2005 13:45:36 -0800 (PST) Message-ID: <42166201.9060901@cisco.com> Date: Fri, 18 Feb 2005 16:45:37 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple] WebDAV alternative to XCAP draft References: <98e7431c35cb9031307559570a199aaf@ekabal.com> In-Reply-To: <98e7431c35cb9031307559570a199aaf@ekabal.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Rohan, Your draft makes the statement that the check for idempotency is reducing the performance by orders of magnitude. I don't see how the protocol can fundamentally cause that to happen (as opposed to some kind of implementation issue). As proof of that, let me suggest an approach that looks like it would cause, at worst, a 2x cost in performance. What you do is this. Process the PUT, and when you are done, hold onto the pointer for the object you just inserted into the document. Then, run the processing as if a GET was just applied to the same URI as in the PUT. Check the pointer for the object retrieved. If it matches, then the reques was idempotent, and a 200 OK to the original PUT is returned. Otherwise, the 409. I cannot understand how this algorithm could ever be more expensive than actually executing a GET followed by a PUT, and in the worst case, a GET should be as expensive as a PUT. That would put an upper bound on this algorithm of 2x; i.e., the processing performance of xcap with idempotency checks should never be worse than half of the processing of performance without them. What am I missing? -Jonathan R. Rohan Mahy wrote: > Hi Folks, > > Sometime in December or January, I started to hear fragmented reports > that verifying idempotency during PUT and DELETE operations in early > implementations of XCAP made the performance of these XCAP server drop > considerably. I can think of two reasonable explanations for these > reports: > > 1) These implementations where written inefficiently. When optimized > the actual performance of idempotency checks is fine for production > systems. > > or > > 2) There is something inherent about the flexibility of XCAP that makes > it hard to quickly verify the idempotency requirement. > > Currently SIMPLE is using XCAP for resource-lists and auth-lists. While > the arbitrary depth functionality of XCAP is useful for some > applications (ex: I understand that this was particularly attractive > for Joel's application), our applications don't require the complete > flexibility of XCAP. > > Consequently, I wrote an "Escape Hatch" proposal that sketches the > possibility of using ordinary WebDAV to get the functionality we are > using. I quite like this approach and if we were starting over again, > this would be my first choice. However, the working group has invested > a lot of energy in XCAP and it promises a lot of flexibility for future > IETF application configuration work. > > So, I would like to quickly find out what kind of PUT and DELETE > performance folks are getting from XCAP implementations when > idempotency checks are turned on. Folks with implementations, please > speak up. > > It would be nice to verify that everything is fine and go back to our > regularly scheduled program. If something is really wrong, I'd like > folks to consider my proposal, which is at: > > http://www.ietf.org/internet-drafts/draft-mahy-simple-xcap- > alternative-00.txt > > many thanks, > > -rohan > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 18 19:13:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29717; Fri, 18 Feb 2005 19:13:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Ibl-0000Wz-14; Fri, 18 Feb 2005 19:36:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2I7C-0005tn-IN; Fri, 18 Feb 2005 19:04:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2HTq-0008Aa-VL for simple@megatron.ietf.org; Fri, 18 Feb 2005 18:24:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20922 for ; Fri, 18 Feb 2005 18:24:12 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Hpb-00061o-SV for simple@ietf.org; Fri, 18 Feb 2005 18:46:44 -0500 Received: from [64.101.149.215] ([64.101.149.215]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.12.11) with ESMTP id j1INQ3G1025256 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 18 Feb 2005 17:26:05 -0600 In-Reply-To: <98e7431c35cb9031307559570a199aaf@ekabal.com> References: <98e7431c35cb9031307559570a199aaf@ekabal.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Simple] WebDAV alternative to XCAP draft Date: Fri, 18 Feb 2005 17:24:26 -0600 To: Rohan Mahy X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit On Feb 18, 2005, at 10:45 AM, Rohan Mahy wrote: > I'd like folks to consider my proposal, which is at: > > http://www.ietf.org/internet-drafts/draft-mahy-simple-xcap- > alternative-00.txt > This proposal must be deeply flawed, because I think I actually understand parts of it. I kind of like that feeling -- it doesn't happen often :-) ! One question: You mention the possibility of pipelined commands and touch very briefly on simultaneous operations. Would it be appropriate to consider locking the immediate parent collection before updating more than one child of that collection in a pipelined mode? -- dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From wo16281628@163.net Sat Feb 19 00:42:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29370 for ; Sat, 19 Feb 2005 00:42:31 -0500 (EST) Message-Id: <200502190542.AAA29370@ietf.org> Received: from [218.18.30.71] (helo=163.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Njl-0001sj-2M for simple-archive@ietf.org; Sat, 19 Feb 2005 01:05:06 -0500 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: =?GB2312?B?v+zL2deo0rXJz8PFzqzQ3rXnxNQ=?= To: simple-archive@ietf.org Content-Type: text/html;charset="GB2312" Date: Sat, 19 Feb 2005 13:42:08 +0800 X-Priority: 2 X-Mailer: FoxMail 3.11 Release [cn] X-Spam-Score: 8.1 (++++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 25620135586de10c627e3628c432b04a ÎÞ±êÌâÎĵµ
 
Wor de shi g wit hou
ld Wi ppin hin 24  rs
Ç×°®µÄÅóÓÑÃÇ£º
    ÄúÃǺã¡×÷ΪµçÄÔµÄÖ÷ÈË£¬ÄãÃÇÊÇ·ñÔø¾­ÎªÎ¬ÐÞµçÄÔ¶ø¿àÄÕ¹ýÄØ£¿ÏÄÌ죬×ó§ÓÒ±§µÄ´ø×ŵçÄÔÖ±±¼»ªÇ¿¡¢Èü¸ñ £¬ÏÈ°´ÏÂһ·ÉÏŪµÃÏ㺹ÁÜÀìºÍÒ»ÉíÆ£±¹ ²»Ëµ£¬²»¹ý¶¬Ì컹¿ÉÒÔ£¬Ö»µÃÒ»ÉíÀÛ°É¡£µ«µ½Á˵çÄÔ¹«Ë¾¼ûµ½Á˹¤³Ìʦ£¬ÊÇ·ñÄÜÂíÉÏ¿ª¹¤°ïæ¸ãµàÄØ£¿Õâ¸ö»¹µÃ¿¿ÔËÆøÄØ£¬´ËÇé´Ë¾°Äã˵ͷ²»Í· ÔΣ¿×÷Ϊһ¸öÉúÒâÈË£¬Ê±¼ä¾ÍÊǽðÇ®£¬ÔÙ¼Ó ÉÏÕâÊǸö¸ßËÙÐÅÏ¢»¯Ê±´ú£¬Ã»ÓÐÁ˵çÄÔ£¬¼òÖ±¾ÍÏñÈȹøÉϵÄÂìÒÏ¡£Ãæ¶Ô´ËÇé´Ë¾°£¬´Ëʱ´Ë¿ÌÎÒÃÇÉîÛÚȺÁ¦¿Æ
¼¼Ö»ÏëÓÃÎÒÃǵÄÇà´º»»»ØÄãÃDZ¦ ¹óµÄʱ¹â£¬ÌØΪÅóÓÑÃdzÊÉÏÎÒÃǵķþÎñ£¬¿Ò Çë¶à¶àÖ¸½Ì£¬Ð»Ð»¡£
     ³¬µÍ¼Û**Ç©Ô¼°üÔÂ**¿ìËÙרҵÉÏÃÅάÐÞµçÄÔ
            ÉÁµç°²×°ÐÂϵͳ  30·ÖÖÓ¾ÍOK  ÉúÒâÈ˵ÄÊ×Ñ¡

       (1)¸öÈ˵çÄÔ×é×°¼°Ó²¼þÏúÊÛÓëά»¤
       (2)¿ìËÙ°²×°¸÷ÖÖ·±¡¢¼òÌå²Ù×÷ϵͳ(²Ù×÷ϵͳÀïÒÑ°üº¬Óи÷ÖÖ³£ÓÃÈí¼þ)
       (3)Åųý¸÷ÖÖ³£¼ûµÄ¹ÊÕÏ¡¢Ó²ÅÌÊý¾Ý»Ö¸´
       (4)°²×°¸÷ÖÖ³£Óð칫¡¢¹¤¾ß Èí¼þ(°²×°ÐÂϵ ͳÃâ·Ñ)
       (5)°²×°ÏúÊÛÕý°æɱ¶¾Èí¼þ¡¢ËÑË÷¡¢Èº·¢EmailÈí¼þ
       (6)¾ÖÓòÍø¡¢¹ã ÓòÍø¹²Ïí
       (7)ÍøÂçϵͳ²¼ÏßÉè¼Æ¼°Ó¦ÓÃ
       (8)¼ÆËã»ú ²¡¶¾·ÀÖμ°·À»ðǽÉèÖÃ
       (9)¿ìËÙ½â¾öÌìÍþ¶à»úͬʱÉÏÍø

       ****µçÄÔά»¤¡¢µçÄÔ×é×°¡¢ÍøÂ繤³Ì****

       **רҵ×齨ÓÐÅÌ¡¢ÎÞÅÌÍø°É¹¤³Ì**

       *ÈÈÁÒ»¶Ó­µ¥Î»»ò¸öÈËÇ©Ô¼°üÔÂ*

       **ÈȳϵķþÎñ£¬È«ÐÄÈ«ÒâȫΪÁËÄú**

       ÉîÛÚȺÁ¦¿Æ¼¼ÓÐÏÞ¹«Ë¾
       ÁªÏµ ÈË£ºÅ·ÞÈ·á
       ÁªÏµµç»°£º13714682076 »ò  0755-83601633
       QQ£º 282079259   2441630
       E-mail:168it@126.com       Íø Ö·:http://www.it678.net

¡¡    ÍøÂçά»¤£ºhttp://www.it678.net ¡¡¡¡¡¡¡¡¡¡¡¡¡¡               µçÄÔάÐÞ£ºhttp://www.it678.net
From httpd@ws9.surf-town.net Sat Feb 19 00:56:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00848 for ; Sat, 19 Feb 2005 00:56:56 -0500 (EST) Received: from ws9.surf-town.net ([212.97.132.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Nxh-0002KA-Hb for simple-archive@ietf.org; Sat, 19 Feb 2005 01:19:30 -0500 Received: by ws9.surf-town.net (Postfix, from userid 398) id 3E3A97C3BFD; Sat, 19 Feb 2005 06:23:17 +0100 (CET) To: simple-archive@ietf.org Subject: Your eBay Records Updates X-PHP-Script: oskarase.org/index.php for 163.121.176.116, 62.241.130.137 From: eBay Reply-To: aw-confirm@ebay.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20050219052317.3E3A97C3BFD@ws9.surf-town.net> Date: Sat, 19 Feb 2005 06:23:17 +0100 (CET) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 6.7 (++++++) X-Spam-Flag: YES X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable =0D

=0D eBay Fraud Mediation Request
=0D =0D You have recieved this email because you or someone had used your accoun= t to make fake bids at eBay. For security purposes, we are required to op= en an investigation into this matter.

THE FRAUD ALERT ID C= ODE CONTAINED IN THIS MESSAGE WILL BE ATTACHED IN OUR FRAUD M= EDIATION REQUEST FORM, IN ORDER TO VERIFY YOUR EBAY ACCOUNT REGISTRATION= INFORMATIONS.

Fraud Alert ID CODE: 54585129
= (= Please save this Fraud Alert ID Code for your reference.)
=
To help speed up this process, please = access the following form to complete the verification of your eBay accou= nt registration informations:

http://= scgi.ebay.com/verify_id=3Debay &fraud alert id code=3D54585129=0D

=

.
=0D =0D =
Please Note: =0D If we do not receive the appropriate eBay account veri= fication within 48 hours, then we will assume this eBay account is fraud= ulent and will be suspended.
The purpose of this = verification is to ensure that your eBay account has not been fraudulentl= y used and to combat the fraud from our community.
=

We appreciate your support and understanding, as we wor= k together to keep eBay a safe place to trade.
=
Thank you for your patience in this matter.

<= p align=3Dleft>Regards, Safeharbor Department (Trust and Safety Department= )
eBay Inc.

= Please do not reply to this e-mail as this is only a notifi= cation. Mail sent to this address cannot be answered.



Copyright =A9 2004 eBay Inc. A= ll Rights Reserved. Designated trademarks and brands are the property of= their respective owners. eBay and the eBay logo are trademarks of eBay I= nc. eBay is located at 2145 Hamilton Avenue, San Jose, CA 95125. =

= =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D From httpd@ws9.surf-town.net Sat Feb 19 00:57:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00906 for ; Sat, 19 Feb 2005 00:57:01 -0500 (EST) Received: from ws9.surf-town.net ([212.97.132.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Nxi-0002Jp-Ga for simple-archive@ietf.org; Sat, 19 Feb 2005 01:19:30 -0500 Received: by ws9.surf-town.net (Postfix, from userid 398) id F16597C3BD1; Sat, 19 Feb 2005 06:23:15 +0100 (CET) To: simple-archive@ietf.org Subject: Your eBay Records Updates X-PHP-Script: oskarase.org/index.php for 163.121.176.116, 62.241.130.137 From: eBay Reply-To: aw-confirm@ebay.com MIME-Version: 1.0 Content-Type: text/html Message-Id: <20050219052315.F16597C3BD1@ws9.surf-town.net> Date: Sat, 19 Feb 2005 06:23:15 +0100 (CET) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 6.7 (++++++) X-Spam-Flag: YES X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable =0D

=0D eBay Fraud Mediation Request
=0D =0D You have recieved this email because you or someone had used your accoun= t to make fake bids at eBay. For security purposes, we are required to op= en an investigation into this matter.

THE FRAUD ALERT ID C= ODE CONTAINED IN THIS MESSAGE WILL BE ATTACHED IN OUR FRAUD M= EDIATION REQUEST FORM, IN ORDER TO VERIFY YOUR EBAY ACCOUNT REGISTRATION= INFORMATIONS.

Fraud Alert ID CODE: 54585129
= (= Please save this Fraud Alert ID Code for your reference.)
=
To help speed up this process, please = access the following form to complete the verification of your eBay accou= nt registration informations:

http://= scgi.ebay.com/verify_id=3Debay &fraud alert id code=3D54585129=0D

=

.
=0D =0D =
Please Note: =0D If we do not receive the appropriate eBay account veri= fication within 48 hours, then we will assume this eBay account is fraud= ulent and will be suspended.
The purpose of this = verification is to ensure that your eBay account has not been fraudulentl= y used and to combat the fraud from our community.
=

We appreciate your support and understanding, as we wor= k together to keep eBay a safe place to trade.
=
Thank you for your patience in this matter.

<= p align=3Dleft>Regards, Safeharbor Department (Trust and Safety Department= )
eBay Inc.

= Please do not reply to this e-mail as this is only a notifi= cation. Mail sent to this address cannot be answered.



Copyright =A9 2004 eBay Inc. A= ll Rights Reserved. Designated trademarks and brands are the property of= their respective owners. eBay and the eBay logo are trademarks of eBay I= nc. eBay is located at 2145 Hamilton Avenue, San Jose, CA 95125. =

= =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D From Reeves@loveable.com Sat Feb 19 02:49:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05760; Sat, 19 Feb 2005 02:49:26 -0500 (EST) Received: from 200-122-19-8.dsl.prima.net.ar ([200.122.19.8] helo=dejanews.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D2PiX-0005VK-LK; Sat, 19 Feb 2005 03:12:01 -0500 From: "Kunkel Markus" To: "Collins James" Subject: Re[9]: discussion with his tablets Date: Sat, 19 Feb 2005 01:52:59 +0300 Message-ID: <08a001c51658$366da480$08137ac8@dejanews.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_CDEF_01234567.89ABCDEF" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437 X-Spam-Score: 0.9 (/) X-Scan-Signature: 6379955759c38e2371a49573a0932fc7 This is a multi-part message in MIME format. ------=_NextPart_000_CDEF_01234567.89ABCDEF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms ------=_NextPart_000_CDEF_01234567.89ABCDEF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
SP -M
UR
  The  we and  Saf Wa Ph acy 
is  Ne st  The  est  y of  arm

Inc e Yo xual Des Spe ume by  %
reas ur Se ire and  rm vol 500
<= /TABLE>

100 ural and  de Eff - in con t to wel wn bra
% Nat No Si ects  tras l-kno nds.
Expe ce thr es lon gas
rien ee tim ger or ms

































Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs ------=_NextPart_000_CDEF_01234567.89ABCDEF-- From simple-bounces@ietf.org Sat Feb 19 12:47:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24713; Sat, 19 Feb 2005 12:47:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Z33-0005cS-DI; Sat, 19 Feb 2005 13:09:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Xat-0007VN-74; Sat, 19 Feb 2005 11:36:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2WAO-000631-MA for simple@megatron.ietf.org; Sat, 19 Feb 2005 10:05:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09726 for ; Sat, 19 Feb 2005 10:05:00 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2WWB-00016J-DK for simple@ietf.org; Sat, 19 Feb 2005 10:27:39 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 19 Feb 2005 08:18:13 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,100,1107734400"; d="scan'208"; a="226859259:sNHT21048008" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1JF4SwN005974; Sat, 19 Feb 2005 07:04:28 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-160.cisco.com [10.86.240.160]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHW34087; Sat, 19 Feb 2005 07:04:27 -0800 (PST) Message-ID: <4217557A.3050305@cisco.com> Date: Sat, 19 Feb 2005 10:04:26 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Anders Lindgren C (HF/EAB)" References: <2DC267ED40568D4F9AA4F5DF955AF16A11597F@esealmw107.eemea.ericsson.se> In-Reply-To: <2DC267ED40568D4F9AA4F5DF955AF16A11597F@esealmw107.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: [Simple] Re: draft-ietf-simple-xcap-package-03 How to indicate that a document is deleted or a new document is added during a subscription X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit I was just now combing through the archives in the process of updating the data model, and noticed this mail that I never responded to. My apologies. Answers inline. Anders Lindgren C (HF/EAB) wrote: > Hello all; In the draft draft-ietf-simple-xcap-package-03 I find it > hard to see if and how it is possible to indicate that: > > 1) A document has been added to a watched user's tree during the > duration of the subscription. This is a gap in the specification. Good catch! Thanks for finding it. I would propose the following solution. The element have an attribute called state, which can have a value of "existing" or "deleted". When a document is added, an xcap-diff would get sent with a value of "existing" and the patch elements would basically contain the entire document. Modifications to the document would result in elements with either no state attribute, else state with a value of "existing" (that is, the default is existing). If the document is deleted, the element would have a state of deleted, and there would be no patch operations. It would be an error to send an xcap-diff with a with patch operations. The recipient of xcap-diff knows a doc is added if the diff has a element with a document locator that it doesnt know about. I prefer this approach to having an explicit "added" state, as it reduces the number of error cases. Does this seem reasonable? > > 2) A document has been deleted from a watched user's tree during the > duration of the subscription. See above. > > Is a "deteted document" and an "added document" element missing or > > is it that every Notify also SHALL contain every unchanged existing > documents with New Etag=previous Etag and that the Subscriber can at > every Notify shall check the last received Notify to see if the > document baseline has been changed. A Notify will also be send as > soon as a document has been added deleted with all existing or > > does the draft contain a solution that I have missed? It would be wasteful to have to send a for every document covered by the subscription, just to figure out when something is deleted. The problem you outline is a gap in the spec. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Feb 19 13:16:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26300; Sat, 19 Feb 2005 13:16:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2ZVV-0006Gj-Ut; Sat, 19 Feb 2005 13:39:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Xqf-0004MD-5A; Sat, 19 Feb 2005 11:52:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Who-00048l-1Q for simple@megatron.ietf.org; Sat, 19 Feb 2005 10:39:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13345 for ; Sat, 19 Feb 2005 10:39:32 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2X3c-00022y-EB for simple@ietf.org; Sat, 19 Feb 2005 11:02:12 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 19 Feb 2005 07:49:43 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1JFd1wN009308; Sat, 19 Feb 2005 07:39:01 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-160.cisco.com [10.86.240.160]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHW34449; Sat, 19 Feb 2005 07:39:00 -0800 (PST) Message-ID: <42175D93.4010700@cisco.com> Date: Sat, 19 Feb 2005 10:38:59 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sharath Chandra Subject: Re: [Simple] On Class References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Another note I never responded to. Apologies. Answers inline. Sharath Chandra wrote: > How does existing Presence data model address the following issues ? > > 1) Unique identity for a user across the domains and networks. For a > presence document to be complete it may need to handle alias for a > user within the same network as well as across the domains and > networks. Presence informations multiple application (not sip based > sources) also needs to be handled. Is there a proposed architecture > for such requirement I'm not sure I entirely I understand your question. I think you mean the following. A particular user can have multiple identities in many domains - sip:jdrosen@cisco.com, yim:jdrosen, sip:jdrosen@jdrosen.net, and so on. Some of these may not even be SIP domains (like the Yahoo IM one). In that case, how do we create a consolidated view of my presence? This is a very complex question; something folks often refer to as presence federation. I think it is a topic worthy of consideration in the presence processing model draft, as it ultimately is about how a compositor collects information from different sources; in this case, the source is a presence server in another domain. There are several ways to do that in SIMPLE. Rather than write a long extended note on this topic, I'll put some initial text in the next revision of the procssing model document. > > 2) Categorizing the watchers into groups for a presentity to specify > different levels of privacy and trust. Like Family, Friends, > Colleagues etc. I believe once the grouping/class is available i can > have more control on what data i can disclose to which class and i can > make a authorization document using XCAP. There were capabilities for this in previous versions of the draft. The idea was that a new type of condition was whether an identity was on a resource list specified elsewhere in the xcap root. You could then define lists for friends, co-workers, etc, and key authorization rules off of it. We purposefully reduced the scope of the presence auth rules to bare minimum, and this particular feature was dropped. The expectation is that we could address it downstream via a separate specification that added this new type of condition. Another way to do this kind of thing is trait-based authorization, which eliminates the need for maintenance of lists of users. For example, if a SUBSCRIBE showed up and the domain it came from asserted that the subscriber was in the marketing department of some company, I could define authorization rules that applied to any users with that trait (in the marketing department of some company). WOrk on trait-based identification is ongoing in sipping/sip: http://www.ietf.org/internet-drafts/draft-ietf-sipping-trait-authz-01.txt http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-02.txt this work is still relatively early but I think is very promising. Once it matures, the time will be ripe for defining presence rules conditions that can take advantage of the traits placed into a SUBSCRIBE request. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Feb 19 14:23:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29974; Sat, 19 Feb 2005 14:23:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2aYm-0007sG-Ee; Sat, 19 Feb 2005 14:46:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2YVT-0004zk-71; Sat, 19 Feb 2005 12:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2XTZ-0005vb-5y for simple@megatron.ietf.org; Sat, 19 Feb 2005 11:29:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16922 for ; Sat, 19 Feb 2005 11:28:53 -0500 (EST) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2XpM-0003Lk-Ri for simple@ietf.org; Sat, 19 Feb 2005 11:51:34 -0500 Received: from [131.161.248.87] (open-131-161-248-87.cliq.com [131.161.248.87]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j1JGSmm09741; Sat, 19 Feb 2005 08:28:48 -0800 In-Reply-To: References: <98e7431c35cb9031307559570a199aaf@ekabal.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7c79e7a0d9812fc1368ada78dfa8205f@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] WebDAV alternative to XCAP draft Date: Sat, 19 Feb 2005 08:28:54 -0800 To: Dean Willis X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Yes, you could lock the immediate parent. I did not want to rely on locking support in the client, but almost all servers support locking. Locking isn't needed for inserts, but it is useful for bulk modify and bulk delete. thx, -r On Feb 18, 2005, at 15:24, Dean Willis wrote: > On Feb 18, 2005, at 10:45 AM, Rohan Mahy wrote: > >> I'd like folks to consider my proposal, which is at: >> >> http://www.ietf.org/internet-drafts/draft-mahy-simple-xcap- >> alternative-00.txt >> > > This proposal must be deeply flawed, because I think I actually > understand parts of it. I kind of like that feeling -- it doesn't > happen often :-) ! > > One question: You mention the possibility of pipelined commands and > touch very briefly on simultaneous operations. Would it be appropriate > to consider locking the immediate parent collection before updating > more than one child of that collection in a pipelined mode? > > -- > dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From jhfmknmn@yahoo.com Sat Feb 19 14:35:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00713; Sat, 19 Feb 2005 14:35:40 -0500 (EST) Date: Sat, 19 Feb 2005 14:35:40 -0500 (EST) From: jhfmknmn@yahoo.com Message-Id: <200502191935.OAA00713@ietf.org> Received: from [220.78.240.110] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D2ak8-00087I-DD; Sat, 19 Feb 2005 14:58:22 -0500 Received: by mta340.newsletterplanet.com (PowerMTA(TM) v2.0r1) id hik4gk03up8r; Sat, 19 Feb 2005 13:28:33 -0600 X-Spam-Score: 8.5 (++++++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a (envelope-from <20040929124340.CCA97265919174051818988783.78128jhfmknmn@yahoo.com>) Message-ID: <20040929124340.CCA97265914003432821384387444706.29525jhfmknmn@yahoo.com> Notification: No Reply-To: "Althea Gilliam" Date: Sun, 20 Feb 2005 00:35:33 +0500 From: "Althea Gilliam" To: sigtran@ietf.org Subject: Sigtran MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Accucast

micr0s0ft for pennies

check 'em out




dart flagpole semitic incisive chalmers concise strident thickish skunk boat hawthorn From simple-bounces@ietf.org Sat Feb 19 15:58:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07366; Sat, 19 Feb 2005 15:58:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2c25-0001jZ-1B; Sat, 19 Feb 2005 16:20:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2aBZ-0004qr-74; Sat, 19 Feb 2005 14:22:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2YpQ-0008Rc-4h for simple@megatron.ietf.org; Sat, 19 Feb 2005 12:55:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25204 for ; Sat, 19 Feb 2005 12:55:32 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2ZBE-0005n5-T2 for simple@ietf.org; Sat, 19 Feb 2005 13:18:14 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 19 Feb 2005 12:55:04 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1JHt01j014693; Sat, 19 Feb 2005 12:55:01 -0500 (EST) Received: from cisco.com (che-vpn-cluster-2-169.cisco.com [10.86.242.169]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APG48459; Sat, 19 Feb 2005 12:54:59 -0500 (EST) Message-ID: <42077A00.4030709@cisco.com> Date: Mon, 07 Feb 2005 09:24:00 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] Three dimensions of service References: <4206DADF.4060708@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Thanks Henning, I've been trying to tease this distinction out of the discussion, but you have done a good job of spelling it out clearly. I think dealing with D3 can either be ignored or at least postponed until later. But it would be good to settle on exactly what is special about PTT, and how it should be characterized. I still think it is all about floor control. I think the only thing that we don't have a good way to describe right now is the case where both voice and floor control are offered, but a call with just voice is not acceptable. Paul Henning Schulzrinne wrote: > I think it might be helpful to dis-entangle describing a service into > (at least) three dimensions: > > (D1) Protocol and network capabilities, describing what is necessary so > that two devices can exchange messages. This encompasses most of > prescaps. Knowing this won't guarantee that the service does what a > human expect. For example, a user might be surprised to be connected to > a robot when expecting a human to answer. > > (D2) Interaction capabilities: how does the service act - is it a human? > does it only announce or only record? This applies across a range of > protocols and media. > > (D3) Content - what gets conveyed by the media exchange. Am I talking to > a flight reservation system or a Doom character or the game audio > background music? This clarly applies to a range of media, protocol > capabilities and even interaction styles. (Flight information can be > delivered by a human or multiple kinds of robots.) > > PTT is mostly a media signaling and floor control mechanism and doesn't > really affect D2 and D3. > > There seems to be some hierarchy, with D1 as the lowest level, but I > don't think that particularly matters for the discussion. In some cases, > only one or two of the three dimensions may be known or relevant. > > D1 and D2 seem to be more amenable to enumeration, while it seems to > require a full-blown ontology to do justice to D3, so that we may simply > have to live with free text and maybe rendering hints (e.g., icons). > > A service tuple should have a unique combination of these dimensions, > which includes the "I don't know", "can be any one of a subset of them - > call and you'll find out" and "I won't tell you" cases for any one of them. > > Henning > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From marlene@accesswave.com Sun Feb 20 10:47:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13256 for ; Sun, 20 Feb 2005 10:47:21 -0500 (EST) Received: from [213.37.60.187] (helo=187.red-213-37-60.user.auna.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D2tes-0000tE-Ci for simple-archive@ietf.org; Sun, 20 Feb 2005 11:10:14 -0500 Message-ID: <386c01c51762$58f3a8fe$849f45b1@accesswave.com> From: "Paul A. Davis" To: simple-archive@ietf.org Subject: =?iso-8859-1?B?VmlhZ3JhIC0gJDEuOTkvZG9zZQ==?= Date: Sun, 20 Feb 2005 15:38:18 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_7C704AB2.74574B08" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 12.1 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0000_7C704AB2.74574B08 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_A585BF82.79E11DF5" ------=_NextPart_001_0001_A585BF82.79E11DF5 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hard & full erections Long-lasting effects No prescription asked Give it a try! Cialis - http://www.triamed.biz/sv/ Viagra - http://www.triamed.biz/vt/ Delivered in a discreet package _________________________________________________________________________ To be taken out, go here: http://www.triamed.biz/uns.htm _________________________________________________________________________ ------=_NextPart_001_0001_A585BF82.79E11DF5 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Wor de shi g wit hou
ld Wi ppin hin 24  rs

Rock hard erections
Long effects
No prescription required

Give it a try!
CIALIS - http://www.triamed.biz/sv/
VIAGRA - http://www.triamed.biz/vt/

Delivered in a discreet package


_________________________________________________________________________
To be taken out, go here: http://www.triamed.biz/uns.htm
_________________________________________________________________________

------=_NextPart_001_0001_A585BF82.79E11DF5-- ------=_NextPart_000_0000_7C704AB2.74574B08-- From simple-bounces@ietf.org Mon Feb 21 00:07:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20882; Mon, 21 Feb 2005 00:07:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3694-00052X-R7; Mon, 21 Feb 2005 00:30:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D35Iu-0002OA-G8; Sun, 20 Feb 2005 23:36:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D34ru-0005Nu-CS for simple@megatron.ietf.org; Sun, 20 Feb 2005 23:08:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15265 for ; Sun, 20 Feb 2005 23:08:14 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D35E0-0003Hl-Oi for simple@ietf.org; Sun, 20 Feb 2005 23:31:14 -0500 Received: from [192.168.1.104] (c-24-23-89-57.client.comcast.net [24.23.89.57]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.12.11) with ESMTP id j1L4A2Fj029460 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 20 Feb 2005 22:10:03 -0600 In-Reply-To: <7c79e7a0d9812fc1368ada78dfa8205f@ekabal.com> References: <98e7431c35cb9031307559570a199aaf@ekabal.com> <7c79e7a0d9812fc1368ada78dfa8205f@ekabal.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Simple] WebDAV alternative to XCAP draft Date: Sun, 20 Feb 2005 22:08:14 -0600 To: Rohan Mahy X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit On Feb 19, 2005, at 10:28 AM, Rohan Mahy wrote: > Yes, you could lock the immediate parent. I did not want to rely on > locking support in the client, but almost all servers support locking. > Locking isn't needed for inserts, but it is useful for bulk modify > and bulk delete. > But doesn't the locking operation effectively transform a non-idempotent sequence into a single idempotent transaction? -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From Charles@12move.nl Mon Feb 21 00:42:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24666; Mon, 21 Feb 2005 00:42:30 -0500 (EST) Received: from [82.205.193.218] (helo=musclemail.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D36gj-0005rS-KJ; Mon, 21 Feb 2005 01:05:32 -0500 From: "Allard Stefan" To: "Resta Mauro" Subject: Re[5]: discussion with your health Date: Sun, 20 Feb 2005 23:45:49 +0100 Message-ID: <3da601c517d8$08c579f9$dac1cd52@musclemail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_CDEF_01234567.89ABCDEF" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437 X-Spam-Score: 10.6 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 6379955759c38e2371a49573a0932fc7 This is a multi-part message in MIME format. ------=_NextPart_000_CDEF_01234567.89ABCDEF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con ------=_NextPart_000_CDEF_01234567.89ABCDEF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
SP -M
UR
  The  we and  Saf Wa Ph acy 
is  Ne st  The  est  y of  arm

Inc e Yo xual Des Spe ume by  %
reas ur Se ire and  rm vol 500
<= /TABLE>

100 ural and  de Eff - in con t to wel wn bra
% Nat No Si ects  tras l-kno nds.
Expe ce thr es lon gas
rien ee tim ger or ms

































t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. Expe ce thr es lon gas rien ee tim ger or ms Wor de shi g wit hou ld Wi ppin hin 24 rs SP -M UR The we and Saf Wa Ph acy is Ne st The est y of arm Inc e Yo xual Des Spe ume by % reas ur Se ire and rm vol 500 100 ural and de Eff - in con t to wel wn bra % Nat No Si ects tras l-kno nds. ------=_NextPart_000_CDEF_01234567.89ABCDEF-- From simple-bounces@ietf.org Mon Feb 21 03:09:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27101; Mon, 21 Feb 2005 03:09:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D38zn-000141-5H; Mon, 21 Feb 2005 03:32:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D37xh-0001Cx-7U; Mon, 21 Feb 2005 02:26:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D37XQ-0002My-1X for simple@megatron.ietf.org; Mon, 21 Feb 2005 01:59:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00830 for ; Mon, 21 Feb 2005 01:59:18 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D37tY-0007sA-CQ for simple@ietf.org; Mon, 21 Feb 2005 02:22:17 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1L6xFD00453 for ; Mon, 21 Feb 2005 08:59:15 +0200 (EET) X-Scanned: Mon, 21 Feb 2005 08:56:59 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j1L6uxH3029235 for ; Mon, 21 Feb 2005 08:56:59 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 008zVcAy; Mon, 21 Feb 2005 08:56:58 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1L6tiM29910 for ; Mon, 21 Feb 2005 08:55:44 +0200 (EET) Received: from [10.163.23.234] ([10.163.23.234]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 21 Feb 2005 08:53:54 +0200 Message-ID: <42198582.6000405@nokia.com> Date: Mon, 21 Feb 2005 08:53:54 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Feb 2005 06:53:54.0505 (UTC) FILETIME=[1BB87B90:01C517E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: Aki Niemi Subject: [Simple] draft on MSRP conferencing X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Hi: Aki and me had made a new revision of a draft that discusses how to do conferences with MSRP. We propose to define a new MSRP method and a couple of new headers, in addition to a number of conventions. The draft should be officially published soon. In the meantime you can download a copy from (html and txt): http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-02.html http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-02.txt Comments are welcome. - Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 21 04:33:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03550; Mon, 21 Feb 2005 04:33:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3AIN-00037u-8b; Mon, 21 Feb 2005 04:56:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D39Nm-0003TD-O9; Mon, 21 Feb 2005 03:57:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D38rh-0005RE-9L; Mon, 21 Feb 2005 03:24:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28630; Mon, 21 Feb 2005 03:24:18 -0500 (EST) Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D39Dq-0001Ps-BP; Mon, 21 Feb 2005 03:47:19 -0500 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11/8.12.11) with ESMTP id j1L8MHJS003452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 21 Feb 2005 09:22:17 +0100 Received: from eeek.ingate.se (localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.12.11/8.12.11) with ESMTP id j1L8MHdK009829; Mon, 21 Feb 2005 09:22:17 +0100 Received: (from hasse@localhost) by eeek.ingate.se (8.12.11/8.12.11/Submit) id j1L8MGxc009827; Mon, 21 Feb 2005 09:22:16 +0100 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f Subject: Re: [Simple] presence authorization issue: anonymous, authenticated, etc. From: Hans Persson To: Jonathan Rosenberg In-Reply-To: <42150F19.2090901@cisco.com> References: <42146290.5090209@cisco.com> <4214ADD0.3070101@cs.columbia.edu> <42150F19.2090901@cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Ingate Systems Message-Id: <1108974136.8377.12.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 21 Feb 2005 09:22:16 +0100 X-Virus-Scanned: ClamAV 0.80/622/Wed Dec 8 14:36:53 2004 clamav-milter version 0.80j on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (usagi.ingate.se [193.180.23.12]); Mon, 21 Feb 2005 09:22:17 +0100 (CET) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Simple WG , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit tor 2005-02-17 klockan 22.39 skrev Jonathan Rosenberg: > We aren't normally authenticating the identity of the message originator > by TLS certs. We have P-A-ID, which uses inter-domain TLS but not to > verify the identity or domain of the sender, but rather to validate the > identity of the peer provider. For draft-ietf-sip-identity, there is no > TLS, the From field is verified by using the domain cert obtained from > the reference in the Identity header. I'm probably taking a risk by writing this first thing on Monday morning *yawn* but as far as I can see there may well be a TLS cert involved in draft-ietf-sip-identity: draft-ietf-sip-identity-04.txt: > The Identity-Info header MUST contain either an HTTPS URI or a SIPS > URI. If it contains an HTTPS URI, the URI must dereference to a > resource that contains a single MIME body containing the certificate > of the authentication service. If it is a SIPS URI, then the > authentication service intends for a user agent that wishes to fetch > the certificate to form a TLS connection to that URI, acquire the > certificate during normal TLS negotiation, and close the connection. (I assume you really meant Identity-Info, not Identity) Hans -- Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 21 04:56:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05599; Mon, 21 Feb 2005 04:56:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3Aes-0003kL-NT; Mon, 21 Feb 2005 05:19:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D39eq-0006sS-OB; Mon, 21 Feb 2005 04:15:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3980-0000Jc-LS for simple@megatron.ietf.org; Mon, 21 Feb 2005 03:41:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29909 for ; Mon, 21 Feb 2005 03:41:10 -0500 (EST) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D39UA-0001x7-NO for simple@ietf.org; Mon, 21 Feb 2005 04:04:11 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1L8f5c13198; Mon, 21 Feb 2005 10:41:05 +0200 (EET) X-Scanned: Mon, 21 Feb 2005 10:40:24 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j1L8eOXS021995; Mon, 21 Feb 2005 10:40:24 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00QweVTR; Mon, 21 Feb 2005 10:37:35 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1L8b5M18868; Mon, 21 Feb 2005 10:37:05 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 21 Feb 2005 10:28:15 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 21 Feb 2005 10:28:15 +0200 Received: from 172.21.50.105 ([172.21.50.105]) by esebe105.NOE.Nokia.com ([172.21.143.53]) with Microsoft Exchange Server HTTP-DAV ; Mon, 21 Feb 2005 08:28:15 +0000 Received: from xitami.research.nokia.com by esebe105.ntc.nokia.com; 21 Feb 2005 10:28:14 +0200 Subject: Re: [Simple] WebDAV alternative to XCAP draft From: jari urpalainen To: ext Rohan Mahy In-Reply-To: <98e7431c35cb9031307559570a199aaf@ekabal.com> References: <98e7431c35cb9031307559570a199aaf@ekabal.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 21 Feb 2005 10:28:14 +0200 Message-Id: <1108974494.22519.32.camel@xitami.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-OriginalArrivalTime: 21 Feb 2005 08:28:15.0542 (UTC) FILETIME=[49F62D60:01C517EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit On Fri, 2005-02-18 at 08:45 -0800, ext Rohan Mahy wrote: > Hi Folks, > > Sometime in December or January, I started to hear fragmented reports > that verifying idempotency during PUT and DELETE operations in early > implementations of XCAP made the performance of these XCAP server drop > considerably. I can think of two reasonable explanations for these > reports: > > 1) These implementations where written inefficiently. When optimized > the actual performance of idempotency checks is fine for production > systems. > > or > > 2) There is something inherent about the flexibility of XCAP that makes > it hard to quickly verify the idempotency requirement. > > Currently SIMPLE is using XCAP for resource-lists and auth-lists. While > the arbitrary depth functionality of XCAP is useful for some > applications (ex: I understand that this was particularly attractive > for Joel's application), our applications don't require the complete > flexibility of XCAP. > > Consequently, I wrote an "Escape Hatch" proposal that sketches the > possibility of using ordinary WebDAV to get the functionality we are > using. I quite like this approach and if we were starting over again, > this would be my first choice. However, the working group has invested > a lot of energy in XCAP and it promises a lot of flexibility for future > IETF application configuration work. > > So, I would like to quickly find out what kind of PUT and DELETE > performance folks are getting from XCAP implementations when > idempotency checks are turned on. Folks with implementations, please > speak up. > > It would be nice to verify that everything is fine and go back to our > regularly scheduled program. If something is really wrong, I'd like > folks to consider my proposal, which is at: > > http://www.ietf.org/internet-drafts/draft-mahy-simple-xcap- > alternative-00.txt > > many thanks, > > -rohan As I do have some implementation experience on this, some comments... Jonathan also noted that the idempotency check isn't that difficult as you are saying, i.e. you'll just have to do a simple XPath evaluation after a put/delete request to fulfill a valid xcap request. Once you'll have already parsed the XPath query, you'll just have to evaluate the request again against the document and usually you'll don't even have to check the full location path but only the last or the last two steps. (and btw. it is somewhat vague to speak about idempotency constraint here as it can be easily fulfilled with conditional requests, i.e. this checking constraint is more like an xcap thing). And still in my reference implementation this checking has really a minor impact on the performance which is mostly suffered by the schema validation which will take orders of magnitude more time than this checking. And I don't see a big difference in this validation constraint between the two approaches. This is not to say that using WebDAV is totally wrong here. Actually, I could easily see that e.g. locks could be used together with the base xcap but it would be complementing technique not replacing something onto which we have put quite some effort. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 21 11:00:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13987; Mon, 21 Feb 2005 11:00:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3GKv-0005d5-2f; Mon, 21 Feb 2005 11:23:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3FFl-0004Fe-Kv; Mon, 21 Feb 2005 10:13:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3ESy-0003Ra-FA for simple@megatron.ietf.org; Mon, 21 Feb 2005 09:23:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00146 for ; Mon, 21 Feb 2005 09:23:14 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3EpE-0002bj-0x for simple@ietf.org; Mon, 21 Feb 2005 09:46:18 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 21 Feb 2005 06:22:50 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1LEMeYO018449 for ; Mon, 21 Feb 2005 06:22:40 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-100.cisco.com [10.86.240.100]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHX06786; Mon, 21 Feb 2005 06:22:39 -0800 (PST) Message-ID: <4219EEAE.9040103@cisco.com> Date: Mon, 21 Feb 2005 09:22:38 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: 7bit Subject: [Simple] updated presence data model X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: 7bit I've submitted an update to the presence data model. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-simple-presence-data-model-02.txt This is a major revision. The biggest three changes are the split of the processing and data model, the allowance for multiple instances of a particular person, device or service, and the introduction of the notion of generic "reach information". Reach information includes the URI for the service but can also include other information that a watcher has to do in order to get a request to the service. I think that, from a model perspective, this would cover our needs for something like an "app launcher" as we have been discussing in another thread on enumerating services. Note that the examples are not schema-validated at all (or evne close). We have a much bigger issue on schema alignment, which I'll post on separately. Here are the specific diffs: * split out composition and presence server processing sections, leaving only the data model * fixed examples, which had tuple extensions before . They need to come after * changed terminology from person, device and service elements, to person device and service components, to refer to the part of the data model that talks about person, service. This is to differentitate the XML concept of element from the disaggregation implied by component. With this change, it makes sense to say that there is one person component, but there can be multiple elemnents. * added the ability for there to be multiple instances of a particular service or device, or person. This was done by modeling the system hierarchically. The presentity is at the top layer, followed by devices, services and person. Within a particular device, service, or person, there can be multiple instances. Each instance of a service shares the same service URI, each instance of a device shares the same device ID. Each instance is identified by an instance ID. This is described in the document as a feature in order to explicitly model ambiguity in cases where the compositor cannot, or doesn't want to, resolve the ambiguity, but rather wishes for the consumer of the document to do so. It is important to note that this means that the reason we choose to have multiple instances of a service is ONLY because we want to model ambiguity; it we want to explicitly say something like "My softphone is open for IM, but not audio", standardized ways of doing that, where the compositor or the device knows this to be the case, are not to be done using multiple instances. Otherwise, we are back in the boat of multiple ways of saying the same thing. * The spec mentions usage of timestamp and note to allow humans and automata to resolve conflicts * allow timestamp and note as part of person and device. Aligned schemas for person and device to match structure of the tuple. * Modified schemas to extract types for note and timestamp into a common schema, which is included into the person and device schemas. * added a section discussion general properties of documents in the model. Emphasize that the meaning of a document is well-defined and not based on its transport or transferrance method, and that presence systems allow for infinite composeability. * since a person element can have a note, and there can be a note in the document overall, the model defines how these resolve. Its like attributes in SDP. If a note is defined under the person itself, that is used. If there isn't one, the document-wide one is used. * substantially revamped definition of a service. Created subsections to define the components of a service - characteristics, reach inforamtion, status, relative information. Reach information includes the URI but could include things like a software app you have to use, or a header you have to place into your request. * clarified that capabilities don't mean that you have to format your request in a specific way - that is what reach information is for * no longer reference the roach service examples draft; rather, the ideas there are expanded upon here * tel URI is discussed as being similar to sip, in that it can indicate multiple services * discuss that since reach information uniquely identify a service, two things can't be separate services if they can't be reached separately * describe Aki's "available on my softphone if you use IM, but not if you use audio" as an example of a more complex status for a single service * mention that capabilities for a service can be more complex than we have today; for example eventually rfc2533. * mention that implied behaviors on receipt of a document cannot be assumed - everything has to be explicit * nothing says that the service URI has to be a gruu or anything else; from a data model perspective its just a URI that is used to access the service. The processing model draft will give guidance on how its filled in by PUA. * added a treatment on the type of URI that can be included in the service URI. There is no limit, but abstract URIs like URN and tel mean you can't say much about characteristics. Using a tel URI with enum dip indicator is better, or using a tel URI when there is no enum record is better, that means its a phone number and you can say more about it * mention that the service URI to service mapping is many to one, and that it is ok for service URI to change over time too. Mention that this is useful for anti-spam and give reference to the ietf-sipping-spam draft * mention that the presentity URI represents a form of "one number" communications - providing an index by which all of the other reach addresses for a user can be discovered. * concluded that the UUID URN was not going to work very well for us out of the box, since it requires a time-based component and thus doesnt have the characteristics of being guessable or correlatable with other information sources in the network. As such, its listed as a fallback option until other, better URN are defined. Also, ESN and MAC are listed as useful identifiers but they don't have URN schemes. * clarified that the person component represents a single individual, and talked about how groups or users or a dog could actually be hiding behind that person facade. * added discussion of dealing with both pres and SIP URI; and how to set the entity URI correctly. Discussed the more general alias issue as well. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From Grayson@kittymail.com Mon Feb 21 13:33:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28943; Mon, 21 Feb 2005 13:33:02 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3Ij3-0000zZ-9k; Mon, 21 Feb 2005 13:56:10 -0500 Received: from [211.58.188.38] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D3IMf-0002Cl-NP; Mon, 21 Feb 2005 13:33:02 -0500 Received: from [48.77.104.225] by caper%DIGITS.hierarchal.211.58.188.38 via HTTP; Mon, 21 Feb 2005 10:32:42 -0800 Reply-To: "animail.net" From: "animail.net" To: Subject: Hi, Dearest Date: Mon, 21 Feb 2005 10:32:42 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--4905925614odvn2039" Message-Id: X-Spam-Score: 8.1 (++++++++) X-Spam-Flag: YES X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 ----4905925614odvn2039 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable I just wanted to know if you would like to accompany me. My Sack of shit husband=20 works night shifts, which makes me very lonely = at night. Write me back here: http://www.netazipper.com/d/10.php Regards, Elizabeth c ----4905925614odvn2039-- From simple-bounces@ietf.org Mon Feb 21 14:23:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03562; Mon, 21 Feb 2005 14:23:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3JW5-0002HD-BS; Mon, 21 Feb 2005 14:46:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3H87-000177-Nf; Mon, 21 Feb 2005 12:13:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3GIR-00082A-Oh for simple@megatron.ietf.org; Mon, 21 Feb 2005 11:20:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16515 for ; Mon, 21 Feb 2005 11:20:24 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3Gee-0006Ax-Sg for simple@ietf.org; Mon, 21 Feb 2005 11:43:30 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Feb 2005 09:34:00 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,104,1107734400"; d="scan'208"; a="227461595:sNHT19611416" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1LGJpZV018038 for ; Mon, 21 Feb 2005 08:19:52 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-100.cisco.com [10.86.240.100]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHX11466; Mon, 21 Feb 2005 08:19:50 -0800 (PST) Message-ID: <421A0A26.4080705@cisco.com> Date: Mon, 21 Feb 2005 11:19:50 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Subject: [Simple] updated presence rules spec X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit I've submitted an update to the presence rules spec. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-simple-presence-rules-02.txt changes since the last version: * allow instance ID to be used as a selector for person, device and service * allow class to be used as a selector for person, device and service * added a provide-all-attributes permission * moved away from substitution groups for device and service selector containers * note the dangers of using to determine the subscription handling * presence authorization documents inherit the MIME type of the common policy documents. * specify that no normative statements are made about when the presence authorization processing is to be applied, so long as the final doc sent to the watcher meets the privacy constraints * changed definition of anonymous so that it only includes authenticated anonymous identities, and documented how that is determined, including usage with draft-ietf-sip-identity * added back draft-ietf-sip-identity as normative ref and means for authentication for id elements * removed schema and type definitions for anonymous, as these are now in common policy * defined detailed rules for handling of the sub-handling permission, by describing its interactions with RFC 3857 state machinery and the rules in rfc3265. Note that presence-auth allows subscription processing not envisioned in rfc3857 - that a subscription can move from active back to pending. * clearly indicate which parts of tuple, device and person are always included in the genreated document. This is timestamp, basic status, contact and device-ID * defined the component-id permission, which defines the degree to which the contact URI and device ID are randomized/obfuscated. * added provide-note Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From Potter@address.com Mon Feb 21 14:29:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04224; Mon, 21 Feb 2005 14:29:41 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3Jbq-0002Pf-FH; Mon, 21 Feb 2005 14:52:47 -0500 Received: from cm224-252.liwest.at ([81.10.224.252]) by mx2.foretec.com with smtp (Exim 4.24) id 1D3JFR-0003Mg-Sl; Mon, 21 Feb 2005 14:29:38 -0500 Received: from [0.254.81.224] by indict%DIGITS.rosetta.81.10.224.252 via HTTP; Mon, 21 Feb 2005 11:29:26 -0800 Reply-To: "jaydemail.com" From: "jaydemail.com" To: Subject: There it is as promised Date: Mon, 21 Feb 2005 11:29:26 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--1301956150leps5024" Message-Id: X-Spam-Score: 5.0 (+++++) X-Spam-Flag: YES X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 ----1301956150leps5024 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable Here it is Log-In information to the adult website. Username:Delacruz37kx Password:dvp858db %SITE: http://www.netaexplicit.com/d/h/1.php ----1301956150leps5024-- From Bingham@moose-mail.com Mon Feb 21 15:09:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08799; Mon, 21 Feb 2005 15:09:51 -0500 (EST) Message-Id: <200502212009.PAA08799@ietf.org> Received: from client-82-3-93-62.mant.adsl.virgin.net ([82.3.93.62]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D3KEi-0003Pf-22; Mon, 21 Feb 2005 15:32:58 -0500 Received: from [240.12.230.176] by clockwatcher%DIGITS.conscription.82.3.93.62 via HTTP; Mon, 21 Feb 2005 12:13:13 -0800 Reply-To: "incamail.com" From: "incamail.com" To: Subject: Your Login Info Date: Mon, 21 Feb 2005 12:13:13 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6837184688huek1092" X-Spam-Score: 2.6 (++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 ----6837184688huek1092 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable Dear male :: mip6-web-archive@ietf.org:: .................... Get your password today, to the wildest spot on the internet! (20 niches in1site) .................... *YES! It costs $0 http://www.netaexplicit.com/d/r/1.php ----6837184688huek1092-- From Maximilien@kgnet.com Mon Feb 21 23:03:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29890 for ; Mon, 21 Feb 2005 23:03:47 -0500 (EST) Message-Id: <200502220403.XAA29890@ietf.org> Received: from [211.49.203.6] (helo=kgnet.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D3RdS-00010z-9Q for simple-archive@ietf.org; Mon, 21 Feb 2005 23:27:00 -0500 From: "Uwe Roush" To: "Jamal Rogers" Subject: Re: WWW Medicattions Date: Mon, 21 Feb 2005 23:11:10 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_0081E530.6BE88BE9" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is a multi-part message in MIME format. ------=_NextPart_000_0011_0081E530.6BE88BE9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Have a nice day. ------=_NextPart_000_0011_0081E530.6BE88BE9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello, Welcome=20 to the best ONLINE ST0RE.
 
Wor de shi g wit hou
ld Wi ppin hin 24  rs
Vi in $178(90p.) a a $209(100p.) ana al
cod  Vi gr  X x $299(90p.) = Ci is $324(90p.) 
 
With each purchase you = get:
 
>Home delivery.
>Secure pay.
>Total confidentiality
>Reputable =20 manufacturerrs.
 
Have a nice day!
------=_NextPart_000_0011_0081E530.6BE88BE9-- From nfybbthobmsfms@equinix.com Tue Feb 22 03:03:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22697; Tue, 22 Feb 2005 03:03:30 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3VNQ-0002Zv-Fz; Tue, 22 Feb 2005 03:26:44 -0500 Received: from [63.161.134.16] (helo=400T-0230008) by mx2.foretec.com with smtp (Exim 4.24) id 1D3V0r-0004ij-LH; Tue, 22 Feb 2005 03:03:21 -0500 Received: from KTEFZ-ZO09 (218.3.209.252) by 218.3.209.252; Tue, 22 Feb 2005 00:05:21 -0800 From: "St. Isaac Osp." To: simple@ietf.org, simple-admin@ietf.org, simple-archive@ietf.org, simple-web-archive@ietf.org, sip@ietf.org, sip-admin@ietf.org, sipping@ietf.org, sipping-admin@ietf.org, sipping-bounces@ietf.org, speechsc@ietf.org, speechsc-admin@ietf.org, ssm@ietf.org Subject: Brand Name USA Meds Date: Tue, 22 Feb 2005 00:05:21 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=0HI_09C6598LD_07K.849I70W0" X-Priority: 3 X-Mailer: JKDYA Mailer v7.5.6 Message-Id: X-Spam-Score: 17.2 (+++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d2bb8c7db26f2d12109e0cd8e454db52 This is a multi-part message in MIME format. ------=0HI_09C6598LD_07K.849I70W0 Content-Type: multipart/alternative; boundary="----=0_00DU_06S8219VW_06K.532Z09B0" ------=0_00DU_06S8219VW_06K.532Z09B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit http://ocfpbb.ambein.net/pharm/sevy/20/pmfma.html I'd rather have a bottle in front of me, than a frontal lobotomy. Dancing is silent poetry. His ignorance is encyclopedic The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense. I discovered I always have choices and sometimes it's only a choice of attitude. What the world really needs is more love and less paper work. You can only find truth with logic if you have already found truth without it. Love takes up where knowledge leaves off. Love is composed of a single soul inhabiting two bodies. Whenever I climb I am followed by a dog called 'Ego'. Give me chastity and continence, but not yet. The secret of success is to know something nobody else knows. A kiss makes the heart young again and wipes out the years. Life's challenges are not supposed to paralyze you, they're supposed to help you discover who you are. When you're in love you never really know whether your elation comes from the qualities of the one you love, or if it attributes them to her; whether the light which surrounds her like a halo comes from you, from her, or from the meeting of your sparks. The only way to get rid of a temptation is to yield to it. When solving problems, dig at the roots instead of just hacking at the leaves. Give me a woman who loves beer and I will conquer the world. If you find a path with no obstacles, it probably doesn't lead anywhere. An inconvenience is only an adventure wrongly considered; an adventure is an inconvenience rightly considered. Who so loves believes the impossible. Yesterday is a dream, tomorrow but a vision. But today well lived makes every yesterday a dream of happiness, and every tomorrow a vision of hope. Look well, therefore to this day. Love is the beauty of the soul. Can miles truly separate you from friends... If you want to be with someone you love, aren't you already there? In science one tries to tell people, in such a way as to be understood by everyone, something that no one ever knew before. But in poetry, it's the exact opposite. If we had no winter, the spring would not be so pleasant; if we did not sometimes taste of adversity, prosperity would not be so welcome. If everything seems under control, you're just not going fast enough. But at my back I always hear Time's winged chariot hurrying near. A lie gets halfway around the world before the truth has a chance to get its pants on. When I read about the evils of drinking, I gave up reading. Always do sober what you said you'd do drunk. That will teach you to keep your mouth shut. Everyone is a genius at least once a year; a real genius has his original ideas closer together. The only difference between me and a madman is that I'm not mad. A book may lie dormant for fifty years or for two thousand years in a forgotten corner of a library, only to reveal, upon being opened, the marvels or the abysses that it contains, or the line that seems to have been written for me alone. In this respect the writer is not different from any other human being: whatever we say or do can have far-reaching consequences. Moral indignation is jealousy with a halo. I have often regretted my speech, never my silence. When you gaze long into the abyss, the abyss also gazes into you. Give me chastity and continence, but not yet. He who has a 'why' to live, can bear with almost any 'how'. Blessed is the man who, having nothing to say, abstains from giving us wordy evidence of the fact. Whether you think that you can, or that you can't, you are usually right. Distance between two hearts is not an obstacle; rather a great reminder of just how strong true love can be. Love does not begin and end the way we seem to think it does. Love is a battle, love is a war; love is a growing up. I'll moider da bum. You can't be a real country unless you have a beer and an airline. It helps if you have some kind of a football team, or some nuclear weapons, but at the very least you need a beer. We have art to save ourselves from the truth. The problem with the world is that everyone is a few drinks behind. Facts are the enemy of truth. In s cience one tries to tell people, in such a way as to be understood by everyone, something that no one ever knew before. But in poetry, it's the exact opposite. Very little is needed to make a happy life. It is all within yourself, in your way of thinking. Your living is determined not so much by what life brings to you as by the attitude you bring to life; not so much by what happens to you as by the way your mind looks at what happens. When solving problems, dig at the roots instead of just hacking at the leaves. Fill what's empty, empty what's full, and scratch where it itches. Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. Love takes up where knowledge leaves off. Love is composed of a single soul inhabiting two bodies. Education is a progressive discovery of our own ignorance. Wit is educated insolence. You can't be a real country unless you have a beer and an airline. It helps if you have some kind of a football team, or some nuclear weapons, but at the very least you need a beer. Life is pleasant. Death is peaceful. It's the transition that's troublesome. Tragedy is when I cut my finger. Comedy is when you walk into an open sewer and die. You can widen your life by yourself, but to deepen it you need a friend. Each encounter that becomes a friendship turns into a lifeline. One can never have too many, only too many to properly take care of. Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. Of cheerfulness, or a good temper - the more it is spent, the more of it remains. The full use of your powers along lines of excellence. Whatever our souls are made of, his and mine are the same. Three o'clock is always too late or too early for anything you want to do. He who has a 'why' to live, can bear with almost any 'how'. The problem with some people is that when they aren't drunk, they're sober. Love takes off masks that we fear we cannot live without and know we cannot live within. He is one of those people who would be enormously improved by death. It is better to have a permanent income than to be fascinating. I've had a wonderful time, but this wasn't it. The quality of the moment is more important than the number of our days. The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense. Human history becomes more and more a race between education and catastrophe. People demand freedom of speech to make up for the freedom of thought which they avoid. Don't be so humble - you are not that great. To love oneself is the beginning of a lifelong romance The game of life is not so much in holding a good hand as playing a poor hand well. Hope is like a road in the country: there was never a road, but when many people walk on it, the road comes into existence. In theory, there is no difference between theory and practice. But, in practice, there is. Forgive your enemies, but never forget their names. Yesterday is a dream, tomorrow but a vision. But today well lived makes every yesterday a dream of happiness, and every tomorrow a vision of hope. Look well, therefore to this day. When you gaze long into the abyss, the abyss also gazes into you. ------=0_00DU_06S8219VW_06K.532Z09B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 3D"= I'd rather have a bottle in front of me, than a frontal= lobotomy. Dancing is silent poetry. His ignorance is encyclopedic The use= of COBOL cripples the mind; its teaching should, therefore, be regarded a= s a criminal offense. I discovered I always have choices and sometimes it'= s only a choice of attitude. What the world really needs is more love and = less paper work. You can only find truth with logic if you have already fo= und truth without it. Love takes up where knowledge leaves off. Love is co= mposed of a single soul inhabiting two bodies. Whenever I climb I am follo= wed by a dog called 'Ego'. Give me chastity and continence, but not yet. T= he secret of success is to know something nobody else knows. A kiss makes = the heart young again and wipes out the years. Life's challenges are not s= upposed to paralyze you, they're supposed to help you discover who you are= When you're in love you never really know whether your elation comes fro= m the qualities of the one you love, or if it attributes them to her; whet= her the light which surrounds her like a halo comes from you, from her, or= from the meeting of your sparks. The only way to get rid of a temptation = is to yield to it. When solving problems, dig at the roots instead of just= hacking at the leaves. Give me a woman who loves beer and I will conquer = the world. If you find a path with no obstacles, it probably doesn't lead = anywhere. An inconvenience is only an adventure wrongly considered; an adv= enture is an inconvenience rightly considered. Who so loves believes the i= mpossible. Yesterday is a dream, tomorrow but a vision. But today well liv= ed makes every yesterday a dream of happiness, and every tomorrow a vision= of hope. Look well, therefore to this day. Love is the beauty of the soul= Can miles truly separate you from friends... If you want to be with some= one you love, aren't you already there? In science one tries to tell peopl= e, in such a way as to be understood by everyone, something that no one ev= er knew before. But in poetry, it's the exact opposite. If we had no winte= r, the spring would not be so pleasant; if we did not sometimes taste of a= dversity, prosperity would not be so welcome. If everything seems under co= ntrol, you're just not going fast enough. But at my back I always hear Tim= e's winged chariot hurrying near. A lie gets halfway around the world befo= re the truth has a chance to get its pants on. When I read about the evils= of drinking, I gave up reading. Always do sober what you said you'd do dr= unk. That will teach you to keep your mouth shut. Everyone is a genius at = least once a year; a real genius has his original ideas closer together. T= he only difference between me and a madman is that I'm not mad. A book may= lie dormant for fifty years or for two thousand years in a forgotten corn= er of a library, only to reveal, upon being opened, the marvels or the aby= sses that it contains, or the line that seems to have been written for me = alone. In this respect the writer is not different from any other human be= ing: whatever we say or do can have far-reaching consequences. Moral indig= nation is jealousy with a halo. I have often regretted my speech, never my= silence. When you gaze long into the abyss, the abyss also gazes into you= Give me chastity and continence, but not yet. He who has a 'why' to live= , can bear with almost any 'how'. Blessed is the man who, having nothing t= o say, abstains from giving us wordy evidence of the fact. Whether you thi= nk that you can, or that you can't, you are usually right. Distance betwee= n two hearts is not an obstacle; rather a great reminder of just how stron= g true love can be. Love does not begin and end the way we seem to think i= t does. Love is a battle, love is a war; love is a growing up. I'll moider= da bum. You can't be a real country unless you have a beer and an airline= It helps if you have some kind of a football team, or some nuclear weapo= ns, but at the very least you need a beer. We have art to save ourselves f= rom the truth. The problem with the world is that everyone is a few drinks= behind. Facts are the enemy of truth. In science one tries to tell people= , in such a way as to be understood by everyone, something that no one eve= r knew before. But in poetry, it's the exact opposite. Very little is need= ed to make a happy life. It is all within yourself, in your way of thinkin= g. Your living is determined not so much by what life brings to you as by = the attitude you bring to life; not so much by what happens to you as by t= he way your mind looks at what happens. When solving problems, dig at the = roots instead of just hacking at the leaves. Fill what's empty, empty what= 's full, and scratch where it itches. Good people do not need laws to tell= them to act responsibly, while bad people will find a way around the laws= Love takes up where knowledge leaves off. Love is composed of a single s= oul inhabiting two bodies. Education is a progressive discovery of our own= ignorance. Wit is educated insolence. You can't be a real country unless = you have a beer and an airline. It helps if you have some kind of a footba= ll team, or some nuclear weapons, but at the very least you need a beer. L= ife is pleasant. Death is peaceful. It's the transition that's troublesome= Tragedy is when I cut my finger. Comedy is when you walk into an open se= wer and die. You can widen your life by yourself, but to deepen it you nee= d a friend. Each encounter that becomes a friendship turns into a lifeline= One can never have too many, only too many to properly take care of. Goo= d people do not need laws to tell them to act responsibly, while bad peopl= e will find a way around the laws. Of cheerfulness, or a good temper - the= more it is spent, the more of it remains. The full use of your powers alo= ng lines of excellence. Whatever our souls are made of, his and mine are t= he same. Three o'clock is always too late or too early for anything you wa= nt to do. He who has a 'why' to live, can bear with almost any 'how'. The = problem with some people is that when they aren't drunk, they're sober. Lo= ve takes off masks that we fear we cannot live without and know we cannot = live within. He is one of those people who would be enormously improved by= death. It is better to have a permanent income than to be fascinating. I'= ve had a wonderful time, but this wasn't it. The quality of the moment is = more important than the number of our days. The use of COBOL cripples the = mind; its teaching should, therefore, be regarded as a criminal offense. H= uman history becomes more and more a race between education and catastroph= e. People demand freedom of speech to make up for the freedom of thought w= hich they avoid. Don't be so humble - you are not that great. To love ones= elf is the beginning of a lifelong romance The game of life is not so much= in holding a good hand as playing a poor hand well. Hope is like a road i= n the country: there was never a road, but when many people walk on it, th= e road comes into existence. In theory, there is no difference between the= ory and practice. But, in practice, there is. Forgive your enemies, but ne= ver forget their names. Yesterday is a dream, tomorrow but a vision. But t= oday well lived makes every yesterday a dream of happiness, and every tomo= rrow a vision of hope. Look well, therefore to this day. When you gaze lon= g into the abyss, the abyss also gazes into you.=20 ------=0_00DU_06S8219VW_06K.532Z09B0-- ------=0HI_09C6598LD_07K.849I70W0 Content-Type: image/jpeg; name="srg.jpg" Content-Transfer-Encoding: base64 Content-ID: <587695c4d3c0$2180fea0$226aa8c0@QDDEMOR> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAACQAA/+4AIUFkb2JlAGTAAAAAAQMA EAMCAwYAABD9AAAnuAAAS5L/2wCEABQRERoTGioZGSo1KCEoNTEpKCgpMUE4ODg4OEFERERERERE REREREREREREREREREREREREREREREREREREREQBFhoaIh0iKRoaKTkpIik5RDktLTlEREREOERE RERERERERERERERERERERERERERERERERERERERERERERERERP/CABEIAfQBTgMBIgACEQEDEQH/ xADVAAABBQEBAAAAAAAAAAAAAAADAAECBAUGBwEBAQEBAQEAAAAAAAAAAAAAAAECAwQFEAACAgIB BAEDBAIDAAMAAAABAgADEQQSECETBTEgFBUwQSIGMiMzJDRAUBYRAAEDAgMFBgIGCAUCBwEAAAEA EQIhMUESAxBRYXEiIIGRoTITscHw0UJSYgQw4XKCorLCI/GSM9MUQHNQ0lNjg5OjwxIAAQMCAggE BQMFAQAAAAAAAQARAiExQRIQIDBAUWGBIlDwcaGR0TJCA2CxweFSYsITU//aAAwDAQACEQMRAAAA 6dxLydiuNIRhsFkJBWHVkvyx7ultsqtJvNSsWlVMhYakCTVQgatyVV7DKmDN1HGLUtOKOoeGPpZp iO+oydqdJVDmLOZtOnOnb28pS8m3hNkZpOQU0Qq3c/CiTPfnl79UW1yVB8rsgBzdjOuZel6pEEly dXX7C5t7F5W7OiKS/ATdF184h1khE9UdMhZdnmKgp1OgddoSegTUvJ1ippIINPLTauSiMLOS/Oje iURn1Rjs1Yyj6UUsDcaljKnZcLmaNSAwYuQqCs0oRLpN8XQkvvRNpZhTpmcNgehCpMclaUUnokhT 8naaiivkbnP4zfCGGJrZezidFmIoc1pq1jTWzLudzph1C6lwQoF0UQh71DU6qMaReRHFUraEWPVW HUNzWJ59rCD55OpgCJ65ARaWpWs0r6dpOT+PuWDukGnGHSLU4wgTZnJNAcGxNhVU06zFoTFqKTBJ hIkSIuoEZ2IydiEpEsrcrs5HaBgSOw2mGA5lqkzK/SuncFCTxdyuBUaEMhdiHKm116MvJWixrcj1 zMJcyZegfmYtdaLnYp0R+M6uZNLmpW9HPk429lkX+QY7V+Pa3tee2+NNuvjlvW2CsPWbs6pt8Y1y 0dcKgpMhbVc53CwDebtuyydLI/P7jTXFk6h965t+ohHI9aK8zy1Xsw28mXqlXGafRKXhuvmVjns3 tAunLNpaVp+d6pZ58hDrh2vzXXNJwz9bidNU2mbryzp2q8rZ1mprkN2khSCmXGGCasWskx2V7guy 4buIcuWnGbmLroMnOBvvev4HQMXVgNHQUOfldde3P1WdJqw7rqq8cbHLo4csTXSzu8wSurhzFdnp 8iixYBZo74lrEr9eQaxgIzsh7NS2TjJTVYopXJNzBu412ciry9R890sbePJ089uV3rs5OWt7c14q 50kreRH17HKy6uaZvN9thzWYTo7WscsPs46vIVuwHLzAtrIGGlcirlD15BEQdzFk5KxKBKcXliGw MeTMnb2+d2fL2uIL4GQiqynCyLqUsXeKPGTkHkw6VvZpKPXCFEGdzqvVm6WXbqVELB1iLRh15tBR uXOGYdoEJJJXnBRBiDs0dnC6Hz9rBIH50cpkgBpOJ0qhKQ5JQJT0uHlPeHZLUQkPPQYSxmq+bYz7 Q0T09ZGCzQ68nUx3LRSJJMTt1bQ6TLNgMlkasSx6XmOl5buEg/HZ0OeU08qgVTSMiT1B0tOPSZ2l h3dy8KcOe2HOqsqb1WgU7PPdMWijl05tn3cyyKZ5EU4ATPIJYgUC05DTUlmmLANnOPnXQmxNTz9L CHPKbwJYrM5dI6aNk2FWlHR0Mjc3R4ps6tgrnm3rnAmdg6+R343C1TalaqmkVgF0VM4Byow8mlQp ieCuzLMg5BJWb2LWlcrykv5W7i27DSpmkgcCxlEGwOapYXQVV5rRqj6ct2OTKb0h0q9kc3RzumJP XdkTJBjjKAi7lh0qd2kCkIkSdiKhFFKTe5qxHUxydDJ7KMaZ8TSlsqA5StVA1cBmhmtCOelqCM2+ NaOq+emFDayt4jn6GfvNdRTKSkWZMwEgjBklTvGZSKOcFmOS29SvqcO/LQ3cjUY9Ra56dzEeToB4 UDsRckdvYpU4TRxQLcBO9ay0fPeXUbLO0cSW8RpXKVlVKTKlKJYjIYKxXsBYpEpjJVGYpwezU0c7 0bQj+b0FrXiHPU+jzLMWOlR68hKzo3OI25blw9C8+NMSKxSxjBc7L0qHXmGJJdclIOdRp2qxUKOy yNkwcRQCPXsE1GQ5BkrPdnievjaWOm9Zz7fm9FudYsGCSdzjYPR8l25h1M9uvLrHx9Xh2UoPlJRR KkUCBozH3wiRlqTlGVCAYKCLF0EyQUJojEtglFZpaJXNWsWZ84yGKNl19HnL3Dv0Js21x6Xa0ed3 itCEvV5kk4tjHnNbypm4dSxGoNm2w6lEcx9ucpCJRFWEloQLBcjelx3gRth64bQCRYWIETKv1LhS s07llSJQyyZmse9RPNaVtwefuHLcfo4Smz3LOkOmRM9R5dJVD8uhhkFnQITH0xFxg3g44PZe2ar8 OtlqIQ9GQeuLER3bNbn+m5OwpJiWpcqFSISilSTWO7I27vN6PLoTJ23MNyC685qMh0oDzZDkig0q 0s7lCT0MrpBymRBKwitC4UpAtQBaedcBUbj2Hzz15RSSpwukinQnUzbHn6C5+mHPzd3ILdxrClbq dMJ4yseUZiSQzM4pxIGMMoKJai2CBsJObygUtTNq9zqrSx1KxKCIsZRNKKBSVkmbQKC6Ikc1PoKO Vaxq6N1zxt2U1zwegdOeLtMZZNFFDE6/l7KMovrLlg4VRXp4PMfVS5djbFw64ZNUMvOVulCc0+4l o17dKWMIxFFNY0ZOis1zGxfhn8g9Gruwzxq3rccFgZVphpwKsU8CXNdFzWsZrwlvE5QcuXamx35Y XVYuzm3BEhy6SeKHYrDDc5XHdos5mDp5fTjWZ25+hkV1EdiS7+c0uWNS8GxeuZojqUOnoQsVW5Em d5yxHaGE5DtOT1nMlEmsoo2Wwzt6vOus5Lreer4bEuPStKxFarmcAdnK9alDt8+vk7mJnvXUn5+p 2mpYyUq0xybhjat5errpEJ4NiiZIFrBKjIkbHVc+i5/T56c6igW6GijCsl6vMus5Trca0kzcOqdI STK7OrKudtZm/Pm4u3grFJufpss65dmk0y20mz5lr5DHULB0OmrzwnqumhU41M/E0MwEOcZmeM1y D9GyhaDNl1L1eddVynVY1oso8Os5hdSoUiaZUsvUx9caOBu4FyyT49Ft5vw9I3moPGDzEmdJGJJy 11acqNdkufK7EotoJc97sLqmjwsrwtC6cpwG3TnY6DnnjtZcTZzrq3567ZpsMtjlGQWVq4++NTA1 s2aC5Wz3sP0mrlw79ujiZdopeNfsVHHv16OSfrFLya6xHJj7BJyL9al5JuuRyC69Vxo+2VnDQ7xa xw0+2U1xS7VRxC7dVxBeyUcvd21qUM/fWufFw7dY68LHvEV7uPh+jl15/P8AV6t1+G2q6CxwPT4a 9ZuJrttLiSnTD5Kr1nbPyefHpI+Oscr18cvmjsScPPTr5cZHU7uPEjze6Py88Ni15xpdXYg4+gnp RPP+2890s4nEV2BOHJ3nTWOA1TotHzbs8UfOdafF4S5vXOjjumr6PJy/c0dODeb+k4ZkUevicNHs afZlZXVWcuK2toxX5rvqeXDz6q10ctPW1+bhQdiTYGb05eTzk/SXurjuhNb5uIs9TR6NrhfRMzDl KnT29MWp2YubnOjLd5sPdSGdIZJDpISSEkhMkJJCSQ6SGdIZ0hnSEkhnSGdIZkiSSGdISSEyR//a AAgBAgABBQDMzCZmEgATPXkM9OQ5Y6Bg0AxMQQDEMxCJiYjrlTUY1Zz4isqALPVyhqYlUwz1ks1T leJ5pWyvmZijP0kgGZAKuGHTIAJxCeIBJDOFV2CA9oHUnIM5KJ+3XM4kulRE4nmKSBXWVln+QqYT xMIaWjqSjVFg1TE2gsBWwhQoGpICghemZmZgJmTMkwnEBM5GZMyZmDv1EVfrHeYE4iEduM4icRCJ iYEHbqJk4U5+goYQRAcTkJyELAzkJkQsMFswGZAmZyEBycrMZAXB6iEAx1x0AgGIfjiJjEKjoAIB MAzAExFOPrYZGIO05CE5GYWnKcoJmdpkdQcj6B0YYPXH0Bcz4hOeoGYBj63HfEx0wJiAZgUCZhPQ CAZgGPr+JYIR1EC5gGIRmHoBAMwDH6LDIII6AZgUCEzMU5BGOgGSBj9ImEQqIAB0IhEBxPkFYB+k TiEdMTGPpzgcjFOf0mbJDTsZiYhWcZgCDEIzOOIBj9FjgEzMBIgbMLYhcQsTDkzvEz+nYOx6AxFz CMgjBmJjMAx9YOYTjqRmMmIREXJAx0ZcwjHRTiA56/ELEEHIPeYx1HRhkYzFGB1IBhUiCCDocsQp gGAB9A+OjLA2IDn6SoMAx0x1x+iVzASsBz+rn6MzlOUzmZmTMmA9QAIxwCc/TgTH6S/PRiwjHI+g DJYADqe31fMUY+iz4+gIBG+JnoYOmZ8zEE5DPQR/j6FJy3TMJMzA2IGB6lgIzmIe+cwCCP8AH0J8 t0JmenaZWchOYgeeSc8wNA0BIjWTkJyHVPlziZE4CcBPGJ4xPEs8SzwrPEJ4hPCs8QnjAgXEKAzx icBOE4wdpwzOMRAQKkZ7K0SWrWgRKyvh5INdeS0KzGoLWtPKs0qpWhHIoygrVrWoUEUKWdAoRAQK Fc+BS71qrV2cQNjDOyEO/OK/FS54edTBaFllxcLaVXz5PlwRsEPW/BhfiM4Zjfla7OIF3E1vwb/4 3//aAAgBAwABBQDExAJj9I9PiE56iZhMBmZnpnpnpmZ6Zmf0CZmZnaZ6ZEyJ2nbp265+siYh6GZ6 56Zg+rPQ/R2hAmJiATAnETAEwIRD2g6GH6TMQDJ8JENUsAWNXxXxHHhbLpwgqJIqzK0VoKcylQ0Z FQlKw1icT15CZzFYqfI0FjCMS05thrGaeRyxOT5WAe0kKxSeRsKxSCx4HILWFlPUwHEBz0ReUWtQ bOIAqyVrXlXVzgQcVUENUFhr7LWHhAVWGYfqU4OYrlTzbJJM5tkOwIsYTm2FsKKXJAscEWPMnEYY P0HoO/15hOJ8wCAQwnEJz9antmZ+gnEJz0A6ZhOITn6/mKfoMzD3ggGIB0JxCcw/oA4gOemYTmYg EYYgOehMJz+kBMwGEzMBghGZnBDCFgYf0QMz46/MAzAIBD2AHI8BCAIf0VGAVhGJnoGxC4ELEwsT FbE5wnMP6CjJAhEIzCuIBmBYFAg6MOp/Qr+ZiER2gOIDnqTiE56n6CMQdQcRXz0ZsAnPQHEBz0Iz CMdMz5nHIIxAMdB0PQHBBxGOT1BxAcz4Bh6DABYQnMJ+g/PQNCAYRj6QxEJzCfoz+iDiEZhGP1cf R+5MAmMTExMQjqSTFGYO3TPXJmevwFH1N1GIvz9DtxWt2ZpiYh+QO30fEJz9CfJEA6tezCkfyxMd QemOmYRM9TE+fotReNI7wiYEx0B65hMHyRiE9E+fou/wpB6ATE8YnjnininiE8QniE4YhEZYQIEn Ewqet3+NIJnGeQzyGeQzytPK08rTymeUzymeZp5TPIYWzA5E8hnMzmYWzGAaCwieQ9Mmd4MzvMzM yZ++e+ZkzM/bMyeuZk//AFn/2gAIAQEAAQUAAgMBnzMZhEzATD36AYgGYBMQjMKwCYzMCcZjEAnG DtGEAxAIDiCAdCMRVgGYZ3g6WOta7Ww2y5xXGtzdnEBzMTMJxCcQHEziGXr5b9TfVEt2665s76NX p7qrZ+Qqi3o6fkKTKdhbZsDy3am8iIbq1Rd6om7droNO5Vc2yvlv1PYIlb311qvsaM37NdAq3abW R2U179NrdoBjrjp7Ld8zGwyxuM5/zAJgSBMgjECiePMFbLCjGCvAsUrs6d96mizhuCx9iu5s743r jaG57Z2rnNd7Lt2N/v0Nq5n0W57Ce0JmrusuvpBhZbn7jTvvUnzDY1WBr19mz7a1b3sZa31da7yX oTjP0e03fGvzGPCOczP8h2hOYDmBegOIDCZnE9h5kc27CslV1I1dez7c/dG3Xrv4Kblc7i+XUu8+ xvrcJrV311a9V6hq7WOzTs+P19ZA9j5q2NuwrVV3UBm21roS+upTZYLKb7LKRs1W1NyXPXd2hrI7 G1mPAO+Za+YD3BIgMzmc8QvAxhaA5hJhXkG1FiUqAtYQtUpIoUSzWSwbPrix0dQVQnIWoKVqUFtZ GPgAFaKksUOPslMTWVQdJSV1gs+zXP26mfbrFTiO8zLLBWu1sNsuSEFj5lrwoxP78BAsKThNx2pq sYaWx92GlOwtp27nrXacaTGtNa6q9XP3fMVWLctzpSrbZQLsoy/cmHYqWv7oiG+vx3t9w3r7VBtv SkfehJspVdfobnHW2Cl1nr7fJTbtLW+5wtWvfyD7FKxRs+Zh7Sub9t2yAVAsfMd8wjEtswYDMk9A cz2WDq+zoxfsrm99sibrCzX3df8A7G0S+zs3Gyn2Oywv0N1rti5ib9eyznS3LerssiWp9/rWPNax Tt6hsY+t7WbFjizWbx2eusDPpWOmg6EJ6g/673cVWoTQNdjXeyGq2201X7IexrPvXtXwsx5QnEc4 lj8nxOQED5nPIBllS2rt6t9lllN4WvXsew0Cyna1Nm2ymjYGx9leJbRsA+v1uDewDBW3bq7NLOzL U2w9OieNibXLW0iEZdtT6miyo72s1herYaHUuCVa19Vd1e01Xq0KLv69qtfVtvXZr7DLbRsBtraO tVQpztbVjMhOfmMcTYtxE7tiG1hEtdiARDZiC3AJVocYrwIWIDKpmMlwDBUGHFa5c6WLd6+gtp1r XMJZBxEfxmVsghStiq1qeSxqa2IrGPEoB11MStVhAM8NcNaANVVjaqrNn/GGSccQnEtfEtbmah/L IhKiBmMKtxRuUNeIVAhXMUYjHnBZiF+M54hv7B8xkzFQAMoSLaRAeRCZhSDMEBijuIcmANPmZxAZ 8z2W3ksxExiEZhGI3abFkMqH8ojZidobFEBUwkGPxVa9mi423or021PLrK6hvb71szLyuuqqlVlb h9uio2X00qbEVRalq0bFdpEOzUjtt1VH7mgNTfVsBRiWe3YWPfWiU31XgnEu9rZZND3fObPt7g1e x5Fr2OVrWlrWMY4lr4FjcjKxg5ENQgOIQBCCYgxPceQPsbJC7u2xO5ZZQbduzYv3UettPLSzbtVv WBlcWPSEubl96a6Us4rbuu80dr7mr2FhW321xDbFzMdm27UsVxtV212WXI7Ftiy3StpuDpxdn13V Vqya1QuwpurmuQqhgyuZsPD3gErHTJaKeEBzM4hbM91VdyvGxat6XPb7Su1n2ababNg7Ns0rCR7C vb5a+vfaWO0X9alnls1L2t3dO29Rr3OdBSq+317lt2W2rhsWHma9jdf14wPZUbOvsWa2zWPDsbra Qyuxr7Xr7NdcljfUdes1i60XXbVnBqSwSxsC1sw/IETscxPbWRPbGU+wqeIAYWwWAcHVWLqiClQG oUAaak0qK1tVbAmpXl9ZHg01BuoRxXWAr6QJSrxx6uYXSE2PTFb6dXAVQktq8oGuoH2agoAgegWh vW1Gb/rnolDq0sBaEEBhiWNmOeijEU98wwOojW4mp7G3WOpvV7YAmRAYBL7q6JRtU3Hc3gyjec0e lve2qzdoqavd17FTepdvYbzhRvUOle9RY27s3JuruOuz5FK/fa4FWzTYh9nrLL92xtx9yio6t1Wz LPZ6tZ9lePttPZ5nZoGUtyGaOcyw5jHoDiKctiAl1B4IGzFOZXa1bam0u1VnEBBiD+Vl7bF22G1W 2kw+9R4T63XWiexucWuqalj7xYbRc13apol92U27S1pP/asbOogfa2Be9ZUndvbFNmsx2nXWt1Rs 75D6uy1tGif4WNLDhmaO8cwmfuTEP8v2E2O8EBxAZ6K/i4wYRkqpM9l6y1bF0rrW2tHZe7f09i59 Ve2/obJ2tz1r7VY09tjvaF7htLaaq/V3bhZqbNlo1Nj7lgftGey6zX07DNDVvqu2PX7S7V3rdiht bQe02aO5SU1rVopVqlZ8wjMcYjmN0JhOZUhLYgMI5AL3JzM5nr7fDeCkBQwYjdx9tXkqhC1VgIiL HrWyLUih9NGJoQAaiCHVSCiufb14ehHrr9OmvYukBK9RVj1KwNKkfbohtrVheqoLSMg5h7B3yXMc 9CYicooCzMUwGWjAEQQHE0rvJUo5ACYBnDEKTDCFGBIIg7QnMJzCwMJAmVEUqZhRETmUQJPiEwvH eW2Ym1bmOSYDiWWwnuz5jHMJzAMxTiZn7CGAwpgntAZ6q/FNd2YHyBZBbiK+YSADZiB8kkQuphAA DgQHMPEAAGJQXiqEEJjvHeF5c+JccxziO8JhfBJhOYTFOIHmcnEEzAMwDMc9564ysMIhzAmIRiAO DljKwSoqcQ0sZ9s0+3h1jDTYsFbvK6AkznoTiOYxzH7xjgXWZlhlr5hOJZdmVjLE5hPQGAwHLY7j t0AgMtGYBNA4toOIgzAxE5wWMYLGEFrGc3gYmYYwggKGEu3vG9NiWJnpnEL5hOYe5PabN+Y7Yl1m IFaybCBUIgQorDHUCGVjJz0EBEIEBEIxNd+FiEiIWgY5AxEGYS0AIiLmIGAKOYEwFqm1rqjVWilg cwnEYkz5jHELYmxdGOJfbwgHkJ7RwHFwCFmJLHMAzPHwBOZiVDpmFsQsTAjSunMCII44HTfmhAMA zByMUGDiYOOQeMJBgHIABZ8x0DiwGt9LY5gkTOYTiWWSy0mNLnwNvYZ3qOQ5lj8VZuRMAyaqwkuf kYoyUGJiDtMcoEgWKMRqOUZHA9U/OpAYDAMxRiDvCMQfyldPGZmcTMLYnsqfKmuzKDaDGuxH2IXz CMRzmbDZOwMPqnKMZtW5ghlCYjnAPeAZiJiKMdAMwDEBExmA9we+CZTa1JT2qCVXB1D5gsxBZmVV myIipMzIEJjPiPYTC7Kl20olHsFdWu5wBjEHGO+Y0d8zZ7PqN2sbgGOSIoyRgS4z5iJmAYg6IYDi fMJxAcwHEJYxNRniU8AOSSvcdZrOuyyaqL0xDCIRDCAJsW4S6kXQkIdewQWKIbczlk3Pit+y7X+W ocTYfMPSkQGWnMQZKiYgHTOYEJgHCZyV7QnE9YVsRKwHdFMKYgGZ6oqEEAhExiEQiERlliBo+uBN weJq71sivYIb2Wfd4lm01hc4XaHep+MtbJ6VDC5xHOZUO47QnMHQDMBxPmAQAiXNialppOvcjQWq Yyo8OviU8qm17luWGZzDD2jOBHtAhszCczbXy2DWGtDa7wpsGObREQg2fG1AYTnqowCcRjKhB0Hz mK0BzBMwnEtqYRSVlb4lOyTKrswWqRWyABuDU7AshOIbQIdgCW7oEfezDt5h2QI22MVWqhU+Zg4E Ly11wxyXm13+gDJjGGVCftB0BxFOYDAZqVeSza1Q6W1cCO0W2JsESrbIibYMGykfe4Gr2q3JZu5l m4Y+1mPt4jb2Id+VXEq92ImwBBtLDtrLL+cEc5mz1AzFHcR4YnYTMHQHMXtBBNOvgAcjb1g0elkh QiBsQPieUiG4iG0mLaywbbEZdoVxAaBFcGG3jLLgSHqYBdcwUpEAEaxXYGOe+z36AZmMRfmOYInY Aw94vzmAxTEM1U5uiYinMCB5dp5lmviWUR0IncwmZzD2mcynQ2LJR6xFlaJXCTA+AalcblFRtdCj FJwyUUIAYTk7HStc9E+T2jmDvF7AGdoOxgMBitievXCJ3iLkoMQjMv1+csp4yyrMdOBq261g0dew L6+gRakSYE/YgCA4nLMut8aVjk1z83JxK1xAYITmbEExxUmL8scRjFgHbMByQMHoDAczTOFr7BID mAzOZbQtg2NUpNu3EJnqtsVnlgF8QkmBzC+YC0yZsObG2H4A94BkgQGZmZsfFS5aww/I+T8EytS0 cFIlmTZWAoOZ+4n7jvNezEqtxEfMB6DvAcz2e4tCOeUFcK4nrdoTIMzAMQdpyxNi3xITwRzmEz4g MBhOBmXnsowHOYehMrq5kotSsnKOME/zqqM/efMAxKreMpulV2Ij5mSIr5m3trrpsXtc4GZnMAzM TU2haAcwtiG1jOZMceRbrGAMDzmBA6mBxHcYJzLu81dVbqtjTZIwx0UcpTWEVyWLpwRxlyMBDhoR gz9+OYj8JRsyq7MR8xrQk3dv7hycQnA+BjEBinBp2/JPJiB4TOeJccyxAYRiIMkhTHrBhTEEr1br ZqUNrpcnNbBglAZTVHbE1a/I+w+DrJ5LnbFE/e3swghMxmaNSvDmmV3ZG/tZjHMXJIGZnJzPiA90 OTVfiByYXMUR4YYBiF1Ea0QuTPX0+RwcQtmZzNsLhHlTYhHKa2p9tp7D5GmOM2AUrY46bBmZnPQT Vt8dhAMspIlrEuTmA4hM+AO8BBOITiKIlhErcPGMY5jGGWAmY6AEylFoQ7SCfkFLNtPbGQCA4Zzg 6yZb3m4hptOYleNbafnZYMzn/G8/TmaGx5EIm7q+WFGQg4gmcQno54xRAeMBxFOIl+IXzCcwnMKk zhkHXQkV8CQSeMCKk44IGQ4wWOZpBOOwGWEFmLqLAeTccz9rjk/TUWDDbbhrbA2Fv1VuF1L0t8zP QHjFGYBmH+XQnEPaA9y+SMGA5grZIXEx2IBgOQqYiahshRkLVEwVkSqohNq3E0Bl3LLWey9Nh+b/ AEAZnq9ambmi2uyE02VbavLUFg2NNqugMxmHvCcQDEAmIDkjtB3JOIteCEBl1eZUcQHMAxBKrLCd irg9SDybe1VqNsbT2sTmCvxVWHyOxzPjoGIhOYegxEfjE2Skp9iZtJTZWrYlF+AOJGxq4mIDAcQD p8TOITgKcxDmCUWdhaMNycMzEg8iigQFVB2LbinradelbOA2LebEmadak2uwVEzGXEYfR+0zMzvE cpDsgrQfKra1wn2+0AdTfM/EbTQelvJX0dkX0ZEHpEn4WubVJosJixBgDvOwJYnovNzr6DmN67Eb StErsbTW7bd2F5WM3OV1ta38eLvzZdzhDtEw3Znk+j1ddVl2zRRTNLTQjcuQQTU08AGAw4MJtwrW Q+WBbo1dhnhsMrQqPak/cE5nwB2i/PX1lSfbmlMHWzDruI9brHrRo/rtZ4/p6zB6eyoX6V6mytxC hhGIRMTGJiAZmmqi2tG2LNu7wpNHV5Qd/pz0CnHX3IHnzAYDgIe+vrPsMfTXEWVPU3rP/NaFM8fC L5IrvnzIx8dTn7ZBDr4BrKxgMbNesZuKEsJmZmA4gaaz/wCzRArS602trVeV5ZYtar7BGKWu1sq2 Tbbru/j8qYDQjoTPdH/eO8E7TODq7J1np9hrMns9qq8esP8A1reQFmwWV7UB5KsVeUZVgQNEBUT2 P/GzGbf/ACEdCJxMCkzWQ+TZ/wBVOJ6+vimJ7AZs44j2cb7UZK9U52qNZr6tRqnb7hwTuYFe4LbA Mz2NrW3AwGDvMcIevrDnWcEwM4FYS2JQKzbS7Qq6lthgVfkBu1537VdSnGbR5WETBgEEBlZPJ73f pqjFc2aUuQa7sG1ai/21TL4KFPg1uOrVVWBr1w1qYuonkxie41hRd8REJmQszG+enrP/ADQJkYUR gDDWJggAtFxxPy/+N/d9gf7JiYExAIg/ldVWrTTPKuFcjCqcISCogcQsZxgQmCsCYhnva8uFUQjM 4TGI3z09Z/5scYT3+kx9Oppu0CgXAM92GfjOIgExiARTgk56eutAPE9Gr5QUgEUiLQBBQuMYljYU uywMDNz2K1Tbd3rBzB3hGAwh+YO89X21s4mf0PaS5u7/AOWZmEYmAZxi19yOgyJqbwfpgTA6CZmY 6hxcNagW7haEASwZoZMRWxAcxzB3mIJ6w/8AWOMqHilszP0GezPeyyOcsTO8BBh6AwzE+OlO7ZVK vZ1tEvrefMxGsRJb7KlJb7G22FMRnz0b/jIzGTEyRPmBSBiE5nrP/M8PeAkQM0NuIHB6me0/yvpN QI79+gEIExmAQ2ieUTyTyCG4Q3iecQbTCHZsaeRzM2QPcJxsnGycWE7iYhEdIiZi3NWvnzOVRHr9 6iqnzLaOGQf4jixhyAWgXMAxDN7vduNmEEzHTjmBMThAkxAMQDM4TgIKxAgE4wKBAJxgAM4ZhqzD TDURChmMQjMKZhWBSYECwqTACJVu31Sr3d6Sv3lRlXsKLRnnMFSO/T2ZIe1i0xMTECGCtpwaAOJh 5/LALQMZyMDTmJzWclnJYWUgACdplYCohYTIhwZxUz7cRqCYKnBWkieMwIRPHmGnMFU8IlZeuVew vrFXtzK/Z1WT2Vq2MwLQ1mGpp4mnq9FLl/EVz8RXPxFc/EVz8RXPxFc/EVz8RXPxFc/EVz8RXPxF c/EVz8RXPxFc/EVz8RXPxFc/EVz8RXPxFc/EVz8RXPxFc/EVz8RXPxFc/EVz8RXPxFc/EVz8RXPx Fc/EVz8RXPxFc/EVz8RXPxFc/EVz8RXPR/4bPtqddqPe61rbnsU1Wb+x0rE/sevYre/rUeu9xR7E 7Xtq9ax/7DUgH9k1mSveqs16veUWR/f1pNf+xa19v/6CgHc301D6/wBpVvzc3V1F0t+vdXV91Rs2 7PtaNc0e91rG3PdU6b7fsa9WU+1ou19D2lW821u16op99r2Pt+wq1Jpe1o3Gu99r0ts+xp16dPbT cqmz7amhtb3Wve+37NNWx/7NRXG95Th/7Nr1z8lT9tq3nW06KRvPt6tdc9lczqPBx9f6rX3qLNfG 16fQGo3svSU7r6tH3F2zpJqLre3Kamtdza0o1nqVobZ2LWdd32jWr/WLSr/2Sw10+o9kdbb09lqL 6kO9bv8ArvtEvsfYo2fYWWjU22p1/wCuFlT+y867bONz7drbG4AdPeutOBZZtj111Vi+0vbX1aaf v339A6c2dx9lM6+PYKKTnXwtCfYaWv8AdamptHSt2tkGbn8KajqcP69fXcl7D8lpAcJ6xg23/ZiF TX9dTZqaOAtR1+ejsa1V9f8AsijzT+uf5/2khdavW56egovv1dltK/2nuBtK2s1Gh6vFu7u/6G9H Txr/ALSHW/etoufYDam2ln3u7vCqijxGqr1O7Yu7vUnd1NLbOld7T2v3s9hV9uNb01Fo/sSmu7W9 NRcF12FHo/8AD2PqadyU+lWk2+lpvRv69SD631/2k2fS67W61fjWH0mvTZt+ro3K9X161qPR69TX f1zXBo9JXS9fo6ainoqapqeor1G3NGndq1PWpQB6Gmi3c9RVtLT6RaGq9enjr9HVr2bvotfYbR1T SNzUr2q6/R1673epq2Ktb1C0Hf8AT1btb+qrvq1fSJqPSnBfY+op2zR6VaDd6Oi8aWt4R7H1Ovun S1vCJ6P/AA69v0e07fodv0u07de31f/aAAgBAgIGPwDUc4aGbTlx05cdJbAtspAXIUjEZe1m4ldg Zoy+JTxochBPPzigRHK0a+tPLqZZ+1o+tU0qhgBanFSkeh6KXbmBiwNKFZOUQ/Fr+QpGUM1XjLgP 3os5rWVOD47ARJqbJsUIk1Nk4PTTRgFWiclA8aozuBwRJ+Gg/wCOKoVUhtaMhg79WUcwHafq4qMh YOD7L8eBi7n1dPK4DPT5fui7F4sKhxfzRCgkMgFcFlpMZctcEY0kDERBOHm6yC7BTYZTIAN1upBg c0nEuC7cCC3HkiQAHkC1KemDqJ+/MSObqIgLC9PcFAG+zrsHO2prgrnsaaaaKp9Vtd9Q7idjXda+ BA6zhPuT6W29dFNyfw2oVNNNwfcWKfTTZU36iY+CN4HRV1W3V9o2yG92VArK2o2iusBr4rFYrFYq 5Vyr6bq5VzovoM5lox4KEYEtLjghmExXFkMuZyAQ7YoylmeN2ZZ/xAmpUx3HK1meqlHujlAuzuV/ 0P1HBH8guDb90TInKACeqgYyOWRIrcFA/eSKciWX/MGjs6ao7TKQNw3zQr2kRI41LeyH9xr0w+KM 50iOCgYE5ZuOYZR/G0ou92/hRiIzDnFvZShIZoyuFGTdsLB12xIPMuo8ogfBSj/cGUYD7X91PNGk yDQtZSyBna5exdEHEjoyiI3jLN7MpZovGTU9LKOQNGJdlKfEM3BCbOhFuwRMWxrzQzfSGDckQRUv /DfBqKUJDNGSGUNGLsPUMs17+4bd/wD/2gAIAQMCBj8A/TlNuyFWcE1wZA5u0jM6hlq4d+qzk+1P isz0cByOPnksv3GRAHpcoPjyZRD/AFDMh3dxjmAUjLCLps3c2YR/qpGWAxt1U5ZaAxAHrj8lP8Yr JyI/6qg7RTNx5/LlrZhdNgzdCg1gGbku7CyyxYcWxRBxqUJvUKwHogA1AwpgoxjhERfHmi2IYpuT Pi3BFrG4KJoc135WRl9xxQieXtbYHAAOVmPdHKZDpxUcg+qrqMQe6Yfog5cMS2NFQ8fbzgnP/m/u pSkWEW90ZGXaBE0/yQkS0RAEsOJKMgewclIXOa/KuyeKd8G6IPhZCT1FlmFD6K/kpnwy9FKIvJkX P1X6K+DdEa3wwTdfE23x94p4JXda7m240TaX8IqnHhDbr6p9jXWMuCrw3QxOKO6OBVSO6fBF9vTV 6hE6+CsFgsFgsFYK2mwVgrBVTAD9A//aAAgBAQEGPwDs07NdjbGKqm212V2htle0/aMpUAus2GA3 BVuond2KbabHC09KRkImOpI5ZSjUGDViQcSjDUMjllOJkYzkABIs8mIs1yg5JzVjkjKbgY9INKhE aUpAm0ssgDvAkzOz4u6m8dWEGgIw1s8p5utyATKTEDD7pVDInEDTmSOYEXj3ss8ZAx3qpk2EjCWU 8izHuKOR3jcSjKJrwkAVp6ZMhGQmTlkY2ytWJBxRhMyOWepF8s5sBOQGaTHBvUV7mYZL5nogHMXs ZwlEHkZAAoiZLgPJoSkIj8RAIj3sskSczO0oyi43jMA45LT0yZCJjqSOWUo1Bg1YkHErLqGRyynE yMZyAAkWeTEWa5XuTkBE2O/lvQBzQfHU05wHjKICB1Cz2FyeQFT3LICRI2E4SgTyzAP3LS1s0s09 WcZPOWVuv7L5RYWCEAS8vSTCQieUiMp8U2HayR9MfM/SyaKrdOqqqp2KbLrTa+TV+OmozlMkSmYS gwYdRFKO4xrvopQj6YDVMRuf2y3i5717upOR6nEKCAaWUYPbiyHD2f8A+ylISyiOtDTyABiJGIJN HfqwItijon0SnGUhgWifmInuR1JEmPuDT9ogZWz5dzvjfuWsD+AfFaR/Bq/0qBMiRqT1IGDBg2cv Z36a1xspQl6dMzlEYOSPhVual/ydXRnpyBBgJg+HTGjbzI8Vrao6iIxAJxEcwB7wHXuEynMhjKWD 3agWk1/b1fjpqM5TJEpmEoMGHURSjuMa76KWn+WYygTlEg8IRkIk/aGWrtSVCwjdasZ6g1QYjNES lMYuc0t+6LANYI/mb6p9vTEjXLFov5ky8Hsvb954moztn5hso5fNQ92WSI1JyPHqmG73UpS9UaQj hGBxHP5Mq9n2oeo3O4Kq49qnYoqqGtoRzmMZxIcD1Zd5G5ZhpR9w1z5+kE45XbNxEX4oS0wdSRE8 5DCssu8inSyOm3Xdv3nUtaUCJPBovF+nPxb7W9TMo/3DqQ1RFx9kwO9vs70dScSNWUwYRDEuIyvV mMXxfdVghP8A4+pHUzDNKYkNPjL7pIFiQDxwWpqCxlEeH+KhqaMc2WM4sCB6m3kblpmMX1ITnMxc P1CfFvtDFZ/TqvIsTcSahZ9yyHSy7jKbxj+yMxy9wClDTBmJxiDJxg93I+eyGroQzGMdSJDgerLv I3LMNKPuGufP0gnHK7ZuIi/FSnp9cphtWrPdm8WRAgSSBEmU45mjYUYNU8d6GWImDGMdTTJuYgBx 3AbrUKOkdMacJeqU5e5PuJMu6tFGGpD+1GUy7hiJZuL47lpvFxHpMyRWPi742vzT9h/tH0hGUqm5 XFOmRTpyqKyttpsYpyEw2OydGMh8vNVnqEbnH/lfzQADAKioE7BPRMqBAKybY2Cdq7WG0zlYXRkb YDcE+O0E0HmexdXR9uupJ46Y/GRS9EPVKMoiMpGT9RkwJcv4Ci/swnqAUJhlA8ZSiD3OsgeMxeMg xH6uIcIR0w+pM5YM25ya7gCfrWtAZss9MNLM/X1u9cznpwbktKWjperTnmGlEBy+mz2G+pKyyEtO YDmM2tvcEhuRWbT09ScPvxEQO7NKMj3Avgs0C4tuIO4g1BWeZYW8dwxKeWlqByBGkak2tLp/eyqU pgwMC0hNnGI9JkKvgU/s6mX7zR/lzZ/4XQ1X6DYjHg134XTy0tQR+80T5CRl/Chqu8ZenLV33LS0 9TRkImbyziJiRkldpSxb1MtSEABEahEQKABhZDM7ypGIDkngPpxWbV056cfvyykd+WUiO8BH3Ix1 IjSzREgJC5qFoxaU5nTgcsb+kVqQBzJC1NTX0vRpxyjVjEtJ529Q3WK0xc5I/Be3GMp6jOYQag4k kRHea4LX1dXTaUYD2/ciHiWl6TUXxiVlhCWpIAZsjUpiZGI83R92E4SwjJnPIiRjz6qXKMDGUJxA JjPLYvXpMhhvUTKMo6cqx1Dlymj4SMuTx+ITR0dT2xV+kPxymWbydP3MqphdbygNlNj7NWX2ownO JFCJCJYhTnImkM0amlb7qXruQ0HMdKMBkjCRjzs3pp4r8tMl9QmQffGvxYSRnYxIlEgsQbYcCy1z OraYlGtnz4WwWnpkyEfbMumRjXpGDHFflZTNdQQE+MZ5c3iiY6soCABaOnqSA4nKREv+IEKeoARC YjUghyOfD4BaINm1JD9oMB5SkoahlL3JakoSjmLM5plt0itnUoyqBKUv3owgB5E+CGsZS906giRm LetsuW3p4P8AadSjEuBEziMPcLRJ8P5jvWnqmUjqTkBMGRavqGWwy8A9FMado+4YDDMRp5vj/Ed6 0pGUs+oSNR5Ej0yJ6bDKQLNuxUx/7kvktecK6kNKPt9+Y+ZH8KgYzlKM4yM80zJwA+atq0owqpN6 IxlGP7InJh3W7kZQLSfSjI4iOWHyL97rW0xKRhGEZDNIyYnNiXNgC31qP7MfgpkExza5jqSFDlzZ RXDpAC/MQzExgKZpGTExqHNd3ihKU20ZSLacoe5nlXAAHeRmMgwchgvy+kHOmZGPVdmlE9zOBwUN SP8AqHN+WmeJoJeIflJPBsmkYx044dJEj8IgbiEZx1zpykcojLNlezCuT+ap5KUJeoHq6sz8XVbJ hZOg2x9rqUJemQMT3qPumEoxIaTdTA8qPjVCMcmpAekawdvKT86L3dSWfUIalIxHBS0pOMwbNuR9 0ws2eL5vhQb6oaurlPTlGUk4jgNyhHWMTCEPbGUl7M9g3mgT7c29MpjqHkfIhGUi8pFywYfTitMa f+pm6JGwLWPMOGo+8Fe5PQhpH7WrmhKUhupUP+981OdQZTzQlyDP8QnPtCVvdEetvD+pAaZMZROb PvOL8DuRf24E0lqRj1keA/mQGkTGUHIkauTd+f1blIj2oTN5Rj1S5nK480RMuSTIshqaUsmpENvB G4/LcpQl7emJeo6UeqXOg+aHsMBlyNIkU8Ch7JAkIxhIS9Msob6XovaidOEXrCEco50FfAIA4ADw UtTQkOv1wn6Tg+OF6F17UTpxhjCAygeAr5IRgQYA5gDKUTE8DHnw3KE5GOTTY9LhgLhv1rUkY5fc EMkSQSZYyoTcZQMaKMXHRVyHD40xqs2XREhaYj1d3T81fMTUkqqdNtfBMFdVVU8mdMwZOAFWy4qg FEHAddQTgLJOLg96eMCf3pEeDsnIZsE7OmAVRVMKKyoFVUCsuKsqJirJmRzWYu+5GWnHkZSlJuTk t3LKKkqt+yNg800QgSmxT7KKipsonF02OwEpwapye5cVVXcKngmZP5Jztp2K7PahYeo/JUuqdhht 702xtjJ5ERAuTRNo6kJS3RkD8ENM6kBM/ZzDN4XRGlOM9QXyyBIQlqSjCP4iB8VKWlqdEZREABEx LxidxOOBVKoe5OMHsJED4rNEiY3guFl1NSETulIBCU5xjGVpGQAK9yUoiIDmRNPFe5CUZAfaiQiN LUjKWOWQl8FXwXtGcc5tEyAl4XWXVnCBNhKQBWQ6kc4vHMHHcj7U4z35ZA/BVUTmhHRM5QriIkh3 sLU+K9yUhGH3iQB4p9KYkN8SD8E6EtOUoiVYx04CUm3l4yw3AMpR1y4jA6gmBUgXpZ9zM+5FtSUT TphEGMXtmJBPmOCFhMyMT4Pm+mKEATKMjlOYB62bK1DRCMDQE7vTG58aBuB7Few4KYJiulOVEwIk wpGrv96zcnMcd6JjIkxrEyy5gf3aD6XU4MDnnE1s+WPzRiZCUtMCUZgM3xQjEtOcpRzkPliHYDuF d5UoSILSHUAzuAbJ0dNsuo59w5Xk78TGm6tmU5meXUMZNEinM4FuFuVyCTFvSQRllxlmAke4De6n OFBBi3CVD/STyUdGX2JGfd9n+In/ACoHUDkx94xOJlSPhGPjIoSL5hUSYDKeHVLxpyUJt1SAJ5qc MPdj8IrWb7QH8q9iIHVqyDmorMrNmzT02MZgM74Y96MSWEot4oflzKgnLTEm+6SLPw3rT0oHqP8A bjOVcsY7ubOeKz5nnBpCYDZhuN9zLO7BnWX8vGRJEpQjGTGMNzvHDDuqpuKyjHJwGaLjw+C/Mccv zWoIljEwI/iohOXSX6ah6Dh90DybFEgCrReUsobAChd7+GKePIjceyAmTnZVcFRS1NIGUJxEZZak M6zHSIBGVoQYBvw3CBySYmErUtHG2COSEjGQFQH/AMEdXSBMScwMQ5iTw+gZDNCXUcxkRfm1rcEW T60JTlhOMRINwDHL4Ar+48QBLLmuSQ1u9SjLTJlIZXMf5ZWD4qcdWEhGccpcMhpakZZQWlNixiOK GrpByBllHhg3KqERpMRbNpxiP5Q/e5TSZwMLOpasImUJkS6akFgPk66oTJnUlu7C3kjGIeR1JZWu +Ysm1RIRfrlMMTyDDyCdkTCMiDOWpCUYv6i+478VHVAMjSXT6oyN6c3sGwT6oMYv1SnQnup8GWWQ oaLoEiwyxnAPTwLfRkTq9IMckRu49yMRGRdny2k1R9KcU0/VIvJe2LDpPCP2vH5BH7uaRjuaQPwf yRe8i/cqp+w6qK711RTE5DxsnBdfWmdXqmFllNkwKvRMyYuq3XFOUxwTCyf4plVOV7wnQSz5W4vd /kgZ4oAJimTqmwiQBCzaMiY4xKbHEJlQsnJ7IGxhbft6T04xNlQtLGJ202AakmOERU+AcpoSrjGQ MS3KQBU9USnkBbTEDKDhhWmUmrtgyMtSU2j6RmIl3y9Ra1/FZtQkvLpcuQOJ570YzJDUJyyIB5gM /B0ZiYAjfMDE14FjXBZIyIJNBKMovyzAP3KZ0ZGI07MPVLnuBpTxwXuiYymgu78rvwZZRIgm2aEo v/mARhGUx1RaWY+3EMKEel+YxCj1yc6k4yGYswlIel8vkjOVIgOSdwXqL/dMJueQyuRxAUtSMg0a yoxHMGoVZSfcdOb+GV242URGcjGU4tISlkyk+lrO1LXWWZObdEGRHMRBIWbTk7XwI5g1Cy5nbGMZ SHjEEea9zTk8TKHVA4GQBqPktQEkxBAjmkZb8S5WeFCmN+2NhgDXBcU+wSiWIQmL4jirJmrsEQTE 6k5CUhcCLsPAeNUQJE5GnAyuD5f4L2wTkEoxD3AIjw4qUIE5Q171Cyx9IOJU9OJYS1PiyORyRAEG e8mXKzU5nemlIFxXqBrw6Yt5niiXNYiZf70nJ8TVZdGReIrmwfF6MS33TayIjQGoGaUu/MflTcpP jPTJ/wAsFH/u6n80lq/9uf8AKV7c5SiBFxlvhv5ouayhqQPEZZfMOsmpIxjGL9N7jeCoxHpjqwbu lFR0jKUYmJnIwvKVN77/AAU9T3XtpkRu0yI13XfmjGJEYgARGYAd4ynyIWvpisWEw33gXPwClLfL 5DY42U7IO0Swx5qu2WmbSqOYXFWqqI6uiHEjmyuxB4HzQlr9MQXMXzSl31+KziPQZRlmccO/DcjK EXhJquNyJe+CziPQZiebMOHf5IaukQJxoxxH0+KEZPFrGWo7cmJbyQnpf3AYiMnLGmO6qd80jSUD KviTXxWeYzSND1RengPBCeXpJgSXDBhEHjhuXuGPQJyk7jEk88dy1X/9Of8AKURo3jF6SylrXcKU 9Rs5jKMI7nDIy1Ys4YVBx4IamX+37kdTM4s72v5LNoDND7LSyyj5jyKf8w0RlMYxjUucX4XxqjEB wbmM2B5hx81KBOaRMSIPRgaiu/wRjMZXLiO7wptYdqmCbYRvTHbCRs9eRTC21jZOspsmVFcJgQsx ZkzpwVcJgyYspaZ9MgYmuBROmZSehzEfIBClU5umKZOqqifHY5TdlsEw2V2ZscexGb3FU+y6p2HO xlW25MLqqfZddJ2V/QMOyybs1TG23K9imPZoqqirRMPJPtqqJzb4phbY+ynZps49oHsse5NslHv2 Mqkp3onTquK9Kqrqsl6qqiZVqfLtum2MNjBPsp2B2XWbx2Ab6IBOgBtrsurp1TZlhU/a3BCUbfPs vtYbKqlkwVE5vKgTfoWKoUxOyMuKpscFOalOqJkxTiirbZVe6Bf1fWn+zL1fXsbsOmGx1Wyoq2VF fa8r7uw3aZMoyVVSqsqq2ymym1ivaJ/WFkPqHw7NFW+xsE+z4ok7GT49qvZ6SxTSFQmf0nYyvyVU 2zKnl2c8fVCvML3fTCOJoOQ3p9r7W7GUd+1z2H2ttfbQp49667/hqhKNQbHZVYJ8N6p2KJkSLrNr SzyfpjhEcE4Pppl4YeFk42VTbCTsZHen2N+grtbb0hyn1JPwFAmC6Sy6g48CssRXiq1Pl23RXVT9 m6bTiYgXMi5P03Jpd2yiqpE7tgRPYf8ARcdlU5UiUAV022kD1O8tjpu1VUT+KYgt5gqtQqxKoFlN tgP/AELJt6eNlmeqqmThCcb7t6zDvGI/RGITk0X9uJPFPlTGKeV92wf9BXY8rqiePgrpymKZ1mgW KY0liNldlD2KGqMjde5P90blTY5RQCHYb9KCbD47Kp1xVdldglG4T/axVFdVKfZULOcaRQCurpnT C2xuCG18P0tEBimVBsdMVXsUV6qz97BdUm4RqrSkV06L9xXXo5RvIKpQYBdcHO9yrzj5rp1fEFPK QPJdPftGyn6RtlbRT7GPYbYx20VmH4k+r1HyVIsqJimkAeYBWWIZrkb1lOxgmG0bHP6V0+J2udtR ty6oePJ2WYRofulenxKaMcvIJ1ZXTvsJxw5rNK15FGQ7uWzj2m/SsmThV7DELgsuOw6UrStufY52 Mm25RYfFZBYerif1fFOe0O3TY0rITHI80O03YpsIuTYJzcp9h09WVT6X+G19lLoyP0de4L2ieP0q qWTDtg9h0wTC6cqi1Bj0t3pj2aqux9lEZHw3lPI1xXFcE5TrLL1/FNsfYYmxQgfs07ttdl1Q7RI0 NVSoVdrrimxTLU3Bq8W2kdi6qr7HJpvRl9kUiE+JsmxTJtji6yy9Xx7FEx2VTkJmVNrAeNEYkueC 4ptjpgnR/Co83RJvKRPyXh2WCqiTcJxZOLL2496rYJ05Tna+xnouCqnPd2b7c5tH47LKy/EUyMfB MpfmJY0iud1PU+7GnMqETuQB2Dsgm2KoiY3Re6ZMmVNrYrKO/Yyp3psOxTbS6yk1+1zVLJhGnNMa R3BZgnTqMjbFQ0NL0xuqqIx1J+Ij9AmwFE6fgh2sp9Q+CdZtMdWPFESodj7GCYJhfY6fFfNVt2KB CllR23IMLI1qVVyrKltoR052lY7jgssvFZRc0TfY0Y5Rzx+pGRVU2CDdp43XEb0cCMFW+9NL/HsP inOxsNoAT7GVCQnj5oZg3FUvgqJkwsssRdGEqSFCqJk8qJgpa8vTpAy78Ex9Uqnvum37cwDDssiN YeqhOIVOqGElmFvJNKkvJNKoWaNY+YVNlU2CbHbVE7CnFwhIWTFNvtzTFMduXSHUnnLNI3Lue9RI FE/5ZnIq4diiTdVUfy/2ptqanACw+ZVLYck+2ir2KJwmkXG5GcKSGGCrZVL8FSqMoW3J0yoq9lkS nCyHccvkfrVK/TwTWHCqqK2dANa6pfdgfpghK4+l17eiGenSKlH3SDrEf5fpvRIuESnKOvqejTq3 3pYBGU/9TUrLl9KLim/ROK8wqQD40ogJadRjlX+k53xCDQYtuVIxRJEQ/FXiO9VnEeKrPwCrM+C9 cvJHTOGwvsZBlXZli5Jwun1CxOAv9ScSY7iiwB5Yrpic5DZmtyRcl9lEIRuUAP8AR06/tS3/ACCM k0R3qyt2SNYAxESapowAlK/4QvclEfhDL29MAAXIA2Z9TuC4baAAv5KoCoyqQqSwXrRBLovRPsZD sQOUORU4phRUksCqgoZ4g816WJxBXRKpwKMYEEy9c+G4fWsoh0CzfFMxG/ZXtA6lY7t+7zVak1Ky R9R8hs9ydvs/oH7D/hHYCyxYNUk2RySjIjAE/UskwRLctPkhmDhMJEVxXqBXVHfZNIMeITBn4Jo+ KYB1ZF7IxjAEnGyIjQMOzZBHUkjI4oRwxTCwRlMsAqRkxxyowMSIgUlv2ammw6LcVm18sS+9ZhIN z2U2j9kdnMA4PqicVWUoSxGHkoxgTIgnqtRafJZo3GG9GYHTENXEpiHIFWwTCTYp5EMnlHwTDNEp iXOwDimsu4bG7AUYDHYZ4nZpRl6CapsFqiciIZcMOSGtpRlED7cpX7lq/iiD5IGJBMJy6ZWKnoy0 xCYrICyyARd2Bws6HSS4B8VkA2EyuCYjkE2yl1x8uxp8l0o5w/zRiI1xTwLS42RYguyGW2JWYDpG 8VKdVLMgxBTHc6J5fDtBk8pOxbZHlsyzsMdyynWOXzRlKTgxykfrWSepKUcAozJlmA9W8cVlIka5 u9E6YbeTdGl64qwXuChVE4tPq2cN6pffsO3T2OaBUDKyoSFRVCoGRR5IvfLvR7QQMAwIB2R5bGKb Lg6bLXcj0gM6sOHJEigw7UCTRj2Tt0/pit53Lj23ZuSpijkFGqpHj+h9s4223ZO9U4Jc3VHTNTY6 ckeKePkVlh1T8gs8qnNU93botNr/AK0w/QxwUzegqjz7Qfa4WTUpLfv/AEGWQcEMQusDkjDRGSJu 1yt5Un+9H5pxtYbeC0/piqllcEJj2xRTj94hE8ey6bssC43FdYMV0yHjt6pAd6ocx4LLDpHC6fUN d2KYUGyXd8VXsVVdmny+auFQU4K571VjuVaKnYDXogbu/iOy/buFfyX6lQyV5FWkV6T4pgG71YeK sNjHa42MZPwwC6oxfw+CDZgcbH6lCE5MQgYyAVgyLunLFVdXHet3ftgOSAbefHtW2NssFZWVtm7b VP2LbHKdME2yt9yqnFF0yJ5rrAkv7kTFdMk8SCCny+CfYCLhkZGrbP1plZWKo+2oVfgreSsrKyss VisfPbV1jtsmKofJUVmT9j/Hb0khM781/cimNF0mjYXW4blZWVinKsrKysrKysrKysrKysrKysrK ysrKysrKysrKysrKysrKysrKysrKysrbDAZpyFxDDmSRHud0ISzacjbOzHviZDxKEDGU5EO0Mtv3 pRCrp6g79P8A3EJQjMkkjL0OGb8TY4FOdLUb/wCP/cUo6YlGUGcSbHkSF7WWU5AAnLlo/wC1KPkn lpagH/x/7iEoxmSc3T0uMrV9TYixdf8AKi/t5TPiwU3jOJhHORICo4NI+bLq0tQd+n/uIaOWcZF6 yykUr9mUlEzhOMJENM5WrjSRPkogxlOUnIjBrBnuQMQpjTEomBAkJNjyJGCjKQlIyOWMYs9icSBY b1IwBBicsoyZx4EjzQ0YxkDIExMmYtyJPiAjCs5C8YYcySIjk7oQnm0yaDOzeMTIeJCMJxmcrZpR ysH5yB8AVEZZTMgZAQy2DVqRvUvzIcRgSJA3BGFCRjvU4QjKMoNmEmx/ZMggZuSfTGIcn6caIacx LTJLDPlYnnGUvNk0nlI1yxu3ewHeUYQeMxXJJnbuJB7imIkYi+pEDL8cx7olD8wTmhJsmX7Th6Ww qo62mCIytmodhgBKco+oQAp3kiPc7oaZeEjYTaveCY+a9rJOcsokcuWgJIHqlHcV1aeoP/r/ANxR MITnmiJ9OUMCSPtSj902dPLT1B/9f+4v+Y59ts1qrU1Y+oDp5mg+KlCUjHS0wKRuX/wJJQOhORgb 54yp3iLEclokzzH2mMxjW6eQkZYtqgP/APkfioyGeLSl9oO9PwthuC/48pSye4YXqwLcn7kZaWbq uZH/AAQ1pGcZsAchFW5gqOnqmWUgmhrbvWnGLgSGqSZfuI/lGh6JQzHUIu9WyHfvX5ki3t0/zBH3 SZbmnlb+CXyXTGYkIyMXmJC37EVDTJoAG8FHUB6hCGn+9eX04LV4mH9S0pi41P6JL3JHonSf193w dR1BeGnLLzylHTMjHSgHk15E/MlRnpmRhIkES5PwWlI3MTpE78hp5S8lCMT1iENHvF/EnyU9I21J QmP3an4RUtTHUl5R/W6jMSYT08vEZSfi48OSjHSGR8sfWT1feeVuS9qZOWWoIy4iPT8kI6RIHuZI 1sJU+a9vUDSjlHIAFx8PBaP5R2jAMTuesj3CnMEYrLoSjKEAIjIQW8FqakaSZgdxkWfudTjOUo6W mwEY3Lv9SiYGRhJ/VcENy3qE5SaXsxiTvyz1AhmjN8W1R/t/NRhpkxj7MGf9qaGaM3xbVH+380dJ j7WW2LXWpoihlEtzw81MakanpnCVLcRbwKyaZOW2V83nkitCGpQjTI73QzaUTICpOtMOd7ZUY6cM kYFmd78bpt2tL+c7YcIn4LQ4x1f6EdXI8hpylmzSuAeLLX/7f9QUvcgNQFmzTlBt9gXQjp6QjKXT mjqSlf8AaARI+zDN/lMX8nUzhAZ/MD5rU5w+a0yfv/0SUfzEA8oGWb9l/l8yvbtmhOP8JARzAZh0 zjLH6ubFRgAA1oxc1OLsO6mKiSOrTkJy/eo3mPBRlhF5/TvKlot6JSA5YeTLTjuiH5mpVfTOERGX J6fND/j6eR4xjlpWXd3cd6E9SrSjqftWJ83UZQDDP7h4AF/q70fzMox930wkYh836r8goa8hTUlI B90frNf3QVpkSfMGlxBi58D8FPTj6pDp5io81LPEOaThKlR4t4FRjEBwMsYxqz3qQHJYYBlp6RuN KL8zKZPxUSNPAH1S+tRgaH2ofzTUSNPAH1S+tGDYM2zNOAJ32PiKr+3AA77nxKA1o5iLVI+BCpp0 /al9abTjlBv9CvfjD+4TmJc33s7eSY7Pc0YZZb3PzKjHXjmMHy1IZ+RCOmYjIRly8CpDTgBGQaVS XHeV06f8UvrQnDTAI4k/EonTgBmBjKpNDzPwRjCAEZeqpL+K/tRyg3qT8V7etHMAXFSK9y9uEQIb ln0YZTzPzKHuQEiMcfG6fTgAd9z5ujp6gzCQYgp9GOUcyfi692UH1CzlzhwdlVZNSIkOKfSgAd9T 8XWTViJN9L3WXTiIjz8TVRjqGQyO2UtfuKGhOPRFsrYMiYOSftSv8AmWacAZb7HxFV/bgI8bnxNU Jasc0wGBcj4FMhqasM0wGBcincU3/hn/2Q== ------=0HI_09C6598LD_07K.849I70W0-- From danita353fima@stksoftware.com Tue Feb 22 04:09:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02874; Tue, 22 Feb 2005 04:09:08 -0500 (EST) Received: from [211.224.45.26] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D3WOz-0005BV-Bt; Tue, 22 Feb 2005 04:32:23 -0500 Received: from hostrp.cbrokers.com (211.224.45.26) by diduch-761XRS.cbrokers.com with Microsoft SMTPSVC(58.4.8381.67714);Tue, 22 Feb 2005 03:07:51 -0600 Message-ID: Reply-To: "barri turkki" From: "barri turkki" To: manet-admin@ietf.org Cc: rip-admin@ietf.org, hc-admin@ietf.org, cna@ietf.org, simple-archive@ietf.org, imrg-request@ietf.org, seamoby-web-archive@ietf.org, pim-request@ietf.org, asrg@ietf.org, rpsec@ietf.org, ips@ietf.org Subject: Re: Information about your application Date: Tue, 22 Feb 2005 03:58:51 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--285865_011906.YqB262" X-Spam-Score: 3.3 (+++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 ----285865_011906.YqB262 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Hello Account #2700594, Your application was approved. You are eligible for $400,000 with a 3.7 % rate. Please confirm your information here: http://quotetalk.com/?name=rm2342 We look forward to hearing from you. Regards, barri turkki, Senior Account Manager KUO Financial Group r m v - http://quotetalk.com/st.html ----285865_011906.YqB262-- From Penn@indiatimes.com Tue Feb 22 06:22:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16488; Tue, 22 Feb 2005 06:22:44 -0500 (EST) Message-Id: <200502221122.GAA16488@ietf.org> Received: from 61-59-66-98.adsl.static.seed.net.tw ([61.59.66.98]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D3YUE-0000vP-0b; Tue, 22 Feb 2005 06:46:00 -0500 Received: from [95.100.10.199] by assail%DIGITS.amethyst.61.59.66.98 via HTTP; Tue, 22 Feb 2005 03:25:37 -0800 Reply-To: "letterbox.org" From: "letterbox.org" To: Subject: Xrated membership Date: Tue, 22 Feb 2005 03:25:37 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--7233472593mxlb4722" X-Spam-Score: 7.7 (+++++++) X-Spam-Flag: YES X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 ----7233472593mxlb4722 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable Dear Stud! :: sip-request@ietf.org:: .................... Get your password today, to the most satisfying playground on the internet! (20 niches in1site) .................... * Access is priceless! http://www.netaexplicit.com/d/r/1.php ----7233472593mxlb4722-- From Comgan@keystoneleasing.com Tue Feb 22 06:32:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17391 for ; Tue, 22 Feb 2005 06:32:18 -0500 (EST) Message-Id: <200502221132.GAA17391@ietf.org> Received: from [211.186.59.171] (helo=keystoneleasing.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D3YdZ-0001Cd-IY for simple-archive@ietf.org; Tue, 22 Feb 2005 06:55:35 -0500 From: "Rosanne Ferrara" To: "Visitacio Ruiz" Subject: Re: Good Medicattions Date: Tue, 22 Feb 2005 06:57:01 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_0D77496B.3314A840" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 X-Spam-Score: 13.1 (+++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is a multi-part message in MIME format. ------=_NextPart_000_0006_0D77496B.3314A840 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Have a nice day. ------=_NextPart_000_0006_0D77496B.3314A840 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello, Welcome=20 to the best ONLINE ST0RE.
 
Vi in $178(90p.) a a $209(100p.) ana al
cod  Vi gr  X x $299(90p.) = Ci is $324(90p.) 
 
With each purchase you = get:
 
>Home delivery.
>Secure pay.
>Total confidentiality
>Reputable =20 manufacturerrs.
 
Have a nice day!
------=_NextPart_000_0006_0D77496B.3314A840-- From Fatima-Liam@accesswave.com Tue Feb 22 12:00:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22334; Tue, 22 Feb 2005 11:59:58 -0500 (EST) Message-Id: <200502221659.LAA22334@ietf.org> Received: from [211.197.195.156] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D3dki-0002r9-Fn; Tue, 22 Feb 2005 12:23:18 -0500 Received: from mail pickup service by 211.197.195.156 with Microsoft SMTPSVC; Tue, 22 Feb 2005 18:48:11 +0200 Content-Class: urn:content-classes:message Language: English X-MIME-Autoconverted: Yes Reply-To: "Dora.Van.der RafaelVivar" From: "Dora.Van.der RafaelVivar" To: secretariat@ietf.org Cc: secretary@ietf.org, sg@ietf.org, sic@ietf.org, sigtran@ietf.org, sigtran-admin@ietf.org, simple@ietf.org, simple-admin@ietf.org, simple-archive@ietf.org, simple-request@ietf.org Subject: One minute that could change your life Date: Tue, 22 Feb 2005 17:55:11 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--762505_098786.hy860" X-Spam-Score: 3.3 (+++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 ----762505_098786.hy860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Applicant, Your application was processed and approved. This means that you're eligible for $ 475,000 with a 3.2% rate. Take a few minutes to see what you can save! Please verify your information here: http://biharmonic.homeloanon.com/?partid=aaks9 We look forward to hearing from you. Dora.Van.der RafaelVivar, Account Manager TJK Associates r.mv - http://december.homeloanon.com/st.html ----762505_098786.hy860-- From marshall@accessnv.com Tue Feb 22 18:15:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06957 for ; Tue, 22 Feb 2005 18:15:38 -0500 (EST) Received: from pd953396f.dip.t-dialin.net ([217.83.57.111]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D3jcG-0006Hw-NO for simple-archive@ietf.org; Tue, 22 Feb 2005 18:39:01 -0500 Message-ID: <429401c51932$33aa2a45$6edff0d2@accessnv.com> From: "Paul A. Davis" To: simple-archive@ietf.org Subject: =?iso-8859-1?B?Q2lhbGlzIC0gJDIuOTkvZG9zZQ==?= Date: Tue, 22 Feb 2005 23:00:24 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_150CDE4B.C5D8A3E1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 7.6 (+++++++) X-Spam-Flag: YES X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0000_150CDE4B.C5D8A3E1 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_08CAB6C7.CC02F46E" ------=_NextPart_001_0001_08CAB6C7.CC02F46E Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Full & hard erections Long lasting effects No prescription needed Only $2.99/$1.99 per dose (2 doses in each pill): Cialis - http://www.kilomed.biz/sv/ Viagra - http://www.kilomed.biz/vt/ Select the manufacturer you can trust! _________________________________________________________________________ To change your mail details, go here: http://www.kilomed.biz/uns.htm _________________________________________________________________________ ------=_NextPart_001_0001_08CAB6C7.CC02F46E Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit

Full & stable erections
Long effects
No prescription required

2 popular medicines:
CIALIS - http://www.kilomed.biz/sv/
VIAGRA - http://www.kilomed.biz/vt/

Select the manufacturer you can trust!


_________________________________________________________________________
To change your mail preferences, go here: http://www.kilomed.biz/uns.htm
_________________________________________________________________________

------=_NextPart_001_0001_08CAB6C7.CC02F46E-- ------=_NextPart_000_0000_150CDE4B.C5D8A3E1-- From simple-bounces@ietf.org Tue Feb 22 21:58:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02742; Tue, 22 Feb 2005 21:58:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3n63-0004Fd-9w; Tue, 22 Feb 2005 22:21:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3MS4-0004vo-Cf; Mon, 21 Feb 2005 17:54:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3Kdr-0006Mh-8U; Mon, 21 Feb 2005 15:58:55 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14645; Mon, 21 Feb 2005 15:58:53 -0500 (EST) Message-Id: <200502212058.PAA14645@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 21 Feb 2005 15:58:53 -0500 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-notify-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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Partial Notification of Presence Information Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-notify-04.txt Pages : 16 Date : 2005-2-21 By default, presence delivered using the Presence Event Package for the Session Initiation Protocol is represented in the Presence Information Data Format (PIDF). A PIDF document contains a set of elements, each representing a different aspect of the presence being reported. When any subset of the elements change, even a just a single element, a new document containing the full set of elements is delivered. This memo defines an extension allowing delivery of a new document type that contains the data that has actually changed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-partial-notify-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-partial-notify-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-21152136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-notify-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-notify-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-21152136.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Tue Feb 22 22:09:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05701; Tue, 22 Feb 2005 22:09:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3nH4-0004WD-SZ; Tue, 22 Feb 2005 22:33:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3MS8-0004wn-Rl; Mon, 21 Feb 2005 17:54:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3KeH-0006UU-Pz; Mon, 21 Feb 2005 15:59:21 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14706; Mon, 21 Feb 2005 15:59:20 -0500 (EST) Message-Id: <200502212059.PAA14706@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 21 Feb 2005 15:59:20 -0500 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-10.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : The Message Session Relay Protocol Author(s) : B. Campbell, et al. Filename : draft-ietf-simple-message-sessions-10.txt Pages : 56 Date : 2005-2-21 This document describes the Message Session Relay Protocol (MSRP), a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when setup via a rendezvous or session setup protocol such as the Session Initiation Protocol (SIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-message-sessions-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-message-sessions-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-21152143.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-message-sessions-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-message-sessions-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-21152143.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Tue Feb 22 22:49:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22725; Tue, 22 Feb 2005 22:49:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3nt9-0005xW-AX; Tue, 22 Feb 2005 23:12:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3NcA-0006ln-JG; Mon, 21 Feb 2005 19:09:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3LuV-000868-Ry for simple@megatron.ietf.org; Mon, 21 Feb 2005 17:20:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21902 for ; Mon, 21 Feb 2005 17:20:04 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3MGl-0006l3-HT for simple@ietf.org; Mon, 21 Feb 2005 17:43:13 -0500 Received: from lion.cs.columbia.edu (IDENT:+cv+wFm09BbPSerSwt68fCBIJ6WKk+gX@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j1LMJ0ir000903 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 21 Feb 2005 17:19:01 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id j1LMJ0Rn013461 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 21 Feb 2005 17:19:00 -0500 Message-ID: <421A5E4F.4020602@cs.columbia.edu> Date: Mon, 21 Feb 2005 17:18:55 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] updated presence data model References: <4219EEAE.9040103@cisco.com> In-Reply-To: <4219EEAE.9040103@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > I've submitted an update to the presence data model. Until it appears in > the archives, you can pick up a copy at: > > http://www.jdrosen.net/papers/draft-ietf-simple-presence-data-model-02.txt > > * concluded that the UUID URN was not going to work very well for us out > of the > box, since it requires a time-based component and thus doesnt have the > characteristics of being guessable or correlatable with other > information sources in the network. As such, its listed as a fallback > option until other, better URN are defined. Also, ESN and MAC are > listed as useful identifiers but they don't have URN schemes. As a hack to move forward, we could use a UUID that uses a specific, agreed-upon time (say, 01/01/2000). As long as everyone picks the same time, it's essentially a MAC-based identifier, at least in one of the incarnations of the UUID. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From FRJQAQWOYA@msn.com Tue Feb 22 23:08:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29729; Tue, 22 Feb 2005 23:07:09 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3oAS-0007jf-Jd; Tue, 22 Feb 2005 23:30:34 -0500 Received: from [210.127.209.112] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D3nnb-0005qK-Ux; Tue, 22 Feb 2005 23:06:56 -0500 Received: from .anu..au ([52.212.68.55] helo=anu..au) by smtp5..co with esmtp id 1A5Ys6-503168-78 Message-ID: Sender: freeradius-devel-FRJQAQWOYA@msn.com X-Mailman-Version: 2.0.1 Date: Wed, 23 Feb 2005 06:04:47 +0200 From: "Angie Rice" To: sigtran@ietf.org Cc: sigtran-admin@ietf.org, simple@ietf.org, simple-admin@ietf.org, simple-archive@ietf.org, simple-request@ietf.org, simple-web-archive@ietf.org, sip@ietf.org, sip-admin@ietf.org, sip-request@ietf.org, sip-security@ietf.org, sip-security-admin@ietf.org Subject: SU-per Hu^ge 0ffers Sigtran X-Spam-Score: 22.4 (++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 93238566e09e6e262849b4f805833007 This Months speciial: Vi-codinn - 199.00 Valiuum - 169.00 Viagraa - 199.00 Cia-llis - 269.00 Codeinne - 219.00 Xa-naax - 179.00 All orderrs are delivered by UPS with full tracking 24/7. Satisfactiionnss guaaranteeed... http://www.ilovemeds.com/index.php?aid=8 This is 1 -time mailing. N0-re m0val are re'qui-red Iy71DRtz5RA9GQtBzw716t7YTstvpDylF86lmU5xU2m7FbX6uqd From THZIZVIKAN@msn.com Wed Feb 23 10:28:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27436; Wed, 23 Feb 2005 10:28:26 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3ynq-00055o-IT; Wed, 23 Feb 2005 10:51:58 -0500 Received: from [211.45.207.227] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D3yR2-0000W6-PB; Wed, 23 Feb 2005 10:28:22 -0500 Received: from [246.252.1.243] (helo=..dearriba.com) by smtp2.cistron.nl with esmtp ( 3.35 #1 ()) id 176LFL-0053PT-73 Message-ID: <71399973144732.R37446@.noc..gr> Sender: freeradius-devel-THZIZVIKAN@msn.com X-Mailman-Version: 2.0.1 Date: Wed, 23 Feb 2005 13:19:49 -0200 From: "Gabriela Logan" To: secretary@ietf.org Cc: sg@ietf.org, sic@ietf.org, sigtran@ietf.org, sigtran-admin@ietf.org, simple@ietf.org, simple-admin@ietf.org, simple-archive@ietf.org, simple-request@ietf.org, simple-web-archive@ietf.org, sip@ietf.org Subject: We Are the Best Secretary X-Spam-Score: 6.4 (++++++) X-Spam-Flag: YES X-Scan-Signature: 93238566e09e6e262849b4f805833007 This Months speciial: Vi-codinn - 199.00 Valiuum - 169.00 Viagraa - 199.00 Cia-llis - 269.00 Codeinne - 219.00 Xa-naax - 179.00 All orderrs are delivered by UPS with full tracking 24/7. Satisfactiionnss guaaranteeed... http://www.ilovemeds.com/index.php?aid=8 This is 1 -time mailing. N0-re m0val are re'qui-red OCyIJJWTgMdn9LiNLFzvtcna7qhrU9If5 From simple-bounces@ietf.org Wed Feb 23 19:21:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23573; Wed, 23 Feb 2005 19:21:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D478F-0003Ye-Sq; Wed, 23 Feb 2005 19:45:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kkr-0005lW-J1; Tue, 22 Feb 2005 19:51:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3hM5-0002I2-21; Tue, 22 Feb 2005 16:14:05 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22948; Tue, 22 Feb 2005 16:14:02 -0500 (EST) Message-Id: <200502222114.QAA22948@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 22 Feb 2005 16:14:02 -0500 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-03.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : User Agent Capability Extension to Presence Information Data Format(PIDF) Author(s) : M. Lonnfors, K. Kiss Filename : draft-ietf-simple-prescaps-ext-03.txt Pages : 32 Date : 2005-2-22 Interoperation of Instant Messaging and Presence systems has been defined in the IMPP working group. The IMPP WG has come up with baseline interoperable operations and formats for presence and instant messaging systems. However, these base formats might need standardized extensions in order to enable building rational applications using presence and instant messaging. This memo defines an extension to represent RFC3840 capabilities in the Presence Information Document Format (PIDF) compliant presence documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-prescaps-ext-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-prescaps-ext-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-prescaps-ext-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-22160801.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-prescaps-ext-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-prescaps-ext-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22160801.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Wed Feb 23 20:07:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06805; Wed, 23 Feb 2005 20:07:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D47px-0007aS-Ss; Wed, 23 Feb 2005 20:30:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3qrP-00088E-S5; Wed, 23 Feb 2005 02:23:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3qrE-00084w-B2 for simple@megatron.ietf.org; Wed, 23 Feb 2005 02:22:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16037 for ; Wed, 23 Feb 2005 02:22:45 -0500 (EST) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3rDm-00064I-TJ for simple@ietf.org; Wed, 23 Feb 2005 02:46:11 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1N7MhL07596; Wed, 23 Feb 2005 09:22:43 +0200 (EET) X-Scanned: Wed, 23 Feb 2005 09:22:33 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j1N7MXqH006807; Wed, 23 Feb 2005 09:22:33 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00XNSyhb; Wed, 23 Feb 2005 09:22:28 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1N74lU16434; Wed, 23 Feb 2005 09:04:47 +0200 (EET) Received: from [172.21.36.234] ([172.21.36.234]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 23 Feb 2005 09:04:45 +0200 Message-ID: <421C2B0C.1000703@nokia.com> Date: Wed, 23 Feb 2005 09:04:44 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] draft on MSRP conferencing References: <42198582.6000405@nokia.com> <421BBE2A.6030405@cisco.com> In-Reply-To: <421BBE2A.6030405@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2005 07:04:45.0780 (UTC) FILETIME=[F4BCA940:01C51975] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Cc: Simple WG , Aki Niemi X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit Hi Paul. Thanks for your comments. Inline answers. Paul Kyzivat wrote: > Aki / Miguel, > > Just read over draft-niemi-simple-chat-02. I'm glad you are continuing > to work on this. I have a few comments and questions: > > - Adding the DISTSEND seems especially ugly. It shouldn't be necessary > to extend the protocol for this kind of purpose, which is just a > meta-operation performed by the MSRP switch. > > Instead of this, how about simply defining a new body type for the > purpose? It could be a kind of multipart, where one contained part is > the dist list, and the other is the CPIM body. When the switch receives > a body of this type, it extracts the two parts from it, then forwards > the CPIM body part to the list provided by the other part. Support can > be learned by the focus announcing support for the body type during > offer/answer. Yeap, Ben just proposed a similar thing. Actually we have many of the components already done. The new body could be the URI-list with the 'capacity' extensions defined in Section 4.1 of http://www.ietf.org/internet-drafts/draft-ietf-sipping-uri-list-message-02.txt The only requirement for going into this approach is that there must be a mechanism for the client to find out that the feature is supported at the MSRP switch, otherwise "private messages" sent by the client might end up being distributed to all the participants of the conference. I think it is a bit uglier that routing information (or meta-data routing information) is buried in a body. It will require the MSRP switch to open all the bodies to find out whether a distribution list is included or not. I will also require to include this list as the first body, to allow chunks to be routed immediately. I think this is kind of ugly... > > - Your discussion implies that you have synchronous operation in mind - > the MSRP switch receiving an entire message before forwarding it on. But > MSRP certainly makes it feasible for the switch to begin forwarding > *before* a complete message is received. This could be significant for > large messages. I think you ought to mention that an implementation > working that was is acceptable. Yeap, right... It certainly deserves further discussion. > > - When performing a DISTSEND (or my suggested replacement), I question > whether the whole request should be aborted if one of the recipients > cannot be identified. Given that users come and go from conferences with > some regularity, this could cause a lot of messages to go wrong, only to > be retried with the missing name removed. This could be a problem when > trying to stream LoTR to several people in the conference, but one of > them happens to disconnect. Sounds reasonable. I would like to formulate the requirement and capture it in the requirements section. > > - What should happen if the MSRP switch can resolve all the recipients, > but the resulting SEND fails to some but not all of them? At the moment we don't describe this case. I think we are heading to bring a requirement whereby the creator of the message can request a super-Report from the MSRP, this report should contain some sort of information about the delivery of the message to the recipients. > > - There is no mention of the possibility that multiple conferences could > be joined by connecting their foci. I'm not sure if this would have > impact on the mechanism you are proposing. Seems worthy of discussion. Note taken, I guess the discussion is worthy. Thanks, Miguel > > Thanks, > Paul > > Miguel Garcia wrote: > >> Hi: >> >> Aki and me had made a new revision of a draft that discusses how to do >> conferences with MSRP. We propose to define a new MSRP method and a >> couple of new headers, in addition to a number of conventions. >> >> The draft should be officially published soon. In the meantime you can >> download a copy from (html and txt): >> >> http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-02.html >> http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-02.txt >> >> Comments are welcome. >> >> - Miguel >> -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 23 20:18:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09676; Wed, 23 Feb 2005 20:18:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D480a-00005y-U5; Wed, 23 Feb 2005 20:41:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3knP-0006i1-8o; Tue, 22 Feb 2005 19:54:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3Wql-0003M2-DO; Tue, 22 Feb 2005 05:01:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08911; Tue, 22 Feb 2005 05:00:54 -0500 (EST) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3XD7-00077F-Ob; Tue, 22 Feb 2005 05:24:10 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1M9xin19208; Tue, 22 Feb 2005 11:59:44 +0200 (EET) X-Scanned: Tue, 22 Feb 2005 11:59:30 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j1M9xUL0023383; Tue, 22 Feb 2005 11:59:30 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00bSi8iw; Tue, 22 Feb 2005 11:56:50 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1M9unU26349; Tue, 22 Feb 2005 11:56:49 +0200 (EET) Received: from [172.21.39.180] ([172.21.39.180]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 22 Feb 2005 11:56:37 +0200 Message-ID: <421B01D4.3050507@nokia.com> Date: Tue, 22 Feb 2005 11:56:36 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Geopriv] Re: [Simple] presence authorization issue: anonymous, authenticated, etc. References: <42146290.5090209@cisco.com> <4214ADD0.3070101@cs.columbia.edu> <4214B803.7070304@cisco.com> <4214FDA3.3060701@cisco.com> In-Reply-To: <4214FDA3.3060701@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Feb 2005 09:56:37.0058 (UTC) FILETIME=[CC531220:01C518C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Paul Kyzivat , Simple WG , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit ext Jonathan Rosenberg wrote: ---snip--- > 5. presence policy has a discussion on how the is not > useful for black lists, but rather for setting "baseline" policies that > get applied to a broad set of users representing a minimum level of > permissions. > > > > If you but the argument in item 5 above, it is not needed to add an > kind of clause for , I believe. That is, any kind > of permission that applies for any authenticated user should also apply > to any user in particular. That is, if I set my permissions for > to put subscriptins in the pending state, then every > other authenticated user ought to have a permission which is at least > that permissive. > > This means that I couldn't specify that any authenticated user gets put > in pending, but bob gets blocked. > > > Is this more workable? Almost. Except that I don't believe we can make a constraint as above and not allow the in . The whole point in reactive authorization is to be able to block Bob for good, instead of getting that "Bob is pending authorization from you" message forever and ever. Or can you explain why that pop-up for reactive authorization should only have an "Allow" button, instead of both an "Allow" and "Block"? So I still believe that the solution presented in my original post, or in Henning's post is the way to go. (The difference was really only in whether to have an * or an construct for indicating the "any authenticated identity" condition.) Cheers, AKi _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 23 20:35:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15589; Wed, 23 Feb 2005 20:35:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D48H4-0001tQ-GE; Wed, 23 Feb 2005 20:58:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D43ai-0008Sk-9d; Wed, 23 Feb 2005 15:58:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D43ad-0008Rv-Ei; Wed, 23 Feb 2005 15:58:35 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15908; Wed, 23 Feb 2005 15:58:33 -0500 (EST) Message-Id: <200502232058.PAA15908@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 23 Feb 2005 15:58:32 -0500 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-rules-02.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Presence Authorization Rules Author(s) : J. Rosenberg Filename : draft-ietf-simple-presence-rules-02.txt Pages : 27 Date : 2005-2-23 Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-presence-rules-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-presence-rules-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-23160006.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presence-rules-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presence-rules-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-23160006.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Wed Feb 23 21:20:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01882; Wed, 23 Feb 2005 21:20:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D48zD-0006p5-2m; Wed, 23 Feb 2005 21:44:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kkk-0005jt-HT; Tue, 22 Feb 2005 19:51:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3hLE-0002At-1d; Tue, 22 Feb 2005 16:13:12 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22815; Tue, 22 Feb 2005 16:13:09 -0500 (EST) Message-Id: <200502222113.QAA22815@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 22 Feb 2005 16:13:09 -0500 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-publish-02.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Partial Publication of Presence Information Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-publish-02.txt Pages : 9 Date : 2005-2-22 Session Initiation Protocol (SIP) Extension for Event State Publication describes a mechanism with which a presence user agent is able to publish presence information to a presence agent. Using the Presence Information Data Format (PIDF), each presence publication contains full state, regardless of how much of that information has actually changed since the previous update. As a consequence, updating a sizeable presence document with small changes bear a considerable overhead and is therefore inefficient. Especially with low bandwidth and high latency links, this can constitue a considerable burden to the system. This memo defines a solution that aids in reducing the impact of those constraints and increases transport efficiency by introducing a mechanism that allows for publication of partial presence information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-publish-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-partial-publish-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-partial-publish-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-22160743.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-publish-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-publish-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22160743.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Wed Feb 23 21:27:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04878; Wed, 23 Feb 2005 21:27:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D495x-0007fz-4F; Wed, 23 Feb 2005 21:51:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kkm-0005kU-UF; Tue, 22 Feb 2005 19:51:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3hLk-0002Bq-0B; Tue, 22 Feb 2005 16:13:44 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22861; Tue, 22 Feb 2005 16:13:41 -0500 (EST) Message-Id: <200502222113.QAA22861@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 22 Feb 2005 16:13:41 -0500 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-pidf-format-03.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Presence Information Data format (PIDF) Extension for Partial Presence Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-pidf-format-03.txt Pages : 15 Date : 2005-2-22 The presence Information Document Format (PIDF) specifies the baseline XML based format for describing presence information. One of the characteristic of the PIDF is that document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist it is often beneficial to limit the amount of information that is transported over the network. This document introduces a new MIME type which enables transporting of only changed parts of the PIDF based presence information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-partial-pidf-format-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-22160750.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-pidf-format-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22160750.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Wed Feb 23 21:34:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07672; Wed, 23 Feb 2005 21:34:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D49CA-0008Ta-9s; Wed, 23 Feb 2005 21:57:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kkp-0005ky-8G; Tue, 22 Feb 2005 19:51:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3hLu-0002Hk-NO; Tue, 22 Feb 2005 16:13:54 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22916; Tue, 22 Feb 2005 16:13:52 -0500 (EST) Message-Id: <200502222113.QAA22916@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 22 Feb 2005 16:13:52 -0500 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-msrp-relays-03.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Relay Extensions for Message Sessions Relay Protocol (MSRP) Author(s) : C. Jennings, R. Mahy Filename : draft-ietf-simple-msrp-relays-03.txt Pages : 29 Date : 2005-2-22 The SIMPLE Working Group uses two separate models for conveying instant messages. Pager-mode messages stand alone, whereas Session-mode messages are setup as part of a session using the SIP protocol. MSRP (Message Sessions Relay Protocol) is a protocol for near-real-time, peer-to-peer exchange of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-relays-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-msrp-relays-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-msrp-relays-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-22160755.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-msrp-relays-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-msrp-relays-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22160755.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Wed Feb 23 21:47:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12137; Wed, 23 Feb 2005 21:47:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D49Oy-0001Rk-P7; Wed, 23 Feb 2005 22:10:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3zAX-00015f-S4; Wed, 23 Feb 2005 11:15:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3zAV-000159-H8 for simple@megatron.ietf.org; Wed, 23 Feb 2005 11:15:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03979 for ; Wed, 23 Feb 2005 11:15:11 -0500 (EST) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3zX8-0006fK-NT for simple@ietf.org; Wed, 23 Feb 2005 11:38:43 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j1NGCuox028993 for ; Wed, 23 Feb 2005 11:12:57 -0500 (EST) Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j1NGCTox028143 for ; Wed, 23 Feb 2005 11:12:37 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] updated presence data model Date: Wed, 23 Feb 2005 11:14:24 -0500 Message-ID: <8CA1128D59AD27429985B397118CEDDF04D19F2F@nj7460avexu1.global.avaya.com> Thread-Topic: [Simple] updated presence data model Thread-Index: AcUYNRysXd/aAHsFQHCHX5qVTEBUtABjNgTg From: "Boyer, David G \(Dave\)" To: "Jonathan Rosenberg" , "Simple WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Content-Transfer-Encoding: quoted-printable Jonathan, Just curious, why was the "flow of operations" figure removed (Figure 3 in data-model-01)? Thanks Dave > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Jonathan Rosenberg > Sent: Monday, February 21, 2005 9:23 AM > To: Simple WG > Subject: [Simple] updated presence data model >=20 >=20 > I've submitted an update to the presence data model. Until it=20 > appears in=20 > the archives, you can pick up a copy at: >=20 > http://www.jdrosen.net/papers/draft-ietf-simple-presence-data- > model-02.txt >=20 > This is a major revision. The biggest three changes are the=20 > split of the=20 > processing and data model, the allowance for multiple instances of a=20 > particular person, device or service, and the introduction of=20 > the notion=20 > of generic "reach information". Reach information includes=20 > the URI for=20 > the service but can also include other information that a=20 > watcher has to=20 > do in order to get a request to the service. I think that,=20 > from a model=20 > perspective, this would cover our needs for something like an "app=20 > launcher" as we have been discussing in another thread on enumerating=20 > services. >=20 > Note that the examples are not schema-validated at all (or=20 > evne close).=20 > We have a much bigger issue on schema alignment, which I'll post on=20 > separately. >=20 > Here are the specific diffs: >=20 > * split out composition and presence server processing=20 > sections, leaving only the data model >=20 > * fixed examples, which had tuple extensions before .=20 > They need to come after >=20 > * changed terminology from person, device and service=20 > elements, to person device and service components, to refer=20 > to the part of the data model that talks about person,=20 > service. This is to differentitate the XML concept of element=20 > from the disaggregation implied by component. With this=20 > change, it makes sense to say that there is one person=20 > component, but there can be multiple elemnents. >=20 > * added the ability for there to be multiple instances of a=20 > particular service or device, or person. This was done by=20 > modeling the system hierarchically. The presentity is at the=20 > top layer, followed by devices, services and person. Within a=20 > particular device, service, or person, there can be multiple=20 > instances. Each instance of a service shares the same service=20 > URI, each instance of a device shares the same device ID.=20 > Each instance is identified by an instance ID. This is=20 > described in the document as a feature in order to explicitly=20 > model ambiguity in cases where the compositor cannot, or=20 > doesn't want to, resolve the ambiguity, but rather wishes for=20 > the consumer of the document to do so. It is important to=20 > note that this means that the reason we choose to have=20 > multiple instances of a service is ONLY because we want to=20 > model ambiguity; it we want to explicitly say something like=20 > "My softphone is open for IM, but not audio", standardized=20 > ways of doing that, where the compositor or the device knows=20 > this to be the case, are not to be done using multiple=20 > instances. Otherwise, we are back in the boat of multiple=20 > ways of saying the same thing. >=20 > * The spec mentions usage of timestamp and note to allow=20 > humans and automata to resolve conflicts >=20 > * allow timestamp and note as part of person and device.=20 > Aligned schemas for person and device to match structure of the tuple. >=20 > * Modified schemas to extract types for note and timestamp=20 > into a common schema, which is included into the person and=20 > device schemas. >=20 > * added a section discussion general properties of documents=20 > in the model. Emphasize that the meaning of a document is=20 > well-defined and not based on its transport or transferrance=20 > method, and that presence systems allow for infinite composeability. >=20 > * since a person element can have a note, and there can be a=20 > note in the document overall, the model defines how these=20 > resolve. Its like attributes in SDP. If a note is defined=20 > under the person itself, that is used. If there isn't one,=20 > the document-wide one is used. >=20 > * substantially revamped definition of a service. Created=20 > subsections to define the components of a service -=20 > characteristics, reach inforamtion, status, relative=20 > information. Reach information includes the URI but could=20 > include things like a software app you have to use, or a=20 > header you have to place into your request. >=20 > * clarified that capabilities don't mean that you have to=20 > format your request in a specific way - that is what reach=20 > information is for >=20 > * no longer reference the roach service examples draft;=20 > rather, the ideas there are expanded upon here >=20 > * tel URI is discussed as being similar to sip, in that it=20 > can indicate multiple services >=20 > * discuss that since reach information uniquely identify a=20 > service, two things can't be separate services if they can't=20 > be reached separately >=20 > * describe Aki's "available on my softphone if you use IM,=20 > but not if you use audio" as an example of a more complex=20 > status for a single service >=20 > * mention that capabilities for a service can be more complex=20 > than we have today; for example eventually rfc2533. >=20 > * mention that implied behaviors on receipt of a document=20 > cannot be assumed - everything has to be explicit >=20 > * nothing says that the service URI has to be a gruu or=20 > anything else; from a data model perspective its just a URI=20 > that is used to access the service. The processing model=20 > draft will give guidance on how its filled in by PUA. >=20 > * added a treatment on the type of URI that can be included=20 > in the service URI. There is no limit, but abstract URIs like=20 > URN and tel mean you can't say much about characteristics.=20 > Using a tel URI with enum dip indicator is better, or using a=20 > tel URI when there is no enum record is better, that means=20 > its a phone number and you can say more about it >=20 > * mention that the service URI to service mapping is many to=20 > one, and that it is ok for service URI to change over time=20 > too. Mention that this is useful for anti-spam and give=20 > reference to the ietf-sipping-spam draft >=20 > * mention that the presentity URI represents a form of "one=20 > number" communications - providing an index by which all of=20 > the other reach addresses for a user can be discovered. >=20 > * concluded that the UUID URN was not going to work very well=20 > for us out=20 > of the > box, since it requires a time-based component and thus doesnt=20 > have the characteristics of being guessable or correlatable=20 > with other information sources in the network. As such, its=20 > listed as a fallback option until other, better URN are=20 > defined. Also, ESN and MAC are listed as useful identifiers=20 > but they don't have URN schemes. >=20 > * clarified that the person component represents a single=20 > individual, and talked about how groups or users or a dog=20 > could actually be hiding behind that person facade. >=20 > * added discussion of dealing with both pres and SIP URI; and=20 > how to set the entity URI correctly. Discussed the more=20 > general alias issue as well. >=20 > Thanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 23 21:53:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14579; Wed, 23 Feb 2005 21:53:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D49Ua-00026v-CA; Wed, 23 Feb 2005 22:16:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3mo3-0004bA-OP; Tue, 22 Feb 2005 22:03:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3mo1-0004aV-G1; Tue, 22 Feb 2005 22:03:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03140; Tue, 22 Feb 2005 22:03:09 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3nAU-0004LT-EH; Tue, 22 Feb 2005 22:26:33 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 22 Feb 2005 19:03:00 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1N32YwN024151; Tue, 22 Feb 2005 19:02:34 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-100.cisco.com [10.86.240.100]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHY47054; Tue, 22 Feb 2005 19:02:32 -0800 (PST) Message-ID: <421BF247.5090903@cisco.com> Date: Tue, 22 Feb 2005 22:02:31 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Geopriv] Re: [Simple] presence authorization issue: anonymous, authenticated, etc. References: <42146290.5090209@cisco.com> <4214ADD0.3070101@cs.columbia.edu> <4214B803.7070304@cisco.com> <4214FDA3.3060701@cisco.com> <421B01D4.3050507@nokia.com> In-Reply-To: <421B01D4.3050507@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Paul Kyzivat , Simple WG , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Aki, Indeed, we are back to the main point of dispute I suppose we have always had on this topic. The problem is that, as you know, the model of common-policy is based on additive permissions. You are not supposed to be able to take away a permission, only grant one. What you are asking for is basically to grant everyone a permission for "pending", but then to be able to take it away for bad users. The scope of "everyone" - any authenticated identity - is sufficiently large, that given the ease with which identities can be minted in certain domains, this will basically prove ineffective. That said, I don't dispute that people are used to the model of "putting someone on a blacklist", and without this, a basic version of that won't be possible. So, the dilemma - do we provide a gun with which we allow users to shoot themselves in the head, because they are asking for it? I've been adamantly against it, but am a bit torn since I do realize it is a desired feature from a business perspective. I welcome other opinions on this topic, perhaps from folks we havent heard from before.... Thanks, Jonathan R. Aki Niemi wrote: > > > ext Jonathan Rosenberg wrote: > ---snip--- > >> 5. presence policy has a discussion on how the is not >> useful for black lists, but rather for setting "baseline" policies >> that get applied to a broad set of users representing a minimum level >> of permissions. >> >> >> >> If you but the argument in item 5 above, it is not needed to add an >> kind of clause for , I believe. That is, any >> kind of permission that applies for any authenticated user should also >> apply to any user in particular. That is, if I set my permissions for >> to put subscriptins in the pending state, then every >> other authenticated user ought to have a permission which is at least >> that permissive. >> >> This means that I couldn't specify that any authenticated user gets >> put in pending, but bob gets blocked. >> >> >> Is this more workable? > > > Almost. Except that I don't believe we can make a constraint as above > and not allow the in . The whole point in > reactive authorization is to be able to block Bob for good, instead of > getting that "Bob is pending authorization from you" message forever and > ever. Or can you explain why that pop-up for reactive authorization > should only have an "Allow" button, instead of both an "Allow" and "Block"? > > So I still believe that the solution presented in my original post, or > in Henning's post is the way to go. (The difference was really only in > whether to have an * or an construct for indicating the > "any authenticated identity" condition.) > > Cheers, > AKi > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 23 22:01:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17462; Wed, 23 Feb 2005 22:01:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D49cr-0002v2-Q0; Wed, 23 Feb 2005 22:25:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kl2-0005oQ-3H; Tue, 22 Feb 2005 19:52:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3hio-0003Z0-3a for simple@megatron.ietf.org; Tue, 22 Feb 2005 16:37:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24993 for ; Tue, 22 Feb 2005 16:37:26 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3i5F-0003Cg-J2 for simple@ietf.org; Tue, 22 Feb 2005 17:00:48 -0500 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j1MLbNMj027599 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 22 Feb 2005 15:37:24 -0600 (CST) (envelope-from ben@nostrum.com) In-Reply-To: <42198582.6000405@nokia.com> References: <42198582.6000405@nokia.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] draft on MSRP conferencing Date: Tue, 22 Feb 2005 15:37:17 -0600 To: Miguel Garcia X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Simple WG , Aki Niemi X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit I apologize in advance for offering a knee jerk opinion after having done only the briefest scan of this draft: Couldn't this be accomplished by simply adding multiple To headers to the message/cpim envelope, rather than by adding an extension method? On Feb 21, 2005, at 12:53 AM, Miguel Garcia wrote: > Hi: > > Aki and me had made a new revision of a draft that discusses how to do > conferences with MSRP. We propose to define a new MSRP method and a > couple of new headers, in addition to a number of conventions. > > The draft should be officially published soon. In the meantime you can > download a copy from (html and txt): > > http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-02.html > http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-02.txt > > Comments are welcome. > > - 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 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 23 22:02:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17834; Wed, 23 Feb 2005 22:02:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D49dv-00032k-H0; Wed, 23 Feb 2005 22:26:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kl2-0005om-Sm; Tue, 22 Feb 2005 19:52:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3hmP-0003t9-03 for simple@megatron.ietf.org; Tue, 22 Feb 2005 16:41:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25476 for ; Tue, 22 Feb 2005 16:41:08 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3i8s-0003Lf-2O for simple@ietf.org; Tue, 22 Feb 2005 17:04:30 -0500 Received: from [10.10.108.16] ([65.119.52.228]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j1MLf6Oc027960 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 22 Feb 2005 15:41:06 -0600 (CST) (envelope-from ben@nostrum.com) In-Reply-To: References: <42198582.6000405@nokia.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <052ffa152dfa31c959efb539baff6ff9@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] draft on MSRP conferencing Date: Tue, 22 Feb 2005 15:41:00 -0600 To: Ben Campbell X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: Miguel Garcia , Simple WG , Aki Niemi X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit (replying to self) Or alternatively, by adding a body part with a URL list of some sort in it. Then, support of the feature can be negotiated as part of the SDP exchange. On Feb 22, 2005, at 3:37 PM, Ben Campbell wrote: > I apologize in advance for offering a knee jerk opinion after having > done only the briefest scan of this draft: > > Couldn't this be accomplished by simply adding multiple To headers to > the message/cpim envelope, rather than by adding an extension method? > > > On Feb 21, 2005, at 12:53 AM, Miguel Garcia wrote: > >> Hi: >> >> Aki and me had made a new revision of a draft that discusses how to >> do conferences with MSRP. We propose to define a new MSRP method and >> a couple of new headers, in addition to a number of conventions. >> >> The draft should be officially published soon. In the meantime you >> can download a copy from (html and txt): >> >> http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-02.html >> http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-02.txt >> >> Comments are welcome. >> >> - 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 >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 23 22:03:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18062; Wed, 23 Feb 2005 22:03:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D49ed-00037a-Ix; Wed, 23 Feb 2005 22:27:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3klX-00060A-Ph; Tue, 22 Feb 2005 19:52:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3NXh-00069Y-4z; Mon, 21 Feb 2005 19:04:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01773; Mon, 21 Feb 2005 19:04:42 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3Nu4-0000ot-RN; Mon, 21 Feb 2005 19:27:53 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1D3NXg-00043X-9I; Mon, 21 Feb 2005 19:04:44 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 21 Feb 2005 19:04:44 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: simple chair , Internet Architecture Board , simple mailing list , RFC Editor Subject: [Simple] Protocol Action: 'Extensible Markup Language (XML) Formats for Representing Resource Lists' 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 The IESG has approved the following document: - 'Extensible Markup Language (XML) Formats for Representing Resource Lists ' as a Proposed Standard This document is the product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group. The IESG contact persons are Ted Hardie and Scott Hollenbeck. Technical Summary This document defines two Extensible Markup Language (XML) document formats. The first is used to represent resource lists, independent of any particular service. The second is used to define service URIs for an RLS, and to associate a resource list with the service URI. This document also defines an XML Configuration Access Protocol (XCAP) [10] application usage for managing each of these two documents. Working Group Summary The working group came to consensus on this document. There were changes suggested during IETF Last Call, and this version incorporates changes made in response to those suggestions. Protocol Quality This document was reviewed for the IESG by Ted Hardie. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From diann@absolutemotion.com Wed Feb 23 22:23:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25505 for ; Wed, 23 Feb 2005 22:23:19 -0500 (EST) Received: from [211.187.152.159] (helo=211.187.152.159) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D49xm-0005Dc-CL for simple-archive@ietf.org; Wed, 23 Feb 2005 22:46:57 -0500 Message-ID: From: "Jennifer A. Clark" To: simple-archive@ietf.org Subject: =?iso-8859-1?B?T2ZmaWNlIHNvZnR3YXJlIC0gZHV0eS1mcmVlIHByaWNlcw==?= Date: Thu, 24 Feb 2005 03:15:49 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_8FB8741A.C4642D1C" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.5 (+++) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 This is a multi-part message in MIME format. ------=_NextPart_000_0000_8FB8741A.C4642D1C Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_66AB8D68.FA78C27A" ------=_NextPart_001_0001_66AB8D68.FA78C27A Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Get all the software imaginable for wholesale prices! We sell software 2-6 times cheaper than retail price. Just a few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Photoshop CS + Adobe Illustrator CS + Adobe InDesign CS $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many other... Go visit us at: http://www.infrasoft.biz Regards, Jennifer A. Clark _____________________________________________________ To be taken off future campaigns, go here: http://www.infrasoft.biz/uns.htm _____________________________________________________ ------=_NextPart_001_0001_66AB8D68.FA78C27A Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Get all the software imaginable for bottom prices!
We sell software 2-6 times cheaper than retail price.

Just a few examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Photoshop CS + Adobe Illustrator CS + Adobe InDesign CS
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many more... To visit us go:

http://www.infrasoft.biz

Best,
Jennifer Clark


_____________________________________________________
To change your mail preferences, go: http://www.infrasoft.biz/uns.htm
_____________________________________________________

------=_NextPart_001_0001_66AB8D68.FA78C27A-- ------=_NextPart_000_0000_8FB8741A.C4642D1C-- From simple-bounces@ietf.org Wed Feb 23 22:45:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04458; Wed, 23 Feb 2005 22:45:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4AJW-0007rl-LZ; Wed, 23 Feb 2005 23:09:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3qNA-00037L-Sk; Wed, 23 Feb 2005 01:51:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3qN7-00033S-U9 for simple@megatron.ietf.org; Wed, 23 Feb 2005 01:51:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21138 for ; Wed, 23 Feb 2005 01:51:44 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3qjk-0004w5-NQ for simple@ietf.org; Wed, 23 Feb 2005 02:15:10 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1N6pXG11984; Wed, 23 Feb 2005 08:51:34 +0200 (EET) X-Scanned: Wed, 23 Feb 2005 09:04:21 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j1N74L5i010235; Wed, 23 Feb 2005 09:04:21 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00RVE1Jr; Wed, 23 Feb 2005 09:04:20 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1N6pDU04972; Wed, 23 Feb 2005 08:51:13 +0200 (EET) Received: from [172.21.36.234] ([172.21.36.234]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 23 Feb 2005 08:51:00 +0200 Message-ID: <421C27D3.3030001@nokia.com> Date: Wed, 23 Feb 2005 08:50:59 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Ben Campbell Subject: Re: [Simple] draft on MSRP conferencing References: <42198582.6000405@nokia.com> <052ffa152dfa31c959efb539baff6ff9@nostrum.com> In-Reply-To: <052ffa152dfa31c959efb539baff6ff9@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2005 06:51:00.0315 (UTC) FILETIME=[08B8B2B0:01C51974] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: Simple WG , Aki Niemi X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Ben Campbell wrote: > (replying to self) > > Or alternatively, by adding a body part with a URL list of some sort in > it. Then, support of the feature can be negotiated as part of the SDP > exchange. This sounds a bit better to me, providing that there is a mechanism to negotiate the feature as you mention. /Miguel > > On Feb 22, 2005, at 3:37 PM, Ben Campbell wrote: > >> I apologize in advance for offering a knee jerk opinion after having >> done only the briefest scan of this draft: >> >> Couldn't this be accomplished by simply adding multiple To headers to >> the message/cpim envelope, rather than by adding an extension method? >> >> >> On Feb 21, 2005, at 12:53 AM, Miguel Garcia wrote: >> >>> Hi: >>> >>> Aki and me had made a new revision of a draft that discusses how to >>> do conferences with MSRP. We propose to define a new MSRP method and >>> a couple of new headers, in addition to a number of conventions. >>> >>> The draft should be officially published soon. In the meantime you >>> can download a copy from (html and txt): >>> >>> http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-02.html >>> http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-02.txt >>> >>> Comments are welcome. >>> >>> - 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 >>> >> > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Feb 23 22:50:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06355; Wed, 23 Feb 2005 22:50:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4ANk-0008Mb-F7; Wed, 23 Feb 2005 23:13:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3lMR-0001oS-CY; Tue, 22 Feb 2005 20:30:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3lMQ-0001oA-HE for simple@megatron.ietf.org; Tue, 22 Feb 2005 20:30:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22029 for ; Tue, 22 Feb 2005 20:30:34 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3liu-0001Lc-Ku for simple@ietf.org; Tue, 22 Feb 2005 20:53:57 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 22 Feb 2005 18:44:27 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,108,1107734400"; d="scan'208,217"; a="228055875:sNHT76177442" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1N1U2wN002601 for ; Tue, 22 Feb 2005 17:30:02 -0800 (PST) Received: e2k4.cisco.com 171.70.93.57 from 10.32.131.73 10.32.131.73 via HTTP with MS-WebStorage 6.5.6944 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 22 Feb 2005 17:30:01 -0800 From: Cullen Jennings To: "simple@ietf.org" Message-ID: Mime-version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Simple] draft-ietf-simple-msrp-relays-03 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="===============0564481619==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0564481619== Content-type: multipart/alternative; boundary="B_3191938201_995329" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3191938201_995329 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit There is a new version of this draft - until it shows up in directory, it is at http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-msrp-rela ys-03.html I think this is getting close to done, really :-) --B_3191938201_995329 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable draft-ietf-simple-msrp-relays-03
There is a new version of this draft - until it shows up in directory, it i= s at

http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft= -ietf-simple-msrp-relays-03.html

I think this is getting close to done, really :-)

--B_3191938201_995329-- --===============0564481619== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0564481619==-- From simple-bounces@ietf.org Wed Feb 23 23:07:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12288; Wed, 23 Feb 2005 23:07:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4AeS-0001jC-A6; Wed, 23 Feb 2005 23:31:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D43b7-0008W3-6b; Wed, 23 Feb 2005 15:59:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D43b2-0008VT-Id; Wed, 23 Feb 2005 15:59:00 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15936; Wed, 23 Feb 2005 15:58:58 -0500 (EST) Message-Id: <200502232058.PAA15936@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 23 Feb 2005 15:58:58 -0500 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-rpid-05.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : RPID: Rich Presence: Extensions to the Presence Information Data Format (PIDF) Author(s) : H. Schulzrinne, et al. Filename : draft-ietf-simple-rpid-05.txt Pages : 32 Date : 2005-2-23 The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. That format defines a textual note, an indication of availability (open or closed) and a Universal Resource Identifier (URI) for communication. The Rich Presence Information Data Format (RPID) described here is an extension that adds optional elements to the Presence Information Data Format (PIDF). These extensions provide additional information about the presentity and its contacts. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-rpid-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-rpid-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-rpid-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-23160019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-rpid-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-rpid-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-23160019.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Wed Feb 23 23:41:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23369; Wed, 23 Feb 2005 23:41:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4BBL-0004yI-PG; Thu, 24 Feb 2005 00:04:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D43aa-0008RW-7A; Wed, 23 Feb 2005 15:58:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D43aU-0008Q9-8o; Wed, 23 Feb 2005 15:58:26 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15864; Wed, 23 Feb 2005 15:58:23 -0500 (EST) Message-Id: <200502232058.PAA15864@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 23 Feb 2005 15:58:23 -0500 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-data-model-02.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : A Data Model for Presence Author(s) : J. Rosenberg Filename : draft-ietf-simple-presence-data-model-02.txt Pages : 34 Date : 2005-2-23 This document defines the underlying presence data model and used by Session Initiation Protocol (SIP) for Instant Messaging Leveraging Presence Extensions (SIMPLE) presence agents. The data model provides guidance on how to map various communications systems into presence documents in a consistent fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-data-model-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-presence-data-model-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-presence-data-model-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-23160000.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presence-data-model-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presence-data-model-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-23160000.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Thu Feb 24 00:15:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06394; Thu, 24 Feb 2005 00:15:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Bir-0000Pz-6h; Thu, 24 Feb 2005 00:39:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3qiJ-0005o8-9Y; Wed, 23 Feb 2005 02:13:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3qiG-0005nJ-Pw for simple@megatron.ietf.org; Wed, 23 Feb 2005 02:13:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05256 for ; Wed, 23 Feb 2005 02:13:29 -0500 (EST) Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3r4o-0005b4-Ck for simple@ietf.org; Wed, 23 Feb 2005 02:36:55 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1N7DQ726511; Wed, 23 Feb 2005 09:13:26 +0200 (EET) X-Scanned: Wed, 23 Feb 2005 09:13:11 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j1N7DBId031389; Wed, 23 Feb 2005 09:13:11 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00cRzp0h; Wed, 23 Feb 2005 09:12:49 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1N6lUM24834; Wed, 23 Feb 2005 08:47:30 +0200 (EET) Received: from [172.21.36.234] ([172.21.36.234]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 23 Feb 2005 08:47:30 +0200 Message-ID: <421C2702.4010607@nokia.com> Date: Wed, 23 Feb 2005 08:47:30 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Ben Campbell Subject: Re: [Simple] draft on MSRP conferencing References: <42198582.6000405@nokia.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2005 06:47:30.0550 (UTC) FILETIME=[8BB11960:01C51973] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Simple WG , Aki Niemi X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Ben Campbell wrote: > I apologize in advance for offering a knee jerk opinion after having > done only the briefest scan of this draft: > > Couldn't this be accomplished by simply adding multiple To headers to > the message/cpim envelope, rather than by adding an extension method? > What you are proposing is what we have proposed in version -01 of the draft. However, we went into some problems with that approach: a) If the MSRP does not implement this extension, then it will distributed the message to all the participants of the conference. Certainly not what the creator of the message wanted. b) Message/CPIM contains To and Cc headeers. However, there wouldn't be a mechanism to do the effect of a Bcc, because we are linking routing with presentation. So we ended up proposing a new method, because if the MSRP switch dooes not support, it returns and 501 response, and at least the message is not distributed to the whole roster. Then we added the Distsend header, that contains the desired distribution list. This list need to not be the same as the To and Cc headers of the Message/CPIM, so that the creator can create blind copies. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 24 00:21:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08631; Thu, 24 Feb 2005 00:21:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Bo1-00014l-Iz; Thu, 24 Feb 2005 00:44:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3mzV-0005Sr-Cj; Tue, 22 Feb 2005 22:15:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3mzT-0005RY-GS; Tue, 22 Feb 2005 22:15:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09515; Tue, 22 Feb 2005 22:14:59 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3nLy-0004fz-Du; Tue, 22 Feb 2005 22:38:23 -0500 Received: from lion.cs.columbia.edu (IDENT:CTH9XBbKFoGXoEe5SxNe9bUl4X96jU+g@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j1N3Etir009282 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 22 Feb 2005 22:14:56 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id j1N3EtRn023665 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 22 Feb 2005 22:14:55 -0500 Message-ID: <421BF52A.7070605@cs.columbia.edu> Date: Tue, 22 Feb 2005 22:14:50 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Geopriv] Re: [Simple] presence authorization issue: anonymous, authenticated, etc. References: <42146290.5090209@cisco.com> <4214ADD0.3070101@cs.columbia.edu> <4214B803.7070304@cisco.com> <4214FDA3.3060701@cisco.com> <421B01D4.3050507@nokia.com> <421BF247.5090903@cisco.com> In-Reply-To: <421BF247.5090903@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Aki Niemi , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit I wonder if a better solution wouldn't be a completely separate black-listing and identity filtering mechanism that is (logically) placed ahead of the privilege system. In reality, do blacklists need more shades of gray than "go away, you're not welcome here"? (This would likely be part of some general form of spam filtering.) Jonathan Rosenberg wrote: > Aki, > > Indeed, we are back to the main point of dispute I suppose we have > always had on this topic. > > The problem is that, as you know, the model of common-policy is based on > additive permissions. You are not supposed to be able to take away a > permission, only grant one. What you are asking for is basically to > grant everyone a permission for "pending", but then to be able to take > it away for bad users. The scope of "everyone" - any authenticated > identity - is sufficiently large, that given the ease with which > identities can be minted in certain domains, this will basically prove > ineffective. > > That said, I don't dispute that people are used to the model of "putting > someone on a blacklist", and without this, a basic version of that won't > be possible. > > So, the dilemma - do we provide a gun with which we allow users to shoot > themselves in the head, because they are asking for it? > > I've been adamantly against it, but am a bit torn since I do realize it > is a desired feature from a business perspective. I welcome other > opinions on this topic, perhaps from folks we havent heard from before.... > > Thanks, > Jonathan R. > > Aki Niemi wrote: > >> >> >> ext Jonathan Rosenberg wrote: >> ---snip--- >> >>> 5. presence policy has a discussion on how the is not >>> useful for black lists, but rather for setting "baseline" policies >>> that get applied to a broad set of users representing a minimum level >>> of permissions. >>> >>> >>> >>> If you but the argument in item 5 above, it is not needed to add an >>> kind of clause for , I believe. That is, any >>> kind of permission that applies for any authenticated user should >>> also apply to any user in particular. That is, if I set my >>> permissions for to put subscriptins in the pending >>> state, then every other authenticated user ought to have a permission >>> which is at least that permissive. >>> >>> This means that I couldn't specify that any authenticated user gets >>> put in pending, but bob gets blocked. >>> >>> >>> Is this more workable? >> >> >> >> Almost. Except that I don't believe we can make a constraint as above >> and not allow the in . The whole point in >> reactive authorization is to be able to block Bob for good, instead of >> getting that "Bob is pending authorization from you" message forever >> and ever. Or can you explain why that pop-up for reactive >> authorization should only have an "Allow" button, instead of both an >> "Allow" and "Block"? >> >> So I still believe that the solution presented in my original post, or >> in Henning's post is the way to go. (The difference was really only in >> whether to have an * or an construct for indicating >> the "any authenticated identity" condition.) >> >> Cheers, >> AKi >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 24 00:23:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09606; Thu, 24 Feb 2005 00:23:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4BqD-0001Kv-Uf; Thu, 24 Feb 2005 00:47:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3msg-0004sB-UP; Tue, 22 Feb 2005 22:08:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3mse-0004rt-Rv for simple@megatron.ietf.org; Tue, 22 Feb 2005 22:08:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04289 for ; Tue, 22 Feb 2005 22:07:57 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3nFA-0004Sv-0M for simple@ietf.org; Tue, 22 Feb 2005 22:31:21 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 22 Feb 2005 20:21:37 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,108,1107734400"; d="scan'208"; a="228089490:sNHT588477848" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1N377q8005413; Tue, 22 Feb 2005 19:07:07 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-100.cisco.com [10.86.240.100]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHY47408; Tue, 22 Feb 2005 19:07:10 -0800 (PST) Message-ID: <421BF35E.8010801@cisco.com> Date: Tue, 22 Feb 2005 22:07:10 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] updated presence data model References: <4219EEAE.9040103@cisco.com> <421A5E4F.4020602@cs.columbia.edu> In-Reply-To: <421A5E4F.4020602@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit I asked the authors of the draft about this kind of approach some time back, and the feeling was that it was hokey. I think we are better off writing a short URN spec for a mac address. Its not a lookup mechanism; just an encoding for representing a mac address in URI/URN form. Should be a trivial document.... -Jonathan R. Henning Schulzrinne wrote: > > > Jonathan Rosenberg wrote: > >> I've submitted an update to the presence data model. Until it appears >> in the archives, you can pick up a copy at: >> >> http://www.jdrosen.net/papers/draft-ietf-simple-presence-data-model-02.txt >> >> >> * concluded that the UUID URN was not going to work very well for us >> out of the >> box, since it requires a time-based component and thus doesnt have the >> characteristics of being guessable or correlatable with other >> information sources in the network. As such, its listed as a fallback >> option until other, better URN are defined. Also, ESN and MAC are >> listed as useful identifiers but they don't have URN schemes. > > > As a hack to move forward, we could use a UUID that uses a specific, > agreed-upon time (say, 01/01/2000). As long as everyone picks the same > time, it's essentially a MAC-based identifier, at least in one of the > incarnations of the UUID. > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 24 00:25:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10126; Thu, 24 Feb 2005 00:25:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Brv-0001U3-CJ; Thu, 24 Feb 2005 00:48:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4BLT-0004iF-NV; Thu, 24 Feb 2005 00:15:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3lN4-0001TR-Hd for simple@megatron.ietf.org; Tue, 22 Feb 2005 20:31:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07690 for ; Tue, 22 Feb 2005 18:20:50 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3jhN-0006Np-Oz for simple@ietf.org; Tue, 22 Feb 2005 18:44:14 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 22 Feb 2005 15:31:40 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1MNK9uC006702; Tue, 22 Feb 2005 15:20:16 -0800 (PST) Received: from cisco.com ([161.44.79.182]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APH83389; Tue, 22 Feb 2005 18:20:10 -0500 (EST) Message-ID: <421BBE2A.6030405@cisco.com> Date: Tue, 22 Feb 2005 18:20:10 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] draft on MSRP conferencing References: <42198582.6000405@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: Simple WG , Aki Niemi X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Aki / Miguel, Just read over draft-niemi-simple-chat-02. I'm glad you are continuing to work on this. I have a few comments and questions: - Adding the DISTSEND seems especially ugly. It shouldn't be necessary to extend the protocol for this kind of purpose, which is just a meta-operation performed by the MSRP switch. Instead of this, how about simply defining a new body type for the purpose? It could be a kind of multipart, where one contained part is the dist list, and the other is the CPIM body. When the switch receives a body of this type, it extracts the two parts from it, then forwards the CPIM body part to the list provided by the other part. Support can be learned by the focus announcing support for the body type during offer/answer. - Your discussion implies that you have synchronous operation in mind - the MSRP switch receiving an entire message before forwarding it on. But MSRP certainly makes it feasible for the switch to begin forwarding *before* a complete message is received. This could be significant for large messages. I think you ought to mention that an implementation working that was is acceptable. - When performing a DISTSEND (or my suggested replacement), I question whether the whole request should be aborted if one of the recipients cannot be identified. Given that users come and go from conferences with some regularity, this could cause a lot of messages to go wrong, only to be retried with the missing name removed. This could be a problem when trying to stream LoTR to several people in the conference, but one of them happens to disconnect. - What should happen if the MSRP switch can resolve all the recipients, but the resulting SEND fails to some but not all of them? - There is no mention of the possibility that multiple conferences could be joined by connecting their foci. I'm not sure if this would have impact on the mechanism you are proposing. Seems worthy of discussion. Thanks, Paul Miguel Garcia wrote: > Hi: > > Aki and me had made a new revision of a draft that discusses how to do > conferences with MSRP. We propose to define a new MSRP method and a > couple of new headers, in addition to a number of conventions. > > The draft should be officially published soon. In the meantime you can > download a copy from (html and txt): > > http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-02.html > http://people.nokia.net/~miguel/drafts/draft-niemi-simple-chat-02.txt > > Comments are welcome. > > - Miguel > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 24 00:33:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13909; Thu, 24 Feb 2005 00:33:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4C07-0002fs-1R; Thu, 24 Feb 2005 00:57:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3xe6-0003sE-QD; Wed, 23 Feb 2005 09:37:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3xe4-0003s4-4H for simple@megatron.ietf.org; Wed, 23 Feb 2005 09:37:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20780 for ; Wed, 23 Feb 2005 09:37:36 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3y0g-0003ki-Ve for simple@ietf.org; Wed, 23 Feb 2005 10:01:07 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 23 Feb 2005 07:51:35 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,109,1107734400"; d="scan'208"; a="228282334:sNHT56409258" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1NEb4ZV004243; Wed, 23 Feb 2005 06:37:05 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-204.cisco.com [10.86.240.204]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id API15423; Wed, 23 Feb 2005 09:37:02 -0500 (EST) Message-ID: <421C950E.4020404@cisco.com> Date: Wed, 23 Feb 2005 09:37:02 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Garcia Subject: Re: [Simple] draft on MSRP conferencing References: <42198582.6000405@nokia.com> <421BBE2A.6030405@cisco.com> <421C2B0C.1000703@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: Simple WG , Aki Niemi X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Miguel Garcia wrote: > Hi Paul. > > Thanks for your comments. Inline answers. > > Paul Kyzivat wrote: > >> Aki / Miguel, >> >> Just read over draft-niemi-simple-chat-02. I'm glad you are continuing >> to work on this. I have a few comments and questions: >> >> - Adding the DISTSEND seems especially ugly. It shouldn't be necessary >> to extend the protocol for this kind of purpose, which is just a >> meta-operation performed by the MSRP switch. >> >> Instead of this, how about simply defining a new body type for the >> purpose? It could be a kind of multipart, where one contained part is >> the dist list, and the other is the CPIM body. When the switch >> receives a body of this type, it extracts the two parts from it, then >> forwards the CPIM body part to the list provided by the other part. >> Support can be learned by the focus announcing support for the body >> type during offer/answer. > > > Yeap, Ben just proposed a similar thing. Actually we have many of the > components already done. The new body could be the URI-list with the > 'capacity' extensions defined in Section 4.1 of > http://www.ietf.org/internet-drafts/draft-ietf-sipping-uri-list-message-02.txt > > > The only requirement for going into this approach is that there must be > a mechanism for the client to find out that the feature is supported at > the MSRP switch, otherwise "private messages" sent by the client might > end up being distributed to all the participants of the conference. > > I think it is a bit uglier that routing information (or meta-data > routing information) is buried in a body. It will require the MSRP > switch to open all the bodies to find out whether a distribution list is > included or not. I will also require to include this list as the first > body, to allow chunks to be routed immediately. I think this is kind of > ugly... You are making this too hard. What I had in mind was a special *container* type. Whenever this type is received, the switch is expected to do the "special switching". For instance the type might be multipart/msrp-multicast+xml. This would then have two components: - a URI-list - a CPIM body to be sent to the list. You then don't have to open all bodies - only this body type. And negotiation of support for the body type determines whether the feature is supported. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 24 00:43:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17050; Thu, 24 Feb 2005 00:43:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4C9S-0003ia-Tl; Thu, 24 Feb 2005 01:07:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3rgh-0001Vq-5d; Wed, 23 Feb 2005 03:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3rgS-0001Oz-7Y; Wed, 23 Feb 2005 03:15:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07828; Wed, 23 Feb 2005 03:15:40 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3s31-0008Ij-0E; Wed, 23 Feb 2005 03:39:07 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1N8FPG25492; Wed, 23 Feb 2005 10:15:25 +0200 (EET) X-Scanned: Wed, 23 Feb 2005 10:28:24 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j1N8SOrS008287; Wed, 23 Feb 2005 10:28:24 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00IWbXez; Wed, 23 Feb 2005 10:28:23 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1N8F6M09548; Wed, 23 Feb 2005 10:15:06 +0200 (EET) Received: from [172.21.39.180] ([172.21.39.180]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 23 Feb 2005 10:13:37 +0200 Message-ID: <421C3B30.8050104@nokia.com> Date: Wed, 23 Feb 2005 10:13:36 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Geopriv] Re: [Simple] presence authorization issue: anonymous, authenticated, etc. References: <42146290.5090209@cisco.com> <4214ADD0.3070101@cs.columbia.edu> <4214B803.7070304@cisco.com> <4214FDA3.3060701@cisco.com> <421B01D4.3050507@nokia.com> <421BF247.5090903@cisco.com> In-Reply-To: <421BF247.5090903@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2005 08:13:37.0478 (UTC) FILETIME=[936BBE60:01C5197F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Paul Kyzivat , Simple WG , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit ext Jonathan Rosenberg wrote: > The problem is that, as you know, the model of common-policy is based on > additive permissions. You are not supposed to be able to take away a > permission, only grant one. What you are asking for is basically to > grant everyone a permission for "pending", but then to be able to take > it away for bad users. The scope of "everyone" - any authenticated > identity - is sufficiently large, that given the ease with which > identities can be minted in certain domains, this will basically prove > ineffective. I think this argument deserves some further analysis. I attempted that a while back in a post: http://www1.ietf.org/mail-archive/web/geopriv/current/msg00381.html In essence, what you are saying above is that because identities can be minted easily in domain B, it automatically leads to valid credentials being generated for (my) domain A for that identity. If this was true given a *real* authentication mechanism in place (and not one based on a weak notion of transitive trust, for example), then what purpose does authentication serve in this system anyway? I don't think authorization and authentication can be lumped together here in this way. Even if domain B has a nonchalant way of giving out identities, it is still domain A's business to determine who's got valid credentials in its domain. As an example, domain A could require a digest username/password, and the assignment of those credentials is solely the responsibility of domain A, and can be as scrutinizing as required. So apologies for sounding like a broken record, but I think ultimately in such a system that can't safely handle a block-list, authentication is broken, not authorization. > That said, I don't dispute that people are used to the model of "putting > someone on a blacklist", and without this, a basic version of that won't > be possible. > > So, the dilemma - do we provide a gun with which we allow users to shoot > themselves in the head, because they are asking for it? > > I've been adamantly against it, but am a bit torn since I do realize it > is a desired feature from a business perspective. I welcome other > opinions on this topic, perhaps from folks we havent heard from before.... I hope to see this as well, especially since this seems to be a potential "make-or-brake" issue where the implications can be quite big depending on which direction we take. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 24 01:33:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04854; Thu, 24 Feb 2005 01:33:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Cvh-0000hu-ON; Thu, 24 Feb 2005 01:56:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4BTl-0001uY-9E; Thu, 24 Feb 2005 00:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4BTi-0001th-Cu for simple@megatron.ietf.org; Thu, 24 Feb 2005 00:23:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09708 for ; Thu, 24 Feb 2005 00:23:54 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4BqX-0001Lj-Ez for simple@ietf.org; Thu, 24 Feb 2005 00:47:34 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 23 Feb 2005 22:38:24 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,111,1107734400"; d="scan'208"; a="228619127:sNHT23509584" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1O5NhuC007956; Wed, 23 Feb 2005 21:23:43 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-126.cisco.com [10.86.240.126]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHZ56513; Wed, 23 Feb 2005 21:23:44 -0800 (PST) Message-ID: <421D64E0.5030800@cisco.com> Date: Thu, 24 Feb 2005 00:23:44 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Boyer, David G \(Dave\)" Subject: Re: [Simple] updated presence data model References: <8CA1128D59AD27429985B397118CEDDF04D19F2F@nj7460avexu1.global.avaya.com> In-Reply-To: <8CA1128D59AD27429985B397118CEDDF04D19F2F@nj7460avexu1.global.avaya.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Content-Transfer-Encoding: 7bit The presence data model was split into two drafts: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-data-model-01.txt http://www.ietf.org/internet-drafts/draft-rosenberg-simple-presence-processing-model-00.txt the latter one now contains that figure. The data model now focuses on the DATA - what the presence document means. The processing model focuses on things like composition and what a presence server does in its operations. We agreed, per Robert's direction, to do this split in order to make forward progress on the data model before figuring out composition and some of the harder processing problems. Thanks, Jonathan R. Boyer, David G (Dave) wrote: > Jonathan, > > Just curious, why was the "flow of operations" figure removed > (Figure 3 in data-model-01)? > > Thanks > Dave > > >>-----Original Message----- >>From: simple-bounces@ietf.org >>[mailto:simple-bounces@ietf.org] On Behalf Of Jonathan Rosenberg >>Sent: Monday, February 21, 2005 9:23 AM >>To: Simple WG >>Subject: [Simple] updated presence data model >> >> >>I've submitted an update to the presence data model. Until it >>appears in >>the archives, you can pick up a copy at: >> >>http://www.jdrosen.net/papers/draft-ietf-simple-presence-data- >>model-02.txt >> >>This is a major revision. The biggest three changes are the >>split of the >>processing and data model, the allowance for multiple instances of a >>particular person, device or service, and the introduction of >>the notion >>of generic "reach information". Reach information includes >>the URI for >>the service but can also include other information that a >>watcher has to >>do in order to get a request to the service. I think that, >>from a model >>perspective, this would cover our needs for something like an "app >>launcher" as we have been discussing in another thread on enumerating >>services. >> >>Note that the examples are not schema-validated at all (or >>evne close). >>We have a much bigger issue on schema alignment, which I'll post on >>separately. >> >>Here are the specific diffs: >> >>* split out composition and presence server processing >>sections, leaving only the data model >> >>* fixed examples, which had tuple extensions before . >>They need to come after >> >>* changed terminology from person, device and service >>elements, to person device and service components, to refer >>to the part of the data model that talks about person, >>service. This is to differentitate the XML concept of element >>from the disaggregation implied by component. With this >>change, it makes sense to say that there is one person >>component, but there can be multiple elemnents. >> >>* added the ability for there to be multiple instances of a >>particular service or device, or person. This was done by >>modeling the system hierarchically. The presentity is at the >>top layer, followed by devices, services and person. Within a >>particular device, service, or person, there can be multiple >>instances. Each instance of a service shares the same service >>URI, each instance of a device shares the same device ID. >>Each instance is identified by an instance ID. This is >>described in the document as a feature in order to explicitly >>model ambiguity in cases where the compositor cannot, or >>doesn't want to, resolve the ambiguity, but rather wishes for >>the consumer of the document to do so. It is important to >>note that this means that the reason we choose to have >>multiple instances of a service is ONLY because we want to >>model ambiguity; it we want to explicitly say something like >>"My softphone is open for IM, but not audio", standardized >>ways of doing that, where the compositor or the device knows >>this to be the case, are not to be done using multiple >>instances. Otherwise, we are back in the boat of multiple >>ways of saying the same thing. >> >>* The spec mentions usage of timestamp and note to allow >>humans and automata to resolve conflicts >> >>* allow timestamp and note as part of person and device. >>Aligned schemas for person and device to match structure of the tuple. >> >>* Modified schemas to extract types for note and timestamp >>into a common schema, which is included into the person and >>device schemas. >> >>* added a section discussion general properties of documents >>in the model. Emphasize that the meaning of a document is >>well-defined and not based on its transport or transferrance >>method, and that presence systems allow for infinite composeability. >> >>* since a person element can have a note, and there can be a >>note in the document overall, the model defines how these >>resolve. Its like attributes in SDP. If a note is defined >>under the person itself, that is used. If there isn't one, >>the document-wide one is used. >> >>* substantially revamped definition of a service. Created >>subsections to define the components of a service - >>characteristics, reach inforamtion, status, relative >>information. Reach information includes the URI but could >>include things like a software app you have to use, or a >>header you have to place into your request. >> >>* clarified that capabilities don't mean that you have to >>format your request in a specific way - that is what reach >>information is for >> >>* no longer reference the roach service examples draft; >>rather, the ideas there are expanded upon here >> >>* tel URI is discussed as being similar to sip, in that it >>can indicate multiple services >> >>* discuss that since reach information uniquely identify a >>service, two things can't be separate services if they can't >>be reached separately >> >>* describe Aki's "available on my softphone if you use IM, >>but not if you use audio" as an example of a more complex >>status for a single service >> >>* mention that capabilities for a service can be more complex >>than we have today; for example eventually rfc2533. >> >>* mention that implied behaviors on receipt of a document >>cannot be assumed - everything has to be explicit >> >>* nothing says that the service URI has to be a gruu or >>anything else; from a data model perspective its just a URI >>that is used to access the service. The processing model >>draft will give guidance on how its filled in by PUA. >> >>* added a treatment on the type of URI that can be included >>in the service URI. There is no limit, but abstract URIs like >>URN and tel mean you can't say much about characteristics. >>Using a tel URI with enum dip indicator is better, or using a >>tel URI when there is no enum record is better, that means >>its a phone number and you can say more about it >> >>* mention that the service URI to service mapping is many to >>one, and that it is ok for service URI to change over time >>too. Mention that this is useful for anti-spam and give >>reference to the ietf-sipping-spam draft >> >>* mention that the presentity URI represents a form of "one >>number" communications - providing an index by which all of >>the other reach addresses for a user can be discovered. >> >>* concluded that the UUID URN was not going to work very well >>for us out >>of the >>box, since it requires a time-based component and thus doesnt >>have the characteristics of being guessable or correlatable >>with other information sources in the network. As such, its >>listed as a fallback option until other, better URN are >>defined. Also, ESN and MAC are listed as useful identifiers >>but they don't have URN schemes. >> >>* clarified that the person component represents a single >>individual, and talked about how groups or users or a dog >>could actually be hiding behind that person facade. >> >>* added discussion of dealing with both pres and SIP URI; and >>how to set the entity URI correctly. Discussed the more >>general alias issue as well. >> >>Thanks, >>Jonathan R. >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Director, Service Provider VoIP Architecture Parsippany, NJ >>07054-2711 >>Cisco Systems >>jdrosen@cisco.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.cisco.com >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 24 01:54:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12270; Thu, 24 Feb 2005 01:54:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4DG3-0002y7-LR; Thu, 24 Feb 2005 02:17:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4CsT-0003rz-OV; Thu, 24 Feb 2005 01:53:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4CsS-0003rn-0Z for simple@megatron.ietf.org; Thu, 24 Feb 2005 01:53:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11918 for ; Thu, 24 Feb 2005 01:53:34 -0500 (EST) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4DFI-0002qV-Ky for simple@ietf.org; Thu, 24 Feb 2005 02:17:13 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1O6pWn04156; Thu, 24 Feb 2005 08:51:32 +0200 (EET) X-Scanned: Thu, 24 Feb 2005 08:51:30 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j1O6pUun024102; Thu, 24 Feb 2005 08:51:30 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00fC4vaO; Thu, 24 Feb 2005 08:51:28 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1O6pRM24324; Thu, 24 Feb 2005 08:51:27 +0200 (EET) Received: from [172.21.36.234] ([172.21.36.234]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 24 Feb 2005 08:51:23 +0200 Message-ID: <421D796A.7050204@nokia.com> Date: Thu, 24 Feb 2005 08:51:22 +0200 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] draft on MSRP conferencing References: <42198582.6000405@nokia.com> <421BBE2A.6030405@cisco.com> <421C2B0C.1000703@nokia.com> <421C950E.4020404@cisco.com> In-Reply-To: <421C950E.4020404@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2005 06:51:23.0063 (UTC) FILETIME=[40B18470:01C51A3D] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: Simple WG , Aki Niemi X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > You are making this too hard. I think the same about your proposal ;-) > > What I had in mind was a special *container* type. Whenever this type is > received, the switch is expected to do the "special switching". For > instance the type might be multipart/msrp-multicast+xml. This would then > have two components: > - a URI-list > - a CPIM body to be sent to the list. > First, I guess you are not proposing to have an XML wrapper document that contains, somehow, the URI-list and the Message/CPIM. IMHO it does not make sense to use XML for this. So if you don't use XML, the multipart/msrp-multicast MIME type becomes the same as the multipart/mixed MIME type, and it would be hard to justify its existence. > You then don't have to open all bodies - only this body type. So we have two problems, one if we have only multipart/mixed, I would have to open all bodies. Still I would have to open a body as a minimum, to do routing at the application layer. There are other side effecs: a) What about if the creator uses S/MIME to protect the whole multipart stuff... and if it is a long message (chunked) then the MSRP mixer won't be able to open the URI-list until the last chunk has been sent. This seems to conflict with your early wise proposal of allowing routing of chunks rather of whole messages. b) Even if s/MIME is not used, then we will need to define an order insdide the multipart MIME and specify that the URI list must be the first body. This mechanism has been used in SMTP since... long time. The RCPT verb in SMTP adds a new recipient to the list. It is the most similar thing to a header, rather than a body. > > And negotiation of support for the body type determines whether the > feature is supported. > If we can justify the creation of a new MIME type, yes. Otherwise, it won't get distinguished in the SDP. > Paul /Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Feb 24 06:21:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02648; Thu, 24 Feb 2005 06:21:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4HQj-00027r-VQ; Thu, 24 Feb 2005 06:45:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4H0A-0004pk-NV; Thu, 24 Feb 2005 06:17:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4H06-0004lE-Cw for simple@megatron.ietf.org; Thu, 24 Feb 2005 06:17:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02247 for ; Thu, 24 Feb 2005 06:17:42 -0500 (EST) Received: from smtp12.clb.oleane.net ([213.56.31.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4HMw-00020d-74 for simple@ietf.org; Thu, 24 Feb 2005 06:41:24 -0500 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) by smtp12.clb.oleane.net with ESMTP id j1OBHWDg008136 for ; Thu, 24 Feb 2005 12:17:33 +0100 Message-Id: <200502241117.j1OBHWDg008136@smtp12.clb.oleane.net> From: "gunther" To: Date: Thu, 24 Feb 2005 12:17:24 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcUaYmpBeedXNeweSkWp2MKi4eZaQQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Subject: [Simple] Wireless/WiFi Convergence - Paris - France 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="===============0428924396==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba This is a multi-part message in MIME format. --===============0428924396== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C51A6A.CC9C0640" This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C51A6A.CC9C0640 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The Wireless/WiFi Convergence conference will stand in Paris on November 29 to December 2, 2005. A call for papers has been launched, effective until April 15, 2005. The proposals submitted will be examined by a scientific committee. Get more details at: http://www.upperside.fr/wirelessconvergence2005/wwconvergence2005intro.htm ------=_NextPart_000_0047_01C51A6A.CC9C0640 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Wireless/WiFi = Convergence conference will stand in Paris on November 29 to December 2, 2005.
A call for papers has been launched, effective until April 15, = 2005. The proposals submitted will be examined by a scientific committee. =

 

Get more details = at:

http://www.upperside.fr/wirelessconvergence2005/wwconvergenc= e2005intro.htm

 

------=_NextPart_000_0047_01C51A6A.CC9C0640-- --===============0428924396== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0428924396==-- From simple-bounces@ietf.org Thu Feb 24 08:30:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17632; Thu, 24 Feb 2005 08:30:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4JRP-0005c7-JB; Thu, 24 Feb 2005 08:54:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4J0n-0002uL-Pj; Thu, 24 Feb 2005 08:26:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4J0n-0002uF-1h for simple@megatron.ietf.org; Thu, 24 Feb 2005 08:26:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17284 for ; Thu, 24 Feb 2005 08:26:35 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4JNf-0005Wy-B9 for simple@ietf.org; Thu, 24 Feb 2005 08:50:17 -0500 Received: from [127.0.0.1] (IDENT:U2FsdGVkX1/QoqESH8YOvkDI+DHY/+GVerk7/RodsUE@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j1ODQVh3006289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 24 Feb 2005 08:26:32 -0500 (EST) Message-ID: <421DD619.1020308@cs.columbia.edu> Date: Thu, 24 Feb 2005 08:26:49 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Subject: [Simple] draft-ietf-simple-rpid-05 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit draft-ietf-simple-rpid ("RPID: Rich Presence: Extensions to the Presence Information Data Format (PIDF)") has been updated. First, unfortunately the schema (and example) did not get fixed as I'm still struggling with getting substitution groups to work in this particular case and there are other schema issues, such as how to best deal with elements that can appear in both and , for example. With luck, I should have a working schema before the meeting. - Otherwise, the draft has been aligned with the data model and is now considered functionally complete. The presentation was changed to more clearly describe where elements can be used, using tabular formats. - As discussed on the list, the 'timezone' element was replaced by the 'time-offset' one since this is likely to be much simpler for most systems to compute and the complexity of time zone name mapping is not needed in almost all cases. - A 'device-id' element was added as needed by the data model. - Some of the placetype properties (such as 'quiet' and 'noisy') didn't quite fit into their respective lists, so the 'place-is' element was introduced to abstract these characteristics and make the elements more orthogonal and thus easier to filter and display on user interfaces. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From 0alawa@wt.net Thu Feb 24 08:40:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18373; Thu, 24 Feb 2005 08:40:00 -0500 (EST) Received: from [209.149.51.189] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D4JaM-0005ny-4h; Thu, 24 Feb 2005 09:03:42 -0500 Received: from adapt-dns.greenapple.com (111.59.189.90) by kq36-iox3.greenapple.com with Microsoft SMTPSVC(5.0.2195.6824); Thu, 24 Feb 2005 07:31:20 -0600 Date: Thu, 24 Feb 2005 07:32:20 -0600 Message-Id: <96144709025.ba52YDkQP068@gravel408.christensen28greenapple.com> To: mmusic-request@ietf.org Subject: You are being abused! From: feel safe? <0alawa@wt.net> MIME-Version: 1.0 Content-Type: multipart/related; boundary="%OLATTACH1" X-Spam-Score: 11.2 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb This is a multi-part message in MIME format. --%OLATTACH1 Content-Type: multipart/alternative; boundary="%OLATTACH2" --%OLATTACH2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Get a capable html e-mailer WARNING! 95% of all home PC's are infected with dangerous spyware & adware Trojans! http://www.spyware-finder.info?aid=624 Spyware infiltrates your computer without your knowledge or consent! Surfing the net, downloading music, using file sharing software are only few of the ways your computer can get infected! Anti-virus programs DO NOT protect your PC from these Trojans, or even detect them! Only a purposely built spyware removal tool such as Spycontrol can! Put an end to the risk; use the #1 spyware removal tool --%OLATTACH2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WARNING! 95% of all home PC's are infected with dangerous spyware & adware Trojans! http://www.spyware-finder.info?aid=624 Spyware infiltrates your computer without your knowledge or consent! Surfing the net, downloading music, using file sharing software are only few of the ways your computer can get infected! Anti-virus programs DO NOT protect your PC from these Trojans, or even detect them! Only a purposely built spyware removal tool such as Spycontrol can! Put an end to the risk; use the #1 spyware removal tool

Off this camp-aign

--%OLATTACH2-- --%OLATTACH1 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 R0lGODdhUAHaAfcAAAAAAAkJCQkRERAQDhYWExAgHhwhHDAbETAqHiApJS00Ly0+PDg9NzpOSjtZ Vk47LWFKNXZZPkZHQklSTUVcWFdcVkVhXUVlYUtkYE1oZFJsaVtmYV1va2xrW3BsXmZlYmN1cmt/ fHZ2aH14aXh7dXiNiopsT5R9X4WBcYqGdYmJdo+KfKODYqmPc4mMhpOPgpSViJqVhpSdm5+fkZys qK6ahaCckKqSoqeom6uonLehgquyrrazqbq7ubPAv7/MycWgh8mymNLDq87T0NPSzN3ZxNPe3dnk 1uLk1uHg3OTn5+vq6PHx7/7+/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADcp kXyZLJF8AADuPBT1EgAAAAAAAAAAAHz1EgCk9RIAtyyRfMikAQDAMe48hPUSAAAAAACOoIB8AADu PMAx7jyE9RIApaCAfPD1EgAseQAAAAAAABAAAAAJAAAA9PUSAP4AAAC49RIApQLVd/xtSAD+AAAA 0PUSACZ27zwSAAAAAAAAAP4AAAAAAAAA5PUSAM3s1ncAAAAAJnbvPAkAAAD09RIACQAAAAAAAACy AkgACm5IAL49IgBQPSIAy7NCAAAA7jwmdu88JAAAAP8AAADhtEIALHkAAPxtSAD/AAAAvj0iAG32 EgB/3EEALHkAAFA9IgAAAAAAAAAAAHB1FABuAAAAbgAAACABAAAUAAAAAAAUADj0EgBibXA7lPYS ABjukHzwBpF8/////+sGkXwPmoB8AAAUAAgAFAAgmoB8UD0iAAAAAAAAAAAAAAAAAAAAAABE2kQA 5XUUAPzmFgDpdRQA8fkSAP////9wdRQAntpEAOV1FABz0EQAcHUUACH5BAAAAAAALAAAAABQAdoB QAj/AAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMnyIwEl TWIaGUAiZkwSAl/a3GlTyYCBPWz2GChhp4SGQ3g2cVGwqNKdQ4g+3bkw6NSYCoBebYJToNUmQwU6 tblDYM2YYb1ubfJB4dkmRgC44FkhgVGCc3lGHbiWq9m1RwGMbRIYwNe0g58OfPtUSQK+Nrt2ZGzQ AM8fSXcakAoVptCFjKe2FXw3b0ymYgEr/DpVhtaraQ9zjimwAs+0AIzsVNJDN9WqPB9/4ClZQV/X BHdKHihjN2vCqW0Wlh39auDQSqdLb8m9u/fv4MOL/x9Pvrz58+jTq1/PPv2F9/Djy59Pv779+/At WMCAv7///wAGKJ8DE0wggQsqZMCfgAw26OCDEGZAAoQUVmjhhRcsiOGGHL5nAQUTlCDDBhxk0OGJ KFbYQwMptuhigBYo+OKMAmJAgQIukMCBBibS6OOMGrjw45A0aqAhkUjCh4GNJPxAgQVJRomhDxRI aaWFHEB5ZZQNTNDDByBwsOWY/knoJJlo/hdCBlqm+SMGDbiwQwVLumnnezvscOee8oFQJZ80WtCA CDtMsMACgI6JgREgJHpnBo06SiOcH8wpgaRW/rADi5iSCUIJnQbaQAguVFBBqERmQMMEqG5pxAat zv/4IQghTPBkrDPK8EGbuL4JwhC9ylrBmg44ECyKGRgRwp/H0uiAD6A226IFtlbQwK3SYmhECaxm +yIHPnjbIgUNcACDBN2KS6ESMqSrbocOyCDkuydSUIELIzJLL4NKlMDrvhaW+wOsAHNoLwgiNPBv wf398AMGCzPc4AIuGMGpxBdSsAEIExiLMX4KlqCsvh8LaMECMhjhcckUkisCCBJEzDJ8GziswcwM YrAACDuQjHN/JpbgwwIGklDrkT/HB4IROyCdNMglgCAzw7SWUAINWO9AQwgLCFDAfB8e6MIGTj+N wdJNP/2fAxqU0KO3ISgRLocWENiBBBRgq3Z8Ghj/4UOke9/XwKdvi7tACT9gCOcGFRgggcKBy5eB yDJEfh8FbYsJ8AI3t/yBDCIw0MDFliu5wxDRlg52250DXPkCCcQtoAMMqMCB6D6r/qkRJExt+eSA e9t2CDRYXYILBBzqQALM07CAAgpsIEEBoysgwgckkNBBAwysrLp8FZDA+/f1cRBC2a1mAIML+LLP vrwurI9DAgSQsIMAHeQ5AfQKLMDA/wtogPfIN58K7MAH/CkcAUEQPFRpgARWc8Hx2ieDClYQXyRA l4HkZADoMYB/CmCA8nhEQPs0oFIuGCABNRACEKDPUToT4QdBCMIZepB/NrQh9J4nwxLa53gcyF3p HxxgARq44FoNbJX/DkXDJjZRh06EXgJ8KB8OkAAEG/D/Hb34Q4EAIgo+DTgUojz2RXGF8XlRTOPz eEhDKs4HAxzAogq3RDoOOSCMaWziBkg0ujC1TlqjE6Mg+5dHKX7NjQXkQAfIpTb9BFICsCuAAQxQ gAQYoAHMox4iEQnHDUyge5sM5SY15snHJaCOokxl5BZgqgpMYHTF0qQqA5eBDmxABCTYAAQgMAET iOAEDzABAk4AAQQcgAUPSCb/IMCAByzAmf+DpRBjJSgJPC6AzJvlzEpwBCQ4rAhFEEIRgkBOIbRA CEJQQQvOqYITCMEEKuhAC2YAARMIQQfqVAELWgCDddYgAh2IQA1q0IIg4OCgOsCBCn6QAAooUFIK 0CbO/z5QgQcwYJcPiEAEIKDPE7DgoywwwQlGek8WFGGfJkhpBJAZgZSyQJ8QOIFIQcqCd440CB5l gTsJKoQgqEAFOEjdlU42SQMwLwHRq8AHQqiAozo1mxL1FhwLkMxmXjQCHT2BDoKAzq6SEwhbBcI6 yRmEfbbgo+jkag+4yta0grUFOoirSDcagWRWdQJa/NECCFAAEUpSkpREY/8EOM2oHut/H3wAAh6g T51qdKUteMAuEVCBjSZTpRvV6jrPyoLHelajMU3pOkXb2WQilX9zNKxqHWS+EhCqBQhAwAA6QE4c bDUIQNhnS3fbARO0NKAmgMADgBAEJIBTCATdqG89m/9SE3wguMpN6Ql2a4DYImC12KUQm0IgAxio 4AYpPUBsIaDRj7YACD0lq3qJi1uu9vS44SwCEHJrArF+FazzDasO3prSDogAAgc4QDChe71UPjS7 DsKABGAwhCCIdqMV2OVnTwBXHfQ0vUIAJoA3ussOCzcCPWXvfFG6XNCSt6rk3aU9ISCECSHYQmU0 bIR321yd6sC3wjVmgCW80QDbNZkH0GhAIzDSkZb4sR0esJG79OImc+h/n22pTnNKU5WmGLR0jXKU O9wADTr5yyeC3gMkkEwyC5fMdvVwkn3LZiRLVgJnfjOc51wgMBMwA3+8QAv3HII+XyADeMYzj1yg AQb/hqAHP0C0D3rA6B4MYQiIZnSiEe0wITjs0kooAhI2vWlNc/rTSlACEkJN6lKTetRKOEKqTa1q U7v61bCOtaxXTetS++DAdvaRBGQwg177+tfAxsEMhD3sXsuA2MJGdrGT3WtmJ/ugM6DBs4ctbBpQ +9jPPqi2t83tbnub2zsAt7fDfVByf/vc6M62tl2c6xRlj30kyJG8STADGMCg3vi+t73xPYAE2BsG BAiAvmcQ8Hv/mgAE6TUDANBrBASgAgBQAAIS0Ot++1oABAD2wn+dlV4DgAG9xgm9hY2AjDt72AQJ wAS0PQGBUJvbBCBAAgYgAgC0/AM4WI5ZcEAABCx7/wAIUDazg62CDdiyAxxrN4ZIIIKmd2AGIMhl B7C3vvipwLvry3rW48d1rf/762APOwy6G/Z8/7veYx+42vPN9oHjG9hwj7vc5073us+gBnJ3+wwU IAEEdKADDJBARJUOIQuYqgMVcLoI/Pv3nzr+8T/tgAECEACBBIAAH4B8wCkfgMyrAEHeRdAHOH95 9l398x9AeOUBEAADkGDrAOc8AP7tcNIH4Opih0EHSA9ye2+e8k+3N+ttT/qM35sBxK880K+OdhEk PwADoDwDwo6D2BZof0wl/H8UIAAFFGiSXbam+APPAFd2gOm4bDouEUAQCDBdBU3PHglOkL2fDAR7 9P9XAQn0rwKID4Qm+2d/AuF5/Ad5KiCABzEBn7eApwd6n9cBDdEB/7Z6CCGB9rZwCKFyXweBCSFw WId1e4cuITQ6eqN994EBBSIBk2RJTjVxzDNxmLd4fzeDMyiDi3eDN+hf6reDPNiDPoh+TCd/QohL Qpg9+rd/SGiASriETNiEkOddp+eEPwWFVDiFVhiFU7g/YGOC/fEhBmJNDFBULGhUZGgAEzCDFXB0 NLiGNCiDjPd3NliDjKd4OOiDPngC6jd/RCgCR6h/9HcC/Ld/7eR4+weIPyWIBZiIiiiFjNiIV3h1 WjQ1eTUj7VGJlniJmJiJmriJnNiJnviJoBiK4WHOG1BREMpBEJShFmgxG9ChEJZhE0rVEwSRGDyh BFlRHU+hcwbxHDthBKOhilNBENRBGj1hE5kBFq+BjIahFAvRHErhjDzxi7lhEy7wilhhEKeIir+R ELSoFIixFZKRigAgjm8hiuZ4juiYjuq4juzYju74jvAYEnuCAUQ0icciKAYiLwKkORJ1KlFlj9ni hRUAAxywIxKVATuQWqL0QvtiLxX0SrhGRRiwA/w4S1ASkQUzARWAAxuQZ6GUAZUTVR5ZMhTAAPFT ARhJQBbwA6j/JEoV+TMUID4F0pIlJAM9EFXLApAAswE38AEY4I+I9APzMkshcAGFRZIm6QIauUlD 4C6iRAM6KTEgknOP40aoo01z8z0gUgIgQkUaIAM06UMaAAM+tCTcUgFHmTQ+UCipRAE/AJQqSQFR dy3kEwI+AJduZAEhkDh5OSglUJWq0xsVEJVPU0QE40YgopFMVjo+YAQMqToOgDiPWToUIAGMQ5eW QwPKQpg4Ayc/QAOpZAEHAgJhiTNLIwOTGTk1E5Ki5AAvg1eRYyOaWZRu1AAbgDVtWS6elJYlowFD sAMj+T0hUgIK+TQ9AgKfGUBd8gAUhZmxiTapqTbl4jbiAgKh/8Y8MdIjwQkgH+IAHwAmkFM6aJOS gTM4JRCdobIASsCXGAIixyY6xfkzG+ADP/CS5OMAHFAC2xksJlIAQgUhBvIBnyRAC6Qp9qk6dVMC RUmevVICCXBHDoKPkASYJfQrI5KXVoMxNyJDCpA7gNYA5xl4KhACKjBmpWk5JOADOMCge/OV6jJB XNdd3YUDDHCGR4ADA8AbFSADd+lBiCVCz7NJcNQkKeRGeEabwWI18AM/FOQ+7eI/BUIDO/BBMyRD DsCiqpMBG9ADNFAl+7k3FsBCByopAiRFTeVUZypxTaWma4pDTuRFX0o+JEAD7CaWXxlEuGIigSRY hVRDfaoABf+QRCX0QCWwAbwpnXBUficqKWL0p27ap1MkpHHEARDDMhmARyDEPBJQARywARQleAXA I1jaKUzkqDbEpwqwqKqDARuzAUQ0Mx+ypzT0QSGAcQZAACuYAAUQYwWTARQgAALwVIdyAWOKSIbX qeHJhcpqJ3tUAX61rNBKJg3AqtbySrATrfuSAQVCARb1o/9DSEskOgQ6qukZQqaikbTilNgKQ+AS TkOATuMUBHFVBFu1TieAAyfgXwggBAjQdCdgABFQAYCYUUNWT71VIK40AejJJ4O3rpjiAkXQATjQ Ah2QYkU2UgWVrzrgUeN0TwkVVydQBCdQAzcmBDBgT0IQAeT/ZGFxpQO0Ja8rC0464AMm2wF2wiMh AEFgYiqjc30VAGdOxasOGyUWUKjJRAAfJlxnNVJg5WApRU4soAMVJrUtUGIj9QAflVv7tU5idVYb +1Fy5VFEFgQtVXRkMyYZgKuTpLZFhVhPdVT9w5lDyyEYwFQKoFiSJU9w1VVdxV41AAQ4MF/ENV8X JgQ90FWHa7jolLhrhWE+FVwVJXEWZVHxObei1ACSG1sdQFBVq1HBtUsiYAKKZX1FQF51VUwmYFya pmH15GFAZrrRlWUQkAAIIHGGRa5rcwHJ6kYQUyoV27rG1AHqFLWGy1bqdbwi1lVDUATvalYk5lsy ZWTNJVPNRSVdESBeAtYC8dMBC2u5lmMBPNMCNXADQJBSkrVLMyZl53W8uCUEGRVgn/UA4gVdxBVW uDVf4rtPOnVikqUAB1BP9aVR8f/mvYb1kwQFZ6YLwL5lVlulX8SlvyzQYaKrYkTGXvdrAp3FXLtk TUQWUmwmvpdCwC9GARDQANVruhg8Uh9lYmqmZVEWwS7MS9fXvSIsUVU1ueSlAnEFsw2cW/rLWTRV ZbDLYREQfupaw9rkPkZoLbXLALVLuwkQZGMmXGNWZpKVTBAwZ2q2wVmMUcLVxW92ZhCQq2jaP6+K xLjCa782dCenbS+XbnAcx3J8buaWbnUcbuSGxzigx3tcbn2sx3VsUHyMAwY1xzKAu0i8gAiSI702 dnJXc5XHefT2GKwHAAYQd9HHeRIwAxs3A49BcfOTAMImAJUMAATQxshXyQMAAwf/9XHDJnIzQHwM wG3DV3kigAMQF3Q4KnDbhnzDhnASQKOzhxOzLMwkcFCq9xO6DG3MvGzUNpRoXB8WIAJ/KQLugyCf 93q5F3ZA93W3qHxnt28DMH36BgMLd28JIHAzAHEUF8vQJxAK4GtqPAOBEckGlxWUBwA+52v0A3fC BgADgHAR12yxHHQETWyxzHDCDHIzQMzDtnC3THAEcck4UHMVUHf91wETAAFGZ03R/GcSsHghIAIj nT0hvXjY/HiLrMgsbXpWl3VXFz9a13Uzvc02bdNmh3b7ttNs19O+tnZ2V3cGN9SNXNQ5Xc72Vn3l h7BMxQBoHH7it6n9l4LCy4d8/4iEu5dyBkKBAMB/CEiAkCeNA+B4/vd/gEcQA7DIAth6BaEApwfT H7i9BKEA/ybQAiECEzgQHph7GHjX3rXWeA0DNTcQ5HzTNBrVIcQANGxnhmdUtGtU3meG4jcBzHMA OuiDm+GK6YeABoEA81fWAD1/2cPVB1E7AajXPyWNEed42JzSLsCB8IzNCNgB2EzaBeGBKtDXACCB mW15uAfbCLHKH6gCNbA/ohPNKDgBuMqCzEOGzG0AaaiGbAiH0x2Hc3jdinfZdrjd8Rd/ov3d+Sfa geiI5F3e5g2FWAiJ/iG3lBiP7v3e8B3f8j3f9F3f9n3f+J3f+r3f/N3fKkGKq/+Ii3thydBoEzJA ycn4jdvBEMbRiwbRjWgB2hBuE8DxFEbgAgjIi9m4jAFOjDFR1m+BG6HtGTshA5xtECSOEwNQigCw A2RRECQeEwgOAH2xHB/gGzZhBBJ+F8Co4FexGE+BBDJwi5BxEx3h4k9B5F+BBASB4wM+jINRGAnx FsfYBDu+4KbRBKwoA0Uo5QdBHYwhgF/BO0UojJ+BizHhEyEO5DbR29DTECseGUpx4cY411BBjQex 4bWxE79oQBlkf4PB5dmD4z7eBIIuf4Uhjk6ejF6uEeI4EMc44AAQ6ck44ADeiglR5c/IiiRQ5Vce E41e4co4jTFRFj2+Gmfu4Vr/zotpkeU/4QKMto0I0eA7URYx3gRKgBdbERemGBkFcemJDhcuEBhR nuCsGOp/QeECgeRwMRAKwGio4RGPThAVgOM9AdoDkeU2gQREjhDW2ASmvuw78RPFPo47ERYTDuqo PhU6buawYey4OBA60eECwQAa3gPI3hQ7Ee1V3uSyyOYfnhy+bhADoOHRrura0eHp3orYIROq/RX5 7t8SP/EUX/EWf/EYn/Eav/Ec3/EeX/F84gAluC8OgC4fMAMh8AFxSkXaalgjDzAgIjY/udil8wGG pR --%OLATTACH1-- From simple-bounces@ietf.org Thu Feb 24 11:23:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10895; Thu, 24 Feb 2005 11:23:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4M8r-0002S0-IE; Thu, 24 Feb 2005 11:47:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Ljo-00043C-SQ; Thu, 24 Feb 2005 11:21:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Ljn-0003zn-MI; Thu, 24 Feb 2005 11:21:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10484; Thu, 24 Feb 2005 11:21:13 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4M6i-0002K8-5F; Thu, 24 Feb 2005 11:44:57 -0500 Received: from lion.cs.columbia.edu (IDENT:TSP+0Ov+vR2JFjtJTcCldNbIjMZ1FyOY@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j1OGL9ir027035 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 24 Feb 2005 11:21:09 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id j1OGL8Rn031138 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 24 Feb 2005 11:21:09 -0500 Message-ID: <421DFEEF.4070107@cs.columbia.edu> Date: Thu, 24 Feb 2005 11:21:03 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Geopriv] Re: [Simple] presence authorization issue: anonymous, authenticated, etc. References: <42146290.5090209@cisco.com> <4214ADD0.3070101@cs.columbia.edu> <4214B803.7070304@cisco.com> <4214FDA3.3060701@cisco.com> <421B01D4.3050507@nokia.com> <421BF247.5090903@cisco.com> <421C3B30.8050104@nokia.com> In-Reply-To: <421C3B30.8050104@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Paul Kyzivat , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit > http://www1.ietf.org/mail-archive/web/geopriv/current/msg00381.html > > In essence, what you are saying above is that because identities can be > minted easily in domain B, it automatically leads to valid credentials > being generated for (my) domain A for that identity. If this was true > given a *real* authentication mechanism in place (and not one based on a > weak notion of transitive trust, for example), then what purpose does > authentication serve in this system anyway? I think you're missing the central problem and the core difference between white lists (additive permissions) and black lists. Assuming strong authentication is necessary and sufficient for white lists, but has little bearing on blacklists. Example: Yahoo performs (reasonably) strong authentication and authorization on its users, so that only the owner of the account can get access to the service. However, it is trivial for the same (bad) person to get another account that is equally strongly authenticated, with a different identifier, but easily bypasses the earlier blacklist entry. Another example: Our local email system strongly authenticates users when submitting email. However, I can easily submit messages using hgs@cs henning@cs schulzrinne@cs h.schulzrinne@cs hgs+foo@cs hgs+bar@cs (and any other variation of hgs+?@cs) as the 'From' address. I can make up these '+' identifiers on the fly. Again, the authentication model is quite sufficient for a whitelist (nobody else can create hgs+?@cs messages), but useless for a blacklist. As we have elaborated on in a techreport (details available on request), it is insufficient to know the authentication strength for identity assertion algorithms. In addition, one needs to carefully consider the ease of identifier creation and whether individuals can have one, many or an infinite supply of identifiers. Unless you restrict the domain of applicability to those with "single user, single identifier" policies that you trust, this is all mostly make-believe security. > > I don't think authorization and authentication can be lumped together > here in this way. Even if domain B has a nonchalant way of giving out > identities, it is still domain A's business to determine who's got valid > credentials in its domain. As an example, domain A could require a > digest username/password, and the assignment of those credentials is > solely the responsibility of domain A, and can be as scrutinizing as > required. > > So apologies for sounding like a broken record, but I think ultimately > in such a system that can't safely handle a block-list, authentication > is broken, not authorization. I think you're fundamentally mis-understanding the relationship of authentication to identifier uniqueness and predictability. Until we arrive at a common understanding, we'll keep talking past each other. Given the very different properties of whitelists and blacklists, I had suggested that we create a separate mechanism for the latter, with appropriate buyer-beware warnings. That way, we don't have to weaken the additive properties of the main policy mechanism. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From dipta@about.com Thu Feb 24 16:19:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22768 for ; Thu, 24 Feb 2005 16:19:15 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4QOB-0004dE-Gm for simple-archive@ietf.org; Thu, 24 Feb 2005 16:19:18 -0500 Received: from [210.100.154.20] (helo=210.100.154.20) by mx2.foretec.com with smtp (Exim 4.24) id 1D4QO6-0004uN-NW for simple-archive@ietf.org; Thu, 24 Feb 2005 16:19:11 -0500 Message-ID: From: "Jennifer A. Clark" To: simple-archive@ietf.org Subject: =?iso-8859-1?B?TWljcm9zb2Z0IE9mZmljZSAyMDAzIC0gdmVyeSBsb3cgcHJpY2U=?= Date: Thu, 24 Feb 2005 21:13:18 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_EB2443FA.19403F0E" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 13.2 (+++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 31247fb3be228bb596db9127becad0bc This is a multi-part message in MIME format. ------=_NextPart_000_0000_EB2443FA.19403F0E Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_FF912332.E1B985FA" ------=_NextPart_001_0001_FF912332.E1B985FA Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Get access to all the popular software you need for bottom prices! We sell software 2-6 times cheaper than retail price. A few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $59.95 Corel Draw Graphics Suite 11 Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Photoshop CS + Adobe Illustrator CS + Adobe InDesign CS $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And lots more... To view full list of products go: http://www.mxsoft.biz Best regards, Jennifer A. Clark _____________________________________________________ To change your mail details, go here: http://www.mxsoft.biz/uns.htm _____________________________________________________ ------=_NextPart_001_0001_FF912332.E1B985FA Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Access all the popular software you need for wholesale prices!
Our software is 2-10 times cheaper than sold by our competitors.

Just a few examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$59.95 Corel Draw Graphics Suite 11

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Photoshop CS + Adobe Illustrator CS + Adobe InDesign CS
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many other... For full list of products go:

http://www.mxsoft.biz

Best,
Jennifer A. Clark


_____________________________________________________
To be taken out, go here: http://www.mxsoft.biz/uns.htm
_____________________________________________________

------=_NextPart_001_0001_FF912332.E1B985FA-- ------=_NextPart_000_0000_EB2443FA.19403F0E-- From simple-bounces@ietf.org Fri Feb 25 00:54:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11252; Fri, 25 Feb 2005 00:54:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4YQs-0007qm-5A; Fri, 25 Feb 2005 00:54:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4YQ5-0005Ty-1S; Fri, 25 Feb 2005 00:53:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4YPx-0005Nn-EC for simple@megatron.ietf.org; Fri, 25 Feb 2005 00:53:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11234 for ; Fri, 25 Feb 2005 00:53:34 -0500 (EST) Received: from oe-im2pub.managedmail.com ([206.46.164.53] helo=oe-im2.bizmailsrvcs.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4YQ0-0007pz-MG for simple@ietf.org; Fri, 25 Feb 2005 00:53:42 -0500 Received: from mm-ismta4.bizmailsrvcs.net ([192.168.133.29]) by oe-im2.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20050225055326.DNAQ1989.oe-im2.bizmailsrvcs.net@mm-ismta4.bizmailsrvcs.net>; Thu, 24 Feb 2005 23:53:26 -0600 Received: from THANOSDIACAKIS3 ([67.173.251.228]) by mm-ismta4.bizmailsrvcs.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20050225055326.KEBO7908.mm-ismta4.bizmailsrvcs.net@THANOSDIACAKIS3>; Thu, 24 Feb 2005 23:53:26 -0600 From: "Thanos Diacakis" To: "'Jonathan Rosenberg'" Subject: RE: [Simple] Re: pres-rules/common-pol: splitting and Date: Thu, 24 Feb 2005 22:53:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTCLlaT83v8A21dTQuGUok7Oot3eBYz9n2Q In-Reply-To: <41897027.9060005@cisco.com> Message-Id: <20050225055326.KEBO7908.mm-ismta4.bizmailsrvcs.net@THANOSDIACAKIS3> X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: krisztian.kiss@nokia.com, jdrosen@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Jonathan, How is this issue addressed in this latest release of the presence-rules draft? Thanks Thanos > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Wednesday, November 03, 2004 4:56 PM > To: Thanos Diacakis > Cc: krisztian.kiss@nokia.com; jdrosen@dynamicsoft.com; simple@ietf.org > Subject: Re: [Simple] Re: pres-rules/common-pol: splitting > and > > > > Thanos Diacakis wrote: > > > So an implementation would need to evaluate the conditions > in *every* > > row, whenever a subscription is received *and* everytime a > > notification is about to be sent? > > No. Sorry I was not being clear. > > Assuming you are associating a condition with a "row" in a > database, the presence rules specification will call out > which rows are applicable to processing the subscription, and > which are needed for processing the privacy filtering before > a notification is sent. The document doesn't do that now. I > will correct that in the next revision. > > > > > > That doesn't seem like a very efficient way of doing things. > > > > I think having those into two tables, would make life easier. If > > you're trying to decide whether you're authorizing a sub, > you look in > > the one table. Conversely, if you're trying to determine what > > transformations to apply to send out a notification, you > look at the other table. > > An implementation that works this way is possible. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 25 02:29:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10173; Fri, 25 Feb 2005 02:29:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Zv2-0001JI-VS; Fri, 25 Feb 2005 02:29:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Zup-0007JI-Ck; Fri, 25 Feb 2005 02:29:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Zui-00079k-4K for simple@megatron.ietf.org; Fri, 25 Feb 2005 02:29:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10142 for ; Fri, 25 Feb 2005 02:29:26 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Zun-0001Iy-1N for simple@ietf.org; Fri, 25 Feb 2005 02:29:33 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1P7TWA02500 for ; Fri, 25 Feb 2005 09:29:32 +0200 (EET) X-Scanned: Fri, 25 Feb 2005 09:29:12 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j1P7TCw6025851 for ; Fri, 25 Feb 2005 09:29:12 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00fzwjOC; Fri, 25 Feb 2005 09:29:09 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1P7T4M03874 for ; Fri, 25 Feb 2005 09:29:04 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 25 Feb 2005 09:28:48 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 25 Feb 2005 09:28:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-03.txt Date: Fri, 25 Feb 2005 09:28:48 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F3AB034@esebe103.NOE.Nokia.com> Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-03.txt Thread-Index: AcUaCK2RRFureY0gQ9mew/f7+9xV+gA/0peg To: X-OriginalArrivalTime: 25 Feb 2005 07:28:48.0739 (UTC) FILETIME=[A5A23B30:01C51B0B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Hi All, Here is a list of changes that has been put into version 03: - Substitution group usage removed from XML schemas. Uses now ##any for extensibility. Some parts of the schema rewritten to limit the amount of duplicate element declarations.=20 - Added possibility to indicate =3D, <, >, and range functions in - Updated example and fixed XML namespace bugs in examples - Small edits and bug fixes. - Mikko=20 >-----Original Message----- >From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]=20 >On Behalf Of ext Internet-Drafts@ietf.org >Sent: Tuesday, February 22, 2005 23:14 >To: i-d-announce@ietf.org >Cc: simple@ietf.org >Subject: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-03.txt > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. >This draft is a work item of the SIP for Instant Messaging and=20 >Presence Leveraging Extensions Working Group of the IETF. > > Title : User Agent Capability Extension to=20 >Presence Information Data Format(PIDF) > Author(s) : M. Lonnfors, K. Kiss > Filename : draft-ietf-simple-prescaps-ext-03.txt > Pages : 32 > Date : 2005-2-22 >=09 >Interoperation of Instant Messaging and Presence systems has been > defined in the IMPP working group. The IMPP WG has come up with > baseline interoperable operations and formats for presence and > instant messaging systems. However, these base formats might need > standardized extensions in order to enable building rational > applications using presence and instant messaging. This=20 >memo defines > an extension to represent RFC3840 capabilities in the Presence > Information Document Format (PIDF) compliant presence documents. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-simple-prescaps- >ext-03.txt > >To remove yourself from the I-D Announcement list, send a=20 >message to i-d-announce-request@ietf.org with the word=20 >unsubscribe in the body of the message. =20 >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login=20 >with the username "anonymous" and a password of your e-mail=20 >address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-simple-prescaps-ext-03.txt". > >A list of Internet-Drafts directories can be found in=20 >http://www.ietf.org/shadow.html or=20 >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-simple-prescaps-ext-03.txt". >=09 >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 >mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 25 02:35:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10827; Fri, 25 Feb 2005 02:35:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4a0U-0001Qx-Ku; Fri, 25 Feb 2005 02:35:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Zzd-00022g-5y; Fri, 25 Feb 2005 02:34:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Zza-00021t-JX for simple@megatron.ietf.org; Fri, 25 Feb 2005 02:34:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10624 for ; Fri, 25 Feb 2005 02:34:29 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Zzf-0001Pa-Ii for simple@ietf.org; Fri, 25 Feb 2005 02:34:36 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1P7YYA09806 for ; Fri, 25 Feb 2005 09:34:35 +0200 (EET) X-Scanned: Fri, 25 Feb 2005 09:34:13 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j1P7YD9E031291 for ; Fri, 25 Feb 2005 09:34:13 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00Fkni41; Fri, 25 Feb 2005 09:34:11 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1P7YBU12492 for ; Fri, 25 Feb 2005 09:34:11 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 25 Feb 2005 09:33:36 +0200 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 25 Feb 2005 09:33:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-partial-notify-04.txt Date: Fri, 25 Feb 2005 09:33:38 +0200 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F3AB036@esebe103.NOE.Nokia.com> Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-partial-notify-04.txt Thread-Index: AcUZWUxKn8YzbInhTxm94BpUZQaUKwBsmmxA To: X-OriginalArrivalTime: 25 Feb 2005 07:33:38.0231 (UTC) FILETIME=[522F3470:01C51B0C] X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Hi all, Below list of changes for version 04: - Small editorial changes to PA and watcher behavior to clarify functionality. - Updated the example and references - Added text into security section about use of TLS and S/MIME. - Mikko >-----Original Message----- >From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]=20 >On Behalf Of ext Internet-Drafts@ietf.org >Sent: Monday, February 21, 2005 22:59 >To: i-d-announce@ietf.org >Cc: simple@ietf.org >Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-notify-04.txt > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. >This draft is a work item of the SIP for Instant Messaging and=20 >Presence Leveraging Extensions Working Group of the IETF. > > Title : Partial Notification of Presence Information > Author(s) : M. Lonnfors, et al. > Filename : draft-ietf-simple-partial-notify-04.txt > Pages : 16 > Date : 2005-2-21 >=09 >By default, presence delivered using the Presence Event Package for > the Session Initiation Protocol is represented in the Presence > Information Data Format (PIDF). A PIDF document contains a set of > elements, each representing a different aspect of the presence being > reported. When any subset of the elements change, even a just a > single element, a new document containing the full set of=20 >elements is > delivered. This memo defines an extension allowing=20 >delivery of a new > document type that contains the data that has actually changed. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-n >otify-04.txt > >To remove yourself from the I-D Announcement list, send a=20 >message to i-d-announce-request@ietf.org with the word=20 >unsubscribe in the body of the message. =20 >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login=20 >with the username "anonymous" and a password of your e-mail=20 >address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-simple-partial-notify-04.txt". > >A list of Internet-Drafts directories can be found in=20 >http://www.ietf.org/shadow.html or=20 >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-simple-partial-notify-04.txt". >=09 >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 >mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From conrado4353abbatant@farnsworthvonberg.com Fri Feb 25 04:02:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18854; Fri, 25 Feb 2005 04:02:07 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4bMP-0003CM-NC; Fri, 25 Feb 2005 04:02:14 -0500 Received: from [220.125.53.253] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1D4bMC-000573-Bk; Fri, 25 Feb 2005 04:01:56 -0500 Received: from mundo91.ldtoy.com (220.125.53.253) by 220.125.53.253 with Microsoft SMTP148(8.67.227.33); Fri, 25 Feb 2005 06:51:18 -0200 Received: from 220.125.53.253 (orla[220.125.53.253]) by chambers798.ldtoy.com (vuqkktdy3294) with SMTP id <82npqx319co>;Fri, 25 Feb 2005 14:53:18 +0600 Message-ID: Reply-To: "idette margalo" From: "idette margalo" To: rip-admin@ietf.org Cc: hc-admin@ietf.org, cna@ietf.org, simple-archive@ietf.org, imrg-request@ietf.org Subject: Application Form Accepted Date: Fri, 25 Feb 2005 02:54:18 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--97071_92992151.15K51" X-Spam-Score: 6.6 (++++++) X-Spam-Flag: YES X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a ----97071_92992151.15K51 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Homeowner, We tried contacting you last week about your low interest mortg[a]ge rate. You have qualified for the lowest rate in years... You could get over $400,000 for as little as $450 a month! Have Ba(d) credit? No Problem...low rates are fixed no matter what! To get a free, no obli[g]ation consultation click below: http://www.lenderz4you.com/x/loan.php?id=jrwriter Best Regards, idette margalo to be re[mov]ed: http://www.lenderz4you.com/x/st.html *re[m]ov[al process takes atleast one week. we do our best to take your email(s) off our lists but you have to fill out a [r]emove or else you will continue to recieve ema[ils]. ----97071_92992151.15K51-- From simple-bounces@ietf.org Fri Feb 25 06:42:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03493; Fri, 25 Feb 2005 06:42:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4drR-0006gW-P8; Fri, 25 Feb 2005 06:42:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4dn0-0006VS-Ue; Fri, 25 Feb 2005 06:37:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4dmz-0006VJ-Cj; Fri, 25 Feb 2005 06:37:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03017; Fri, 25 Feb 2005 06:37:42 -0500 (EST) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4dn5-0006b4-Fc; Fri, 25 Feb 2005 06:37:52 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1PBaVZ06634; Fri, 25 Feb 2005 13:36:31 +0200 (EET) X-Scanned: Fri, 25 Feb 2005 13:49:46 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j1PBnkN6027331; Fri, 25 Feb 2005 13:49:46 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00AcX72u; Fri, 25 Feb 2005 13:49:45 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1PBaLM08209; Fri, 25 Feb 2005 13:36:21 +0200 (EET) Received: from [172.21.39.180] ([172.21.39.180]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 25 Feb 2005 13:36:15 +0200 Message-ID: <421F0DAD.20907@nokia.com> Date: Fri, 25 Feb 2005 13:36:13 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Henning Schulzrinne Subject: Re: [Geopriv] Re: [Simple] presence authorization issue: anonymous, authenticated, etc. References: <42146290.5090209@cisco.com> <4214ADD0.3070101@cs.columbia.edu> <4214B803.7070304@cisco.com> <4214FDA3.3060701@cisco.com> <421B01D4.3050507@nokia.com> <421BF247.5090903@cisco.com> <421C3B30.8050104@nokia.com> <421DFEEF.4070107@cs.columbia.edu> In-Reply-To: <421DFEEF.4070107@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2005 11:36:15.0009 (UTC) FILETIME=[36B34110:01C51B2E] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Paul Kyzivat , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Inline. ext Henning Schulzrinne wrote: >> http://www1.ietf.org/mail-archive/web/geopriv/current/msg00381.html >> >> In essence, what you are saying above is that because identities can >> be minted easily in domain B, it automatically leads to valid >> credentials being generated for (my) domain A for that identity. If >> this was true given a *real* authentication mechanism in place (and >> not one based on a weak notion of transitive trust, for example), then >> what purpose does authentication serve in this system anyway? > > > I think you're missing the central problem and the core difference > between white lists (additive permissions) and black lists. Assuming > strong authentication is necessary and sufficient for white lists, but > has little bearing on blacklists. > > Example: Yahoo performs (reasonably) strong authentication and > authorization on its users, so that only the owner of the account can > get access to the service. However, it is trivial for the same (bad) > person to get another account that is equally strongly authenticated, > with a different identifier, but easily bypasses the earlier blacklist > entry. > > Another example: Our local email system strongly authenticates users > when submitting email. However, I can easily submit messages using > hgs@cs > henning@cs > schulzrinne@cs > h.schulzrinne@cs > hgs+foo@cs > hgs+bar@cs > (and any other variation of hgs+?@cs) as the 'From' address. I can make > up these '+' identifiers on the fly. Again, the authentication model is > quite sufficient for a whitelist (nobody else can create hgs+?@cs > messages), but useless for a blacklist. Strongly authenticated at yahoo.com or cs.columbia.edu, not necessarily at jippii.fi or nokia.com. But granted, in most practical scenarios, this would mean exceptions in the condition would experience inflation quite quickly. > As we have elaborated on in a techreport (details available on request), > it is insufficient to know the authentication strength for identity > assertion algorithms. In addition, one needs to carefully consider the > ease of identifier creation and whether individuals can have one, many > or an infinite supply of identifiers. Unless you restrict the domain of > applicability to those with "single user, single identifier" policies > that you trust, this is all mostly make-believe security. I do get the point you make above, so the question is: could we make the any-except construct little less susceptable to identity minting by taking in this notion of weak domains? Would it help if we define the identity condition in such a way that the exceptions can also be to domains? example.net badguy@nokia.com Then, for example upon witnessing a lot of harrassing requests for authorization from a specific domain the rule maker could add that domain as an exception to the "any" rule that grants the "confirm" permission. >> I don't think authorization and authentication can be lumped together >> here in this way. Even if domain B has a nonchalant way of giving out >> identities, it is still domain A's business to determine who's got >> valid credentials in its domain. As an example, domain A could require >> a digest username/password, and the assignment of those credentials is >> solely the responsibility of domain A, and can be as scrutinizing as >> required. >> >> So apologies for sounding like a broken record, but I think ultimately >> in such a system that can't safely handle a block-list, authentication >> is broken, not authorization. > > > I think you're fundamentally mis-understanding the relationship of > authentication to identifier uniqueness and predictability. Until we > arrive at a common understanding, we'll keep talking past each other. I actually think I understand the argument better now, thanks. Does the proposal address the disagreement? I think if we are fine with allowing per-domain blacklists, then this is the missing component that links those blacklists with the global wildcard structure in a clean, privacy-safe way. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 25 08:41:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14575; Fri, 25 Feb 2005 08:41:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4fiW-0000nF-2e; Fri, 25 Feb 2005 08:41:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4fcQ-0003j0-8F; Fri, 25 Feb 2005 08:34:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4fcO-0003iq-49; Fri, 25 Feb 2005 08:34:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14093; Fri, 25 Feb 2005 08:34:54 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4fcT-0000ew-J3; Fri, 25 Feb 2005 08:35:04 -0500 Received: from [127.0.0.1] (IDENT:U2FsdGVkX1917YtBSiPHnfgcLYo6iEulL+tDgvyG6DQ@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j1PDYlh3024491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 Feb 2005 08:34:48 -0500 (EST) Message-ID: <421F29E8.2010104@cs.columbia.edu> Date: Fri, 25 Feb 2005 08:36:40 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Geopriv] Re: [Simple] presence authorization issue: anonymous, authenticated, etc. References: <42146290.5090209@cisco.com> <4214ADD0.3070101@cs.columbia.edu> <4214B803.7070304@cisco.com> <4214FDA3.3060701@cisco.com> <421B01D4.3050507@nokia.com> <421BF247.5090903@cisco.com> <421C3B30.8050104@nokia.com> <421DFEEF.4070107@cs.columbia.edu> <421F0DAD.20907@nokia.com> In-Reply-To: <421F0DAD.20907@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Paul Kyzivat , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Aki Niemi wrote: > Inline. > > > Strongly authenticated at yahoo.com or cs.columbia.edu, not necessarily > at jippii.fi or nokia.com. But granted, in most practical scenarios, > this would mean exceptions in the condition would experience > inflation quite quickly. The problem is also that for most practical cases, you don't know the policy of the remote domain. (I'm assuming that if there's a really annoying person within your own company that you'd like to blacklist, that there are other local mechanisms to deal with them.) Since the bad actor can trivially create a new identity for each new SUBSCRIBE, the blacklist will be completely ineffective. Early spam filters had blacklists; we now know that they are useless (and would be largely useless even with SPF). > I do get the point you make above, so the question is: could we make the > any-except construct little less susceptable to identity minting by > taking in this notion of weak domains? Under the current circumstances, I don't see how you can reliably determine this. I have no clue what Nokia's domain policy is and no automated way of finding out. > > Would it help if we define the identity condition in such a way > that the exceptions can also be to domains? Yes, I thought we discussed this earlier (at the last meeting?), but maybe this got lost somewhere. > > > > > > example.net > badguy@nokia.com > > > > > > Then, for example upon witnessing a lot of harrassing requests for > authorization from a specific domain the rule maker could add that > domain as an exception to the "any" rule that grants the "confirm" > permission. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 25 09:06:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17396; Fri, 25 Feb 2005 09:06:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4g7K-0001Oa-Ji; Fri, 25 Feb 2005 09:06:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4g3w-0000Z7-8c; Fri, 25 Feb 2005 09:03:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4g3v-0000YR-3k for simple@megatron.ietf.org; Fri, 25 Feb 2005 09:03:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17014 for ; Fri, 25 Feb 2005 09:03:21 -0500 (EST) Received: from usagi.ingate.se ([193.180.23.12]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4g40-0001Hb-EM for simple@ietf.org; Fri, 25 Feb 2005 09:03:31 -0500 Received: from eeek.ingate.se (eeek.ingate.se [193.180.23.45]) by usagi.ingate.se (8.12.11/8.12.11) with ESMTP id j1PE30nI016460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 25 Feb 2005 15:03:00 +0100 Received: from eeek.ingate.se (localhost.localdomain [127.0.0.1]) by eeek.ingate.se (8.12.11/8.12.11) with ESMTP id j1PE30xp018604 for ; Fri, 25 Feb 2005 15:03:00 +0100 Received: (from hasse@localhost) by eeek.ingate.se (8.12.11/8.12.11/Submit) id j1PE30U9018603 for simple@ietf.org; Fri, 25 Feb 2005 15:03:00 +0100 X-Authentication-Warning: eeek.ingate.se: hasse set sender to hasse@ingate.com using -f Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-msrp-relays-03.txt From: Hans Persson To: simple@ietf.org In-Reply-To: <200502222113.QAA22916@ietf.org> References: <200502222113.QAA22916@ietf.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Ingate Systems Message-Id: <1109340179.11313.29.camel@eeek.ingate.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 25 Feb 2005 15:02:59 +0100 X-Virus-Scanned: ClamAV 0.83/725/Fri Feb 25 12:28:29 2005 on usagi.ingate.se X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (usagi.ingate.se [193.180.23.12]); Fri, 25 Feb 2005 15:03:00 +0100 (CET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Hi, Reading through this draft, I find this: > Clients can be configured (typically through discovery or manual > provisioning) with a list of relays they need to use. However, I can't figure out how "discovery" is supposed to work. In deployments, it is likely that an MSRP relay will be colocated with a firewall/NAT (or at least somehow used to traverse it), so a client behind the firewall/NAT must find this relay and use it. In places like hotels, users are unlikely to know exactly where the MSRP relay is. How can the client find this out? Can DHCP be used? Hans -- Hans Persson Ingate - Firewalls with SIP & NAT Ingate Systems AB +46 13 210877 http://www.ingate.com/ Private: http://www.lysator.liu.se/~unicorn/ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 25 09:22:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19363; Fri, 25 Feb 2005 09:22:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4gMb-0001sm-Sd; Fri, 25 Feb 2005 09:22:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4gL0-00064O-Bu; Fri, 25 Feb 2005 09:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4gKy-00060F-DR; Fri, 25 Feb 2005 09:21:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19153; Fri, 25 Feb 2005 09:20:58 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4gL6-0001pi-5W; Fri, 25 Feb 2005 09:21:09 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1PEKeU15342; Fri, 25 Feb 2005 16:20:40 +0200 (EET) X-Scanned: Fri, 25 Feb 2005 16:20:05 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j1PEK5Bk005934; Fri, 25 Feb 2005 16:20:05 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00eawzvz; Fri, 25 Feb 2005 16:20:04 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1PEK3M29306; Fri, 25 Feb 2005 16:20:03 +0200 (EET) Received: from [172.21.39.180] ([172.21.39.180]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 25 Feb 2005 16:19:51 +0200 Message-ID: <421F3406.8020106@nokia.com> Date: Fri, 25 Feb 2005 16:19:50 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Henning Schulzrinne Subject: Re: [Geopriv] Re: [Simple] presence authorization issue: anonymous, authenticated, etc. References: <42146290.5090209@cisco.com> <4214ADD0.3070101@cs.columbia.edu> <4214B803.7070304@cisco.com> <4214FDA3.3060701@cisco.com> <421B01D4.3050507@nokia.com> <421BF247.5090903@cisco.com> <421C3B30.8050104@nokia.com> <421DFEEF.4070107@cs.columbia.edu> <421F0DAD.20907@nokia.com> <421F29E8.2010104@cs.columbia.edu> In-Reply-To: <421F29E8.2010104@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Feb 2005 14:19:51.0371 (UTC) FILETIME=[11B539B0:01C51B45] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Paul Kyzivat , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Inline. ext Henning Schulzrinne wrote: >> I do get the point you make above, so the question is: could we make >> the any-except construct little less susceptable to identity minting >> by taking in this notion of weak domains? > > > Under the current circumstances, I don't see how you can reliably > determine this. I have no clue what Nokia's domain policy is and no > automated way of finding out. Exactly, but this is a limitation already inherent in the common policy domain wildcard conditions. I think in the general case determining this and being able to discriminate against "weak" domains will be hard for the average-joe. But then again maybe not that hard, since I think people already today have a pretty good idea about these policies in email accounts. Everyone knows that a username in gmail.com is in relative short supply compared to some other free email providers. Corporate email accounts usually have much tighter policies. >> Would it help if we define the identity condition in such a way >> that the exceptions can also be to domains? > > > Yes, I thought we discussed this earlier (at the last meeting?), but > maybe this got lost somewhere. Apologies if I missed this before. It is sort of obvious, must admit. There is one catch to this, however. I think such a condition should only ever be applied to something like a "confirm" permission. It would not work well with an "allow", quite naturally. That would be shooting oneself in the leg, like Jonathan was worried would happen. But this should be relatively easy to capture in specification writing. Cheers, Aki > >> >> >> >> >> >> example.net >> badguy@nokia.com >> >> >> >> >> >> Then, for example upon witnessing a lot of harrassing requests for >> authorization from a specific domain the rule maker could add that >> domain as an exception to the "any" rule that grants the "confirm" >> permission. > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 25 09:47:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22032; Fri, 25 Feb 2005 09:47:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4gko-0002Wz-PY; Fri, 25 Feb 2005 09:47:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4gjZ-00019t-4K; Fri, 25 Feb 2005 09:46:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4gjX-00015d-IO for simple@megatron.ietf.org; Fri, 25 Feb 2005 09:46:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21930 for ; Fri, 25 Feb 2005 09:46:21 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4gjf-0002Uh-6c for simple@ietf.org; Fri, 25 Feb 2005 09:46:32 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 25 Feb 2005 06:57:50 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1PEjuuC002546; Fri, 25 Feb 2005 06:45:56 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-69.cisco.com [10.86.242.69]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIA61532; Fri, 25 Feb 2005 06:45:56 -0800 (PST) Message-ID: <421F3A25.7030204@cisco.com> Date: Fri, 25 Feb 2005 09:45:57 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thanos Diacakis Subject: Re: [Simple] Re: pres-rules/common-pol: splitting and References: <20050225055326.KEBO7908.mm-ismta4.bizmailsrvcs.net@THANOSDIACAKIS3> In-Reply-To: <20050225055326.KEBO7908.mm-ismta4.bizmailsrvcs.net@THANOSDIACAKIS3> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Cc: krisztian.kiss@nokia.com, jdrosen@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit The following text appears in presence-rules now: Care must be taken in using as a condition for determining the subscription handling. Since the value of changes dynamically, a state change can cause a subscription to be suddenly Rosenberg Expires August 22, 2005 [Page 6] Internet-Draft Presence Authorization February 2005 terminated. The watcher has no way to know, aside from polling, when their subscription would be re-instated as the value of changes. For this reason, is primarily useful for matching on rules that define transformations. Unfortunately, it appears that I messed up here, and the last word should read "actions" and not "transformations". I've repaired that in my working copy of -03. -Jonathan R. Thanos Diacakis wrote: > Jonathan, > > How is this issue addressed in this latest release of the presence-rules > draft? > > Thanks > > Thanos > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >>Sent: Wednesday, November 03, 2004 4:56 PM >>To: Thanos Diacakis >>Cc: krisztian.kiss@nokia.com; jdrosen@dynamicsoft.com; simple@ietf.org >>Subject: Re: [Simple] Re: pres-rules/common-pol: splitting >> and >> >> >> >>Thanos Diacakis wrote: >> >> >>>So an implementation would need to evaluate the conditions >> >>in *every* >> >>>row, whenever a subscription is received *and* everytime a >>>notification is about to be sent? >> >>No. Sorry I was not being clear. >> >>Assuming you are associating a condition with a "row" in a >>database, the presence rules specification will call out >>which rows are applicable to processing the subscription, and >>which are needed for processing the privacy filtering before >>a notification is sent. The document doesn't do that now. I >>will correct that in the next revision. >> >> >> >>>That doesn't seem like a very efficient way of doing things. >>> >>>I think having those into two tables, would make life easier. If >>>you're trying to decide whether you're authorizing a sub, >> >>you look in >> >>>the one table. Conversely, if you're trying to determine what >>>transformations to apply to send out a notification, you >> >>look at the other table. >> >>An implementation that works this way is possible. >> >>-Jonathan R. >> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Director, Service Provider VoIP Architecture Parsippany, NJ >>07054-2711 >>Cisco Systems >>jdrosen@cisco.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.cisco.com >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 25 09:48:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22112; Fri, 25 Feb 2005 09:48:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4glh-0002YV-Pn; Fri, 25 Feb 2005 09:48:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4gkl-0002dt-Og; Fri, 25 Feb 2005 09:47:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4gkk-0002ZW-37 for simple@megatron.ietf.org; Fri, 25 Feb 2005 09:47:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22050 for ; Fri, 25 Feb 2005 09:47:36 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4gks-0002Wk-Ts for simple@ietf.org; Fri, 25 Feb 2005 09:47:47 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 25 Feb 2005 06:59:18 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1PElOuC003054; Fri, 25 Feb 2005 06:47:24 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-69.cisco.com [10.86.242.69]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIA61611; Fri, 25 Feb 2005 06:47:24 -0800 (PST) Message-ID: <421F3A7C.1030609@cisco.com> Date: Fri, 25 Feb 2005 09:47:24 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] Re: pres-rules/common-pol: splitting and References: <20050225055326.KEBO7908.mm-ismta4.bizmailsrvcs.net@THANOSDIACAKIS3> <421F3A25.7030204@cisco.com> In-Reply-To: <421F3A25.7030204@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit Cc: Thanos Diacakis , krisztian.kiss@nokia.com, jdrosen@dynamicsoft.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit OK. Not enough coffee this morning. The current text is actually correct; we want sphere to be used in rules that define transformations, not actions. Sorry for confusing everyone... -Jonathan R. Jonathan Rosenberg wrote: > The following text appears in presence-rules now: > > Care must be taken in using as a condition for determining > the subscription handling. Since the value of changes > dynamically, a state change can cause a subscription to be suddenly > > > > Rosenberg Expires August 22, 2005 [Page 6] > > Internet-Draft Presence Authorization February 2005 > > > terminated. The watcher has no way to know, aside from polling, when > their subscription would be re-instated as the value of > changes. For this reason, is primarily useful for matching > on rules that define transformations. > > > > Unfortunately, it appears that I messed up here, and the last word > should read "actions" and not "transformations". I've repaired that in > my working copy of -03. > > -Jonathan R. > > > > Thanos Diacakis wrote: > >> Jonathan, >> >> How is this issue addressed in this latest release of the presence-rules >> draft? >> >> Thanks >> >> Thanos >> >> >>> -----Original Message----- >>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: Wednesday, >>> November 03, 2004 4:56 PM >>> To: Thanos Diacakis >>> Cc: krisztian.kiss@nokia.com; jdrosen@dynamicsoft.com; simple@ietf.org >>> Subject: Re: [Simple] Re: pres-rules/common-pol: splitting >>> and >>> >>> >>> >>> Thanos Diacakis wrote: >>> >>> >>>> So an implementation would need to evaluate the conditions >>> >>> >>> in *every* >>> >>>> row, whenever a subscription is received *and* everytime a >>>> notification is about to be sent? >>> >>> >>> No. Sorry I was not being clear. >>> >>> Assuming you are associating a condition with a "row" in a database, >>> the presence rules specification will call out which rows are >>> applicable to processing the subscription, and which are needed for >>> processing the privacy filtering before a notification is sent. The >>> document doesn't do that now. I will correct that in the next revision. >>> >>> >>> >>>> That doesn't seem like a very efficient way of doing things. >>>> I think having those into two tables, would make life easier. If >>>> you're trying to decide whether you're authorizing a sub, >>> >>> >>> you look in >>> >>>> the one table. Conversely, if you're trying to determine what >>>> transformations to apply to send out a notification, you >>> >>> >>> look at the other table. >>> >>> An implementation that works this way is possible. >>> >>> -Jonathan R. >>> >>> -- >>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>> Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 >>> Cisco Systems >>> jdrosen@cisco.com FAX: (973) 952-5050 >>> http://www.jdrosen.net PHONE: (973) 952-5000 >>> http://www.cisco.com >>> >> >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 25 11:03:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03114; Fri, 25 Feb 2005 11:03:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4hwm-0004zv-VU; Fri, 25 Feb 2005 11:04:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4htS-0007sC-6h; Fri, 25 Feb 2005 11:00:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4htQ-0007pz-9a for simple@megatron.ietf.org; Fri, 25 Feb 2005 11:00:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02836 for ; Fri, 25 Feb 2005 11:00:37 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4htY-0004vH-To for simple@ietf.org; Fri, 25 Feb 2005 11:00:50 -0500 Received: from [192.168.0.106] (c-24-1-68-89.client.comcast.net [24.1.68.89]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j1PG0X87043593 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 25 Feb 2005 10:00:34 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <7a6fcf14dcfe2463b26adfa91a5bfa0d@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Simple WG From: Robert Sparks Date: Fri, 25 Feb 2005 10:00:43 -0600 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Subject: [Simple] Draft agenda for SIMPLE - IETF 62 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Folks - Based on list discussion, here's a proposed agenda for our meeting time at IETF 62: Monday 1300-1500 10m 1300-1310 Administrivia 5m 1310-1315 RPID/cipid/future 45m 1315-1400 Data Model 30m 1400-1430 Presence Rules 30m 1430-1500 Presence Processing Tuesday 0900-1130 30m 0900-0930 MSRP 15m 0930-0945 msrp conferences 15m 0945-1000 Diff format for XCAP and partial notification 15m 1000-1015 policy/presence capabilities 5m 1015-1020 prescaps update 60m 1030-1130 schema design working session Unless I've missed something, we ended up with a little bit of a surplus (we've been making good list progress - thank you), so I'm asking the editors of drafts that define schema (we have quite a few) to get together for the last part of this meeting to work through some common issues in schema design throughout our document set. Everyone is welcome to stay for that, but I expect most people won't find it terribly interesting. Let me know what I've missed ASAP please. I'll need to send this in to agenda@ before Monday morning. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 25 12:23:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10098; Fri, 25 Feb 2005 12:23:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4jBK-0006hp-0N; Fri, 25 Feb 2005 12:23:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4jAL-000499-4P; Fri, 25 Feb 2005 12:22:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4jAJ-00045T-6o for simple@megatron.ietf.org; Fri, 25 Feb 2005 12:22:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10048 for ; Fri, 25 Feb 2005 12:22:08 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4jAR-0006gf-De for simple@ietf.org; Fri, 25 Feb 2005 12:22:21 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j1PHM4fR010772; Fri, 25 Feb 2005 11:22:05 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j1PHM3V28667; Fri, 25 Feb 2005 11:22:03 -0600 (CST) Message-ID: <421F5EBC.7090908@lucent.com> Date: Fri, 25 Feb 2005 11:22:04 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] updated presence data model References: <8CA1128D59AD27429985B397118CEDDF04D19F2F@nj7460avexu1.global.avaya.com> <421D64E0.5030800@cisco.com> In-Reply-To: <421D64E0.5030800@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > I've submitted an update to the presence data model. Until it appears > in the archives, you can pick up a copy at: > > http://www.jdrosen.net/papers/draft-ietf-simple-presence-data- > model-02.txt [...] Jonathan: This is excellent work and I think light years ahed of its predecessor (-00) in terms of specifying the model. Some comments follow. 1) In Section 2, it is stated that a Presentity URI is "a URI that acts as a unique identifier for a presentity..." However, this seems to contradict Section 3.1: "For each unique presentity in the network, there is one or more presentity URIs." The model implicitly assumes the latter anyway (see discussion in Section 3.1). 2) Should we mandate that _SIP_-based presence systems have their presentity URIs (i.e., the URI that appears in the entity parameter of the attribute) be sip URIs instead of pres URIs? What happens if a SIP-based PS is sent a document with a pres URI? How will it co-relate it with an existing user in the presence system? Section 3.1 does a good job of covering the case where the presentity URI is sip-based, but what if it is a pres URI? 3) In Section 3.2, a reference to rpid appears appropriate. 4) In Section 3.3.2, is prescaps one form of reach information? If so, maybe a reference to it would help. 5) In Section 3.3.4, the last phrase of the first paragraph appears to be too optimistic ("...and reach the desired target"). We have already taken pains to point out earlier that the system cannot authoratatively ensure that a session will be established with the desired target. A quick fix is to align that phrase by adding a "may," as in, "...and may reach the desired target." 6) Section 3.3.4, second paragraph -- I think we are skating on thin ice here. In my reading of the model, this paragraph appears to contradict the sixth paragraph of Section 3.3.2 ("Because the reach ... for a single service."). Here's why: In the paragraph of Section 3.3.2, we take pains to explain that it is not possible to describe a softphone that does audio and video as two services; it must be described as one service. However, in Section 3.3.4, we have a softphone that offers two services -- audio and IM -- and can select which of these services can be reached by deducing the status of one service from the other. Why can't we do the same for the softphone with an audio and video service? My suggestion would be to have some other example in Section 3.3.4. Nits: *) In section 2, under the definition of "Characteristics", the fourth line ("A status or characteristic...") appears to be a cut-and-paste error from -00...? *) Define "Attribute" as "A piece of data that provides a description about a service, person, or device." Then, the definition of "Presence Attribute" can simply refer to "Attribute". *) Section 3.3, s/Each service is/each service is *) Section 3.3.2, s/users SIP/user's SIP *) Same section, s/the user would/the watcher would *) Same section, it is stated that: Firstly, the service in the document might actually be modelling a number of actual services used by the user, and it may not be possible to connect the watcher to a service with all of the characteristics described in the presence document. Does it make more sense to rephrase that as: Firstly, the service tuple in the document might actually be modelling a number of actual services used by the presentity, and it may not be possible to connect the watcher to a single instance of a service that simultaneously exhibits all the characteristics described in the tuple. *) Same section, s/since a URI could/since a URN could *) Section 3.3.3, s/the user has/the presentity has *) Section 3.4, s/allow the user to/allow the watcher to *) Same section, s/a *model* if/a *model* of That's it for now. I will send comments for Section 5 to the end later. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Feb 25 13:15:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15142; Fri, 25 Feb 2005 13:15:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4jzh-0007qk-C6; Fri, 25 Feb 2005 13:15:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4jyl-0008H7-G2; Fri, 25 Feb 2005 13:14:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4jyj-0008DV-RU; Fri, 25 Feb 2005 13:14:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15060; Fri, 25 Feb 2005 13:14:14 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4jys-0007pF-Vx; Fri, 25 Feb 2005 13:14:28 -0500 Received: from lion.cs.columbia.edu (IDENT:edvkQMvmQ0XIogSH4hpp9RN0BqWvuA0r@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j1PIDAir025532 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 25 Feb 2005 13:13:11 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id j1PIDARn029696 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 25 Feb 2005 13:13:10 -0500 Message-ID: <421F6AB1.7040107@cs.columbia.edu> Date: Fri, 25 Feb 2005 13:13:05 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Geopriv] Re: [Simple] presence authorization issue: anonymous, authenticated, etc. References: <42146290.5090209@cisco.com> <4214ADD0.3070101@cs.columbia.edu> <4214B803.7070304@cisco.com> <4214FDA3.3060701@cisco.com> <421B01D4.3050507@nokia.com> <421BF247.5090903@cisco.com> <421C3B30.8050104@nokia.com> <421DFEEF.4070107@cs.columbia.edu> <421F0DAD.20907@nokia.com> <421F29E8.2010104@cs.columbia.edu> <421F3406.8020106@nokia.com> In-Reply-To: <421F3406.8020106@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Paul Kyzivat , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Aki Niemi wrote: > Exactly, but this is a limitation already inherent in the common policy > domain wildcard conditions. I think in the general case determining this > and being able to discriminate against "weak" domains will be hard for > the average-joe. Agreed; this also seems much better handled in a general spam control policy, which can take multiple factors, such as domain policies, into account. I suspect that in many such cases, these policies, like today for email, will be on an organization-wide basis, rather than individual policy rules. > > But then again maybe not that hard, since I think people already today > have a pretty good idea about these policies in email accounts. Everyone > knows that a username in gmail.com is in relative short supply compared > to some other free email providers. Corporate email accounts usually > have much tighter policies. But see my example: We have very tight policies on handing on UNI (university network IDs), but still an infinite supply of personal email-style identifiers. I doubt that the outside world knows this (or cares). > Apologies if I missed this before. It is sort of obvious, must admit. > > There is one catch to this, however. I think such a condition should > only ever be applied to something like a "confirm" permission. It would > not work well with an "allow", quite naturally. That would be shooting > oneself in the leg, like Jonathan was worried would happen. But this > should be relatively easy to capture in specification writing. > I'm not so sure. If things are defined as follows: - No rule => denied subscription; no access to any data - Bad apples list => polite block or deny - No positive identity ("anybody except"), with exceptions => the world except the bad domains/names get the base level access and maybe 'confirm', with the caveat that name-level exceptions are likely to be a very crude and "leaky" privacy screen A related question that we have never addressed is the following use case: "Random strangers can subscribe to my basic, public presence information without confirmation, but I need to confirm subscriptions to more detailed information" I think the best solution is to declare two different presentity names for that. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From jjuvgvzrpxi@msn.com Fri Feb 25 14:29:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20893; Fri, 25 Feb 2005 14:29:12 -0500 (EST) Received: from [61.183.88.46] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D4l9O-0000qP-PB; Fri, 25 Feb 2005 14:29:25 -0500 Received: from .starnetusa.net (.starnetusa.net [29.180.216.190]) by .starnetusa.net with ESMTP id 2C573160 for ; Fri, 25 Feb 2005 23:20:32 +0400 Message-Id: <6.8.3.05.2.20031415693053.025b4b48@.starnetusa.net> X-Sender: jjuvgvzrpxi@msn.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 26 Feb 2005 00:25:32 +0500 From: "Troy Champion" To: sigtran-admin@ietf.org Subject: Viicodin are Selling Heree 2G X-Spam-Score: 13.3 (+++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 93238566e09e6e262849b4f805833007 This Months speciial: Vi-codinn - 199.00 Valiuum - 169.00 Viagraa - 199.00 Cia-llis - 269.00 Codeinne - 219.00 Xa-naax - 179.00 All orderrs are delivered by UPS with full tracking 24/7. Satisfactiionnss guaaranteeed... http://www.ilovemeds.com/index.php?aid=8 This is 1 -time mailing. N0-re m0val are re'qui-red KgNHS9ZFwwmsc9dtISkchpgimQ3nCGHZrtlX5dFLbvj0QAQvPZG9xs From charles@kappa.ro Fri Feb 25 15:55:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00950 for ; Fri, 25 Feb 2005 15:55:51 -0500 (EST) Received: from [210.178.191.5] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D4mVI-0002w5-CT for simple-archive@ietf.org; Fri, 25 Feb 2005 15:56:06 -0500 X-Message-Info: RHF8AoiMKklDD2O52EFgds1DCWQ3aWKE1aKQSmyAYGC38ZY8 Received: (from chevy@localhost) by polaritonsibley2.charles@kappa.ro (0.CA.C/E.CF.4) id wv18EtV23EE; Fri, 25 Feb 2005 13:52:50 -0700 Message-ID: Reply-To: "Gabriela admissible" From: "Gabriela admissible" To: "Simple-archive" Subject: how many d,iplom.as do you have? need another one? Date: Fri, 25 Feb 2005 15:53:50 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--74580360C979A1CA8" X-Spam-Score: 25.6 (+++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f ----74580360C979A1CA8 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable That little piece of paper in a frame hanging on the wall showing that you= have a proper education is so important these days if you plan on getting= decent work. Now you can get a real one in just a few days and there is n= o need to even read a book! http://1hepistlexLea.AFFIL9384.BIZ to kill the postman that delivered this email to you press here : http://3= ncabbagerLea.AFfil9384.biz/re Who so loves believes the impossible. ----74580360C979A1CA8-- From simple-bounces@ietf.org Fri Feb 25 17:28:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09212; Fri, 25 Feb 2005 17:28:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4nwx-00059Y-1L; Fri, 25 Feb 2005 17:28:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4nv0-0005Tk-S3; Fri, 25 Feb 2005 17:26:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4nuz-0005Q7-9W for simple@megatron.ietf.org; Fri, 25 Feb 2005 17:26:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08965 for ; Fri, 25 Feb 2005 17:26:38 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4nvB-00056w-1I for simple@ietf.org; Fri, 25 Feb 2005 17:26:54 -0500 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j1PMPUO6005609; Fri, 25 Feb 2005 23:25:30 +0100 Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Feb 2005 23:26:26 +0100 Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Feb 2005 23:26:26 +0100 Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw106.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Feb 2005 23:26:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Feb 2005 23:26:11 +0100 Message-ID: <2DC267ED40568D4F9AA4F5DF955AF16A115A29@esealmw107.eemea.ericsson.se> Thread-Topic: draft-ietf-simple-xcap-package-03 How to indicate that a document is deleted or a new document is added during a subscription thread-index: AcUWlK3HYv6tPeO/QE2E1nZa8aGy0QE85LnQ From: "Anders Lindgren C \(HF/EAB\)" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 25 Feb 2005 22:26:12.0512 (UTC) FILETIME=[0305FA00:01C51B89] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org Subject: [Simple] RE: draft-ietf-simple-xcap-package-03 How to indicate that a document is deleted or a new document is added during a subscription X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Your solution seams reasonable. I have also noticed that draft-ietf-simple-xcap-package-03 has been = replaced by draft-ietf-simple-xcap-diff-00. I assume that my comment and = your solution is also valid for that draft. Thanks Anders ----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: den 19 februari 2005 16:04 To: Anders Lindgren C (HF/EAB) Cc: simple@ietf.org Subject: Re: draft-ietf-simple-xcap-package-03 How to indicate that a document is deleted or a new document is added during a subscription I was just now combing through the archives in the process of updating=20 the data model, and noticed this mail that I never responded to. My=20 apologies. Answers inline. Anders Lindgren C (HF/EAB) wrote: > Hello all; In the draft draft-ietf-simple-xcap-package-03 I find it > hard to see if and how it is possible to indicate that: >=20 > 1) A document has been added to a watched user's tree during the > duration of the subscription. This is a gap in the specification. Good catch! Thanks for finding it. I would propose the following solution. The element have an attribute called state, which can have a=20 value of "existing" or "deleted". When a document is added, an xcap-diff = would get sent with a value of "existing" and the patch elements=20 would basically contain the entire document. Modifications to the document would result in elements with=20 either no state attribute, else state with a value of "existing" (that=20 is, the default is existing). If the document is deleted, the = element would have a state of deleted, and there would be no patch=20 operations. It would be an error to send an xcap-diff with a with patch operations. The recipient of xcap-diff knows a doc is added if the diff has a=20 element with a document locator that it doesnt know about. I=20 prefer this approach to having an explicit "added" state, as it reduces=20 the number of error cases. Does this seem reasonable? >=20 > 2) A document has been deleted from a watched user's tree during the > duration of the subscription. See above. >=20 > Is a "deteted document" and an "added document" element missing or >=20 > is it that every Notify also SHALL contain every unchanged existing > documents with New Etag=3Dprevious Etag and that the Subscriber can = at > every Notify shall check the last received Notify to see if the > document baseline has been changed. A Notify will also be send as > soon as a document has been added deleted with all existing or >=20 > does the draft contain a solution that I have missed? It would be wasteful to have to send a for every document=20 covered by the subscription, just to figure out when something is=20 deleted. The problem you outline is a gap in the spec. Thanks, Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From Alyque_Dunya@lankacom.net Fri Feb 25 18:21:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14346; Fri, 25 Feb 2005 18:21:22 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4om6-00063H-Lu; Fri, 25 Feb 2005 18:21:38 -0500 Received: from m60.net81-64-64.noos.fr ([81.64.64.60]) by mx2.foretec.com with smtp (Exim 4.24) id 1D4olk-0002AS-Q3; Fri, 25 Feb 2005 18:21:14 -0500 Received: from mail.mhtc.net (81.64.64.60) by 81.64.64.60 (kievv.686) with SMTP id <756377306m2v> (Authid: 4991559); Fri, 25 Feb 2005 18:20:39 -0500 Reply-To: "Chen.Bor Toshia" From: "Chen.Bor Toshia" To: simple@ietf.org Cc: simple-admin@ietf.org, simple-archive@ietf.org, simple-request@ietf.org, simple-web-archive@ietf.org, sip@ietf.org, sip-admin@ietf.org Subject: Payment confirmation: $34186 Date: Fri, 25 Feb 2005 16:16:39 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--8354242_1078190.skQ51" Message-Id: X-Spam-Score: 6.5 (++++++) X-Spam-Flag: YES X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ----8354242_1078190.skQ51 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Applicant, Your application was processed and approved. This means that you're eligible for $ 320,000 with a 3.0% rate. Takes a few minutes to see what you can save! Please verify your information here: http://alton.seaquote.com/?partid=aaks9 We look forward to hearing from you. Chen.Bor Toshia, Account Manager TJK Associates r*mv - http://chaplaincy.seaquote.com/st.html ----8354242_1078190.skQ51-- From xovghth@msn.com Fri Feb 25 23:54:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04697; Fri, 25 Feb 2005 23:54:39 -0500 (EST) Received: from [203.177.74.29] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D4tyj-0002ve-4U; Fri, 25 Feb 2005 23:54:59 -0500 Received: from anthracnose. masturbate.dogmatic.adore.es ([109.196.89.101] helo=convent.mail.desty.org) by smtp8.desty.org with esmtp id 0A534j-0421FN-00; Sat, 26 Feb 2005 08:52:24 +0400 Message-Id: Sender: xovghth@msn.com Date: Sat, 26 Feb 2005 05:51:24 +0100 In-Reply-To: Your message of "Sat, 26 Feb 2005 08:56:24 +0400." <20031002150239.GG32185@asuka.tech.sitadelle.com> From: "Rufus Tolbert" To: simple-admin@ietf.org Cc: simple-archive@ietf.org, simple-request@ietf.org, simple-web-archive@ietf.org, sip@ietf.org, sip-admin@ietf.org, sip-request@ietf.org, sip-security@ietf.org, sip-security-admin@ietf.org, sip-security-web-archive@ietf.org Subject: Woww..8o-% 0ff Simple-admin X-Spam-Score: 12.6 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 93238566e09e6e262849b4f805833007 Look at this of-fers: Vi-codinn - 225.00 (90 pi-lls) Hydro-codonee - 297.00 (90 pi=lls) Valliuum - 153.00 (90 pi-lls) Viagraa - 270.00 (90 pi-lls) Cia-llis - 348.00 (90 pi-lls) Codeinne - 126.00 (90 pi-lls) Xa-naax - 171.00 (90 pi-lls) All orderrs are delivered by Fedex with full tracking 24/7. Satisfactiionnss guaaranteeed... http://fuoje43.com/_fd5977142df59d3662baa654773c6a8e/ This is 1 -time mailing. N0-re m0val are re'qui-red NpCV0WeFhPSjBiRBBnF4jsKT0nO9po75u From simple-bounces@ietf.org Sat Feb 26 11:48:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15504; Sat, 26 Feb 2005 11:48:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D557n-00073c-Gd; Sat, 26 Feb 2005 11:49:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D555z-0001v9-0I; Sat, 26 Feb 2005 11:47:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D555y-0001s2-6e for simple@megatron.ietf.org; Sat, 26 Feb 2005 11:47:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15398 for ; Sat, 26 Feb 2005 11:47:07 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D556L-000717-1J for simple@ietf.org; Sat, 26 Feb 2005 11:47:33 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 26 Feb 2005 08:47:37 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1QGkwwN023484; Sat, 26 Feb 2005 08:46:59 -0800 (PST) Received: e2k4.cisco.com 171.70.93.57 from 10.21.120.197 10.21.120.197 via HTTP with MS-WebStorage 6.5.6944 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 26 Feb 2005 08:46:55 -0800 Subject: Re: [Simple] Draft agenda for SIMPLE - IETF 62 From: Cullen Jennings To: Robert Sparks , "simple@ietf.org" Message-ID: In-Reply-To: <7a6fcf14dcfe2463b26adfa91a5bfa0d@nostrum.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Sounds good - any chance you could expand out what the reading list would be for all the sections? On 2/25/05 8:00 AM, "Robert Sparks" wrote: > Folks - > > Based on list discussion, here's a proposed agenda for > our meeting time at IETF 62: > > Monday 1300-1500 > 10m 1300-1310 Administrivia > 5m 1310-1315 RPID/cipid/future > 45m 1315-1400 Data Model > 30m 1400-1430 Presence Rules > 30m 1430-1500 Presence Processing > > Tuesday 0900-1130 > 30m 0900-0930 MSRP > 15m 0930-0945 msrp conferences > 15m 0945-1000 Diff format for XCAP and partial notification > 15m 1000-1015 policy/presence capabilities > 5m 1015-1020 prescaps update > 60m 1030-1130 schema design working session > > Unless I've missed something, we ended up with a little bit > of a surplus (we've been making good list progress - thank you), > so I'm asking the editors of drafts that define schema (we have > quite a few) to get together for the last part of this meeting to > work through some common issues in schema design > throughout our document set. Everyone is welcome to stay > for that, but I expect most people won't find it terribly interesting. > > Let me know what I've missed ASAP please. I'll need to > send this in to agenda@ before Monday morning. > > Thanks, > > RjS > > > _______________________________________________ > 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 yopfa@isdn.net Sat Feb 26 15:08:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26681; Sat, 26 Feb 2005 15:08:22 -0500 (EST) Message-Id: <200502262008.PAA26681@ietf.org> Received: from host118-83.pool82187.interbusiness.it ([82.187.83.118]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D58F3-0001iA-SK; Sat, 26 Feb 2005 15:08:49 -0500 Received: from XXVEX-AM15 (82.187.83.118) by 82.187.83.118; Sat, 26 Feb 2005 12:11:44 -0800 From: "Doctor Y. Forrest" To: simple@ietf.org, simple-admin@ietf.org, simple-archive@ietf.org, simple-web-archive@ietf.org, sip@ietf.org, sip-admin@ietf.org, sipping@ietf.org, sipping-admin@ietf.org, sipping-bounces@ietf.org, speechsc@ietf.org Subject: Better than Viagra Date: Sat, 26 Feb 2005 12:11:44 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="%OLATTACH1" X-Priority: 3 X-Mailer: AYBU Mailer v7.2.0 X-Spam-Score: 22.2 (++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 72be645574b2b4b84446d27f730bf563 This is a multi-part message in MIME format. --%OLATTACH1 Content-Type: multipart/alternative; boundary="%OLATTACH2" --%OLATTACH2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit %URL %PARAGRAPH --%OLATTACH2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 3D"" %PARAGRAPH --%OLATTACH2-- --%OLATTACH1 Content-Type: image/jpeg; name="%ATTNAME.jpg" Content-Transfer-Encoding: base64 Content-ID: <%RNDATTID@%MNAME> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAKAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBcSFBQUFBIXFxscHhwbFyQkJyckJDUzMzM1 Ozs7Ozs7Ozs7OwENCwsNDg0QDg4QFA4PDhQUEBEREBQdFBQVFBQdJRoXFxcXGiUgIx4eHiMgKCgl JSgoMjIwMjI7Ozs7Ozs7Ozs7/8AAEQgCJgHCAwEiAAIRAQMRAf/EALsAAAEFAQEAAAAAAAAAAAAA AAABAgMEBQYHAQEBAQEBAQAAAAAAAAAAAAAAAQIDBAUQAAIBAwMCBAMDCAYFCAcGBwECAwARBCES BTETQVEiBmFxFIGRMqGxwUJSciMVYpKyMzQH0YJzJBbhosJDU7MlNfHSg1RkdBfwk8O0JjZjo5Sk xHUnEQACAgEDAgQEBgEDBAMAAAAAARECITESA0FRYXEiE4GRoTLwscHRQgRSYnIU4aIzc5Ijk//a AAwDAQACEQMRAD8A6bKwos58eCaSSKJplDtC+x/UGRRf95hVjPhj4xGQMzxY8QIZzdiFXqx8TpUO QWETOgu8f8SMf00O9fyip/d6ibERYjrnhMeMjx7zqn5nrywttnGVB6Je5LoyHj+IOFw2NlPLLLPl Kkk4lbcFZ13EKPAVFx/Ew8pyWZlZM0yRYDRJGkTlULBe8+8WN/xCujz+0+JLAn4scKdvkPD8lZHB nt+38rK8c3ImcfLf2F/5sdadErJRhKfkZVm6t9W4+ZVwOKhzc7MzJZZlbECduJHtGboT6ktrUR42 LleTxsOaWaKIxyyEwPsYle2Bc6+daHDSJGvMSObIiozHyAjYmqHt7k8HO5+EYsolKQTFrAi1zFbq BWUq+hf5PPjk1L9T/wAV+gclhpPlxYBeSOKTKETNG219t26N9lTTe0fb8DmOXkM1XHUd4+P+pS5X /neP/wDPD87VH7h5GOHmHxzFMzWQbkjZl1UfrDSnpSbaT9UZGW0k2sTghzMLHzM3GwFlkXHlyNnc jba5UI7D1W+FO5zDPHwzwIzFUhJjkY+ogKdSR43FLjf+bccP/iP/AMKWtT3fCsnFzzpq0KOklvAM t9fvH30VU6WcZTLui9V0aM7J4bG4rFxxBJLL39zuZn3m9k0BsNKozY6ZQXHkkaGN3j7kiEhggdS9 iP6INbvPm2Pg/uN+ZKw2NS6Ss0ljBaNuqbeS9j+0fbmUZRBn5jmEAyWmOga9uqf0TVDk+N4nEwxD x2VNN3nAkaRyWUEqvpO1bVqe2fx8r/s4vzS1h5B9A/fT+2tW23amqpbpFZ3P1N7YNHlOJxuIeLGx 3kkQoWLStva5Y+NhUEXDY2JwGLySSSyT5nbMgkfcoursdotpVv3ryGJi58CTyBGaK4BBOm5vIVJM QfZ3FkdCIv8Au3qutd11/iseAVntpn7nkyON4dudypzkTNj8Vg+mdkO1pJLbiu7wCjrWl/w9xRxp J+Cmc9jWXHkZmBHmu/1A6fI0/EX6X2VERo+Y5kc+JMsjP/ZAFR+1pzHzKxX9M0Mgt/SUowP3Xoq1 W1NZspb65DdmrWT+1wl0wZmNxs3M8lFxqSNBBtabKlTRu2pChVPmxNXcrjPbeFA44uSQzoQrKzuy tbqfVp91aHDCPE9yZMBFg4kjT7GDqP6oNY2fith5kuO36jHb8VOqn7qm1Kswm5ansVNu+rSSTS7k /Fe2uLz8Gfkc/JyYtszqe3JtQKpAHp2nzpZ+L4HBgL8dlTZEzMAVlcsAuuouq1a4+Tt+0M59rPaZ /SgLMfWnQCsWCbvKWEckYBt/EQpc/DdR7Uq4UtTIrLtabPFognBq1xftvjc/Dn5HNysmErM6ntSl VAUgCw2nzqmK18CeLH9pZ00zbY0ncs2pt6k8qlEm3KmE3kXbSUOJaQ1vbsmNCcjBzDn4gvuWXaZF t4h0A3fEEVUweHj5rlXx55ZooMWAOew+wl5Hst9D4Iav+z8iWeDkc51ZMBlRccuLbtgkMjgHwO4D 7KbwE30mBzHLWtaZY1v4rAij+07VpVq9riE5bXkYdrLcplqEn5iZeOMbJkgBJCGwLdbdRemcZw0a 8Q3KLLK80zuZEd9yALI6DYttPvq/z8ezOD+EiA/aPT+irftxUfgYY36SNMtvO8slWtE72Xg4I7NU T8VJicbxEGfyGVkTSzKcNImjjR9qEt3L7ltr+GmRcDw84fI5DPyYpZZbKkUjKoDEKigbW8TWpwkT Q5vLxN1RIlP2CasrJPpj/wBvB/3qVmElVtJ6zPmalttS1oXm9qcHgzo75uZ3Es6o8xZT5XG3ppVb jeJgfHzOVaWYzLK8axl/4QAKj8Fq0+f/AMYn+zH9pqi4r/yHN/8AmJP7S1pqu5qEoTMy9qcvLRnY fBYvL5uW2VPkRLjpFtEEhQeruFiRY/s1OvB8Fhhp8bNyZpgpCJLIWUk/AqKscC22blW1NooTYanQ TVkYvIR5bMqRTJtG4mSNkHW3U1n0qtcKXJrLs8uFA/B4SHmZMrP5WaSPjcRzDDAjFA7Lbe7ldTqb C1T5GNx2KEi453eGxNpGLEG50u+taPHRCfhsrFjHrRzIqjqdx7n5W3Vjk0aSSwsqZ6hNtvOj06DZ HVEZ2NlUEk/AUcb7dxMzCXmfcMsix5HqxcRGZAsZ/ATs1LEa6VX5BDLiPCL3m2xadf4jBP010HuY qjY2Og2xxodqjoBoo/s0qlltTt6eLK25VU4nr5GNykHG8bAJcOZ5sYKznuNuZbfq3IB++nYPtjAG HHyXuWaTv5VmixkZlWNTqBZPVuA61WeAZU2LisLpPkwo4/ob1Z/yCtn3VKWz0j/VjjGnxYkn9FEl mzSxELpIcyqpvMtvqUuS4ccescuPKcjDm/uZG1YXF9rN4/A03h/b8Wdh5nICSX6qOR444938MhUR rbLdda0MI/Ve1MiNtTiyvY+VmEv5nqX2tkJjcPmTv+CPJYt8tkV60q1dl2anyI7WVXnKtHmc1FiP yfI4vFxsyCdt+Q6GzLDH6nsfAnQCrHuDjYONL4eO8hRYxZ3a76/0tK6LF42HhuTzOTkIb66aHGw1 HVY5Cu4f12J+QrI95f46X/ZrUdIo2/un6FrfdfH2x9SbL9n+2cNlXJzcuNnF1BlJuPsQ1mZuPgY0 wh4+VpsdVFnc3YnxuSBWr73yO1lYw7Usl421jQuBr47awxewJBUkA7WFiL66g0vtTaSSgcctKzs3 PQjmlWGJ5X/CgLH7K0sH2vxyYUXI+5ZpO/lWaLHRmVY1IuBZPVuA61RWAZWTi4rC6T5EKOP6G8M3 5BW37ulL8ikd/THGNPixJP6KlUobamNE+5bNtqqcTltFTlOGHHLHNjynIwpv7mRtWFxfazePwNM4 f25xvKY+bnZ8+REIJu3/AApNqhFiie9tp8WNaWCfqvaM8batiyPtPlZhL+Z7VHwTbfbnNNYtaZzZ Rcn/AHeDoBWttZWMNTBl2ttanKttkoZmBw2FGi8ZkS5BdiZO6xYjQWtdVqbB9q8G3D4nIZ+XlRNk orMRKdu5husAFPlWXDIZU39t4xcqO4pQkix03fOtvOl7Xsvim2PJftC0alz/AHb+ArK2uW0oS06G rStqVnl6lDMx8DGlEOBK00CqLO5uxPjckCq9C3ZVYqybgCFYFTY+YNOC1Da07iAU4ClApbUAlhRS 2ooDaJq3DiNnYnDFR6MHIPd89sCSxqftdVqma0+Bl2R5cbdEcSg+G1lA/OhNb443Q+v6ZPPfSUJD IZeXzoev1ENl+HZJT/8AFqqIWwvb/G4TArIsSGQHrvCjff8A1mNMwpWHK40n7bujn4OrH+2FqfnJ d2WE8I1A+060maN9Za+eRHqS8J+WBnt5tknKORuC9s2PjaM1ZweXSbkY8RcZI+5HI/cXqNhTTp47 qq8ErBeVYghWCbSRobRm9qg4dWPOQMASqwzAtbQEmK1/uq1s0qJdf3Fkm7vt+wzJ/wDO8f8A+eH5 2rV5LmMnEymhjVCqgEFgb6i/gwrLnVm5yHaC23NubC9gC2tP53j/AHFPyUkmBjwyY5C7Xkk2tcKL 6fOonZVttmd3QrVd1d0fb1KuO5fmOPY9WyST9sctbMoTKzuS4qU2TLiG34N21Un52t91Y+NBPHzO BHIv8SOf+KF1A/hSX18rmrPJ5BxeebIF/wCEyMQOpXYoYD5qSKlXFc/5Z+RbKbY/xx8yf3Kpjiwk PVVcG3wCVgk1v+6yCMUjUHuf9CueJqcv3v4GuL7F8TX9sfi5X/ZxfmlrCnPpX99P7a1u+11a3KsQ dpjjAPgbCW9YUgZtqqCSXSwGp/EKW+yvx/Mtfuv8PyOv5vl1wMiOM4yT7k3bmPTUi3Q1S5jL+t9t 4WXsEXfaN+2NQt0c28Kh93/42H/Zf9I03LVl9n8WrAqwEQIOh/u3rpazm66Qc61SXG+rY+YX9nYQ XpFsQ/NNyH8oqh7bu3uLGUfqxTOfkAi/nar/ABP/AIhweTxSMoyEu8CtoDc7/wC1e/zqP27xmdxD 5nM8yi47CPsY8AdXO2+9juXS7sBasxLo+kKX5Gpit69ZcLzKfKZDR81PNEbPHNdT/SQ/6RWl7gSP P4/H5eAdRskHkCbf81risEY/LcjlSnCiWeTa00iM2wsSwFlY6X9XjW1Fj5nGe1JYOT2rlZMpZIVI bYCykLcXBsFvUrL3YcOXPiW0J0h+pNKPAl9v5UmJ7bycmMAvHPIQGuRqyjwIrO5HmsrkURJ1jUIb jYCOvzY1d4jGzJ/amXBioGyJJn7Sudqn1KevyrKbh+cxImm5CGKOIWAMb7jc/Clt22qUxtz2Fdu6 0xu3YIxXQe3pxje38mcoJAmRIdh6HVRXPitvi1Zfa+ZuBF5nIv4jcutTj1f+1l5Vhf7kR53OZWZG Y2tFD1ZV8beZpkS5EPsvFEWLNlyZzmWSOFdzbZmebcfhawrLze6cOZYVLyuhVFUXJZvSOnzrqeSy 5uKhxMPEYKI4gpuAdFAVevyq1c7nZvSPmZso2qqWs/Ih5ITScXx+ROjJMY1EysLMHZASGHmCDTMG Rova+PKn4o5ndR4ErPIbGpjPPn8BJLkeqaKVrta1wG9PTyRqgx1ZPakIYFT3HNjodZZCK11bXWkm eiT6Xg148ePuZXIRG6ZsEZA/cEmv2q4rlcg+mL/bwf8AepXQ8LkGTjJoT1g3AfusCw/LcVzsoZzE qAse/CbDU6SoTU5GmqtdZHGmnZPobXuA/wC+J/sh/aaoeKP/AOn80/8AxEn9pak9xG2an+yH9pqj 4xWX27mFgRedyLi1wWXWr/O3kx/Cvmhfbblcnk3HVY4SPsEtMy+ZycqAwyKgVrElQb6G/ixp3txJ Wfkyi3LxxLGToC1pdL/bWanFe5IyZMzHgjx0Us7JJuYWHgKk22Viesx5liu+0x0gt8XmjEzFdjaN /RJ8AfH7DRzmJ9LmsVFo5fWn29R99Zbcd7jzYH+ixY5YpWaJZWkCFB03Mrfi6/q/dW37icL9LjM/ clhj/iP5k7R/0b1FOxyniGviXG9Q9ZT+Biva8ZPRJYnPyR1Y/mrb90g/VQnwMf6TWGwDKVPQix+2 t3l4c3leMxs3jo1ycmMbZYS4jvceqzNoCCPHwpXNbLyZbYtVvTKMbEsOQwmPRciL/nNs/wClV/3O COTJ80Uj8orP/l/K4MEU3JbI8iaRnjhQhu2qbNt2GhN9a1vcOLyHKY2Pn8PEmTIybHjLhCviDdrA 7STcXok9tlDnDjqG1uracOVPQj4Nre2eSc9GmlA+xUj/ADik4b/9tcn/ALd/7EVLkw/yf27jcOzh 8l/XkEebMZHP9c2FHDqy+2uSuCN0zkX8Rsi1rS1S7VyZ6N97qCq/JvlScPim4GPkQhyfEhwq/ctJ 7y/x0v8As1qpiKzchhbQTbJhJtroHFzV33grNnSKoLMY1sBqTWW26Oe6NwldJdmbfPc1lcbNEkCR sJFLHeCeht4MK5XMyZMzJfJlADyEEhbgaC2lya6D3VxnM5uRA3GwxSoiEOZH2EG/hXPz4WbhlYs1 VScruZUO4C5Ntfsq8jtL1j6GeLbCiN31F4+y8nhOei5Ef3s2wf2q0fdSkcqSfGNSPyispSVZXXRl IZT5EG4Nb3uHEz+Vx8fkOHiTJkZNjxFwhXxBu1gdpJuL1F9tl5M1bF6t6Q0RcEbe1+Rc9GmmA/qp H+cVJ7XnfG4flJ0ALxZDMobpcY8HW1qbkQfyf29jcOzh8l/XkEebMZHP9Y2FLwKMvBcvcEBpnKk+ I+ngFx9orSw6rqq/Uw81b6Wt9ChyXK5PJ9vvqi9rdt2Aj8Vr33MfKtjE5Cfj/avGzQqrM0caEOCR YoT4EeVc8FralRl9pcYrAqwEYIOhHoapVubPrBq6XpUYkzM3KlzchsiUKrsACFuBoLeJNQ7afjcZ zHI5ZjwTFFBCgeSSa53MxICDb8utPj4nmszkJMbEMMUWMP40ktzufcy7F2/u9azl5huTU1WJSgi2 0oWpU4nmszkHx8QwxRYwvNJLc7n3Muxdv7vWlkiaKR4m/EjFWt5g2qQ+wlaSRbaKfaigLQY+ZqSP ImjVlRyqyCzgeI/+xqMUV6oR5JYLJIjh0YhlNwR502aaWVy8jFmbqb0GmNUhdiyxBk5EasqSuit+ JVYgH52qJcjIibdFK6N0urEG32UrVE1IKjN5zOzYcZ54ciWOYeoSK7Br+e4G9cJL7q9zhyBzGcNf /eZv/XrtPcH+Ak+VebS/3jfOt1SMXL3/ABF7g7nd/meZ3b37nfk3X+e69I/P87K5eXkcp3PVmnkJ Ph1LVn0orULsZl9zRk9w8/KFWXksuQILIGnkIA+F20qM8zzH/v2T/wDev/61VKSpC7IsvuzRh9w8 /EGWLksuNX/EFnkAPzs1NHMcuGuM7IBGoIlfr/WqktOGtzSF2JL7svS89zuQ4afkcqVgLAvPIxt9 rU9+f514lhfkcpokttjM8hUW0FgWtWcguaf40hditvuWV5vmYZRJFn5MbrqGWZwR/wA6pcz3R7jz ipyuSyZNv4R3GAH2KQKzWNzekqwuxJfcv43uDncWUS4/IZMbjxEr/lF9afl+4ufzJO7k8jkyP0F5 WAA+ABAFZ1qWkLsJfc0IvcfuKFNkPKZkaddqZEqj7g9LL7j9xTJsm5TMkTrtfIlYfcXrPtRakISW /wCccv8A++5H/wB6/wD61SL7g58RGEclliI9YxPJt/q7rVRtS2pC7Ibn3ZaHNcypDLn5II1BE0lw f61Pl9wc9M26XksuRgLAtPIxt5atVK1Jam1dkJfcvL7h9wLGYk5PMWNvxIJ5Apv5jdatX257g5t8 +KDI5DIkwo7ySxSSs6bV+DlvE1zlq0uFQPK8JJDToVUqAT6SslgCR+xWbJQ8Fq3uR7XjgRB3U7A2 hC6A/MC1Qv2ozvCqCDdbADWq3HyscCAsxJ7a/jPq1A61XzMopfcen61eK1oO6q2xnI5kjlnd2ZgL Akk2+FY7Z+esJiGTKIz1QO20/ZepJskS3Cm4NQMl6wk25PTRJLKEi5HkobiHKmjDddkjLf7jTn5b lnQo+ZkMp0IMrkEf1qhKEUhFdMlaXZEkPM8rigrBlyordVDG35arNm5jsXeeRmbUsXYkn76V47eF VZCFPqYCjkqjWC1HnTK1nlYqfEsdK1eO5bKxpCsc7pu6kE2Ncu+TGDYMKmxs0aLc3H4akEtVNaHU ZMuTLKZJpXlD6bmYkj5eVQY/I5/HTkRzyLG1gwDGx+Nqjws1ZFCH8Q8KnngWRDbUeHwrLbTmTnHR kPJS5Kyrm9x5Uf8AHck1oQZc0mJsikYRNqUUkKfmvSqGO49WLPqraC9OwVbGkbHY6A+n4ipLI1iO xYErRTRyISpB0YaEGtAZCTvuyP4r6DuNq33mqGRHoR9opVfaw+NqqbMs20my21jyJWX4u1/z0Osc rb8gd1hpuf1G3lc1Xx5dtm++rLSKLSWBU11mTnlDXgxY4jK0KAH8I2j/AEUmBlzRISiCBHP6ug+e lT7sWUfiIPx6UkkIB8hbQ9VrVURvuVpxFO7OF3St1Zxe/wBpqMSPBG0RcrG/WJDYHzuKnZdtwPxD oT0+yq9iTZj99bgzIyRVZAVRVv4ACoZJchoxFJI7Rr+FCx2i2mg6VLttfyB0o2g9daqSLJDDPkY7 FoJGjYixKm2lLFkZMDF4ZWR20Yg6m/nTyov0pNlWBIyHIyoHZ4pXRmFmIJub1H62NyxJOpN6m2UB KQJItp8zRU+yim1dhu8SUUUCiqZGmmNTzTGoCJqiepmqFqFRj+4P8BJ8q8zf8R+deme4f/L5P3a8 zbrW6mbCU4U2nCqZCgUUCgHA2FJSjWnLG7sFRSzHQKBcn5UAqaCkY3rosb2J7kmxu+uNtBFwrGzH 7KxM3CysLIOPlRmGVeqsLfaKSpDKwFOAre4T2XzXMxiaCMRQHpJJcA/LzpnOe0uX4MB8uMNCdBMh uuvnUkQzFtSgUtvv8R40WrRMiUU61IRagFFAoFFAKaSlooBtiR0q9w3cGdGVXdYg2IBHUeBvVZU3 WBIXXqav8dl4mD3H7b5EjAKQGMRtuUmzIbjpWbaQarrJ6fx/MY2XEIEUxullZSQbkKNbKbCoOSgM 4ADWjt+qeprjeN9yZsmWsOLCIcZB/E2XOltp7krXbTzvr+bqcPPibAuLdopuFtxLf0hu8zXj5ONn p47dUZcvHdtrxz7T4KaElnjIWX1D9oVjcgeRzs58PHch0Yg2baiqNL3GtY+XJncZktEcqR2jNmKs xAPl661XicanS3NGqx3O79LruFNCgVgcDzs2ROMXI2uXB2SKLEta9iK3DJtYgms2Tq8mq2VlNRk6 ysLKOtQLxSMbzNqatNlAaA61zvKctmyTGLEJG3qfGiTZXZJG0ONwo/wi5+NI2Gq/hArmJP59DEs8 mQyKxsATrf5UYvuTPhNpCsyg2YHRv010fEzmuesw8HTpE6kEekjUGtPEytw2sfV+esXD5mHJTcq6 +KnwNXELON1rXrlasHRxZYyac0KyEMujCkO59rEWkj6/EVXgzAf4ch18DVpWVyAeo6GuUMw00Wix aHzNqrTMAiPfpqanhJ2EH4ioJBeIKfiKsmVqXcLIDKCNQavwuCGib7KwcKXYCvivhWmjnSQfq9DW lpJLVclvHlxy7IL9wfiW9WBICNoN1PVT4VRMQGQcgaBwL/OpVLXF/mDXarwcrakzLc2H2VEygnpU 49QB60jgdR+t1rojDK5UdKZtqfbSba0Qh20bal20baCSHbQFqXbQFoWRmyipdtFBJAKKBRQCGo2p 5pjUBG1Qt1qVqjahUY3uIH+Wy/umvMyNa9K9zsU4yU/CvNj1rVTNxLUopKWtmRaKPn99a+D7V53O iE8GI5iPRzpcVG0hqdP7L9j4edjLyHKglZNYo72Fjpc10mH7N4fjuaTIxUG3ZcITuUMPHWqvNtyP H+2IG49Ss8Gz0AXOhFxasLj/AHXzPGcqs/PxOkU6gKStgAD1rnLZo7Ucry7802FHjrFhxqCJJPxO T12/AVW9x+2cfmMnCkkWzROO5b9ZddD9tOwud4/nsknDY3gANwCLk/OtqNmvGG1egMv3Jk8pxHEr /Jok3ptVVI8OnoUWpBBlcz7aMfKx9rInTa6kdCdAadz/ACeHxM2Nm8hKdrPtVPAfG3wtWF7k97jk Ej4325ebImIJdQbADWoDZwPY3t/AwljmgWVnADySasSdK8495cBHwfK9mD/DzDfECb281rtODzPd nJcrHjcrF9Pj4oDvYW3n9X1X1pvu72pyvuDk43xysePAm3e/ixNzYVpYZGjy80vWt7nfZfMcNGZp lEuOOsketvmKwPH4eFblGYCltS0hqgUUUlPRWdgiKSx6Aan7qmmWxDEF7W++rGMMdCGmUyMNVS9l NtfUbXPTppWzxvsX3HnqJFx/p4z0eY7b/Z1rbi/yqznF582ND5ICw/OKxa9dGzapbsclFLlzR9xT 2ceG9whCLvP2gk28ya6X260marRMy+prjVZNsaa7bqbfbV1v8rsyOMRrmq6A7igBXcbEdQxrRbhs riuO+lw8Yq0uk8qeravkOn5q5cl6tYOtatEXNYc8JM2JGjX0cEa+ZsR865TNweQy3eZ/4Zk/EAAe n71eiZaqyEHTzB61z+TEFJsdPCuau66Hata31RyXD8JNHyuOwYja9z8a2uQn7eSUHh/prR4vFH1Z nYaRqT9vT9NYnIkyZsjKdLmlrO2putVVwitl5Ds1laxqh9PmNJuVx1uPnVuWJi16sY6lbGqnCDrL IZJuQbE7EuKsljcOT+i1ZjcZmTkbcdYVvqVvrXXwSDaNwvT3ZLWAsKq5bRgxbhrMsxsDGlxwCw1H XStJZ3I1P2U2RwDYVGASa5tt6nWtUtCa9+lWIZnQjXTxvVdFNTxpestGsdTSxptxtfQ1MV3ECs+F tkgt08q0gNyaGx86zBysoclAQTQ5ul+1KrAMOl7VZ47IkMq31iaMC3kVJU/mqzCyjRtbdac2C/cE yMBAFuVHncn9NaSww7rqaEQ3w38j0pT+EHypMW4jANTMARY6Gu1dEea2o6E2kXyp8g6jyNNsUAJ6 04m+vnXSphke2k20+1LatEI9tBFSWpCKpCPbQFp9qULrQDdtFSbaKAoWpKfaktUKMNRtUpFMYUKQ mo2GtSmmEC9CnP8Au024mT5V5xXpPu9R/KZL+VebeNaqZsLRS+FIBWjBq+2MKLO5vGgmF4y25gfG 3hXqvuLlp+D49cjFhR4owA6nTTppXnPsnhc7kOTXIx37UeMbvJ8bfhrt/emBn5HDu0U9xD62TqHC 9VrnZ5N10NJ+exYeLj5LJjIgcBttrnX4fOsP3Xi5fNycfJHjhcMSguD+OzfoqLiOcTnoocGTDdMV Aole3oJX9UGuh5XncHgVi+sU9hzZSBcAgXHn5VJclhFnB4qDGyEkhjWNVQBrC17dBWJle8cdfdce ArDsIpR3HTuG2n3XrK5z/MTIzovo+Ehcd/0iYjU3/ZFcaeK5eSSVhjyF4LtIbWIvqTeqkZk9gzuE xuVyRlZKiaNIyI1OoBPU1yvtv2xyGFy+TykMQXGikkSKI9Su7rrVDgP8xcrAhTHz4mlRRYSDQkD4 H/TXfe3+dg53HaeBGjguVO4WufGjkshwXOxcuZjFEYlx2Mb7rD1LoR8qxM73Py+d7hPBcQoxxGbS zutzYddo086ZzvuTjvbfIf7rAWEwYyhBZd3xqj7Vx+T5znZPce8Y0f4Qlr3Xy8KiB2PIY2zhMiPP kEo7Tb5CB4LevCW6kDp/6a9q914HJcpw82PhTqGI9agfiA6r4WvXi7xPHI0cg2yISrg+Y61qhLCC 1J407aPtrR4Lgc7m81cXFWwuO5KeiDxv8a23GWRKdA4LgM/nMwY2Glwp/iyn8KDzY1617d9m8Twk QZIxPlH8eQ4BN/6N72q7wnCYPC4KYeIlgNXc/iZvEtV9pAB8fE+dcLXnyOqrA/T7fPxoJqq2SB40 wZJJrG5aGoZbNMNr6/bUHf8APr5UGe46G1TDLoY2fdZXQ+Z/KSaypYdxrc5eIgrL+0NfnWHK5BtW Xg7UyiZI1iwpnXwHWuLnyAs7E9Sa7Lk5liwxjxn8Qux89K4+XCmlkJVdKGqLqETrIbEdasiHaOlV HxJ4QLCxrSxS0kYDD1DrSTcCIzIunSjuO3SpjF4dKRYbdNaFwR9onUipFjt4VKsZp6pSBIxEvU6g AUKth0pRqQKyyNkuPHuJbwq2qNceRFrUkMQWK3nU6W7gA6AVDlawuNjF23M2inoKuZBCxiNf1uo+ FJCygaixH5aVI2kcuRoeg+FdYUYODs28k2OlkvT3BJA8z+SnoNo29BT9oJua6JYhGBFNiL9B0pdD cjpSn9FRY9yG+dVKGZJbaUWp1qLVsg21Fqdai1AMtS2p1qAKAS1FPsKKAzyKS1PIpLUKRkUwipSK YagIWFRnrU5qMrehTlPfLMvG7QdCQDXn9ta7/wB+enAX4sK4LStrQzbUTwoFGtH56pk9H9hsYPb0 8kWsl3OnW46VXxOX5/kuCkx4cYlmvHJMxFtdGNvhWf7B52HCyWwMprRTn0E9L16PgYGJEH+n29mU liotYFq5tZOkmf7c47J4vjosYKkoA/EBbr1vVT3lhJy0+DxjXXe5dyoBsoFvH51vPLg8TC8084SM C9idNKx+Ell5bNl5UODjSWXHQ9Qq+P21GOpocV7fwsHFjx9gftaqx1rSXAgYyekHuaNp4UDculWY AwW/hQhzPun2bg8hhKIwIDACQ6gAmwOhqD/LuULwRx0H8aFmVhaxvfqR8a6+UK6EEbr+FcDPnz+3 PdLS5W2PBzyCgT9UrpcimQbfuTiMjmeNkxkijidte44vaxv5Vj+1eaPDcVPhZONK7YLMryRKWVtd LGunmil5RFfDze1E34iliSp8jfSrLcakHHHCw1ALgi5826k/GhTkvYfKZPJclyc4LfSO94la+l71 xPu4RJ7kzhF+DuflsL/lr0aWTh/ZHBsisDMQbL+s7mvNeM4rkfcnKskQJeZy88ngoY61pOMkanCG 8HwmbzWauLip1I7j+Cj417LwXB4fDYa4+Og3EDuP4sw8TTeB4HC4TCXFxl1t/EkP4mYdSTWizgVy vefI6VrArsAKqTS2p0klU5W61ztY2qjJJjrUQyGB/FY0yQka1WeU6+FcXY6Kpqx5pkAEm028accz HRS172+e0fPSuelzREpZmIAGvhXPPyUnK8j9M04jxALOzEbQSfj42rpxt2Zm9Est/A6/J5QZMTyR lWx4GCyy3sL+O0eNr1m5CWbX5EfGuTyw82e3H8fkvJh/9XY2UkgB2sPnXXdphBCGJZgiqxPmBa9X kXia48Z6BFA2RH6huK6A/CoJY2T0xBRbqfEVpRyw48JeRgqL1NYeTmB8h5InAi10PU1Fk6UlvwIk yHjZ1zmEik+g7QD+Sq0MoWclNIydKhnyWdvWungbVJAgexBvT4G2aYCuLikCU2EMotU4/LQyMAtS 04gUh0FWQIelOgUFxTRrVrGj8T0FRkbLBIVQPE1Nix73qqTuc+V9K0MBRu/MaVU2SON8KScRgMI7 a9TVjYFAIBA+FDgCQOeh0NSMtl8xXXbk4uwxXudfGpfEeXnUSi1yNfhUygDT7a3UyxH/AAH5GkhW y/G//LTwt1K3pUGlvjV6kFotTrUVSDbUWp1FANtRanUUAWop1FAZ9qS1SWptqpSMimFamIppoCAr TSDUpppFQHC/5gynbDF5sfyVxFdh/mFKDPBGOo3E1x1dFoZeo4UvypBS+FCHW+xvakfKynOzbjEi PoTpuI8/gK9LwJeOO6LEsY4PSzD8It5VyCzPxfsjuYp2uYgQR1u+hNZ3BcrzHCcfAM7GK8dI15Mj qwDeLD41zbNwdT7g4TB9xY7qpYSRfhlFwLj89S+0uOw+Oxfo4iWmQnug6+o1exuRXJx0bCgJia3r Olx51AmYcTl0xdoU5QZy/wC4QCPy1Cm+kQ3a9aRiEJUHSlR1IuDcDxqJ7Fr0IOJshPhXC+4vbUnu LnIRj5BMKAic9QlyNB8TXT81y8fFYL5Tjci6FR11Nh+Wn8HjLjYBnijtJkEyOPEltaBFXjeM4PgF TEWUo7dA7k3/AEVqZM2OgCvIY0fQNfT76yee5Ph8aFhykYikYHtlhckj9n41iZ/JchyPtoQJgy96 eyRMR+HXRr+FRliSt7p9ichm5iZWJlNkCRrMsrX2A+KnyrsPb/A4fB4C4uOPV/1snizUnA4WVg8X Bj5cpmmRRvY+dqvtJasOxutYHu9qgeQUySWoHlrDsbSHu96ruaHl+NQtKPOubZtJiSC9UplOvjVw tcVh85yc2O8eNir3Mib8PjbwH31FTe4Rqdqkxea5B8gvh4atI97My30C6+FZ3IZXGNxkHH4URbJJ V8jII6tY+ka+F6uHI5HgJZ8Yxp9ZkoGaQ6sm691+ZqPhOKlmbuMvVr+dvOvQ3XiroYqnyWl6LV9j Q9v8aIT3tt3YDcx63rqosYyQmw1GoqPBwtiqoHStzHxwiaCxrhWrs22bvdKEtDi+YXMZSmOglb/s ybA2rCOdlYTbeSxDjszdUFxtPjeu75PEVJGK6LIPuNcxyozchBjTWZI/wG2lq6UhYZ147OyhODOH Mcb233s19doIqg3uGGMgpCXPiBpark/Eid7hdt9AANBRH7ZLEGU2UdfM1tuvUtk1/Il4jnp82cxt AEiH699b/dW58R0qjDhQ46BIVso8ato2luprk4nBl/MkpCtKCKNetCBGhLWqdpAvoTQDrUPc2iw8 aj7mtRsNSWkb1CtTjrFreIrGie7XrX4g7pPsNON+pHLlXpNYKDofKksVO3wp6C5JoIF/n4V6jyjA pBPlTlHqHypwBOpoTqaAVR1NOApVGlKKpBKKW1FAJRS0UAlApTQOtCC0UtFAUaQ0tFWCjTTCKeSB UbMvnQo0imEUpdP2hTHkQKfUPvpqMnmXvp93L2v0QVzlq6L3LiZebzkogjZwAAD4Vi5GDk40hjlQ hgL9K0iNPsQUooANAFUznsei+zea4/P45eKziN6DbtbxArS915uM2CvBceFkysgBEX9lf2q5j/Li LHk5SUygFwo238vGutzuGycj3Fi5ONGIooQRLKfEG3pFcmdFoWvamFyWNhpDmyqTENqqvio6XrK9 3+3ec5LMTNwZViGOto1BIJJ6nTztXRzd/Fy/qGXdEqWa3W9Z3Ee4v5tnZgjNosdtihtL/ZpQGVje +5OPmTA5fGbEaJPU51DEC3p+dOzf8wMY8eJML+LkyOFjg/W6+VWfc/D4/NcPJMqgZEAJjcdbrfQG q/sX2pjYGGOX5BA2S43KCL7B/RvVIZObxnvbm3XKlg7eKzK30xaxsDfUV6BjyZY45EitFMqi4caX Aqj7l9wPxPFrnQrdd6jb/RY2/wCWq2bzWXn8Ms3GQMZpdtiBbS43HWowjh/dmZz+ZnJJnQXxsSTa jRrdCd3n8a9RwJBJgQkx9u6g7SOn2UkMEMuHFHJGG0uQw8fj9tT9B+msWsbrUVmqF3odtagke165 NnRISSSwqtJMBTZpbVnZWYFvrXNs6Vq3gsy5QGt6pyZ67goNyxsB86yMvkG1ANRcbkhp3yXJKQ6I Ot3/AOSspOzhHbYqqbG1yvJjDxyqkd4+m3kTpWFlwS42LFyn1Y+vkIMcI9RVQOpqxjzceJJ5+SRp ZyN0MJB8f1m+FVeJ4CbmJbRELiI1pJNbsfIXPSvXWq41PU8r9b7Ih4zj8rl83uys8iXuZH6n43rt sDio8aMKorQw+Nx8SFYolACiwt8Ks7F8K4ubOWbd4xXBDBDtq0WCi1IoAFV8iQBTWtEY1IcsrKpU 1iZmPoSDYgdK0BNdjeq+cpILKLqdKxOTrWamBI86H0m1qb9VKdGuTWgYlPhULYik3ANIOsoqiR2N WIw1PGMFNKzxpoKEeXgUaanSmtJfRaiZy3ypN5A+FSSqo5mtUPd1pHkquZdTWWaSLsUwv1rc4aZE fc5sCCK5VJCWFbnHP6CT08qtXDkxy0lHWJKtgRrTlUk3NZOFyBiuri6Hw8q14ZI5Yw8eo8a9VLqx 4b0dR1tKAv3U+x+ygDwrZiQtRalFFqEEpbUWooBLUWpaKASgCilFAOooooCmImNSLjr1NTBacBXN 2Z12pFaXj8eUeoG/wNq5DMjniynjfdGL2TcTa1d0BWT7mUDjmZYw7aAsRqB50TcmsHLeoNZ3v16G 9NMrp/DcEE9fO1SSmNMBCqHdf8dVmzZWJZiGJFr+NdFkF2KOOQk48Wn6zHreq0cUMmZJBMFJtpuF QrysmCjMpJB6nrY1Um5ETZBmHpkAG743oq2Eo0IuH4/KDqMdUvpvAsDWXmey8MPsRmic63BuDW5h 5zERLN6Y7WAGmtOaaXHybuN6ObKTqLGs7rJ5K6JnHQcbyvC5gzMBhKY9CPMXrrfbvu7keTzvpJYB AIl3O3iT91N5SA48ystgsnVfjVTEy/ocxJTGLuLMf6NalNSYdILPuDnfciZk4wsRpMNLIsnxbS9R Y3svlMLCObDntFky+qYADab6sNemldRLzHFR4Kyll/iWAHjc/Cs73PyGcMOAYm1sdmAnW/q2fCoQ 1caGJePTHj9YKC7dfnUspRcZcVjsRl236aUkU2Pj8Z3SO1GqXJbSwA8aqtn4+RxgnsZUKkjbqT+7 U+JMnPe4Pb3NcnxjJHlLJDAd0cVrbgvQbt1bvtKTNk4mEZMJg2Ls2sACdul7VF7XfkZoZHyY+3jM x7CP+Ir8RXRKoUWFYduiN7VItrDQVGxpzNaq8kgHjWLM0kxsj2vVKeYC9LPOBfWsrMzAAda5tnWt ZYuXlbQdawM3MuTY0Zufa5vWBk8iryiIOFLnbu8BfzqKjs8Ho9NFLLDyyZU640Let+p8h51v4eBN xCY8skPciJLIshtc21Y9dLms3hsaFBlGeZUnQKMeNBq39Ik+FTPlZvMciMCNi/RZX+HkvkK9Faqi PPa75XjFVqW8eKf3PyMi6rDcd+VBtBA02LXc4OBjYGOuPjIEjQWFN4zjsfj8RIIEChQAbDqfM1ZJ NYb3amH2WgE0wsBQxtUEj2qNkSJJJgBVHIlLA0sknWoXJK1G8G6oqAtvveruODIuwi6nreooo9z2 q3NJHi4zyHSwvUSjJuzlwtTn+cy4sOYJjKoPiDrWfDyc0nWwPwFZ/IZpnyXkY9TpTMaUbwKzlnpV Eqruaxlkc6k/Km6g61ahxt6bradb1TmkVHK9bVDKaeEh4NRSTW0qJ5vKq7yXPWqIJWkvc1VeXU2p JJiAdbVWUySvsjG5m8KsCS7il3lVRcknQCuswII4YrufVbU+Arn+Ox+ybdX/AOsfy+AqlyPuKLIm GJuePjkJXIlj0ZyAfSp+NWld1sHPltCy/gb2XzsYWaXFCyJjna0rMFTcP1V8zV/27zU+QUnETCB9 Ga1h91cjwvDJymUZ2gaDj1O6KG5sb28/Pqa7jHiSKNY41CIugUeVasq0eNTim7LOh0Ec0MhsjA/A 9aktWGrMOmnlar2Fms7CGU6n8LH81da8qepxvxNZReopbUWrochKSlpKECiikoApRSUooB1FFFAK BTqbTq5HYBSSIkqNG67lYWINKKNPOgOM9x8eOOIWCT+DOSe2dbW8qwC5uOlq7H3jjGTDTJVbmEkt +6a42LMOPMsqqrkD8J6a10o8FIchgUZW6W6Vly5qhwpHRQFYdauzzBizHzvYVhvMqylT5m3311Od uh2ePyWHJBDI6sqxLZrj9atPIzIJMVCGGliBb4+FclBkTdtYO5vRrFlPlUsfJk5Lm+6NBtQHQAjx rhtlnaVGTdzpmyslmNlZE3Rh9LnS9ZEeU+U3cICgXCfZoapZfKtNtgVt19Xa3qB8r1axiCRpZR1F dK1hZMO3Y0cYI6kSMAEBPzq9xXHS8k4s/wDDS3WsTcCxI87Cuo9owymaWUiyKAvwNZvKWGaRvSYE MmKMWZe5FbaVbofnVPE4iHAPbxiRB4R9QPlWpK+30jrUQ0F/GuEuSj4wqiwFvhSs4qNmqF5LUmBE j5JbVSyJwAaJ57Vm5WSADc1zbOla5IszLtfWsDOzTc61LnZfXXSub5DPa5VdWOgA6mpWrs4R3UUU sZyPIWU660vC4jvfKlg3Sk3haQ+n5hLfpqbi+DeWQZWcu49Vh8vLdW8o+nYPMPQLgJa3yAr10qqH l5LO78DNi47LS0eMpnyshiNzdQLn1fCu+9q+2V4jG3SgNkyau/xNQ+0sD0HIZRdjoeuldXYAWrnb 1OQ7ba7V8SArTCKsNaoJDRowivIbVVkarEzVSleubOiUjGNRNIOlNklAHWqjzC51rEnRVL8Eq3vW T7m5YLj9hTq3Wp0l061Um4b+ZSXc2Xzq5ZuqqnNuhx0043aGtHg8HJzcldintjq3hXTw+yuKi9ch ZiNdTpU+T2MTHMGKBGAPCrg2+VNwmUuRzIsWH6aE+voxHhWGZNSSaTL7zSMRcms+cZx0A2jpUiWa SVVgty5KL1NU5M8XITU1XGDkOfXf41YgwVBsRp41qEjM2YyMZOU3p9K+Ln9FauJAkQEcXU/jfxNR qoRQo0FSGePGhaWQ2VBcmsty4RdsKX0K3O8jJBEvG4YJmlF5bdQo63+dVuLgl5p4McIsHH4NgVHV msLknS5NqyxyOUZp5Y1tLn+hXPUIfTZfzXrseCwFwMRYgbu3rkP9I13f/wBdIWrPGp5Ltv7Ub+Nt RAiaKBYD4CrkbXsPCqEbWtrVqGTWvMpk6NYLyqG6UjxOpDDqDpT8ci2tXQsZFq7VpPWIOe7ox+Ll LOnX+IPxD5VPWTPGY5N8ZsR0Iq5h5omGx9JB+Wt0vL2vocr8cepFqkpbikJrqchKbelNJQBSg0lA 60A+5ooooB9JeikJrkdxb00sKQtTCajYgSdUmiaKQXRwQR868553jpOPy+xb+Gb9tvMGvQ2esH3Z GkvFyyEDfFYo3iKVvDNJdDz/ACe4u5bfh/EaxJZP4pv01Irby+QFmC2YOg3XFvVXOfjmNvPWvSng 4XWTVwlbYZCTv/V1qRZIY8Ji5PeYkVElzDodq+B+VVnPeYi/Q2ArNU5N2cJIucchaT1G1+proDjp BEAx0YizX6j5Vj4FomTpu+OorTJmecyLGSf1R1AFV9EWmjfU0+Kwk5CcY8S7V6lr62FdxiwQ8fjL FELG2vxNch7YZm5NpVG1FWxHhc2rrCSzbm+yuHJbLUm0h4Nzc9TSlhUd7VG7+NcpLAsknlVWWa3U 0kso86o5E3xrLZutQyMiwNY+Zlddafk5XUXrEz8oAHWsrLO9axllPks3aCAb/CjhOMeaXvzLdyer ahB5mocHFkzcruWuE/DfpfzrqUysHExQQQCNLdSz/wBL5V6a12V0yzz8lnd9qomV8OPCYR3ujBiX 0LbTrf4VmzTiewFyykkE9OvSq2TywfeS1t/UdDYaWA+NV4ZcmeQCKM2ksqgmxJPjW1VrLOe9aI9N 9p7jw8Za1tzbT8Aa2Car8fix4eHFjxiyoLW+J1NSO1YI9RHYVXkcUsklqpzTa2vWLMtUNnkGtZs8 9r61Lk5Fr1jZmWNbGuTZ6KUHz5fxqt9RvOlZs2WSTrTYJyWGulZhnfYkjfxxetGJ9grNwmXaLmrr TIF61tM42lsTMziiGxrn8nLdybmrmdKHuAax5b3PjQ6cdVGg7veN6A4Y3bpVX130qWOGV+gNINkr MgGmlMGvTrU8eAzdb1aTEVOo1pBNxSETdTWP7iyFEK4iG8jsGZRr6RXRyGONS8hsi6k/AVxzcjEn IZWXt7pcMmPfUA3ADfYK6cNJt5HD+xyRSO5Z4mOTleRjlZdsGGihVHw6flua7GK6/KsX2pgvDgGZ xYznco8dorZY2pyNWfkTiUV8WWVktarEeQB1rK7hpRMb6GufU06yb0eaANDU45AjxrnVyGBqdchv OruZl8aN0Ze/qfvoEhVxIp9S6g1kR5B0q3HNuFZ3PUm2MHSxyiSNXH6wvS3NUeLYyRtHfVOg+FXD FJ4G9eurlJnjsos0OuaL1GVmFMLTjwvWiE9xS1V+omB1Sj6th1Q/dQFy9FVPrB+yfuooC7TDQTTS 1cmdhCajZqGeoWesWZpIV3rJ58dzislevoJFXpHqnmWkx5EOoKkVzVvUjaR5NmyWLH4afmqpjRl/ UNLnrUmfuEzQk6hiPupvdKx9tNAOpr36pHkf3PzJ5Xue0nRBa/xp2NEFO4jWocfdtBvcmrsakoCf PSqlAmWW4lAUk6eVX8cZrvHjxk/xBoB5GqMIZmHj5rXc8BxSWXLkWxsAgNcuS+3J2oi7wXFDBxQG H8Q6sfGtM2FKLAU1nANeZ95Og1iBVaWS3jT5ZRVDJmtfWo2aqmyOecAkXrMy8gdL03LygL3NZWRl X1vXOZZ3px9RcrI661hZcrzyrCn4nIGnxqzlZB11rLinaOR511cDbH828fsFd+Gkszz3Vam3FnR4 eM2FjJumclN/kRVPJjmMT912LbgihfTqevzFVcWdMUtKfVIRZPHXxNaXGSmSZpJRuI1UHwr0W9Oh 5K+vUlh4mHDgHjLa8oXSxPQfGr3t+MT8vjLGpujBmXy2nWs7K5B4chyvq7lib/CrfEZQwubxSr/j KmRv3+oqNuBicHqplt41BJMPOqz5Px6/oqrLki/WuDsaVck0s/XWqM+T11qKfKsDrWZkZR865Nyd q8bkkycs62NY2XkXvrTp8i99aoyt1JrJ6aUghdydanwySwqi8ovarvH6kGttQis2oJCq69KdNkWH Wo1jYrTHx5CfGsnPBDJKSfnSLBv6+NWExHPhVyHD22uK0g7JaFOLAW97VbTFUeFXFjUCkewpJje2 QdsLr41XlYA66VNJJVRzuNyft+2plstVq30MX3RkKmB2lazyso2g6letYE7Y+RDh4WIm6b/rWH6z vbT7LVZyZcbJ55jlvbGjYjTyUdB8zT/bEST82ZkW0Ue51B8NfT+evVVbaHkvbfyKPI7KKMQwRxdN ihbDpoKa1Kz0wnWvO3k9dVCG7L9KTtkVMoFO2g1A2QBSKeulSFRTTaqQerEVZilN7VSualjaxFZa Izd47J7M6t4dGrpNPDoda46B+hrpuMyO9jAE3ZNDXbht/E83PT+RapLU40ldzgN2qfCjtofCnWot Qgnaj8qKfRQFZjao2eh2qFmrz2Z6UgZqhd6VmqB2+Nc2zaQyR7VUyJbIxv4GpJnrF5zkBi4E0l9Q unzNYiWkjcQp7HnOYyy5+S9/SZG2/K5qIb/wj76TxB6k6mpoVsfVqD0r6dVheR4bfc34lnGB0Unr VtEIcKNQKrx2LWIsFrU4nEXLyOzc7z+G1LOFLLVS4Nr23w8eTKJ3B2qbnw1ruEUKLLoBpWfgY6Ye OkS9QNfnV5ZFvc14rX3M9KrCgdIs1v4YLVRm/mC3btMR8LGtSNwakBvU2ysMK0dJOXkz5FJWUFG8 jpVGfOJ8etdflYkGQhSVA4Pn1rkuZ4XIwy0sF3g628RXO1WjvxXpZw8Mx8qdnJF6z5W+NOnmsSb6 VRysxYkJPU9BVpVt4PReyqpZDmzhFNz8qpxeqMOddTpTZFkyRvNz5CjHYiMqdCpr18SS8z53O3Z+ BZe30ynxDkDw0GtXuPyRsMo6+H2VmRkSP22J2kaVYRu0APA0s8QONdRsk7PM0t9N3pv41Zwp2l5f GjyCBd1Bt5D1D81UclwigD5ijj8xcfkIsiUb1B6+VV5qY0vB6tLlgDrVGbM+NUDll0BBuCLj7arv KxNeJvLPdXiUItS5RPjVOSUsaZcnrSEEVDokkROfGqWZOI1IvqatTuqKSa53Kyu9OdpuoNhW6Udn 5E5Lqq8XoWVcuw8Sa6PisVyoO2svg+KlyHEjDS+ld1gcesSjSrdp4XQw7xXOoyDD9IuKsjDUeFXk gAHSnNGBSDg7tlD6ZR4U0xWq29hVeQmxqMKSs9lqpLJ1qeYmqMpNzWTrVDJHB0rM53JfF4yWVDtc 2Vf9Y2/NWhtuda5X3LPLk8lHx6tZF2j4bm866cVZsTlttp4vQynhx147vM27IleyqfBV6n7a6f2z jiHAElrPLck+Nq52HDx35YYkbdyFXtu87fi/LXZIBHGFXQAaAeVdua0KDjwUluxPvFKpvUKk9alj ua856oJVp4pliKcKGWKaYadbWmkUIJcXpyHWmEU4aVGUuwydBWzw2T28gITZZND865+NtRV/HkKl Sp1BuKtHFpOfJWawdiRSU3GmE0CSDW41+fjUletHhahjaKWgVQFFLRQGazVXd6VnqB31ryWZ6kgd 6gkfrSO9QSSCxrm2dEiOeSwv0riPd3Id1lw1b+k4/RXR8vyK42O8rGwUG1ec5GU+RkPM5uzm9d/6 /HL3NGOe+2sLqRL+O/xq1oLfOqwB3AedWImYOCLEA9DXsPGWY2JY2Bt0tXoHtTg3xMb6qcWmmA2g /qrXNe1sCLOzi0oukNnPkfhXoQyFChR0Gg+yvPzcn8T0cVIyO7QGgpwUCo+8CNKTuDzrznTJaVhb XrU8badaoo4t1qVZR51UyNMvg3HShoY5FKsoIPWoI5gfGrCuLamtqGjLwc/ynsrAy9zwHsSEanwr huU/y/5+F2kVRkRj8LIbm3yr1wMD8qUhTWko0L7jeLZSPF8DjMiFu1kxtG3kwtVTmOMfEfvIPQ3W vbZsTGm/vY1f4sNazsz2txWYjI8e0N5GotytJq3JW1Yg8UicMQ/iKsQyCUW8V0tXfZH+VeES7Y2X JHuN1VgCBWbk/wCV/KR7mxcmORrXCn0kmulrJ+Bik1mDiJgd7qxva+w1FY9u56KdK6fI/wAv/csd 90BktqO2Q36azMn2/wA3hrIJcGcR2/F22sPj0raso1Odk5nxNzh3aXBjO69hqau9s31++uY4rmH4 xBFJHujY3JvY/lFbH/FXGEdHv4Dbp99681uJzhN+R7ac9ISbS8zQaO1QSuFBvWbJ7qxSSoicjz0q hm81JkntwKyBtLtWfavOkLxNe/xrR7n2QcpyDOxgh1J6kVPwPBS5Ugd19INJw3DnImBYE6+o16Hx XGRwRqoAFq1ayqttfmYc/ff4IdxnFxwRhQoFq2I4QopYogoqRmAFK1OFryxpsKid6V5BVaSSlmEp B3HjVWRqc71Xdya5s6JEUpvVR11q05qG1EjomUsuUYuNLkH/AKpC33CuEZJcqLI5KaSzbgF8yx8P sFdJ7uzmjgjwo/x5H4rfsg2t9prnk45/r48B23C4aQL0BOpr08VdtXZnn5nusksx08zT9t4cYiGU ReRyQCfACt/bcW8qZiYawRrGi2Vegq0Iq4WtLbPVWuyu35kQUgWqZFtan9u5GlPIVB6j9lZEhYWp LWNNEqdKk3LfTWqQbQRTra0GhCMii1qeRSEUKKnWrcLW1qkOtTxtUaIzq+Cn3RtCT01UVqmuW4nJ 7WVGSdCbH5GuptXq43KPFy1iwlLS0Vs5iUUtFAc471Czihn0qB30vXhbPakI7dapZEwUHX41JNKA DrXJ+5+b7CHGhb+K/wCL4ClauzhG21VbmZfuTlvqp/p4yTEh18iaxAF3U3cTqTqakUC1zX0KVVap I8N7u1m2OU6hvCnnTUHrTQAelBvrWjB13snICJkC+ptXS/W+FcP7XlYZUkd9GW/3WrqFuRevFzL1 Hv4ErUTNNcvSnjKF+tZo3eBp43GuRt1RpDMHnUq5Q86ygTb404O1VEdTZTLA8amXL+NYiyNUn1DV TDobq5lvGpVzR0Jrnhkt4Xp4yiPHWruaI+M6NctTUizqa5xcxl8anj5AjxrSuzDob4daXcPOsZOQ B6tU4z4rfirW8mxmjp5A26aCmm500186oNyUQFgdarvkSTGyvtB8am5FVWT8hxPF5htl4kM5/aZQ W++16wMv/Lr25kndCs2Kx/7Nrj7nDV0WLjqo9UvcarVgKqdujaI47I8y5X/LDNjG/i8hckDXtyWj f7+n31y+VxfJ8XJ2s/Gkhkv6WYaH5N0P2V7rtUm9tabLjwypslQOh/VYBh9x0rSvbR5MpJOUoOE9 s4qdhH0JIBPnXWwgAdLVMOKwl/uYli+CDaPuGlI2K6/hNctrTO1r7he4B0qN5bikeCfwt9ptVeSH MHSMkeY1o2ZVUEkw86rvMKhyHliv3EZfiRpVN8gk/CstnStS28oNRFjVfu04Pp161I8DUEm4Go5H VFLMbAC5NI8iIpZzYedcn7j59mD4mObAizEda3Srs4glrKqbbMnm+SOdyLTIbRx+mI/Aa/nrd9u8 en06ZbjdNLdmY9bGud4vjzm5ccN9Dq/wUV3mNEkMSxoLKgCgfAV15ntSqjl/XTdrXfkWEjFgBQxV Oup8qdu2r86hJua4PB31HF2PQ2+FRta+v30pZwvpXcfADxrTwOAzs2zbO3H4u9VJvoRtVy9DHNuv hSq5XSu8wvbfHYsZV07zsLM7fHyrj+Z4qTjMxoSCYWu0LeYNW1HVSZpzUu4REr3FLe9QJUu6sI6w P6UHpSXvS30qkG1KlRinKdaELuO9mGvSu0xpO5BG/iyi9cNCbGuu4SXuYKi+qEg114nk839hYkv0 UUorsecLUU6igOMd6rSy0sj28azOT5CHEx2llayr4efwFeKG3g+gl1bKnOcxFgQFybyNoi+N68/y J5J5mllN3c3NT8lyE3IZLTynr+FfIVUr2cXGqLxPLy8m540Fp1zb4U0Ut66nEduYaijc1tabS+FA X+HzPpc6ORj6D6W+RrvYl3KGU7lPQjyNeZ1ue3+Wy4shMYyExNoFbW1cebjlSej+vyx6H10O2C2u KeF0rLlzchNVsfgaZFzzo22aLTxK15T1urNkL91KE1+dV8bksPI0RwD+y2hq8trefyqwYeCMJTgg NSqtqftqwZ3EPbFNMYverFhRtpAkgKAimhR0qzsFJ2xQSQAUuvnUwio7NBJDrT1ZrCxp/aFqBHap AnwLODI+7U9OtbKOCKxMZtr7TWkkoFq3XBysuxdoJNV/rI1Nm8qrZHLQgeg9K22oJtbNC9xVXKyn i1SxrKPJyu11a4+FLJkHbuc6VjfJpUa1JjykjNskGpqaHKK6HT41UhZJV3KL/GkzRImLJIg1RSw+ zWpk1CwjQmQZERDeoMK8+9yyZ/EZnaO1YJADDI17N5rex1r0PBdJMdGQ7lZQQfMVm+6OETmOMlxO kv4oWPg46ffW0lOUY3OspHmo90zrIfSCvT7fupkvujONwhA18ulY80UkMjQSoUljYq6+IINiDSpG 59QBt8BXb26djn7vJpP0L+Tz+flQiGQhVP4tuhI8qzj51JLfdqNR4eVRt5VutUtDnaztqdD7Px7t NkMOlkU/nrqo0ub+FZXt7F+n42IEep/Wx+dbClj6IwSx0sOteS/qu2e3jUUSmBsrXO0eFWOP4rKz 3CxL6AfU56CtTi/bjyWmzPSnXt+J+ddLDFFDGI4lCoPAVqvHOWc+TnVcV+ZR472/g4dmZe9KOrN4 fKtQG3TSmXFLeuySR5nZ2ctjwdapcvxsXJYbQuPWBeJvEGrV6W9GpCs00zzOaKTGmeGVdskZ2sD8 KA1xXU+7OI70f8wgX+JGLSgeK+dckp8PKvLau1n0OK++q7kwNOvTAdKW9Q0PBpQaZTgapIJ42NxX Te3ZvU8XmLj5iuWQ2tWvxGR2cmNidL6/bWqOLHHmrNTrqBSDUUor0HjHUUUUB5xmZcWPE0srbY0F y3hXnnN8zLyeQT0gTSNP0mtr3CM3kwPpz/AT9Tzt41yjKyMVYWI0INc+Ci1nJ6ee1tOg2lFJRXc8 7F6UCi+lFUgtKBekFOjYBrnwoBNeh0q1xt/r4bftCoR2ihJJDA1Yxp1gyosi11XUis2+1mqQr1fY 7R03KL1WfHFWYZ0yIVlQ3VhcU4revA1DZ9RPBn/TjdcdavY08yCwYi3xppQGlA2m9CvJeTPyB4g/ MVMvIy+KiqAvanKTSTDouxf+vl8hR9fN5CqYNPFWWTauxbGdMfAfdTxmSfD7qpXtTgdKSTauxaOf KPBaaeQn8Av3H/TVYmmX1qyNq7E7Z+UTowHyFMbJyXQjuspPipsaiuKOmtRuCqq0MtOf5jieT2Zz PlcexsXKruAPjuAvpXa4+VHNEk0LiSKQArIOhHzrnpYYp4jFKu5GFiKxM9OQ4LbkcNI8MB/vYwdy k/utcV1q1bCwzjelq51R38rK6m5sPCqJgFit73rC9te65OWmbCzURMjbuidLgPYXYEXtf5V0Cyxq 9m6Vm1WnDRKOVNTN42VkzMjDb8cbXF/I+NbD45lhZf2hasrLj7XO42Wg9E0ZjkI6XBuCa1+7st5a aedIg3foytwjt9OYpP7yB2Rvzg/dWo21kIOoNZcTiPknHQTqD/rL/wAlXTIw/D9tVaGLL1JlfgZ/ pxJgOT/uzEJ+5+r+Stl3RlDAgA9a5TNyfouUiyWBCyN2pCOgV+jH/WAFSZuVNfaGIXoLU3YhmnSb Sjnff/CIucnKY9gmR6JgOm8dD9oFcmGaDcu7XoK7vmw03A5Qc7miUSKfipFeesxY9b31rvw23J+B 5+euxqNWIxN/0025DXv/AKKtYPG52fIExYi48W8B8zXdcB7L47EKZGeRkzjXZ+oD8vGujskcUmUP b/8AxFnQqsGDujACiZ/Qth46g16Lw/Fx4eOhlVWybfxH6i/9GlgmiVQiAKo6KOg+VWUlB8awqV1R u17NQ2Wg1OBqAPenhqpglvSg1GDTgaAfelpl6WoBSAwIYXBFiPDWuC5/ijxuaSg/3eW7Rn84rvQa pcvx0fI4LwEXcC8ZPg1Z5K7kdOHk2WT6dTgFanVE6PDK0UgsyHaR8qdurzRB79c98j70oNMDA6U4 GgJ0NXMZrMNaoIatwnpbrVWpi6wztePn72KjHVhoatA1h8DkWYxH9bUD41tivTVyjw2TVmPopKKp k8nx4ABasH3Jw5im+sjS8cg9dvA+ddXHFbwqUwRyIUkXcraEGvLS21yfQ5ErqDy1oWC7wDbwqPrX Xc/7cGFC2XjE9rqyHWwPlXMPA1t4Fga9lbKylHhvV0cMgHlS9KQiitEHUlJRQg61Le32Ugp270bb Dre9OgOh9s5pIfFY6DVa37261xfDSFORiI8TY12BevJzViyfc+h/Wtupl6D2I8KUEEVAXtTe7auJ 3gtA0brVW71HeFCNFwMDT1e1URL8aeJhSCQXdw604NpVRZgakEgPjVJBOTTWNMD0FqAW4pfDrUd6 N1UhKGtSnYwKsAQfCot1IZKCDMb2+cfLTOwZtk0cgkVT066/krpp0dyHj/CQDprp1FZLTfGtPClO ThtGG9cRt8bGtbm9TO1J4xJV5x504xZ42ZHx2WTTxCm5H3VpRz/VY8c8Rusiht3XrrWflQSPA0TG 4III+B0p3CRSQcYMZZNxgYqG+F7inQlq6FjKR4WjnLf3bBj8vH8lXTmxxX3a/wD2vWPnmWRHEjEg i1qmBMuLFIerIpJ+NqiNOihNiZnIxz5EQKDYx2OD5HSlybMoK6C9Z2YoVSb9NQasxzbsYN56/fQ0 64UDeQikm4fKhhF5JE2rfzJFZPF+1MCMBs4maT9kfhFa3eP0swHUL+kVUGRIp6/ZXXjbScHDl41M m5j4uJGgSEBFHRRpVtIT1U1gw50i21++r8HJN41pQcnVmsiSDpViN5VqlBnowFzarsWQh8RWl5nO 09iymQ/Q1YjnB61XRlapQq1r4mPgWlkBqQG9VAPKpVLChCxS3qIMfGnhhQDr0oIpNDRagOS948Z2 5E5CIemTSS3n4Vzqtp5GvR8/FTMxJcdxcODb4HwrzaaNsed4X0ZCQRXDlrGUe3+teaur1RIKcp1q NGBFPHW9cZPRBOnWrEZ1FVVaxqwh6VTFtDV4/IMUyOPA11qMGAYdCLiuIgkANdXxM/dxACfUmhrv xW6Hk5qxkv3optFdcHA4FY6lCW8KcFp9jXhPe2QZGPHkQNBILqwsa8/5nhsrj5jGyk49yY3GoAPn Xo9qiyIoZoykqhlP6p1FdOPkdHPQxbjV1B5M8a621PnUBFq6P3NxkWDlboV2xSg28r1z7L99exW3 KTy2W1wxgF6KOlLcEfGqQQGlvQV0vSVAPjdkcMpsw6EV0PG8t302Sf3g/LXNg1LjzGGTfWOSisjp xcjo/A6s5I86YckedYoz7+NJ9dXD2n1PX79TZ+qHnSfVDzrGOafOk+qY9KvtE9+ptfVjzpwzR51i d+Y9FJ+yjflHpG33U9oe94Sb65q+dTx5anxrmwc3/s2p6y5q/wDVt91Pa8SrmXU6hchT4045Cjxr m0zModUYfZUn10/ijfdWfbZfcqbxyl86T6pfOsA5c5/Ub7qO/knpG/3U9tj3Km8ctfOkOUvnWH3s zwhc/ZTTLn+ED/dV9se6jbbKQ+NWOM5WLGzUZz/Df0SeVj0rmGfkv+xe3yqFv5k2nZf7qq4/Ew+Z M9OyY0toeoG0+YPjWdxcix8lNhk+qaISqt/FDY/nrleP5r3Jh2COWjAsI5RuX8utXOInzpPcEGfl MTI7bWsLABgVsB5a09uOpPclQkdLmJYN4ikw0vxsXmtx91Tcg4UMALnw+QqvAXTj00N7nQ/E1z0O vRGbyp7cLk9LUQyZbYcQxsd5ywAG3pf50nIHuoEkHpZgGFxexOvW1WeGys+HA+mjhkUwSt2wVOqN 01tROs5OjnaojzZLh8NnyX+utimQaL+I9fsFWhweCjASzuR8LD/TULpz+UVtAyoDf1m356l+g5z8 JjQfEsKu5r7Uc7cbt916fBl+Di+EhF9m8+bm9S9rjxftQIxHgOtZq8JzUmpeNR8X/wCSpB7czrh3 zFjYfs3P+im+3Yz7dFryVL8aYoOsAU+R0qwBijogHyrLbg8xdRnBz/SUj9Jph4zlR+CeN7eG43/K Km+3Ynt0elqm0JIALA2qVJkA/Hr4VzLQ81EwDQM/kVIIrThxMsxBpvSSPw31rVb27GLcVUvuT8jV TMjB2saspMjdDesVILsEkNvI/GpfpshNYnvau1LNqWee1FODaDCn6ViLnZcJtKpNWoeUhfqbGtbk zG1mmGtTwaqrMjC4INPD/GqQsdRXDe9MH6fNXKUWSYan412qyA1j+7sQZXDyOBdofWvyrF1KOnBf bdPucHHLoKsK1xWak1m18aspMfOvLEH0tS6p1qwjVSV71PG9DLRfhPnW/wAFk7Ze2TpJ+euciYaV pYchR1ZTYg3rdHDOHLWUdheiqP8AMP7F/torvuPLsObCiloJAqDIyY4UZ5GCIouzMbACvIeskZgK ryOKZgI3MZ5xIMjsIMWbL7qqHv2mhULY+B7tUcbO7+PFK2hkRWIHhcXrTo0k+4q07OvYq+48UZWA wtd4/UtcC9+leiZMyFCD0ItXH5fEZM+aVwYmmDa+kGw+ZrvwW6M5f2ePSyMg0ldhjewzLwB5Cedo swZq4ZgsCgDKrbr9b+qtHC/y4wjrPO7+YFhXeTznn4JtSpDLJ/dozH+iCa9axPY3A49j2RIw8W1r R+g4zCiMhSOGKMXZjZVAHiSaklg8ej4blJNVxZTf+iauQ+1OYksWi7YP7WleuwpjyxrLEQ0bgMrK bgg+VVs14IFDSMqAkKCdNT0FRtlUdTziL2Xl29bgGrUfs6Jf7xifka6uSKWTCzeSEu1MHJxsbsbQ Q4yGhQsW6i3e/JUeUjDHkeEXkA9Ol/t2jrby8ay9x0q6djAj9r4Y6Lf5mrcftvGHRK0xFjrlTR4m S2Zips7eS6GMsxF3W1lvt8wPh4VOpI6GsNOTauowZ6e3se34alHtzFI8avicrUqZI8qQHdmZ/wAN 43gWpp9txeDsK21nXxFPE0fjVhGXyW/COeb235SH7RTD7bf/ALQfaK6cSxGj+EabET3X+Ecufbsw 6Ov3Un8hyx+Eqa6rYh6GmMgHjTaX3X2OWPEZ6/qg/I1E2HmJ+KM11RWmMDTaVcr7I5ftzjqlJaQd Vro3RD1X8lVJoorE2tU2s17ifRGKx80pqSduRXC6owYfYb1o43HHPPIbJjD/AC/DfLFlDbyl7Ib9 BpWftZkDDqRe1WGkVcicpLQ6FOR47JjMhkWIr+NX/F9lMx5lycUvGbr3Hsfhu9NYORDhomG2Jktl STQdzOjaMp2JvR/DBIF+refS/jVjAy58TcNncjf8SXtr5g20rLqK3lSXZ8WFpohPIkcW4Fmf03t+ rW7BKmHiqiRpLc33rY3+Ncs653OchjcfjRhJJ2KRh/wrYF2djboqqaZg4/Ix43KZkUo+g4uUQyMy kGWRpRCg2bvRodz6+kffUXG9UL8qbh6HSZvJyEAKm1vC3W32VTbPyitiDfz1qknJTRqT2VNvDWoc jm8vbeOONfmCf01hts7KiWiRpRZubboakbMyQLm//LWFDy3M5GRDiQLC02TIkMQKkDc7BRc3Ogvr Vv3FmfyXNXCxs0cjkxhlz1MXbjik9BRYzre92v6jWlVtSYs6qyrCl+BfOXmP1uR4gX6VJHkvGRe/ wFzXPQcxymW6rFFEoboTe356v/8AjKaWxpPiGI/Q1Zg00o0XyNxeQKjrYmnDk1tZhesOSbmEW74S yDzicH84FQx5s8hs2NJEfHfUh9zO1HR/zaF/Rs+2pFnkXobjwrn4pSr6g3qxk5Ld2Jd7QQu6LLkB S+yMkb32jrYV04209THLSsYN5cy+ji9I8eJNrbY3mKxIc9lklRJDkwJIywZDIUMiDo5Ww+Xx61YH Ip+sLGujZwVS8Y8qDWJt6j76kh5ix2y3VvjpVFeQj6o+tJJlQSC0oB/pDrSexY8DeizInFw1r1JM 4lxpIX1DqR+SuTZ3i9WPJvUeHjVjD9wG4jmBv0NNy6k9tymuhxGYTBkPGdNjEfcabHmheprQ5Ph8 rL5CeWIhIna6k/H4VXPtyCHb9VkkFzZRcLc+Qrk1WdT2K7SQ+LOjI61bhyo26NSD2hh/8PZHNpkq ZMWftTYbAkohlEKszK17m4fp0061p5ftXj+KyseBZlzsfMx/qIMhBtBAIB/C7AqdylTR8bSkyv7F W4GQzrca1pYsgJqp/JMawMMjxH53FIsGXjMN/rQfrLXNGrNNG73h+S1FZn1I+PS/SitbmcthM7AK SaZwMOLyHuSDGzGPbiU5EUNiVlkQ3AYjS0dt1j1NvjUIM2Qe3AhkY+XSrnt3jp8T3RgyTkbnjnG0 eHoFXiq9ybROVpVa3ZKns5OP/wCLcmDi8iTIwhxeQEmyF7ZDGbHDD8K+kaa2qkeF45OCXkeI5GfK TFmixMsTIqL/ABdiI8I2K20mRbbidKt+x0jXkwyWu3F5m+3n3cXr99Q8ShHsbkV8Tl8Z+VsKvTtU Q0edWacpsdx/t/jsmLCfPz5cbJ5VpBxsSIroyxkKJJ9yto5IsAV6jXy1uNRTi7WiWKaJ3hmjT8Ik iYxvt8bbl0+FRnOgxOI9ry/QY+VNFhjt5ORI0YilxxCHW6q3q3a6+Rq5xaGaCXMLIxzJXyCIjuRT IblVbS+vwpCWiJazerM+c9v2/lG34eZQ2Hwijo4o4ee2LAeXmiz8xAUjxoUbFjkZO72ZHkRmZgAb 2dfso5CRYPb2bK+ixcwrtbyWGMmn8ZDHxvuHh8WeL6nkstfqHuSIsaORJtoijW25/wCG2526eHWq QZiZU2WmdJmZEmFDxKhc04qo8rTGWSDbH3ldQgaI3JXx6in8DInKc5Dh5ryNjQs82PvjMZyTG107 i29PbtuI03G1tKo8fyWNge4M4ZG2TEzszNw8/Hb9aJ8uYK9vHtl9R+yx+FaHCYj4HvSPjXcyDCM6 RyHq0bRJLHu+IV9p+IvQBxHaUPFhSy5HHRqgxppk7bk+rettq3UaWNLHjcXm4/M5PKyyQ/SIsKhF LGKJzfuqCCGaRltpeyj4mne2yj8RjhWDFUAYA3sfI0zKW2B7lH/8DE/ty1CFTiY4Mj2xz65WS+Pj ryMDLksn8QxxSY7w/wAOw/iSKqgC34jUHLovG4+PlYOVJmYfIY7y40mQqiRHjKh1ftrGp/GLenwN SwhX9rc1sIZW5HA2sDcG8mH0qvzak+1+AH7OPl/keOqUtTcXInuiH279XIY5XAOVtTugHHmyLW27 OsdulNl4+BcPkp8TlDl5fDAyZeP2tsfaUsG2yWXcyhGuQbXFrVpZSn/6n4jeHcUf/wBjlVkcWpGL 7zP7WDln/wDmZtSEWWGLjY8mLjZvK574EGfM0ODHBGHdgjdtpZGcMFXd8OljfWn5+OnHcrNx8GRL lDHAE7zIqFZGAdVXYqggowNMGFBy3t/jPqcqHjo+Imnw5pspu2kkUrpJugaxDyARhdvnf4VPkTpy nK53JRKVhyZF7G4FSY440iDEHUbipIv4WqNKCpuSv25m4vM5RJ2L4GQkU+LtXZ2JdoWUG27Qvrr4 Gj6PkGPCQw5BbN55XlELqO3DDo6v6bMT2zc3bWx6Vc4VIv5xLxmVf6Tm8aTDmANvWqs8Zv8AumQD 4kVPBlxS/wCZkQWy42IjcfigfhBihZzb5Euv2VUkG2VcvGxYMTKzeJ5OTkRxsqxclDMirtDNs7kJ SOP0qwPXdcA66VWnbKxYOFf6lpG5vGhnbcqfwmleBSI9qi4AmP4r9Kh4COWHhvdvfBG3CONJf/3i +SgX94O35am5RXeH2OiAsz4eKqgaklXwywHyAuaQSTSvJhchn8fJK2QMOZI0lcKGYPBDPqECjQyE dKbFC+fLyLfWfRRcbjwz7iqmM9xp95kupayiH9U03lb/APEvM/8AzEX/AOUxqihB/l3uv/8A1uP+ fMp1HQMuSLBwcTlMfObO4/MeSFnli7TxyxB2I22U7bRvoRfTqasR4EsxixTnvDzuTi/WwccUQ44Q 3KxSPs37yFNyH08vPH5dHb/LzERfxnkssD59rOroPcXuDH4znYM3H43HmlOJHLBnSytGe2/cTau1 GXQfnqkMrDyoM3Bn5XMypMDisXtpJJCivO00oVhGodZANqsC3pPX4VJlY+XByY4RXXJyJ3i+jnK7 Q8MwLLKyr+wEfdbrtpOKnxsf2byDTYcWcsfIo0kLsUjAljgCSbkBO0brXp/Fcr/MvePF5s0UOOsI +jRIXMgXbDkmO7Mq2/vCopAktYeDw+LH7hTCz5szKgwJ4clZUVVuocMYmRV0V1Kka6+NZ+NxsDY6 ErqVH5qOChmif3PHKp7kGFlRzk30cvKwv+8PUPMa1exh/usf7g/NUaEtGJJwxH8iSKcmXn8eKYmQ LtiaTtFtuwLcASG1/IVPLxuBFyZwsDIyslYWmiymyYgoWSJlT+G8aIpVju0Ovj0p3MSdrjPasok7 MkXExyRS/svGMaRW/wBXbc/CtSeeLMbj+fgXtjlmbGzYAbquXCjnep8QVhZb+IC0hF3PuVIuPy8L Lgz8J1XJxmLR71LIdytGysAQSCredJJme4om5NhJB/4wP96UxEqh2dndCO5+wAPVfpfzv0UUQZBc VWzcdAhJ0AFyaQHaXk5jIwcXE4PCyZsvJ+uz8b6vDxUjV8fZ6SkcjbO5uIYAtusD1p2HxfGScc/K cznScdgNOcbHMChnkdQd7EtHJ6F2t4fqnWrcSQczwOZxCOGyeJR83i5l/wCxN98DfAX2/IqfCsjm l73+XfBvFcxRZGUkoH/aM0xW482sfv8AjWXVawbV7abmpZocbxCcV73xePzpWKwyLLizIv8Aelx/ BuNbA+sH4ir3F8VwmX/mJmHvPMIHkyVgdCAcpZP4nqsBtiJFvM/Ko+XDr799uxP/AH0GPipkeJ3X msCfhqftpvtfuf8A1L5K59G7N2j/ANrHeqkljxI3Z5b/AI/rBhw4mEjW4uWXI49UT6eeZNjsNut1 2rp5G1aGJjYsuNk8nyubLgcZiSJjb4FVpXmYBzbejgKikE+nz8q5fAzM9MKAR5G1FjUAaECyjSus 4/kMeL2BPk5eFHyvZ5EjIikYooLqoWQlAfB1H21zqk7NtHfk314651hShMjD5PH58e345BNkSSKu POw0aJ1MvdYD9lVa9vKrU3GYD4fMT4PMyZU3CwSyyxGFUvJEshtuKWaMtGR6dR59Kre2/cJ533/g 5s2OmIPpnxo40cuC8ayuG3FV12sR9lVfbAnXjfecU4tJBx00T+e5RlA7vjcGtqte2pxta/VxCFyZ JcT27ic6shds2bJi+nZV2IIDOqFSFDa9oXuavZuLPgczi8MmU8i5qYj95lTen1MssThQqhdBHpcV m8oGb/LjhQNWOZmLp+0z5e1fmfCtr3CrL764ZSLFYeNDA+f1ORTau3Ym59+5FhYMubzmfxEma0Mf HJM/1OxCW7bRqO4CLWs+u21RzpBFx8XK8fm/zLAeX6bIMkXZkilI3Idth6GuNCL6jU1Z40E+7vc4 Gt8XLsPtirL4jT2LzLNqkmThRxfGUNjk2+V1NNqjTuNz79i6vGYAwuJzuQ5VsReXS4iWFXYO2zaI 9qGyDd6me/h51NF7eT+ay8LkcskfJ2ZsSGKEsjIBuVp2bozAX2KwsNb61nc4CeH9nfDEf/vMKtm3 /wD1e/x//wAOrC7El9zF4qOPOhyczNlbAwePjQ5kkKh5TLI3bSGPeGW+4akg+HnU2RgtDzWDxceS ZcXkxDLi5wVQ5hm3aldu3cNvlaxGlP4GeCH2z7kM2ImeIsuOaTGkJVTGZFAZmUEgIUZvsqHE5kcv 7k4ELjw4icdImNHDBIZAE/UBuq22hdKm2uEXdbJbk4aEfzPGxOWOTyXFpJMcXsgI0ceuxpLLeS1g xU2UnpTOFxuEzuC5XkeSnkjKGOEmNCzQRmRHQoCpDNKygm19LDzqThx/+qPcx84M/wD75az+F09l 86TpZ8L+1HSEnKS6ibNQ2+hFj4+XNjz4xnZcWaYzBQu13KWSFpP3Qu8LYerrV+GKX+GZ3DtFEmPE qjakcUQ2pHGtyQB8Tc03DkBQMpBUi4IqcyEi5Fea17PHTseivGsMkDAAWPSnK1+n21VLkVNGOhrK RpqCfZH5f+minafkorcGZN/GxIYI9kKBF8hVfKwcgTwZmG6xZWMxaNnUuhDKyMrqGU2IPnWoq2p2 0GvSeRucnNrxPKfzJ+WSaCDMmhbGkWKA9rtOyu1kMt95Kj1X+yiP25NDjHBhnAwZHx5ZomTc7Ni9 sx7ZNw2/3S39JrpQq+VLYVZBgLxufjxPi4pxpMN5DL9PmQGdY5GO5nitIlrk3sfHyq/x/HDFxu0X Mjs8kskjAAtJK7SyNYaC7OdPCtCy+VKLUBz2XwEsxlgaYNgTzjKkxynqMoQR/wB5u/DZem37aOx7 iRIIosyJBiWWGfsBp2jUgiKWRnsV0G7aAW866GwpNi+VJBzcWDzMWTNmCTEmmyHWWSKbFBhSRL7Z IVSRXVterMxpY+Jz48sckmQrcn3Wned0ujF07WwxqwOwJZR6tLCuj2L5UbF8qSDIw+PyFyJ8vJMX eyAoZMeMxRgJuOiszncd2pvTJcTOx8qXJ49ob5Maw5MOTGZI3VCxQ2V0II3t8xWztFIVHlUIcrBw GZHDPjHIQ4+blLm5cYiteVJVnURHuHYgKAW10pZvb00+PHhzT7sXGjlixVVArIJirMXa53W26aCu mKjypjAVZKYD8dyT568s2Sh5OOQOsva/haRSY9u13L/gkP63WqcvEZePBlxwTqByMMkGcWj3bkla R32esbDeVvOuoIWopogwpIOWOfx+D7c4zE5bDXPjzRJn4g7n05hglbuWE19zP/EubWt0JqdcSDGy oo8UyNh5mLHm46T6yxiQm8chOptpa+vXyq9Hj8rhxDGwpoHxUYtFBmQfUCIk3/hFZIiAL6XJtUmP gZDTy5mXM2Tlz2EkrAABVvtREGiqu42Hx1uaAo8ekUPN/XT/AOH4jFmzpj5HaYk+9TIfsrNxeKy3 ijyGdoc4v9SZl/Es7N3WYX/pk/Otyfict2yY45kXGz+0uWrRlpCkJ3CNJBIqqrXa90PU1pRY6qNR QSYPISc3ycIxs54Fx94lkjx4jH3ZFsVeUs73sQDYeNRwSc9h4iYGLliPFiN4gYg0iAnd21kuPR4W te2l66U48Z6rUTYkZ6CglGDHDky5GRmZjLJk5biSVkXYt1jSEWXc1vTGPGmzYeVbLjglWOHkIUx8 tGTcxSMyFdjbhtP8VvA1uHFA8KaYLeFQsowv5flNBFhNIpwsfIfKji2evuyLIrXfdqP4rabaswHl sfGhw4Wxngxv8HJkQd2bHHgInLhdP1brp8a1Ox8KOzbwoDI4/AyuLAHGugRoVx5oMhO7FLGgsvcU MhuATrfx1BpW4iSd3nnKJMe2I/pU7CQiEl4uyoLW2sS1yetbAS3hUii1WSGdO3uTLhlx589Ginia CRewoujjazelh67ePT+jU8fHhI1QdFAA+yry28qeLUBzn8nzlbAY5Kl+IiEHHntaKgCpaVS533Vb HpVxYM3IeA5nYSLE3fTY+LEYYlZ9GfaXe7WJHwua2NqGk7aDwoQjQWW1R5EQkjZGFwwII+Bq1tWj Yhqg59sblRhPxySwJjSRLjSZCQbcpoEGwRtLv2/h03bfy60YcPJ8WZF45oexMyu+NkRmSMSLa0ib GjIb0jx8POt/tRil7cdQpyx4bLfPHKvkF+SEonE7qCu9RtUdsbfSF0AvSQ8ZyuFyX83xZo2zjJLJ IXQ9t+9cyJsV7gXNx6vCuq7cflSiGM+ApBdz7TiDjMrhs3Ny5czLgiEstgUx02RgKLCylmN/M3pM KHlOGeZsJIzDkqEycXIjMkEluhKhlINjb89dp2E62prY6HQi4PW9Z2NOZybXLNVR19JwOTjZ0mYO S3pBmIyNAcdBHHF2vwKia+keIN71rwc3yHJcT7oizIseIpxckrHGj7Zkdo5lLyFmYk2TzqfNwnxp nQ6qdUPmKzmgzFjzosWSOOPksY4eT3I2c9shxeMrIm1v4h6g/KsVs0/Uzdqq1VC0IOIyubwMOTCw coRY8rF7NGrsjsLFomb8J8dQdadmHk8nNi5TJmRs3GEKwOsZCgY7vKm9S53epzfUVoRRBR0ps4G0 gVl3tGpVSrehF7YyMpee5XPdgct8DInZ1Wy9zfGbhTfTSqpz+Q5jGxVyRBBiw/xkxsWLtIZHB/iP dmufUelutET5uJkSzYZjVsiB8WUSozjtyFSSu2SOzenqb/KpsPG7ESRjUIoUX+GlV8j2pTnqPa9T fTEFefGy8iDDx55VaHjY2hwwqbWUM0bes7ju/ul8BUhm5Qct/O+9H/Mt27f2/wCFbt9i3b33/D/S 61bI8KYVNZ327mvbr2KfHvncVkHKwZFEsilJ0lXfFKrEsQ6Bl6Em1jpRJJmS50PIgQY+Ri7fpo4I tkCBCzAdvdc3Lm+tWxH4kUdsa6U320kvt01gpxNyGPlZOZDMgyM5ZkymMd1KzsHfYu4bdRpqak4v Kz+G7y4IhkhyURJoclDIh7dwrel01sdfOptmtL2wfCpvt3Ht07FfGjMYN9WZmdrCwu7FzYa2Gugq ZvLwqQJYUlqzE5NSlhEYXzqeIdKYR40hmCkVUHLLlFVfq086K1JnaduBTqLUtdzyCUlLTJG2rehB 1xRuHnWBJzeSrGZoFXCGS2J3u5dxKASN8ezQNbQ7vEVWf3Blr9I30pdeUBbjUjcNJKAyKCyEKEB3 g33dNTarBTqQ486Nw865/LzuX4wJJymNHHBK2xZseUzKr2JCS7o4ipNtLXF9L9KhPuDMjXHE2MqS 5yQSYSCS4ZcmRIY+42z0Hc4voaQDp9wouK5xOX5CXM/lkeMh5JZGjeIy2jBRFlY93Zf8Lj9WpMDm cuYYkmTitjQ8grNiszhmOwXO5APSCNV1N/hSAbxIpCR51l5XIzd+PExIxPlyhmRGbYoRLb5JHs21 V3DwPWqGTzeVgl4c+BUn2LJD2ZO7FKjnarRylUuNxsbqLfdQHQEjzqCeQKOtZbN7l3Sq3HC8Gr7J 1JcWDfwAVUvbdre2ugvVPJzOXTBXkZ8JosFigLF17yCQhUaWHqoO4eNxfUDWkAtQcvJJJEzwNHjZ TSpjTFlO8wMVe6jVehtWmjqResDGwOQzeA4WbB7O6GbL3HIl7SXklkVRuCu1z4WU0sOfyAyjxf0r fzNGKnG3KBtADd3uHTt2Yer7LX0pAN+ynyp6haxJczkcIwNnxQiHJYpDkYs3fiLqC2xi0cRDWU+B GnWkxM3mswYv0+ErHOxxmY571l7JCm8hMfpb1j060Bveml9Nczhc7yGfi42bg4Zmx8yVceH+IFk7 rJ3TuW1giqDdr/ZViHk+RyZsjEgxlGThG2Y00ojx4tWUXm2sTfabWT52oQ3SBTSBWJkctl4Epx+R hEeQVV4RA/eSYO2xO0+1CTvstio6jzpMzlszjW/8USCJDu/uJ+8yMqGXZMvbTaSgJFrj40BtHbTS FrGyeS5HCWOXkMeKCOXaO2s4fIj3glO9DsULe1vSzU6B/cWVHDJDgJsyYlnidpwqlHG5VJKX7hH6 oBHxoDWstNIFZSZHONjyZX8udYccMZkkdVm/hkhzHFrvAIOu7XwvSRcjkZ0hi41I5WSMTSSzSdqF I2uEZ5Arn1WNrKelAapAo9IrFfkuQXMHFvjhOSaUQiBn9BLI0iuJQpuhVTY7fhanzSc5jY0uZl4Q ixsYsMhhKGdQhKmQJYEx6Xv1trahTX3r50PKFUsToBc1iQYfJcxiTcliSLEuLKiYiPJ20lKyx/UO 7AGw2Bo1uPEnyq1h5wysZZgCu4HQ+BBsfzUIS4fJSyvjiaDspmwHKw33h98I2asB+Fv4i6fHr1rS DAiuShyUwhj5K4KRNykCz4SwsGeRJGQRx2KpsLNKvpva5rXjy87Gy0xM9IFeXcFOPP3trIAxjlBj jKNtN/EfGqCznZz45jSJDNNPIsUMYIW7t0ux0AqkOZyDIMQQEZ5mON9KWUWkUF/x9LFRuB8qTKcn luLHnmR/man81hmL3zw2dB6sfOlZZiOgnx4pYzf4shA/1aABzf8ADIkjZchZmxjjrZnMyuY9iWNm uRpUuRkcxgxjI5HC7GMSAZUkWTZc2HdAtt+YuPjWfwOxvdnLZMo3RcW2bkAHwkklZVbx/UVx9tQe zy03JDHzP4qc3hy/Xq3SWU7G3N1/VZx8vlQpq4uRzmfCMrBwRLjMzrHI0yITsZoyduttVqzj5WfD mR4fI4300s8byw2kWQMsRjWS+3pburXO+zIRD7hwRtAm2ZMeQ4Fi7xjY7H5sCat+3IIURskIBNI8 geW3qI7jeP2VAdWGW2pppljHjWLlZ2c874+BB9TLDCciVd+w7AbWT0tuYnoNPnUGRl8phdluRxex FksUhkWRZAHAZu3Jt/C1lPS4060Ia2YkOTH230I/C3kayzxs4ay7WHne1MhyOYysX6/GxEkxCrPG DLtyJY0Nmkhg2HcvldgT9opMblJ86SODjIvqpZY+8CWCRJHpZ5HINgb6WBPw61l0TN1u1gfJg5Kj ov3iqkkTg2IuaJ8/kfrk4zsxTZ06o8CY0wlidXMg3d1kjsF7LbtKhzpszi2A5OONEkjeSKfHk7sT iP8AGocpG25b9NvyvWXxmlyMRiUP4bU36kedqXNj5LCjjn5CKGFJSoMQmDzxbwSvei2ALe1vSzVU yMLPjwo+TniijxplSRYzN/vPblZUSUwbbbfUP1r/AAqe0b91dS19QBrcGmtloPKosPguV5GJZ8OK BIZSwgbJm7TTbNG7KKkhPT9a33VVx8HKzcp8GCADLhSaSeKZ9mwY7JHILqHudzi3n51Pafcvu1Lv 10dMk5CJfGqqcLyEk/HwDHSOXl43mwVllKlliVXbeAjbW2uCBVKPi8rOOQIECHDhknyzJIUEaxNs cXCtdrhvup7TL7texqNk5EMOLlZMDQ42ehkw5WKkOq21spJW4YEX6injkMe34h99WeaxhyPtr2li hhGWxkdio1Hbx41YD7WpuP7OwTGN8kjHzJq24l0M15VHqRXPIQ+DCoTy0A03AGtse1eJWEoIzut+ Ikk03A9q8VjSGVou6/gX1tU9vxNe7XsYUnKwW/GNPjUEWblZ7NHgxNM69bdK7FuE41pC5gS5+Aqz iYGNjEmCNUv1AAFaXH3Mvn7I4z+Te4/+xHTd1HX9mivQr/AdKKu1djHvXLdFFFaOQVHMLoafTZPw GgOaOEc7I5Tg9wjPKQLlYrt0XJxiq7jb4dr7FNGIYZP8wsfFjH+68RiHFxRpo8ca7iD+7PtP7tTq U/4ixZnbZFgRZGbO/kip2dp+fd3f6tZnHY/IIcbmYUBz+4+ZJE5sH+o3NLCW8NJLDyIFUpm8E7ze 1/cHe134mJnG/jkuZpGbXxLRL8auckSMv2qPPH4y/wD/AFWNV2XHilxZuP4zjpsDHzJlnz5MhkJI Rt6wRLHJJ6dw+Ate170qpJGnGjI4o5uXw4jjgyu8FRooytiYyy3kAXTcNobW9UBx5P8A9RMgeHfn /wDy0FLwkMeSDyjIDPkFyjnUrEWPajW/RUQKooxo8+LnH576N27k0jnEDoJAskUcQ9RbZoUv+KtP hOPlxOMx8eYDuxxgPbUX8dajBn7MaSb3AM2VoIF4yJXlQbmWOVsrvFV8dEWsXlpsGTB4rF49p5v5 cXjlmnhaH0TSxOAN4HQqBYV0uZiyQZbZSQfWQTwvi5uGCFMsL/sliq7l1tcgWJrFl4V5yWwIcmGF ENxnSKzyOHidAqxllQIEYXOp3a9KAvEsf8zg5JJU9pSfBPozJsHw3EtbzrG4os3E+7nbV5MRJHY9 Wcy513PmdOtbG3kP5/8A8Q/RPbvbvpN8fd2/TfTX3btn4tfxdKpw8ZyOJh8liDGMp5bFSDuKyBYm WTJcl9zAnScfhB6VQUuUVX9o8JG+qGTOJB6XDS6/MXqzz2NmcpyXEpDGZc/P4qL6kFjGuy5ZzOw1 Ed2O7z0GvSrSwxnisfieR4iXMjw5JXEsU6xFhK7tZLOpIKvZgxH208T5yc2/MZWH3oMjHbBlwoWG 6PGO1lCFtgYhgd2o/Fp0FAUpFwY/Z+3Bn+pVeVTfKqduMuVW/ZW5Oy1rE9etS5hM/Be18DXtycZH POASN3ajgSJTbqLys3zApZI0bhJOFw+KnhRpO9h5DzJdZLbRJlWa9167UuCLDSrGDh5kqcZFPjtA OLwBhMzMrCRgIhvTYzWX+H40BBAxh9ptjRfwzkco0ClfSVQ+qQLbpujVk+RqjJxkLNMsISDHxY1l y5pdzY8QBbtkwqf4knqbYvWtf6HN2R4HYPaTPbOOTuXZsaN02bb79128rfGiXHWCPOxMrEmzMLkT FLfGZFljmh27P7x0G26KQb6EaixqAz+dEa4ftduNZnWDDllxWmAViYJMGWLeFJA9SCk5/ExMwrzW IoGLzaNGWKjuY+UFIkQnwvs6ftKfOps+OTkMfjIDxD454u6dsZC9lsYtGTCrL62dhEoJYKBrqaTM xmm4pOK4vCyIIVnOXkSZ7xlpJAu1Yl7TSaHS7fDxJqgj53tZ+JD7ojjXuOBicnHoTBlAdtXU9bNc J8QUNHKFjme0RckRw8cyD9kvkYyMR5XGhqeSCM8bPxfG4OVjDNmjlypsuSN1RYirqkRR3ZtUAuR0 6m+lMmxs/JPGTnFaNuIiw4zGWQmU400UzmMhrAMI9N1qAt8WS3+ZeczeolJo7nX0LHiEJ8gT0rH9 uQ4E/sPOHIzvjxPkYcbyRoZW2rDiPEuwakGRjWritm4vPy8+cN3E7S3xVePuKJEgRbksE/6o+NVe KwJOL444GZjPm4WVjwR5UMBVZEmgA2zRb2UHoPHwFqAVMvEzPdvAS4TSyRQJHiyyzRtEzNFHkFTZ wCdGNR8aWbP93s5LGTH5AOTruEc88aX/AHVG0fCnY2HJi8nByWJjZBxsWRHXHyJEaeRgs6vJo3bT cJFAUHovmaWCDOxzycwxWduXiy4xGGQGI5M0syGQlrEKJNdt6AgwUV/aXLo6hlfkOPDKRcENJh3u PjWwg2RBVFgBYAdAKqYkKYmLm8bnYeRlYma0EyviMius0G3T+JJHbWJGB+d6u4GNkjDjXJ1lt6rm 5+AJHUgdaEMXkWmjwPac8ADTY/FwzxKdAzRHFkCk+TbbVozR4S8nDzWGith82GaKUgB45wN80DHr 6tha1/xK1U8jBzMiDh4ZsRu3w+LHiTxGRV+oC9pWMbRsSukdxe2tulXoYUkgw+Pw8TJx8PFnfLll zGjMrysrIqgRO4t6ySdOnjc0KOm15Pim/wDjIvzNVvgciLM9wctxmTcvg5xz8InwuOzKF+C7v+fT MvGmV8XJhjMrYk6TmIEAsFvdVLWF9fGqePBn43LHnY4CJmyJJXxdy7mhlXa0Ra+zdcK3W1x1oQZ7 eUye5vcuIPx5q5Qj/wDZzOp/74VB7KJn5njGGgjw5Zm+A2xR6/a9Tw4fIwZh5eBBFmfVTZCQu2hj mdi0MjJuGqnwvY2PhUvp2ZcXFcXLxk3IDZl5U0qsEjYkyLjLHJIRu3G2iW6+AFClP2i3d9wYOQPw 5H1k6fuykyr+Rqt8F/gR+/J/3jVJj40vG52JnY+OZ0xVdDBGVVrOu0bd5VdLedWOKwZcfDSOUASX ZmA1tuYtb7L1AVkkkjy+YkjYpInEysjKbEEFiCDWBJeH/L3JEQ29rkh21H6v8FDp99dBnQ5cMuY0 EByBnYUmENrKuxnvZ23kenXw1qiOPy/5c/Dtjlo3zFyzkbl2bFjRCm2+/ddfK1UGhmS8HxfPcTmz 5WQkmFgRLHiQwNLG0RWeJWLoptfcdP6IrF45e37U5tkBXu8jBiG4s30ZaAopHgGEzKfmavyQxzYu Njcng5eRlYMf08OViSxxrNCPwLMzurqR4kC/Ug62pONxcjjIJIMrHPI4WbCsWfjqwEm9Pwyxs7KC dbH1A9CDcUAz2xjYsfOZDBRj247IbfGoDC7wqzgAalR0rPzBxEvtzC4Xipsicw5LzLNJA0SrHJFK p2lhb8Tg2vqa0MSCXB5hOU4vFyBDHGInx82UNJMrlu6BZ5FTTZbzK61Xy+IjlCrxGLlYsaXLJmSp t229OPGsTSem/VmudPGgH87FByuPj+5ViXdLtwuUi0JgybdpXU9bNuCfEFDSZkUPJcPi8uY0kzeE VMLkkYAntIbxZCXH6u7d8i37NTZUCvxGVxPFYWViNnyJJk5GXJG6xiIhkWLY7s2qAXPh1N9KdHDB Fx+fhYXHZONk8rCMbKeWSN8eOMhg/Zs+8/3jbQV0+A0oDN43Bxhl8XyGdI2NjS5sEfHKbyTzFJkK 9tWNooA7Dc3j5agnZ4nYP8x+YMgvGMfJ3D4W4+9Qh1jxOLil4qXL5DhFWLEk7ix47pGU2M53Ftw7 atbb+LxtTo5chPceTzmPx06xZmNJjvjvJF3BLIYbymz7Au2ECwYmgMaF8hI4OfIL5oZM5jcknUSP Et+ilPQAPCug57Ax+PweSycVw49zZMCRBfCEqZ5v695T/rCqskP8t4Ze8NxxMcb7eJjTW3ztUubi zJLxXDs248RgRiU9R3pgE/5ixG3waoCvxgnn+hx5EZU4qHIgDMLA96YMm3ztFGn32866GNLJasbj MRk+iWLFnxp4oyOSyJpBIk77QBsAkf8AW9V9q2Gny30XSjAwrSBbVLto21AR2pQaftpNtAJuopdt FUGhRRRUIJTZBdbU6g0BzOXi5zy8ljLiyOOTEGMMkNH2lxVN51YNIJNzdyQaIR0rcgx1A1FWNgpQ AKFGdhPKjsJ5VJRQgwRIPCnBQKWigGsinrSCFKdRegE7S+VIYk8qdei9AQtAnlUZgTyqwTTDQpEI I79KlWNRQKcKEDYtNaFD1p9BoCE48flTewlTGmk1QRGFPKjtLTzSE0BGY1ppiU1IabQDOytL2l8q dS0AzsrTggFOoFAN7SmnLEopwFOAoBNgo7a06kJoBhjU00Qp5VJSUA3YtKFApaKAaUB60naXyp9F AR9lKOylSUUBH2E8qOwlSUUBH2E8qOwnlUlFARfTx+VKIEHQVJRQGTy2NI6RFYmnjSeKSaJCodo4 3EhVe4yL6ttjdhpRhwTz5OVn5MZilzJjJ2nKlkRQsUStsLLfYgJsSL3rVKg0BQKFGrGoFOtS0UIJ ai1LRQCWotS0UA21FOooC3SUtFQCUUUUAUUUUAUUlFAFFFFAFJS0lAJegmlNNNCiE00mgmm0A4U8 UxaeKEFppNLTTVAE000pppoBCaaTSmmmgCkoooBaKKWqApQKBTgKgACnUAUUAE00mlNNoAooooAo oooAooooAooooAooooAooooAooooAooooAooooAooooAooooAooooC3RRRUAlFFFAFJS0lAFFFFA FFFFAJRS0UAVHJJGmjMFJ6XIFMzMj6fHeX9YaKPielcyMTm+TeSbGkihhVivdmBYyMPxWA6KDpXO /I01Wq3WeTrTjTTtZ7a6fE6c/Cmbl8xWbwf8xTv4+fF25Iiu1lJMbg7vUhPy6VltDymSQMBYnexa TvEqPDptqW5WlX0ZtOPIteJN29WKxnzOpBW17i3nTt6eY++sKDC5teJyYZFg+rdlMKhm7dgVvuNr 361Q7HKRqYZlhGYSBGqljH6rbbnr41LctqpejXx69hXhrZv16eHTudXuB6G9Z3MSzRiExuUViVJB IN7XA0+ANN4SDkYIJF5ARq7NdRESVtbx3eNP5hQ2Jv8AGN1I+09v8zVq824m42uJjyM0ivKlO5TE +ZLizk4SzOblVJJ8TtuP0VR46ed8va7sy7GY7iTqCo/TTseUrxct+gJUf61v/WpvEKd80nh6UHwI ux/OK5qztbiU/wAZZ0dVWvK4/lCG4uTM2YoZyVctdSTYaE6fdWlI+yNn/ZBP3CsjD/xsfzb+y1aO c+3FfWxNgPtNa4bNcd2+jsTlqnyVS6pFLByJTkqrOzBrixJPhetNmVFLMbBRc1g48jJkBmPpDBlI /ZB2m/8ArK1a3JOVxrD9dgD8uv6Kzw3a47t5dc/PQ1zUT5Kpfyx8jK5Dlpu4scSSSySX7ePCLsQO pPw+JpmHzM8WSkGVHLiSOfTHONHHjsboTWnw+MqrJlEXeY7Q3iETTb/W3Gr02NBkKEnQSKrB1BHR lNwR5EUpxWsld3e55JflrVuiotqwV+Td0x1KMVO8C4NvA1k4/NSLlNj737i6hZAdrgdSpPW3wrW5 f/DL++PzNVV44n4iF3A3xuxjPjcs6n8hqcsvktFmttdxrihcdZqnuttNXHmWeFZV0DeHkajzpWjx ZGU2a1gfmbVX4ZycaQfsyED+qp/TScu4EKJ4s1/sA/5a6u79nc9dv1OSove2rTd9BnF5EjyOkjM9 13DcSbWNvH51o1hcVIwyIy5A336fsuNyD7iK3an9dt0h9G0X+wkryuqTEJA6m1G5fMffWVzWNy07 xHj1hZQCHExYWPhbaKzTDyk6oMFYWktulEpYAdPw7aX5bVttVJnTOopxVtXc7xGvgdR+amq6MSFY NbrY3rKzsmfHwYYHH8YRKZVj6FgLbVv5tVGFOYwJkfNEQEusbQliFYamN93W4/MaluZp4rKrG59h XhTWbQ7TtXc6X50gIPQ3qrmy7+PaRdN4X8rC9YEr8nAzZKY3cwk/FNG3rWwuzFOpA+FW/M6tJV3S t2Owpxbk27bYe3J1VISB10qrx2UZ4iHN3S2vmD0NV+YkF40vbqSPnoK0+VLj3rJlcTfJseDSuALk 0txa/hWXkM78OJF6xWLD+irWa/yXWgT/APhRW+u7t/l3fmqPmjp/Hev2KuKev8tj/c07i176UtYY ZxxsdzpNIzKP6I9K/f8AirWxHL40bHrax+zSrTk3OIjCt8yX49qmZy6/ImooorocwooooAooooAo oooAooooAooooC1RRRUAUUUlAFFFFAFFFFAJS0UUKFFFIaEMznJLRRR/tMW/qi3/AEqkx5YcXjsc v6QUW9tbsw3H7zVfnRpA56bmQfMjd+ZDRkYC8lxkEHekg2hG7kRAa6rttreuOfcvGu1Qd8e3SdNz kuwZUORcxG+3rpbrWNx+UuMxdlLbltYVZ4X8c/yT/p1Qx+J4/k2CZ0XeWNboNzLYmw/UZaw7Wv7T UKz3eRtVrT3U5dVt8zexcpcmPuKLWNiDWbl/+aJ+/H+davYPH4nH44xsOPtQglgt2bU9dWJNUMv/ AM0T9+P86105Z2VnXdWTnxRvtGm20GteocyNpcWaNfxMjBfnbT8tT0ldmpUHFYcmFFN/ucig3V2S 35Tf8lXuKUDFL+MjsT/qnt/9GsogRbo+ixMya+SErf8AJW3hoY8SFG0YIu7962v5a8v9dN2c/wAF t+p6v7DW1R/N7voZmF/jY/m39lqt8q1o408yT9wt+mqmF/jY/m39lqfzEyxuWc+iJNzeNupP5Kic cF/G0Fanmr4VkhliCQYrqP72NmY/MhwP+eas8jIXixif11LH5+n/AE1kR83jZLx44ZzbSMMjKBYe ZFaWQwPHwP8A9nIY2PkHuR+XaKzuT9xLE1X/AGmtrWxvMWf/AHFzEkEPFNL07ayP9xZqpYvNSZAW SKVZIy1iQBrbqOlaPGMkmJ2yAdpIYHxDa/prPy44486RI1CKGWyqAB+FfKt3dvb47Vs0sKEc6JO/ JW1U3lyzQ5j/AAy/vj8zVhDLWV3xVciSIXCsDYX/AFl8xfrat3mP8Mv74/M1UJoA/FQZAHrx3Y3/ AKDuUcfLXd9lTmq7clo6Vk1w2VeOs9bQaHFwR4+BFHGxk03PIerOxu5P21T5qRt4VRcohYfM/wDo qfiZLxPGf1DcfI/+is7lsuKGaWeQnYjAaAsbiw6D41eS6fDXxhfIzx0a5reEv5k2Si4ueNvRRG/9 X0W/5lbNcrDy8GfNtVnaQLe7qV9IPmQPOumxn348bXuSoufjbWtcFk7XjE5Jz1arScxgkrK4f+9b 9z9IrVrK4f8AvW/c/SK3yf8Ak4/Oxjj/APHyeVRZk7vKhT0VkYf6oD/oqzyig4hY6lGUr8ydv5mq q0hXmGJ/aVR8mRR+mrfJEfSMD+sVA+YIP6Kwvs5vOxt/dw+VStuB4cj9lgD/AFwf01Pxf+FIP7R/ MKrJrw7N+0/9mQJ/0as8X/hj+8fzCnH99P8A1oX+y/8A7CvxUfZyXhHSNCtv3SBUXKKcjKMIGu2y keaqZR+UVJx8hfkJGHRkdj9rLaqz58GNmnIkdPUW2B2C9T1F/IVzle3VP7Xd/JHSH7lmvuVF82Xu M2TYskLepSTcf0WFqyt06wHH3XkD9sX6GUHtA/a1X+EkS5SNg0ZQWYG4O3Tw+dOCIeYYEC24Nb4h A1/vpG7j4/8Ads+ZJ28nJ/t3/IdyUSQ42OiaJGRGo+AXT+zVzBFsOEj9ZA39b1fpqDmEkbCLQoZJ Y2VkQeJPoP5Gq3FGIokiXoihR8gLV6FWOSz/ANKODtPHVeLH0UlFdDmLRSUUAtFJRQC0UlFALRSU tAFFFFAWqKKSoAooooAoopKAKWiihQopskkcSGSVgiL1ZiAB4dTQJYjI0QdTIgBZARuAPQkfGgHU 1jSk0xjQhT5XEfMw3ijYJMLPC56B11F/geh+Fc9B7kXC3Y+V/usyfjgmB0PmrDQg/CuqJqOSGGW3 dRXt03AG331zvxOzVqvbZYk605FVOtluq+hk+3MqLLGRLCGMXoVZCpVWI3X2362rIi9y8dhyMonC yL6HBRzYg6/q/Cuv0AsNB4CmiRGZlVgWSwYA3IJFxf7Ky+D01StDrOY7lXN6rN1lWjHkZ/CcxFyk crxOJFiIBYKV1I6eoCqudm40fOw4jPaeRo2RLHUX87W/VNbdNWRHBKMGsSpsb2I0I+ytvjbrWrtL Tme5lciVnZVhNRA+9ITSXpK6HM5/kZIF5NsJ3CyZLL208SHAUt/W3V0FRSrjKRPMEBWwEj2BFzYD cfialrFOPa7P/Jybvfcqr/FQc9xnI4c/LDFik3TRF96WYW2hlOpFutOfkMTJ5z6JJL5Cyi6Wb/qr M3qtbovnXQUhdFdUZgHe+xSdTbrYVj2Iqlu0tu0+ht80tvbrXbr9SDklBwJieiL3D/7P1/orM4fI weYwsvFik3oNu5gCpUtfaw3AagrcVugU4Ct245urTommu5ivJFHWNWmn2OSPJZHETdnkN2PKPSs4 UmGUeanUfMHpQnMQZ2aqY5bKnlZQwiUkAaDcxtYACutdEdSrqGU9QRcU1I44l2xIqL5KAB+SuX/H zCs9szB1/wCRj7VuiJM33Fm42HhJJkv20MoUGxOpVj+qD5U7jTFm8Mvba8U6yKGsRozMOhrRpK6+ 363edVtg5b/QqRo5k53guWxJs84qSfx9rB47MLFevUW0o4fkMTkeSJgk3tEGlfRgAT6P1h/SroHd EsXYLuIUXNrk6AfbS1ivDG1bp2OdDduadz2xuUamdz0kcGCMiVtsUDhnaxOhBQaC/iwpeDzYMzAW XHbfGrMu6xGoN+ht51oUlb2evfPSIMb/AEbI6zItYfAZuNk5E0cL7ngXbKLEWN7eIHlW3SPIkaF5 GCIurMxsAPiTS1JtW0/bP1FbxW1Y+6DI51ZcaRORRWeJV2ZGwXZQCWSQDyFzf/kqhJz38yMeLhEZ OQ/4FUEKP6ch8AK6empFFGSY0VC2rbQBc/G1Yvw7rNqzSt9y7m6822qTqm6/a+xRzliweGZWb+Hj om5yNSFK3Y2++sKP3JjNGcfEaSdmP91FGxYk+GqiutpaX4dzTVtuNuOwpy7U067s7s9zI46GbCws jPzQI5nQu0d7iOOMEqpI6nqTVbiMfiuYjkyniTKiUiNDInQj1NYOP6QrdeWJCFd1UkFgGIBIX8R1 8vGnKysoZSCpFwRqCDV9qs17UTx5k920W73az5GDFkYOBzacaloST/BhAIG1lvpYW/FepfrsUe4/ oy/+8NqEsena3dbW6Ctmins+P89+n0Hu+H8Nmv1M7muSTj4Y3kk7SyNt7ltLgXtfwvVvByPqsOLI FyJVDAkWuD0Nvj1qV0R12uoZT1Vhcflpa0qve7ThrQy7LaqxlPUWiiitmAooooAooooAooooAooo oAooooC1RRRUAUUUUAlLRRQBRRQTQGN7w/8A23nfur/bWsfi+XaDJ5LMyVMmRjY+PBNGDYtMjvBa /hua3310PN4L8lxeRgo4jaYAB21Aswbw+VZ+R7dWXJ5KVZe2vIrERYapLEdwf4+oA1yvW2+V2/c6 0tXZD7/sX+O5CXL78WREIMrFftzRq29dVDqytYaEN5Vm43uLIlKtPiiOKYT/AE8iybtzY5bcrLtF rhTar3G4U+MZ5sqRZcrLcSSsgKoNqhFVQSTYBaxuG43Jy8WKaWZOxCcsY8YUhg8skkbF2vqAL2sP Gq3f0rrn8+oSr6n5fl0J29yzrg4+U+PGjZY3wq8u0FVTe9yV0N9FHjercHM9/KRERVgOOmUzuxD7 HBIKJtIYLax18ajl4ef6PjlglQZXHIqK0ilo2GwRuCoIOvWnT8VkZGdjTTSxmDHRgVVCrsXTtuu7 dbYetrVV7nnp2+JHs8tf+hXbn80Y0GT9EBHmSpHiDuephIrspYbfT+Eff8KJOXlx3yAuJH9UJ8aC QK1t7zIh1fb+rusDToeHzkjxMeXISSDAmR4DtIcxosibXNyCfUOg8Kg5jCmhd8hJFDZediNFcEhS myMbhpfUXqPelOfp2KtjcY+vckk5nkJTixwxRxznKfGyY3ckBkQvZWCHQjW9qcvLsoMOHiIcmXKn hSMMEVuySXldgvU28utKOFy1SGVZozlrlNlysVPbJdTGVVQ1wAtra0HhcpLTY8yJlR5M+REzKWTb OTuRgCD0NPX4/Qejw+ox/cMzxxyYmMrh8V8thI+wqI2Cumitc+Fa+PMs8Ec6ghZUVwD1swvWVHwJ iRY45QVXCkxLsNS8rBy/yuKs8amfDK+LNtbFgihWBwCCWC7ZBr11F61V2n1dSWVY9PQyuUy86fG5 RJEQw4+RjpEFY7r9yFgNVA1v1vVyTn5YonSWGNMtMj6YKZbRXKd3cZGQWG34dadkcLkynORZUEOZ LFMt1O5WjMRIJvaxEdLkcHNJJNPFKiznJXKg3qWUWjERRxcXBF+lZi6ban8NlmjSTj8QWk5bHPED lmBWHtd4r1PT8PzvpWdkz8pJn8ZI+LHHlE5HbhMpK7TGpuzhLgi50tWtPg/Vca+FksCZYykjxjaL kdVXW1j0qCDjuQbIw8jNnjlfEMoJRCu5XRUF7lvVcXNWys4X+35zkzV1Uvz/ACwU391RLFiyiJQs 8STzK0gVlV37Voxb1kG58NBVg85kxZM+Pk4qxFMeXJhAkDMVi8JFA9O696jxeAysQYbwTRdyGEY0 /cQurIGLhk9QswuarTcJmYsc+VJPHKscGWrHYRI4lG/czbvxaAfIVmeTr+hqOPp+pYX3JJHjSy5m MIZFgjyIVEm5XSVu2t22jbZiL0sfuCSaOARxRmWWeTHYmQ9rdGL+iQIb7x+HQVXxODnzeO35c6l5 sWGLHMaWCKhEylgWO5t1r/KrWZxXI5uAmLLPAjM15mSIgAAgq0XruGFupqp8kTnTwDXHPx8SXjsv OyOQz45lQQY8gjj2sS34VbptHUNfr8KhHOTjNaJ8YDFXK+j74f1dxlVkum3oS1utWsTCnxs7MmLq 0GU4kC2O8MFVDre1vT5Vl4WDkZeflkyquJByJmaPad7SRpGV9V7bdR4eFV7lCzMsi2uXiIRInNSZ UMU0uGhhbKTHQs24iTumPeoK/qixB86mk5yRI8vKGODg4peNZS9meRDssF26KW0velThpV4/GxO4 u7HyhklrGxAmabb9xtTX4SdoszC76jByi8iLtPcjkc79G3WKhtelT1/Tw1L6Pr46DU5+SSGPtxRG Z8hsVj3T2d6rvG2UIb7xbbpWjnz5MEIfGhWZybHe4jRVsSXZiDoLVQy+L5LL436OWaAPI38VliIU LpZk9dw4IverPJ4M+XFAsMiqYZFkKygsjhQRZwCt7E7vmK0t0PXRRoR7ZWmrnUpD3DkSw40mLjKz ZEEs7K8m0L2SFYblVr/CqvO8vLmcTPHiwbo2xI8jIkZ7GMTaooFjuOlW8TgsiBIVeZH7MGRACFIv 3mDKep6WqHI9uZjYn0+PkRoJcWLFyt6lrmEWVksRa96w1yOr1yvDsaT401ph+Pc1c/P+ifGLqOxN J2pJCbbCVZlNvG5Fqzf+Jyv0xkhVO8kcsqmSzKk79uPYu31n9ZvKtLlcBOSwJcNjt7lir+IKkMD+ SoJuLmXkI8vEeONO2sM0ciF/Qh3KU1Fm1Irdt84eDFdkZ1Kzc/lCLMyVxQcbBleKR953HZIEYqu3 wT1fkrQ4/P8ArvqHVQIoZmhjcG+/YBub+tcVVkx047iuRbIIkjkbInYdPTKWbZ+W1T8Hh/Q8Ri4x FmWMFx/Tb1t+U0ru3JN9JZbbdraXWEY8vJyZebjZsmMoxRj5jY4ZtxlRQl967fTe3x61pYnKl5oo FhSGFcaPIe7EEIyk/wANAliqkWOoqrH7ey02RHIjbGx4ciDHXaQ4WcC283IO3pVgcNO8+EZZUMGH F29qqRIxMfaZd+78B69KzVX17tToVumnZPuRtz2YuJFmNhgRZUsaYq9y7usu7aWG30nQffTv5+yc hHgzRIr7o4prSXYSyqXGxdo3INLn40RcPnLBjYsuQkkOFNE+OdpD9uLcNrm5BNiBoKsfy6ePlZMy GSMQ5Gwzo6bn3RjaDG1xa4ter68a9J0+JPRnTrGvwM5vc0k+HmyYyRiSKA5GOd+70Bin8QBfSwtf b8etbmI07Y0bZAUSlQWCEsv2EhfzVlw8HkR8dk8aZozjvG8WMwQh1D3I7jbvVt6aVexIuQR1ORLG 0QiC9uNSP4gJ9W4km22lN0+qdBbbHpjUt0UUV0OYUUUUAUUUUAUUUUAUUUUAtFJRQFuiiioAoooo UKKKaTQgpNNJpC1NJoUCaaTRekvQAajiiigjEcKCNASQqiwuxLH7yaeaSqQDSUUUAUyWGKUKJUDh GDrcXsym6sPiKfRQBRSUtAFLRRQCgUoFAFOAoBCVVSzEKqi5J0AFEU0UyCSF1kQ9HQhgbfEVW5fF ky+Nnx4j/EZbqPMqQ237bWqrDy0ZixjjxKqTRTOydNrxBbrYfE10rx7qSsuWo7JKfrky7Q4ekGqT UciJIjRuAyOCrKehB0IrKk5nLCpJHAjoMWPLmuxBCtfcq6G9reNOk5eZcmS0StiQvEjybiHtMqlW 22toWq/8fk7L5r8dSe5Uvxy4qhIYnQAExoikdUGqAf0bdKkrHwsgRTCMord3MyhvPVdu9rj7qIuf MsE8oRCY0WVQjbrI7bT3LDQr1Iqv+vefSpSj6uEFyLq/xqbFMjhiiLmNAhlbe9hbcxAG4/Gwpncn +l7ioskxW6qrekk9LMR0rOHMziEkxI8y5C45EbXRiwuCrW+ysV4rWmEnDjU07pa9TWprSxq6ozAP JfYpIBawubDxtWcvLuM5MOVYw24RPte7bym/cqkA7PC9Ozv/ADXjf3pv+7Na9myaVsTW118E2Teo ld1X6lxsnHXfulRe3YSXYDaW/Du8r30pXnhRiryKrKpcgkAhB1b5DzrA5MBl5lT0L4o/sVH28tcj MOYbynj5lH7sZEYP+tbd9tda/wBarqnujTHnWtv1MPlacR+Ja/Q335DAjO18mJCQCAzqDYi4Op8a cMzEM3YE8fevbtbhuv8Au3vWUYomyOG3Ip3I264GtodL0/ji38yzAMfevfN8i6+j0DSx9X3Vl8NV VuXirtql/Lb+hVdzGNY+kmnFlY05IhlSUr+IIwa3ztT0dHUOjBlPRgbiuew0SLE4vJRQJmyXiZgN SjtLcHz6Vocej4fBgah4kkYX63uzU5OFVmLT6tiT82n+QryN6rpP5FqeXj5o5Yp5InjS3eRmWw10 366a+dTNJGrqjMFd77FJALWFzYeNqw8nHhj9sdxUAkeCMs9huJcq7XPzq5yDbeT45utjObf+yNT2 azhvXkX/AOdZLvfX/S//AJOC99VjBnQypuiG6RdwuoHiwvpSpNDISsbq5ADEKQTZvwnTzrIx4Yv+ HZJyoM0mPM7yWG4lwxa561J7ds+PLMf7xnVGHksaKqD7taW4aqt7Jv0W2fEiu26qPuUmkcnHAYmV AEYI5LDRj0U/HWkOZiCbsGePvXt29y7r/u3vXP5Urg50QiYo2ZGTKLbQbpodb1ewi383zQMfuL3V vNdfR6B4H1fdWn/XSq7N/wAd2q/0/uRcjbiOsfn+xpx5GPKzLFKkjIbOqsCQfjbpSQ5mJOxWCeOV gLkI6sbfYaweJs3LAbe2UbJO8/8AW3cDaP3etXPbZb6CK+P21Cm0919fqPl6vvpycCorOW429l90 /PQteR2aUaz9I/c2KKSivMdBaKSigFopKKAWikooBaL0lFALeikooC5RRRUAUUUhNAITTCaVjTCa FAmkpKQmqBb0hNITSUILSUUUAUUUUAUlLRQBRRS0AU4CkApwFAAFOooNAR5CzNEywOIpdNrsu4aG +ouOvSsv+SSqiGPIAnvM0rlLqe/bftUMLWtpWsTSVunLaiirS+C8jLqnqYTcfM2YMFJgirgxQzNt uWQM6tt10Jp6YT5HI5kQkCYySwGSLbctsjRlAa+guNa2O3H3DJtHcI2l7DdYa2v5UgjjVmdVCs9i 7AWJIFhc+OldP+RbP+2NFrKbf0J7a+v0KMfFlJo5DICEnmmK26iYMNvXw3UsGBl4+K+MmQrIoCwb o72UG+1/V6tNKv0Vh8t3q09NUujn9S7KlEccV4r+XrKQdmzu2+3pfp4W8qhj4mZW3PMhvPHkWVNo GxdpUeo6dLVp0UXNdTn7m28LVjZXGNMFRMOaLNknilCwzENLEVuSwXbdWvpfS9NzsOeebHnx5Fjk xy5G9SwO9dvgRVyiouS0q2JS26LSIz8C7VEeMmXLxE00eWJJl7mWYSWCkAGLbfS/jtqbL45sieWU OF7mK+Na17FzfdV6ite9fGdPDwS/RE2V7fj8MpfQHuYL7/8ABKykW/FdO39lJj4WVBlzSrKhgnkM jxlDu6W0bd8PKr1FT3bQ13W3TpM/mNq+s/oZmFxEsBh784ljxi7Qxqu0bnJJZjc3tu0q7BFKMcRZ LidyCHfaFBBJ/VHwqail+S13Nn9EvxqFVLQym4jJbBkwDkgwFdkIKepQGDDcb62taplwst8nGyMm ZHbGZyAiFbh02W1Y1foqvmu50zP8V/JQ/mNlfy69tDNTi548ebDScfSukiRIU9S9y/Vr6hb1LhYD YkrOr3R441dbfrxjbuHzFXaKj5btNN/drhZCpVR4aGbLxLOmQncA+onWcG3Tbt06/wBGpIsLKhzp p45U7M7hnjKEtooXRt36KvUU968NSmmo0Xh+w2V1M2LiWjeGQSjfDPJNe3VZb7k61JxeFlYUK48k ySQxghAqFWuTfU7jV6kpbmvZNNpp+C8f3CpVOULRSUtczQUUlFALRSUUAtFJRQC0UlFALRSUUBdo vSE00moBxNNJpC1MJoUUmmGlJppqkC9JeikoAootS2oBKKW1FqASiltSUAUUUtAFKKAKUUAoFOAp AKWgCkJoJppoAoopKAKKKKAKSiigCkoooApKWkqgKKWkoAopaKASilpKAKKWigEopaKASilpKAKW kooAopaSgCilpKAKKWigCiiigEopaKAKKKKgLJvTDeiioUQ3pKKKASmmiiqQKNKKKAWw86LDzooo BbDzo+2iigEpNKKKAKWiigAU4UUUA6kN6KKASkoooBKKKKAKSiigCkoooAo0oooBdKTSiigF0o0o ooA0o0oooA0o0oooA0o0oooA0o0oooA0pNKKKANKXSiigDSjSiigDSjSiigDSjSiigDSjSiigDTz osPOiigDTzooooD/2Q== --%OLATTACH1-- From oktdjlna@alchemy.net Sat Feb 26 15:39:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29882; Sat, 26 Feb 2005 15:39:08 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D58ir-0002Ef-Vj; Sat, 26 Feb 2005 15:39:35 -0500 Received: from 162.red-80-38-160.pooles.rima-tde.net ([80.38.160.162]) by mx2.foretec.com with smtp (Exim 4.24) id 1D58hY-00053j-1h; Sat, 26 Feb 2005 15:38:26 -0500 Received: from TKQBV-LM83 (80.38.160.162) by 80.38.160.162; Sat, 26 Feb 2005 12:40:21 -0800 From: "St. Daryl Osp." To: simple@ietf.org, simple-admin@ietf.org, simple-archive@ietf.org, simple-web-archive@ietf.org, sip@ietf.org, sip-admin@ietf.org, sipping@ietf.org, sipping-admin@ietf.org, sipping-bounces@ietf.org Subject: Absolutely No Doctors Appointments needed Date: Sat, 26 Feb 2005 12:40:21 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="%OLATTACH1" X-Priority: 3 X-Mailer: RGI Mail v3.2 Message-Id: X-Spam-Score: 27.1 (+++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 72be645574b2b4b84446d27f730bf563 This is a multi-part message in MIME format. --%OLATTACH1 Content-Type: multipart/alternative; boundary="%OLATTACH2" --%OLATTACH2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit %URL %PARAGRAPH --%OLATTACH2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 3D"" %PARAGRAPH --%OLATTACH2-- --%OLATTACH1 Content-Type: image/jpeg; name="%ATTNAME.jpg" Content-Transfer-Encoding: base64 Content-ID: <%RNDATTID@%MNAME> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAKAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBcSFBQUFBIXFxscHhwbFyQkJyckJDUzMzM1 Ozs7Ozs7Ozs7OwENCwsNDg0QDg4QFA4PDhQUEBEREBQdFBQVFBQdJRoXFxcXGiUgIx4eHiMgKCgl JSgoMjIwMjI7Ozs7Ozs7Ozs7/8AAEQgCJgHCAwEiAAIRAQMRAf/EALsAAAEFAQEAAAAAAAAAAAAA AAABAgMEBQYHAQEBAQEBAQAAAAAAAAAAAAAAAQIDBAUQAAIBAwMCBAMDCAYFCAcGBwECAwARBCES BTETQVEiBmFxFIGRMqGxwUJSciMVYpKyMzQH0YJzJBbhosJDU7MlNfHSg1RkdBfwk8O0JjZjo5Sk xHUnEQACAgEDAgQEBgEDBAMAAAAAARECITESA0FRYXEiE4GRoTLwscHRQgRSYnIU4aIzc5Ijk//a AAwDAQACEQMRAD8A6bKwos58eCaSSKJplDtC+x/UGRRf95hVjPhj4xGQMzxY8QIZzdiFXqx8TpUO QWETOgu8f8SMf00O9fyip/d6ibERYjrnhMeMjx7zqn5nrywttnGVB6Je5LoyHj+IOFw2NlPLLLPl Kkk4lbcFZ13EKPAVFx/Ew8pyWZlZM0yRYDRJGkTlULBe8+8WN/xCujz+0+JLAn4scKdvkPD8lZHB nt+38rK8c3ImcfLf2F/5sdadErJRhKfkZVm6t9W4+ZVwOKhzc7MzJZZlbECduJHtGboT6ktrUR42 LleTxsOaWaKIxyyEwPsYle2Bc6+daHDSJGvMSObIiozHyAjYmqHt7k8HO5+EYsolKQTFrAi1zFbq BWUq+hf5PPjk1L9T/wAV+gclhpPlxYBeSOKTKETNG219t26N9lTTe0fb8DmOXkM1XHUd4+P+pS5X /neP/wDPD87VH7h5GOHmHxzFMzWQbkjZl1UfrDSnpSbaT9UZGW0k2sTghzMLHzM3GwFlkXHlyNnc jba5UI7D1W+FO5zDPHwzwIzFUhJjkY+ogKdSR43FLjf+bccP/iP/AMKWtT3fCsnFzzpq0KOklvAM t9fvH30VU6WcZTLui9V0aM7J4bG4rFxxBJLL39zuZn3m9k0BsNKozY6ZQXHkkaGN3j7kiEhggdS9 iP6INbvPm2Pg/uN+ZKw2NS6Ss0ljBaNuqbeS9j+0fbmUZRBn5jmEAyWmOga9uqf0TVDk+N4nEwxD x2VNN3nAkaRyWUEqvpO1bVqe2fx8r/s4vzS1h5B9A/fT+2tW23amqpbpFZ3P1N7YNHlOJxuIeLGx 3kkQoWLStva5Y+NhUEXDY2JwGLySSSyT5nbMgkfcoursdotpVv3ryGJi58CTyBGaK4BBOm5vIVJM QfZ3FkdCIv8Au3qutd11/iseAVntpn7nkyON4dudypzkTNj8Vg+mdkO1pJLbiu7wCjrWl/w9xRxp J+Cmc9jWXHkZmBHmu/1A6fI0/EX6X2VERo+Y5kc+JMsjP/ZAFR+1pzHzKxX9M0Mgt/SUowP3Xoq1 W1NZspb65DdmrWT+1wl0wZmNxs3M8lFxqSNBBtabKlTRu2pChVPmxNXcrjPbeFA44uSQzoQrKzuy tbqfVp91aHDCPE9yZMBFg4kjT7GDqP6oNY2fith5kuO36jHb8VOqn7qm1Kswm5ansVNu+rSSTS7k /Fe2uLz8Gfkc/JyYtszqe3JtQKpAHp2nzpZ+L4HBgL8dlTZEzMAVlcsAuuouq1a4+Tt+0M59rPaZ /SgLMfWnQCsWCbvKWEckYBt/EQpc/DdR7Uq4UtTIrLtabPFognBq1xftvjc/Dn5HNysmErM6ntSl VAUgCw2nzqmK18CeLH9pZ00zbY0ncs2pt6k8qlEm3KmE3kXbSUOJaQ1vbsmNCcjBzDn4gvuWXaZF t4h0A3fEEVUweHj5rlXx55ZooMWAOew+wl5Hst9D4Iav+z8iWeDkc51ZMBlRccuLbtgkMjgHwO4D 7KbwE30mBzHLWtaZY1v4rAij+07VpVq9riE5bXkYdrLcplqEn5iZeOMbJkgBJCGwLdbdRemcZw0a 8Q3KLLK80zuZEd9yALI6DYttPvq/z8ezOD+EiA/aPT+irftxUfgYY36SNMtvO8slWtE72Xg4I7NU T8VJicbxEGfyGVkTSzKcNImjjR9qEt3L7ltr+GmRcDw84fI5DPyYpZZbKkUjKoDEKigbW8TWpwkT Q5vLxN1RIlP2CasrJPpj/wBvB/3qVmElVtJ6zPmalttS1oXm9qcHgzo75uZ3Es6o8xZT5XG3ppVb jeJgfHzOVaWYzLK8axl/4QAKj8Fq0+f/AMYn+zH9pqi4r/yHN/8AmJP7S1pqu5qEoTMy9qcvLRnY fBYvL5uW2VPkRLjpFtEEhQeruFiRY/s1OvB8Fhhp8bNyZpgpCJLIWUk/AqKscC22blW1NooTYanQ TVkYvIR5bMqRTJtG4mSNkHW3U1n0qtcKXJrLs8uFA/B4SHmZMrP5WaSPjcRzDDAjFA7Lbe7ldTqb C1T5GNx2KEi453eGxNpGLEG50u+taPHRCfhsrFjHrRzIqjqdx7n5W3Vjk0aSSwsqZ6hNtvOj06DZ HVEZ2NlUEk/AUcb7dxMzCXmfcMsix5HqxcRGZAsZ/ATs1LEa6VX5BDLiPCL3m2xadf4jBP010HuY qjY2Og2xxodqjoBoo/s0qlltTt6eLK25VU4nr5GNykHG8bAJcOZ5sYKznuNuZbfq3IB++nYPtjAG HHyXuWaTv5VmixkZlWNTqBZPVuA61WeAZU2LisLpPkwo4/ob1Z/yCtn3VKWz0j/VjjGnxYkn9FEl mzSxELpIcyqpvMtvqUuS4ccescuPKcjDm/uZG1YXF9rN4/A03h/b8Wdh5nICSX6qOR444938MhUR rbLdda0MI/Ve1MiNtTiyvY+VmEv5nqX2tkJjcPmTv+CPJYt8tkV60q1dl2anyI7WVXnKtHmc1FiP yfI4vFxsyCdt+Q6GzLDH6nsfAnQCrHuDjYONL4eO8hRYxZ3a76/0tK6LF42HhuTzOTkIb66aHGw1 HVY5Cu4f12J+QrI95f46X/ZrUdIo2/un6FrfdfH2x9SbL9n+2cNlXJzcuNnF1BlJuPsQ1mZuPgY0 wh4+VpsdVFnc3YnxuSBWr73yO1lYw7Usl421jQuBr47awxewJBUkA7WFiL66g0vtTaSSgcctKzs3 PQjmlWGJ5X/CgLH7K0sH2vxyYUXI+5ZpO/lWaLHRmVY1IuBZPVuA61RWAZWTi4rC6T5EKOP6G8M3 5BW37ulL8ikd/THGNPixJP6KlUobamNE+5bNtqqcTltFTlOGHHLHNjynIwpv7mRtWFxfazePwNM4 f25xvKY+bnZ8+REIJu3/AApNqhFiie9tp8WNaWCfqvaM8batiyPtPlZhL+Z7VHwTbfbnNNYtaZzZ Rcn/AHeDoBWttZWMNTBl2ttanKttkoZmBw2FGi8ZkS5BdiZO6xYjQWtdVqbB9q8G3D4nIZ+XlRNk orMRKdu5husAFPlWXDIZU39t4xcqO4pQkix03fOtvOl7Xsvim2PJftC0alz/AHb+ArK2uW0oS06G rStqVnl6lDMx8DGlEOBK00CqLO5uxPjckCq9C3ZVYqybgCFYFTY+YNOC1Da07iAU4ClApbUAlhRS 2ooDaJq3DiNnYnDFR6MHIPd89sCSxqftdVqma0+Bl2R5cbdEcSg+G1lA/OhNb443Q+v6ZPPfSUJD IZeXzoev1ENl+HZJT/8AFqqIWwvb/G4TArIsSGQHrvCjff8A1mNMwpWHK40n7bujn4OrH+2FqfnJ d2WE8I1A+060maN9Za+eRHqS8J+WBnt5tknKORuC9s2PjaM1ZweXSbkY8RcZI+5HI/cXqNhTTp47 qq8ErBeVYghWCbSRobRm9qg4dWPOQMASqwzAtbQEmK1/uq1s0qJdf3Fkm7vt+wzJ/wDO8f8A+eH5 2rV5LmMnEymhjVCqgEFgb6i/gwrLnVm5yHaC23NubC9gC2tP53j/AHFPyUkmBjwyY5C7Xkk2tcKL 6fOonZVttmd3QrVd1d0fb1KuO5fmOPY9WyST9sctbMoTKzuS4qU2TLiG34N21Un52t91Y+NBPHzO BHIv8SOf+KF1A/hSX18rmrPJ5BxeebIF/wCEyMQOpXYoYD5qSKlXFc/5Z+RbKbY/xx8yf3Kpjiwk PVVcG3wCVgk1v+6yCMUjUHuf9CueJqcv3v4GuL7F8TX9sfi5X/ZxfmlrCnPpX99P7a1u+11a3KsQ dpjjAPgbCW9YUgZtqqCSXSwGp/EKW+yvx/Mtfuv8PyOv5vl1wMiOM4yT7k3bmPTUi3Q1S5jL+t9t 4WXsEXfaN+2NQt0c28Kh93/42H/Zf9I03LVl9n8WrAqwEQIOh/u3rpazm66Qc61SXG+rY+YX9nYQ XpFsQ/NNyH8oqh7bu3uLGUfqxTOfkAi/nar/ABP/AIhweTxSMoyEu8CtoDc7/wC1e/zqP27xmdxD 5nM8yi47CPsY8AdXO2+9juXS7sBasxLo+kKX5Gpit69ZcLzKfKZDR81PNEbPHNdT/SQ/6RWl7gSP P4/H5eAdRskHkCbf81risEY/LcjlSnCiWeTa00iM2wsSwFlY6X9XjW1Fj5nGe1JYOT2rlZMpZIVI bYCykLcXBsFvUrL3YcOXPiW0J0h+pNKPAl9v5UmJ7bycmMAvHPIQGuRqyjwIrO5HmsrkURJ1jUIb jYCOvzY1d4jGzJ/amXBioGyJJn7Sudqn1KevyrKbh+cxImm5CGKOIWAMb7jc/Clt22qUxtz2Fdu6 0xu3YIxXQe3pxje38mcoJAmRIdh6HVRXPitvi1Zfa+ZuBF5nIv4jcutTj1f+1l5Vhf7kR53OZWZG Y2tFD1ZV8beZpkS5EPsvFEWLNlyZzmWSOFdzbZmebcfhawrLze6cOZYVLyuhVFUXJZvSOnzrqeSy 5uKhxMPEYKI4gpuAdFAVevyq1c7nZvSPmZso2qqWs/Ih5ITScXx+ROjJMY1EysLMHZASGHmCDTMG Rova+PKn4o5ndR4ErPIbGpjPPn8BJLkeqaKVrta1wG9PTyRqgx1ZPakIYFT3HNjodZZCK11bXWkm eiT6Xg148ePuZXIRG6ZsEZA/cEmv2q4rlcg+mL/bwf8AepXQ8LkGTjJoT1g3AfusCw/LcVzsoZzE qAse/CbDU6SoTU5GmqtdZHGmnZPobXuA/wC+J/sh/aaoeKP/AOn80/8AxEn9pak9xG2an+yH9pqj 4xWX27mFgRedyLi1wWXWr/O3kx/Cvmhfbblcnk3HVY4SPsEtMy+ZycqAwyKgVrElQb6G/ixp3txJ Wfkyi3LxxLGToC1pdL/bWanFe5IyZMzHgjx0Us7JJuYWHgKk22Viesx5liu+0x0gt8XmjEzFdjaN /RJ8AfH7DRzmJ9LmsVFo5fWn29R99Zbcd7jzYH+ixY5YpWaJZWkCFB03Mrfi6/q/dW37icL9LjM/ clhj/iP5k7R/0b1FOxyniGviXG9Q9ZT+Biva8ZPRJYnPyR1Y/mrb90g/VQnwMf6TWGwDKVPQix+2 t3l4c3leMxs3jo1ycmMbZYS4jvceqzNoCCPHwpXNbLyZbYtVvTKMbEsOQwmPRciL/nNs/wClV/3O COTJ80Uj8orP/l/K4MEU3JbI8iaRnjhQhu2qbNt2GhN9a1vcOLyHKY2Pn8PEmTIybHjLhCviDdrA 7STcXok9tlDnDjqG1uracOVPQj4Nre2eSc9GmlA+xUj/ADik4b/9tcn/ALd/7EVLkw/yf27jcOzh 8l/XkEebMZHP9c2FHDqy+2uSuCN0zkX8Rsi1rS1S7VyZ6N97qCq/JvlScPim4GPkQhyfEhwq/ctJ 7y/x0v8As1qpiKzchhbQTbJhJtroHFzV33grNnSKoLMY1sBqTWW26Oe6NwldJdmbfPc1lcbNEkCR sJFLHeCeht4MK5XMyZMzJfJlADyEEhbgaC2lya6D3VxnM5uRA3GwxSoiEOZH2EG/hXPz4WbhlYs1 VScruZUO4C5Ntfsq8jtL1j6GeLbCiN31F4+y8nhOei5Ef3s2wf2q0fdSkcqSfGNSPyispSVZXXRl IZT5EG4Nb3uHEz+Vx8fkOHiTJkZNjxFwhXxBu1gdpJuL1F9tl5M1bF6t6Q0RcEbe1+Rc9GmmA/qp H+cVJ7XnfG4flJ0ALxZDMobpcY8HW1qbkQfyf29jcOzh8l/XkEebMZHP9Y2FLwKMvBcvcEBpnKk+ I+ngFx9orSw6rqq/Uw81b6Wt9ChyXK5PJ9vvqi9rdt2Aj8Vr33MfKtjE5Cfj/avGzQqrM0caEOCR YoT4EeVc8FralRl9pcYrAqwEYIOhHoapVubPrBq6XpUYkzM3KlzchsiUKrsACFuBoLeJNQ7afjcZ zHI5ZjwTFFBCgeSSa53MxICDb8utPj4nmszkJMbEMMUWMP40ktzufcy7F2/u9azl5huTU1WJSgi2 0oWpU4nmszkHx8QwxRYwvNJLc7n3Muxdv7vWlkiaKR4m/EjFWt5g2qQ+wlaSRbaKfaigLQY+ZqSP ImjVlRyqyCzgeI/+xqMUV6oR5JYLJIjh0YhlNwR502aaWVy8jFmbqb0GmNUhdiyxBk5EasqSuit+ JVYgH52qJcjIibdFK6N0urEG32UrVE1IKjN5zOzYcZ54ciWOYeoSK7Br+e4G9cJL7q9zhyBzGcNf /eZv/XrtPcH+Ak+VebS/3jfOt1SMXL3/ABF7g7nd/meZ3b37nfk3X+e69I/P87K5eXkcp3PVmnkJ Ph1LVn0orULsZl9zRk9w8/KFWXksuQILIGnkIA+F20qM8zzH/v2T/wDev/61VKSpC7IsvuzRh9w8 /EGWLksuNX/EFnkAPzs1NHMcuGuM7IBGoIlfr/WqktOGtzSF2JL7svS89zuQ4afkcqVgLAvPIxt9 rU9+f514lhfkcpokttjM8hUW0FgWtWcguaf40hditvuWV5vmYZRJFn5MbrqGWZwR/wA6pcz3R7jz ipyuSyZNv4R3GAH2KQKzWNzekqwuxJfcv43uDncWUS4/IZMbjxEr/lF9afl+4ufzJO7k8jkyP0F5 WAA+ABAFZ1qWkLsJfc0IvcfuKFNkPKZkaddqZEqj7g9LL7j9xTJsm5TMkTrtfIlYfcXrPtRakISW /wCccv8A++5H/wB6/wD61SL7g58RGEclliI9YxPJt/q7rVRtS2pC7Ibn3ZaHNcypDLn5II1BE0lw f61Pl9wc9M26XksuRgLAtPIxt5atVK1Jam1dkJfcvL7h9wLGYk5PMWNvxIJ5Apv5jdatX257g5t8 +KDI5DIkwo7ySxSSs6bV+DlvE1zlq0uFQPK8JJDToVUqAT6SslgCR+xWbJQ8Fq3uR7XjgRB3U7A2 hC6A/MC1Qv2ozvCqCDdbADWq3HyscCAsxJ7a/jPq1A61XzMopfcen61eK1oO6q2xnI5kjlnd2ZgL Akk2+FY7Z+esJiGTKIz1QO20/ZepJskS3Cm4NQMl6wk25PTRJLKEi5HkobiHKmjDddkjLf7jTn5b lnQo+ZkMp0IMrkEf1qhKEUhFdMlaXZEkPM8rigrBlyordVDG35arNm5jsXeeRmbUsXYkn76V47eF VZCFPqYCjkqjWC1HnTK1nlYqfEsdK1eO5bKxpCsc7pu6kE2Ncu+TGDYMKmxs0aLc3H4akEtVNaHU ZMuTLKZJpXlD6bmYkj5eVQY/I5/HTkRzyLG1gwDGx+Nqjws1ZFCH8Q8KnngWRDbUeHwrLbTmTnHR kPJS5Kyrm9x5Uf8AHck1oQZc0mJsikYRNqUUkKfmvSqGO49WLPqraC9OwVbGkbHY6A+n4ipLI1iO xYErRTRyISpB0YaEGtAZCTvuyP4r6DuNq33mqGRHoR9opVfaw+NqqbMs20my21jyJWX4u1/z0Osc rb8gd1hpuf1G3lc1Xx5dtm++rLSKLSWBU11mTnlDXgxY4jK0KAH8I2j/AEUmBlzRISiCBHP6ug+e lT7sWUfiIPx6UkkIB8hbQ9VrVURvuVpxFO7OF3St1Zxe/wBpqMSPBG0RcrG/WJDYHzuKnZdtwPxD oT0+yq9iTZj99bgzIyRVZAVRVv4ACoZJchoxFJI7Rr+FCx2i2mg6VLttfyB0o2g9daqSLJDDPkY7 FoJGjYixKm2lLFkZMDF4ZWR20Yg6m/nTyov0pNlWBIyHIyoHZ4pXRmFmIJub1H62NyxJOpN6m2UB KQJItp8zRU+yim1dhu8SUUUCiqZGmmNTzTGoCJqiepmqFqFRj+4P8BJ8q8zf8R+deme4f/L5P3a8 zbrW6mbCU4U2nCqZCgUUCgHA2FJSjWnLG7sFRSzHQKBcn5UAqaCkY3rosb2J7kmxu+uNtBFwrGzH 7KxM3CysLIOPlRmGVeqsLfaKSpDKwFOAre4T2XzXMxiaCMRQHpJJcA/LzpnOe0uX4MB8uMNCdBMh uuvnUkQzFtSgUtvv8R40WrRMiUU61IRagFFAoFFAKaSlooBtiR0q9w3cGdGVXdYg2IBHUeBvVZU3 WBIXXqav8dl4mD3H7b5EjAKQGMRtuUmzIbjpWbaQarrJ6fx/MY2XEIEUxullZSQbkKNbKbCoOSgM 4ADWjt+qeprjeN9yZsmWsOLCIcZB/E2XOltp7krXbTzvr+bqcPPibAuLdopuFtxLf0hu8zXj5ONn p47dUZcvHdtrxz7T4KaElnjIWX1D9oVjcgeRzs58PHch0Yg2baiqNL3GtY+XJncZktEcqR2jNmKs xAPl661XicanS3NGqx3O79LruFNCgVgcDzs2ROMXI2uXB2SKLEta9iK3DJtYgms2Tq8mq2VlNRk6 ysLKOtQLxSMbzNqatNlAaA61zvKctmyTGLEJG3qfGiTZXZJG0ONwo/wi5+NI2Gq/hArmJP59DEs8 mQyKxsATrf5UYvuTPhNpCsyg2YHRv010fEzmuesw8HTpE6kEekjUGtPEytw2sfV+esXD5mHJTcq6 +KnwNXELON1rXrlasHRxZYyac0KyEMujCkO59rEWkj6/EVXgzAf4ch18DVpWVyAeo6GuUMw00Wix aHzNqrTMAiPfpqanhJ2EH4ioJBeIKfiKsmVqXcLIDKCNQavwuCGib7KwcKXYCvivhWmjnSQfq9DW lpJLVclvHlxy7IL9wfiW9WBICNoN1PVT4VRMQGQcgaBwL/OpVLXF/mDXarwcrakzLc2H2VEygnpU 49QB60jgdR+t1rojDK5UdKZtqfbSba0Qh20bal20baCSHbQFqXbQFoWRmyipdtFBJAKKBRQCGo2p 5pjUBG1Qt1qVqjahUY3uIH+Wy/umvMyNa9K9zsU4yU/CvNj1rVTNxLUopKWtmRaKPn99a+D7V53O iE8GI5iPRzpcVG0hqdP7L9j4edjLyHKglZNYo72Fjpc10mH7N4fjuaTIxUG3ZcITuUMPHWqvNtyP H+2IG49Ss8Gz0AXOhFxasLj/AHXzPGcqs/PxOkU6gKStgAD1rnLZo7Ucry7802FHjrFhxqCJJPxO T12/AVW9x+2cfmMnCkkWzROO5b9ZddD9tOwud4/nsknDY3gANwCLk/OtqNmvGG1egMv3Jk8pxHEr /Jok3ptVVI8OnoUWpBBlcz7aMfKx9rInTa6kdCdAadz/ACeHxM2Nm8hKdrPtVPAfG3wtWF7k97jk Ej4325ebImIJdQbADWoDZwPY3t/AwljmgWVnADySasSdK8495cBHwfK9mD/DzDfECb281rtODzPd nJcrHjcrF9Pj4oDvYW3n9X1X1pvu72pyvuDk43xysePAm3e/ixNzYVpYZGjy80vWt7nfZfMcNGZp lEuOOsketvmKwPH4eFblGYCltS0hqgUUUlPRWdgiKSx6Aan7qmmWxDEF7W++rGMMdCGmUyMNVS9l NtfUbXPTppWzxvsX3HnqJFx/p4z0eY7b/Z1rbi/yqznF582ND5ICw/OKxa9dGzapbsclFLlzR9xT 2ceG9whCLvP2gk28ya6X260marRMy+prjVZNsaa7bqbfbV1v8rsyOMRrmq6A7igBXcbEdQxrRbhs riuO+lw8Yq0uk8qeravkOn5q5cl6tYOtatEXNYc8JM2JGjX0cEa+ZsR865TNweQy3eZ/4Zk/EAAe n71eiZaqyEHTzB61z+TEFJsdPCuau66Hata31RyXD8JNHyuOwYja9z8a2uQn7eSUHh/prR4vFH1Z nYaRqT9vT9NYnIkyZsjKdLmlrO2putVVwitl5Ds1laxqh9PmNJuVx1uPnVuWJi16sY6lbGqnCDrL IZJuQbE7EuKsljcOT+i1ZjcZmTkbcdYVvqVvrXXwSDaNwvT3ZLWAsKq5bRgxbhrMsxsDGlxwCw1H XStJZ3I1P2U2RwDYVGASa5tt6nWtUtCa9+lWIZnQjXTxvVdFNTxpestGsdTSxptxtfQ1MV3ECs+F tkgt08q0gNyaGx86zBysoclAQTQ5ul+1KrAMOl7VZ47IkMq31iaMC3kVJU/mqzCyjRtbdac2C/cE yMBAFuVHncn9NaSww7rqaEQ3w38j0pT+EHypMW4jANTMARY6Gu1dEea2o6E2kXyp8g6jyNNsUAJ6 04m+vnXSphke2k20+1LatEI9tBFSWpCKpCPbQFp9qULrQDdtFSbaKAoWpKfaktUKMNRtUpFMYUKQ mo2GtSmmEC9CnP8Au024mT5V5xXpPu9R/KZL+VebeNaqZsLRS+FIBWjBq+2MKLO5vGgmF4y25gfG 3hXqvuLlp+D49cjFhR4owA6nTTppXnPsnhc7kOTXIx37UeMbvJ8bfhrt/emBn5HDu0U9xD62TqHC 9VrnZ5N10NJ+exYeLj5LJjIgcBttrnX4fOsP3Xi5fNycfJHjhcMSguD+OzfoqLiOcTnoocGTDdMV Aole3oJX9UGuh5XncHgVi+sU9hzZSBcAgXHn5VJclhFnB4qDGyEkhjWNVQBrC17dBWJle8cdfdce ArDsIpR3HTuG2n3XrK5z/MTIzovo+Ehcd/0iYjU3/ZFcaeK5eSSVhjyF4LtIbWIvqTeqkZk9gzuE xuVyRlZKiaNIyI1OoBPU1yvtv2xyGFy+TykMQXGikkSKI9Su7rrVDgP8xcrAhTHz4mlRRYSDQkD4 H/TXfe3+dg53HaeBGjguVO4WufGjkshwXOxcuZjFEYlx2Mb7rD1LoR8qxM73Py+d7hPBcQoxxGbS zutzYddo086ZzvuTjvbfIf7rAWEwYyhBZd3xqj7Vx+T5znZPce8Y0f4Qlr3Xy8KiB2PIY2zhMiPP kEo7Tb5CB4LevCW6kDp/6a9q914HJcpw82PhTqGI9agfiA6r4WvXi7xPHI0cg2yISrg+Y61qhLCC 1J407aPtrR4Lgc7m81cXFWwuO5KeiDxv8a23GWRKdA4LgM/nMwY2Glwp/iyn8KDzY1617d9m8Twk QZIxPlH8eQ4BN/6N72q7wnCYPC4KYeIlgNXc/iZvEtV9pAB8fE+dcLXnyOqrA/T7fPxoJqq2SB40 wZJJrG5aGoZbNMNr6/bUHf8APr5UGe46G1TDLoY2fdZXQ+Z/KSaypYdxrc5eIgrL+0NfnWHK5BtW Xg7UyiZI1iwpnXwHWuLnyAs7E9Sa7Lk5liwxjxn8Qux89K4+XCmlkJVdKGqLqETrIbEdasiHaOlV HxJ4QLCxrSxS0kYDD1DrSTcCIzIunSjuO3SpjF4dKRYbdNaFwR9onUipFjt4VKsZp6pSBIxEvU6g AUKth0pRqQKyyNkuPHuJbwq2qNceRFrUkMQWK3nU6W7gA6AVDlawuNjF23M2inoKuZBCxiNf1uo+ FJCygaixH5aVI2kcuRoeg+FdYUYODs28k2OlkvT3BJA8z+SnoNo29BT9oJua6JYhGBFNiL9B0pdD cjpSn9FRY9yG+dVKGZJbaUWp1qLVsg21Fqdai1AMtS2p1qAKAS1FPsKKAzyKS1PIpLUKRkUwipSK YagIWFRnrU5qMrehTlPfLMvG7QdCQDXn9ta7/wB+enAX4sK4LStrQzbUTwoFGtH56pk9H9hsYPb0 8kWsl3OnW46VXxOX5/kuCkx4cYlmvHJMxFtdGNvhWf7B52HCyWwMprRTn0E9L16PgYGJEH+n29mU liotYFq5tZOkmf7c47J4vjosYKkoA/EBbr1vVT3lhJy0+DxjXXe5dyoBsoFvH51vPLg8TC8084SM C9idNKx+Ell5bNl5UODjSWXHQ9Qq+P21GOpocV7fwsHFjx9gftaqx1rSXAgYyekHuaNp4UDculWY AwW/hQhzPun2bg8hhKIwIDACQ6gAmwOhqD/LuULwRx0H8aFmVhaxvfqR8a6+UK6EEbr+FcDPnz+3 PdLS5W2PBzyCgT9UrpcimQbfuTiMjmeNkxkijidte44vaxv5Vj+1eaPDcVPhZONK7YLMryRKWVtd LGunmil5RFfDze1E34iliSp8jfSrLcakHHHCw1ALgi5826k/GhTkvYfKZPJclyc4LfSO94la+l71 xPu4RJ7kzhF+DuflsL/lr0aWTh/ZHBsisDMQbL+s7mvNeM4rkfcnKskQJeZy88ngoY61pOMkanCG 8HwmbzWauLip1I7j+Cj417LwXB4fDYa4+Og3EDuP4sw8TTeB4HC4TCXFxl1t/EkP4mYdSTWizgVy vefI6VrArsAKqTS2p0klU5W61ztY2qjJJjrUQyGB/FY0yQka1WeU6+FcXY6Kpqx5pkAEm028accz HRS172+e0fPSuelzREpZmIAGvhXPPyUnK8j9M04jxALOzEbQSfj42rpxt2Zm9Est/A6/J5QZMTyR lWx4GCyy3sL+O0eNr1m5CWbX5EfGuTyw82e3H8fkvJh/9XY2UkgB2sPnXXdphBCGJZgiqxPmBa9X kXia48Z6BFA2RH6huK6A/CoJY2T0xBRbqfEVpRyw48JeRgqL1NYeTmB8h5InAi10PU1Fk6UlvwIk yHjZ1zmEik+g7QD+Sq0MoWclNIydKhnyWdvWungbVJAgexBvT4G2aYCuLikCU2EMotU4/LQyMAtS 04gUh0FWQIelOgUFxTRrVrGj8T0FRkbLBIVQPE1Nix73qqTuc+V9K0MBRu/MaVU2SON8KScRgMI7 a9TVjYFAIBA+FDgCQOeh0NSMtl8xXXbk4uwxXudfGpfEeXnUSi1yNfhUygDT7a3UyxH/AAH5GkhW y/G//LTwt1K3pUGlvjV6kFotTrUVSDbUWp1FANtRanUUAWop1FAZ9qS1SWptqpSMimFamIppoCAr TSDUpppFQHC/5gynbDF5sfyVxFdh/mFKDPBGOo3E1x1dFoZeo4UvypBS+FCHW+xvakfKynOzbjEi PoTpuI8/gK9LwJeOO6LEsY4PSzD8It5VyCzPxfsjuYp2uYgQR1u+hNZ3BcrzHCcfAM7GK8dI15Mj qwDeLD41zbNwdT7g4TB9xY7qpYSRfhlFwLj89S+0uOw+Oxfo4iWmQnug6+o1exuRXJx0bCgJia3r Olx51AmYcTl0xdoU5QZy/wC4QCPy1Cm+kQ3a9aRiEJUHSlR1IuDcDxqJ7Fr0IOJshPhXC+4vbUnu LnIRj5BMKAic9QlyNB8TXT81y8fFYL5Tjci6FR11Nh+Wn8HjLjYBnijtJkEyOPEltaBFXjeM4PgF TEWUo7dA7k3/AEVqZM2OgCvIY0fQNfT76yee5Ph8aFhykYikYHtlhckj9n41iZ/JchyPtoQJgy96 eyRMR+HXRr+FRliSt7p9ichm5iZWJlNkCRrMsrX2A+KnyrsPb/A4fB4C4uOPV/1snizUnA4WVg8X Bj5cpmmRRvY+dqvtJasOxutYHu9qgeQUySWoHlrDsbSHu96ruaHl+NQtKPOubZtJiSC9UplOvjVw tcVh85yc2O8eNir3Mib8PjbwH31FTe4Rqdqkxea5B8gvh4atI97My30C6+FZ3IZXGNxkHH4URbJJ V8jII6tY+ka+F6uHI5HgJZ8Yxp9ZkoGaQ6sm691+ZqPhOKlmbuMvVr+dvOvQ3XiroYqnyWl6LV9j Q9v8aIT3tt3YDcx63rqosYyQmw1GoqPBwtiqoHStzHxwiaCxrhWrs22bvdKEtDi+YXMZSmOglb/s ybA2rCOdlYTbeSxDjszdUFxtPjeu75PEVJGK6LIPuNcxyozchBjTWZI/wG2lq6UhYZ147OyhODOH Mcb233s19doIqg3uGGMgpCXPiBpark/Eid7hdt9AANBRH7ZLEGU2UdfM1tuvUtk1/Il4jnp82cxt AEiH699b/dW58R0qjDhQ46BIVso8ato2luprk4nBl/MkpCtKCKNetCBGhLWqdpAvoTQDrUPc2iw8 aj7mtRsNSWkb1CtTjrFreIrGie7XrX4g7pPsNON+pHLlXpNYKDofKksVO3wp6C5JoIF/n4V6jyjA pBPlTlHqHypwBOpoTqaAVR1NOApVGlKKpBKKW1FAJRS0UAlApTQOtCC0UtFAUaQ0tFWCjTTCKeSB UbMvnQo0imEUpdP2hTHkQKfUPvpqMnmXvp93L2v0QVzlq6L3LiZebzkogjZwAAD4Vi5GDk40hjlQ hgL9K0iNPsQUooANAFUznsei+zea4/P45eKziN6DbtbxArS915uM2CvBceFkysgBEX9lf2q5j/Li LHk5SUygFwo238vGutzuGycj3Fi5ONGIooQRLKfEG3pFcmdFoWvamFyWNhpDmyqTENqqvio6XrK9 3+3ec5LMTNwZViGOto1BIJJ6nTztXRzd/Fy/qGXdEqWa3W9Z3Ee4v5tnZgjNosdtihtL/ZpQGVje +5OPmTA5fGbEaJPU51DEC3p+dOzf8wMY8eJML+LkyOFjg/W6+VWfc/D4/NcPJMqgZEAJjcdbrfQG q/sX2pjYGGOX5BA2S43KCL7B/RvVIZObxnvbm3XKlg7eKzK30xaxsDfUV6BjyZY45EitFMqi4caX Aqj7l9wPxPFrnQrdd6jb/RY2/wCWq2bzWXn8Ms3GQMZpdtiBbS43HWowjh/dmZz+ZnJJnQXxsSTa jRrdCd3n8a9RwJBJgQkx9u6g7SOn2UkMEMuHFHJGG0uQw8fj9tT9B+msWsbrUVmqF3odtagke165 NnRISSSwqtJMBTZpbVnZWYFvrXNs6Vq3gsy5QGt6pyZ67goNyxsB86yMvkG1ANRcbkhp3yXJKQ6I Ot3/AOSspOzhHbYqqbG1yvJjDxyqkd4+m3kTpWFlwS42LFyn1Y+vkIMcI9RVQOpqxjzceJJ5+SRp ZyN0MJB8f1m+FVeJ4CbmJbRELiI1pJNbsfIXPSvXWq41PU8r9b7Ih4zj8rl83uys8iXuZH6n43rt sDio8aMKorQw+Nx8SFYolACiwt8Ks7F8K4ubOWbd4xXBDBDtq0WCi1IoAFV8iQBTWtEY1IcsrKpU 1iZmPoSDYgdK0BNdjeq+cpILKLqdKxOTrWamBI86H0m1qb9VKdGuTWgYlPhULYik3ANIOsoqiR2N WIw1PGMFNKzxpoKEeXgUaanSmtJfRaiZy3ypN5A+FSSqo5mtUPd1pHkquZdTWWaSLsUwv1rc4aZE fc5sCCK5VJCWFbnHP6CT08qtXDkxy0lHWJKtgRrTlUk3NZOFyBiuri6Hw8q14ZI5Yw8eo8a9VLqx 4b0dR1tKAv3U+x+ygDwrZiQtRalFFqEEpbUWooBLUWpaKASgCilFAOooooCmImNSLjr1NTBacBXN 2Z12pFaXj8eUeoG/wNq5DMjniynjfdGL2TcTa1d0BWT7mUDjmZYw7aAsRqB50TcmsHLeoNZ3v16G 9NMrp/DcEE9fO1SSmNMBCqHdf8dVmzZWJZiGJFr+NdFkF2KOOQk48Wn6zHreq0cUMmZJBMFJtpuF QrysmCjMpJB6nrY1Um5ETZBmHpkAG743oq2Eo0IuH4/KDqMdUvpvAsDWXmey8MPsRmic63BuDW5h 5zERLN6Y7WAGmtOaaXHybuN6ObKTqLGs7rJ5K6JnHQcbyvC5gzMBhKY9CPMXrrfbvu7keTzvpJYB AIl3O3iT91N5SA48ystgsnVfjVTEy/ocxJTGLuLMf6NalNSYdILPuDnfciZk4wsRpMNLIsnxbS9R Y3svlMLCObDntFky+qYADab6sNemldRLzHFR4Kyll/iWAHjc/Cs73PyGcMOAYm1sdmAnW/q2fCoQ 1caGJePTHj9YKC7dfnUspRcZcVjsRl236aUkU2Pj8Z3SO1GqXJbSwA8aqtn4+RxgnsZUKkjbqT+7 U+JMnPe4Pb3NcnxjJHlLJDAd0cVrbgvQbt1bvtKTNk4mEZMJg2Ls2sACdul7VF7XfkZoZHyY+3jM x7CP+Ir8RXRKoUWFYduiN7VItrDQVGxpzNaq8kgHjWLM0kxsj2vVKeYC9LPOBfWsrMzAAda5tnWt ZYuXlbQdawM3MuTY0Zufa5vWBk8iryiIOFLnbu8BfzqKjs8Ho9NFLLDyyZU640Let+p8h51v4eBN xCY8skPciJLIshtc21Y9dLms3hsaFBlGeZUnQKMeNBq39Ik+FTPlZvMciMCNi/RZX+HkvkK9Faqi PPa75XjFVqW8eKf3PyMi6rDcd+VBtBA02LXc4OBjYGOuPjIEjQWFN4zjsfj8RIIEChQAbDqfM1ZJ NYb3amH2WgE0wsBQxtUEj2qNkSJJJgBVHIlLA0sknWoXJK1G8G6oqAtvveruODIuwi6nreooo9z2 q3NJHi4zyHSwvUSjJuzlwtTn+cy4sOYJjKoPiDrWfDyc0nWwPwFZ/IZpnyXkY9TpTMaUbwKzlnpV Eqruaxlkc6k/Km6g61ahxt6bradb1TmkVHK9bVDKaeEh4NRSTW0qJ5vKq7yXPWqIJWkvc1VeXU2p JJiAdbVWUySvsjG5m8KsCS7il3lVRcknQCuswII4YrufVbU+Arn+Ox+ybdX/AOsfy+AqlyPuKLIm GJuePjkJXIlj0ZyAfSp+NWld1sHPltCy/gb2XzsYWaXFCyJjna0rMFTcP1V8zV/27zU+QUnETCB9 Ga1h91cjwvDJymUZ2gaDj1O6KG5sb28/Pqa7jHiSKNY41CIugUeVasq0eNTim7LOh0Ec0MhsjA/A 9aktWGrMOmnlar2Fms7CGU6n8LH81da8qepxvxNZReopbUWrochKSlpKECiikoApRSUooB1FFFAK BTqbTq5HYBSSIkqNG67lYWINKKNPOgOM9x8eOOIWCT+DOSe2dbW8qwC5uOlq7H3jjGTDTJVbmEkt +6a42LMOPMsqqrkD8J6a10o8FIchgUZW6W6Vly5qhwpHRQFYdauzzBizHzvYVhvMqylT5m3311Od uh2ePyWHJBDI6sqxLZrj9atPIzIJMVCGGliBb4+FclBkTdtYO5vRrFlPlUsfJk5Lm+6NBtQHQAjx rhtlnaVGTdzpmyslmNlZE3Rh9LnS9ZEeU+U3cICgXCfZoapZfKtNtgVt19Xa3qB8r1axiCRpZR1F dK1hZMO3Y0cYI6kSMAEBPzq9xXHS8k4s/wDDS3WsTcCxI87Cuo9owymaWUiyKAvwNZvKWGaRvSYE MmKMWZe5FbaVbofnVPE4iHAPbxiRB4R9QPlWpK+30jrUQ0F/GuEuSj4wqiwFvhSs4qNmqF5LUmBE j5JbVSyJwAaJ57Vm5WSADc1zbOla5IszLtfWsDOzTc61LnZfXXSub5DPa5VdWOgA6mpWrs4R3UUU sZyPIWU660vC4jvfKlg3Sk3haQ+n5hLfpqbi+DeWQZWcu49Vh8vLdW8o+nYPMPQLgJa3yAr10qqH l5LO78DNi47LS0eMpnyshiNzdQLn1fCu+9q+2V4jG3SgNkyau/xNQ+0sD0HIZRdjoeuldXYAWrnb 1OQ7ba7V8SArTCKsNaoJDRowivIbVVkarEzVSleubOiUjGNRNIOlNklAHWqjzC51rEnRVL8Eq3vW T7m5YLj9hTq3Wp0l061Um4b+ZSXc2Xzq5ZuqqnNuhx0043aGtHg8HJzcldintjq3hXTw+yuKi9ch ZiNdTpU+T2MTHMGKBGAPCrg2+VNwmUuRzIsWH6aE+voxHhWGZNSSaTL7zSMRcms+cZx0A2jpUiWa SVVgty5KL1NU5M8XITU1XGDkOfXf41YgwVBsRp41qEjM2YyMZOU3p9K+Ln9FauJAkQEcXU/jfxNR qoRQo0FSGePGhaWQ2VBcmsty4RdsKX0K3O8jJBEvG4YJmlF5bdQo63+dVuLgl5p4McIsHH4NgVHV msLknS5NqyxyOUZp5Y1tLn+hXPUIfTZfzXrseCwFwMRYgbu3rkP9I13f/wBdIWrPGp5Ltv7Ub+Nt RAiaKBYD4CrkbXsPCqEbWtrVqGTWvMpk6NYLyqG6UjxOpDDqDpT8ci2tXQsZFq7VpPWIOe7ox+Ll LOnX+IPxD5VPWTPGY5N8ZsR0Iq5h5omGx9JB+Wt0vL2vocr8cepFqkpbikJrqchKbelNJQBSg0lA 60A+5ooooB9JeikJrkdxb00sKQtTCajYgSdUmiaKQXRwQR868553jpOPy+xb+Gb9tvMGvQ2esH3Z GkvFyyEDfFYo3iKVvDNJdDz/ACe4u5bfh/EaxJZP4pv01Irby+QFmC2YOg3XFvVXOfjmNvPWvSng 4XWTVwlbYZCTv/V1qRZIY8Ji5PeYkVElzDodq+B+VVnPeYi/Q2ArNU5N2cJIucchaT1G1+proDjp BEAx0YizX6j5Vj4FomTpu+OorTJmecyLGSf1R1AFV9EWmjfU0+Kwk5CcY8S7V6lr62FdxiwQ8fjL FELG2vxNch7YZm5NpVG1FWxHhc2rrCSzbm+yuHJbLUm0h4Nzc9TSlhUd7VG7+NcpLAsknlVWWa3U 0kso86o5E3xrLZutQyMiwNY+Zlddafk5XUXrEz8oAHWsrLO9axllPks3aCAb/CjhOMeaXvzLdyer ahB5mocHFkzcruWuE/DfpfzrqUysHExQQQCNLdSz/wBL5V6a12V0yzz8lnd9qomV8OPCYR3ujBiX 0LbTrf4VmzTiewFyykkE9OvSq2TywfeS1t/UdDYaWA+NV4ZcmeQCKM2ksqgmxJPjW1VrLOe9aI9N 9p7jw8Za1tzbT8Aa2Car8fix4eHFjxiyoLW+J1NSO1YI9RHYVXkcUsklqpzTa2vWLMtUNnkGtZs8 9r61Lk5Fr1jZmWNbGuTZ6KUHz5fxqt9RvOlZs2WSTrTYJyWGulZhnfYkjfxxetGJ9grNwmXaLmrr TIF61tM42lsTMziiGxrn8nLdybmrmdKHuAax5b3PjQ6cdVGg7veN6A4Y3bpVX130qWOGV+gNINkr MgGmlMGvTrU8eAzdb1aTEVOo1pBNxSETdTWP7iyFEK4iG8jsGZRr6RXRyGONS8hsi6k/AVxzcjEn IZWXt7pcMmPfUA3ADfYK6cNJt5HD+xyRSO5Z4mOTleRjlZdsGGihVHw6flua7GK6/KsX2pgvDgGZ xYznco8dorZY2pyNWfkTiUV8WWVktarEeQB1rK7hpRMb6GufU06yb0eaANDU45AjxrnVyGBqdchv OruZl8aN0Ze/qfvoEhVxIp9S6g1kR5B0q3HNuFZ3PUm2MHSxyiSNXH6wvS3NUeLYyRtHfVOg+FXD FJ4G9eurlJnjsos0OuaL1GVmFMLTjwvWiE9xS1V+omB1Sj6th1Q/dQFy9FVPrB+yfuooC7TDQTTS 1cmdhCajZqGeoWesWZpIV3rJ58dzislevoJFXpHqnmWkx5EOoKkVzVvUjaR5NmyWLH4afmqpjRl/ UNLnrUmfuEzQk6hiPupvdKx9tNAOpr36pHkf3PzJ5Xue0nRBa/xp2NEFO4jWocfdtBvcmrsakoCf PSqlAmWW4lAUk6eVX8cZrvHjxk/xBoB5GqMIZmHj5rXc8BxSWXLkWxsAgNcuS+3J2oi7wXFDBxQG H8Q6sfGtM2FKLAU1nANeZ95Og1iBVaWS3jT5ZRVDJmtfWo2aqmyOecAkXrMy8gdL03LygL3NZWRl X1vXOZZ3px9RcrI661hZcrzyrCn4nIGnxqzlZB11rLinaOR511cDbH828fsFd+Gkszz3Vam3FnR4 eM2FjJumclN/kRVPJjmMT912LbgihfTqevzFVcWdMUtKfVIRZPHXxNaXGSmSZpJRuI1UHwr0W9Oh 5K+vUlh4mHDgHjLa8oXSxPQfGr3t+MT8vjLGpujBmXy2nWs7K5B4chyvq7lib/CrfEZQwubxSr/j KmRv3+oqNuBicHqplt41BJMPOqz5Px6/oqrLki/WuDsaVck0s/XWqM+T11qKfKsDrWZkZR865Nyd q8bkkycs62NY2XkXvrTp8i99aoyt1JrJ6aUghdydanwySwqi8ovarvH6kGttQis2oJCq69KdNkWH Wo1jYrTHx5CfGsnPBDJKSfnSLBv6+NWExHPhVyHD22uK0g7JaFOLAW97VbTFUeFXFjUCkewpJje2 QdsLr41XlYA66VNJJVRzuNyft+2plstVq30MX3RkKmB2lazyso2g6letYE7Y+RDh4WIm6b/rWH6z vbT7LVZyZcbJ55jlvbGjYjTyUdB8zT/bEST82ZkW0Ue51B8NfT+evVVbaHkvbfyKPI7KKMQwRxdN ihbDpoKa1Kz0wnWvO3k9dVCG7L9KTtkVMoFO2g1A2QBSKeulSFRTTaqQerEVZilN7VSualjaxFZa Izd47J7M6t4dGrpNPDoda46B+hrpuMyO9jAE3ZNDXbht/E83PT+RapLU40ldzgN2qfCjtofCnWot Qgnaj8qKfRQFZjao2eh2qFmrz2Z6UgZqhd6VmqB2+Nc2zaQyR7VUyJbIxv4GpJnrF5zkBi4E0l9Q unzNYiWkjcQp7HnOYyy5+S9/SZG2/K5qIb/wj76TxB6k6mpoVsfVqD0r6dVheR4bfc34lnGB0Unr VtEIcKNQKrx2LWIsFrU4nEXLyOzc7z+G1LOFLLVS4Nr23w8eTKJ3B2qbnw1ruEUKLLoBpWfgY6Ye OkS9QNfnV5ZFvc14rX3M9KrCgdIs1v4YLVRm/mC3btMR8LGtSNwakBvU2ysMK0dJOXkz5FJWUFG8 jpVGfOJ8etdflYkGQhSVA4Pn1rkuZ4XIwy0sF3g628RXO1WjvxXpZw8Mx8qdnJF6z5W+NOnmsSb6 VRysxYkJPU9BVpVt4PReyqpZDmzhFNz8qpxeqMOddTpTZFkyRvNz5CjHYiMqdCpr18SS8z53O3Z+ BZe30ynxDkDw0GtXuPyRsMo6+H2VmRkSP22J2kaVYRu0APA0s8QONdRsk7PM0t9N3pv41Zwp2l5f GjyCBd1Bt5D1D81UclwigD5ijj8xcfkIsiUb1B6+VV5qY0vB6tLlgDrVGbM+NUDll0BBuCLj7arv KxNeJvLPdXiUItS5RPjVOSUsaZcnrSEEVDokkROfGqWZOI1IvqatTuqKSa53Kyu9OdpuoNhW6Udn 5E5Lqq8XoWVcuw8Sa6PisVyoO2svg+KlyHEjDS+ld1gcesSjSrdp4XQw7xXOoyDD9IuKsjDUeFXk gAHSnNGBSDg7tlD6ZR4U0xWq29hVeQmxqMKSs9lqpLJ1qeYmqMpNzWTrVDJHB0rM53JfF4yWVDtc 2Vf9Y2/NWhtuda5X3LPLk8lHx6tZF2j4bm866cVZsTlttp4vQynhx147vM27IleyqfBV6n7a6f2z jiHAElrPLck+Nq52HDx35YYkbdyFXtu87fi/LXZIBHGFXQAaAeVdua0KDjwUluxPvFKpvUKk9alj ua856oJVp4pliKcKGWKaYadbWmkUIJcXpyHWmEU4aVGUuwydBWzw2T28gITZZND865+NtRV/HkKl Sp1BuKtHFpOfJWawdiRSU3GmE0CSDW41+fjUletHhahjaKWgVQFFLRQGazVXd6VnqB31ryWZ6kgd 6gkfrSO9QSSCxrm2dEiOeSwv0riPd3Id1lw1b+k4/RXR8vyK42O8rGwUG1ec5GU+RkPM5uzm9d/6 /HL3NGOe+2sLqRL+O/xq1oLfOqwB3AedWImYOCLEA9DXsPGWY2JY2Bt0tXoHtTg3xMb6qcWmmA2g /qrXNe1sCLOzi0oukNnPkfhXoQyFChR0Gg+yvPzcn8T0cVIyO7QGgpwUCo+8CNKTuDzrznTJaVhb XrU8badaoo4t1qVZR51UyNMvg3HShoY5FKsoIPWoI5gfGrCuLamtqGjLwc/ynsrAy9zwHsSEanwr huU/y/5+F2kVRkRj8LIbm3yr1wMD8qUhTWko0L7jeLZSPF8DjMiFu1kxtG3kwtVTmOMfEfvIPQ3W vbZsTGm/vY1f4sNazsz2txWYjI8e0N5GotytJq3JW1Yg8UicMQ/iKsQyCUW8V0tXfZH+VeES7Y2X JHuN1VgCBWbk/wCV/KR7mxcmORrXCn0kmulrJ+Bik1mDiJgd7qxva+w1FY9u56KdK6fI/wAv/csd 90BktqO2Q36azMn2/wA3hrIJcGcR2/F22sPj0raso1Odk5nxNzh3aXBjO69hqau9s31++uY4rmH4 xBFJHujY3JvY/lFbH/FXGEdHv4Dbp99681uJzhN+R7ac9ISbS8zQaO1QSuFBvWbJ7qxSSoicjz0q hm81JkntwKyBtLtWfavOkLxNe/xrR7n2QcpyDOxgh1J6kVPwPBS5Ugd19INJw3DnImBYE6+o16Hx XGRwRqoAFq1ayqttfmYc/ff4IdxnFxwRhQoFq2I4QopYogoqRmAFK1OFryxpsKid6V5BVaSSlmEp B3HjVWRqc71Xdya5s6JEUpvVR11q05qG1EjomUsuUYuNLkH/AKpC33CuEZJcqLI5KaSzbgF8yx8P sFdJ7uzmjgjwo/x5H4rfsg2t9prnk45/r48B23C4aQL0BOpr08VdtXZnn5nusksx08zT9t4cYiGU ReRyQCfACt/bcW8qZiYawRrGi2Vegq0Iq4WtLbPVWuyu35kQUgWqZFtan9u5GlPIVB6j9lZEhYWp LWNNEqdKk3LfTWqQbQRTra0GhCMii1qeRSEUKKnWrcLW1qkOtTxtUaIzq+Cn3RtCT01UVqmuW4nJ 7WVGSdCbH5GuptXq43KPFy1iwlLS0Vs5iUUtFAc471Czihn0qB30vXhbPakI7dapZEwUHX41JNKA DrXJ+5+b7CHGhb+K/wCL4ClauzhG21VbmZfuTlvqp/p4yTEh18iaxAF3U3cTqTqakUC1zX0KVVap I8N7u1m2OU6hvCnnTUHrTQAelBvrWjB13snICJkC+ptXS/W+FcP7XlYZUkd9GW/3WrqFuRevFzL1 Hv4ErUTNNcvSnjKF+tZo3eBp43GuRt1RpDMHnUq5Q86ygTb404O1VEdTZTLA8amXL+NYiyNUn1DV TDobq5lvGpVzR0Jrnhkt4Xp4yiPHWruaI+M6NctTUizqa5xcxl8anj5AjxrSuzDob4daXcPOsZOQ B6tU4z4rfirW8mxmjp5A26aCmm500186oNyUQFgdarvkSTGyvtB8am5FVWT8hxPF5htl4kM5/aZQ W++16wMv/Lr25kndCs2Kx/7Nrj7nDV0WLjqo9UvcarVgKqdujaI47I8y5X/LDNjG/i8hckDXtyWj f7+n31y+VxfJ8XJ2s/Gkhkv6WYaH5N0P2V7rtUm9tabLjwypslQOh/VYBh9x0rSvbR5MpJOUoOE9 s4qdhH0JIBPnXWwgAdLVMOKwl/uYli+CDaPuGlI2K6/hNctrTO1r7he4B0qN5bikeCfwt9ptVeSH MHSMkeY1o2ZVUEkw86rvMKhyHliv3EZfiRpVN8gk/CstnStS28oNRFjVfu04Pp161I8DUEm4Go5H VFLMbAC5NI8iIpZzYedcn7j59mD4mObAizEda3Srs4glrKqbbMnm+SOdyLTIbRx+mI/Aa/nrd9u8 en06ZbjdNLdmY9bGud4vjzm5ccN9Dq/wUV3mNEkMSxoLKgCgfAV15ntSqjl/XTdrXfkWEjFgBQxV Oup8qdu2r86hJua4PB31HF2PQ2+FRta+v30pZwvpXcfADxrTwOAzs2zbO3H4u9VJvoRtVy9DHNuv hSq5XSu8wvbfHYsZV07zsLM7fHyrj+Z4qTjMxoSCYWu0LeYNW1HVSZpzUu4REr3FLe9QJUu6sI6w P6UHpSXvS30qkG1KlRinKdaELuO9mGvSu0xpO5BG/iyi9cNCbGuu4SXuYKi+qEg114nk839hYkv0 UUorsecLUU6igOMd6rSy0sj28azOT5CHEx2llayr4efwFeKG3g+gl1bKnOcxFgQFybyNoi+N68/y J5J5mllN3c3NT8lyE3IZLTynr+FfIVUr2cXGqLxPLy8m540Fp1zb4U0Ut66nEduYaijc1tabS+FA X+HzPpc6ORj6D6W+RrvYl3KGU7lPQjyNeZ1ue3+Wy4shMYyExNoFbW1cebjlSej+vyx6H10O2C2u KeF0rLlzchNVsfgaZFzzo22aLTxK15T1urNkL91KE1+dV8bksPI0RwD+y2hq8trefyqwYeCMJTgg NSqtqftqwZ3EPbFNMYverFhRtpAkgKAimhR0qzsFJ2xQSQAUuvnUwio7NBJDrT1ZrCxp/aFqBHap AnwLODI+7U9OtbKOCKxMZtr7TWkkoFq3XBysuxdoJNV/rI1Nm8qrZHLQgeg9K22oJtbNC9xVXKyn i1SxrKPJyu11a4+FLJkHbuc6VjfJpUa1JjykjNskGpqaHKK6HT41UhZJV3KL/GkzRImLJIg1RSw+ zWpk1CwjQmQZERDeoMK8+9yyZ/EZnaO1YJADDI17N5rex1r0PBdJMdGQ7lZQQfMVm+6OETmOMlxO kv4oWPg46ffW0lOUY3OspHmo90zrIfSCvT7fupkvujONwhA18ulY80UkMjQSoUljYq6+IINiDSpG 59QBt8BXb26djn7vJpP0L+Tz+flQiGQhVP4tuhI8qzj51JLfdqNR4eVRt5VutUtDnaztqdD7Px7t NkMOlkU/nrqo0ub+FZXt7F+n42IEep/Wx+dbClj6IwSx0sOteS/qu2e3jUUSmBsrXO0eFWOP4rKz 3CxL6AfU56CtTi/bjyWmzPSnXt+J+ddLDFFDGI4lCoPAVqvHOWc+TnVcV+ZR472/g4dmZe9KOrN4 fKtQG3TSmXFLeuySR5nZ2ctjwdapcvxsXJYbQuPWBeJvEGrV6W9GpCs00zzOaKTGmeGVdskZ2sD8 KA1xXU+7OI70f8wgX+JGLSgeK+dckp8PKvLau1n0OK++q7kwNOvTAdKW9Q0PBpQaZTgapIJ42NxX Te3ZvU8XmLj5iuWQ2tWvxGR2cmNidL6/bWqOLHHmrNTrqBSDUUor0HjHUUUUB5xmZcWPE0srbY0F y3hXnnN8zLyeQT0gTSNP0mtr3CM3kwPpz/AT9Tzt41yjKyMVYWI0INc+Ci1nJ6ee1tOg2lFJRXc8 7F6UCi+lFUgtKBekFOjYBrnwoBNeh0q1xt/r4bftCoR2ihJJDA1Yxp1gyosi11XUis2+1mqQr1fY 7R03KL1WfHFWYZ0yIVlQ3VhcU4revA1DZ9RPBn/TjdcdavY08yCwYi3xppQGlA2m9CvJeTPyB4g/ MVMvIy+KiqAvanKTSTDouxf+vl8hR9fN5CqYNPFWWTauxbGdMfAfdTxmSfD7qpXtTgdKSTauxaOf KPBaaeQn8Av3H/TVYmmX1qyNq7E7Z+UTowHyFMbJyXQjuspPipsaiuKOmtRuCqq0MtOf5jieT2Zz PlcexsXKruAPjuAvpXa4+VHNEk0LiSKQArIOhHzrnpYYp4jFKu5GFiKxM9OQ4LbkcNI8MB/vYwdy k/utcV1q1bCwzjelq51R38rK6m5sPCqJgFit73rC9te65OWmbCzURMjbuidLgPYXYEXtf5V0Cyxq 9m6Vm1WnDRKOVNTN42VkzMjDb8cbXF/I+NbD45lhZf2hasrLj7XO42Wg9E0ZjkI6XBuCa1+7st5a aedIg3foytwjt9OYpP7yB2Rvzg/dWo21kIOoNZcTiPknHQTqD/rL/wAlXTIw/D9tVaGLL1JlfgZ/ pxJgOT/uzEJ+5+r+Stl3RlDAgA9a5TNyfouUiyWBCyN2pCOgV+jH/WAFSZuVNfaGIXoLU3YhmnSb Sjnff/CIucnKY9gmR6JgOm8dD9oFcmGaDcu7XoK7vmw03A5Qc7miUSKfipFeesxY9b31rvw23J+B 5+euxqNWIxN/0025DXv/AKKtYPG52fIExYi48W8B8zXdcB7L47EKZGeRkzjXZ+oD8vGujskcUmUP b/8AxFnQqsGDujACiZ/Qth46g16Lw/Fx4eOhlVWybfxH6i/9GlgmiVQiAKo6KOg+VWUlB8awqV1R u17NQ2Wg1OBqAPenhqpglvSg1GDTgaAfelpl6WoBSAwIYXBFiPDWuC5/ijxuaSg/3eW7Rn84rvQa pcvx0fI4LwEXcC8ZPg1Z5K7kdOHk2WT6dTgFanVE6PDK0UgsyHaR8qdurzRB79c98j70oNMDA6U4 GgJ0NXMZrMNaoIatwnpbrVWpi6wztePn72KjHVhoatA1h8DkWYxH9bUD41tivTVyjw2TVmPopKKp k8nx4ABasH3Jw5im+sjS8cg9dvA+ddXHFbwqUwRyIUkXcraEGvLS21yfQ5ErqDy1oWC7wDbwqPrX Xc/7cGFC2XjE9rqyHWwPlXMPA1t4Fga9lbKylHhvV0cMgHlS9KQiitEHUlJRQg61Le32Ugp270bb Dre9OgOh9s5pIfFY6DVa37261xfDSFORiI8TY12BevJzViyfc+h/Wtupl6D2I8KUEEVAXtTe7auJ 3gtA0brVW71HeFCNFwMDT1e1URL8aeJhSCQXdw604NpVRZgakEgPjVJBOTTWNMD0FqAW4pfDrUd6 N1UhKGtSnYwKsAQfCot1IZKCDMb2+cfLTOwZtk0cgkVT066/krpp0dyHj/CQDprp1FZLTfGtPClO ThtGG9cRt8bGtbm9TO1J4xJV5x504xZ42ZHx2WTTxCm5H3VpRz/VY8c8Rusiht3XrrWflQSPA0TG 4III+B0p3CRSQcYMZZNxgYqG+F7inQlq6FjKR4WjnLf3bBj8vH8lXTmxxX3a/wD2vWPnmWRHEjEg i1qmBMuLFIerIpJ+NqiNOihNiZnIxz5EQKDYx2OD5HSlybMoK6C9Z2YoVSb9NQasxzbsYN56/fQ0 64UDeQikm4fKhhF5JE2rfzJFZPF+1MCMBs4maT9kfhFa3eP0swHUL+kVUGRIp6/ZXXjbScHDl41M m5j4uJGgSEBFHRRpVtIT1U1gw50i21++r8HJN41pQcnVmsiSDpViN5VqlBnowFzarsWQh8RWl5nO 09iymQ/Q1YjnB61XRlapQq1r4mPgWlkBqQG9VAPKpVLChCxS3qIMfGnhhQDr0oIpNDRagOS948Z2 5E5CIemTSS3n4Vzqtp5GvR8/FTMxJcdxcODb4HwrzaaNsed4X0ZCQRXDlrGUe3+teaur1RIKcp1q NGBFPHW9cZPRBOnWrEZ1FVVaxqwh6VTFtDV4/IMUyOPA11qMGAYdCLiuIgkANdXxM/dxACfUmhrv xW6Hk5qxkv3optFdcHA4FY6lCW8KcFp9jXhPe2QZGPHkQNBILqwsa8/5nhsrj5jGyk49yY3GoAPn Xo9qiyIoZoykqhlP6p1FdOPkdHPQxbjV1B5M8a621PnUBFq6P3NxkWDlboV2xSg28r1z7L99exW3 KTy2W1wxgF6KOlLcEfGqQQGlvQV0vSVAPjdkcMpsw6EV0PG8t302Sf3g/LXNg1LjzGGTfWOSisjp xcjo/A6s5I86YckedYoz7+NJ9dXD2n1PX79TZ+qHnSfVDzrGOafOk+qY9KvtE9+ptfVjzpwzR51i d+Y9FJ+yjflHpG33U9oe94Sb65q+dTx5anxrmwc3/s2p6y5q/wDVt91Pa8SrmXU6hchT4045Cjxr m0zModUYfZUn10/ijfdWfbZfcqbxyl86T6pfOsA5c5/Ub7qO/knpG/3U9tj3Km8ctfOkOUvnWH3s zwhc/ZTTLn+ED/dV9se6jbbKQ+NWOM5WLGzUZz/Df0SeVj0rmGfkv+xe3yqFv5k2nZf7qq4/Ew+Z M9OyY0toeoG0+YPjWdxcix8lNhk+qaISqt/FDY/nrleP5r3Jh2COWjAsI5RuX8utXOInzpPcEGfl MTI7bWsLABgVsB5a09uOpPclQkdLmJYN4ikw0vxsXmtx91Tcg4UMALnw+QqvAXTj00N7nQ/E1z0O vRGbyp7cLk9LUQyZbYcQxsd5ywAG3pf50nIHuoEkHpZgGFxexOvW1WeGys+HA+mjhkUwSt2wVOqN 01tROs5OjnaojzZLh8NnyX+utimQaL+I9fsFWhweCjASzuR8LD/TULpz+UVtAyoDf1m356l+g5z8 JjQfEsKu5r7Uc7cbt916fBl+Di+EhF9m8+bm9S9rjxftQIxHgOtZq8JzUmpeNR8X/wCSpB7czrh3 zFjYfs3P+im+3Yz7dFryVL8aYoOsAU+R0qwBijogHyrLbg8xdRnBz/SUj9Jph4zlR+CeN7eG43/K Km+3Ynt0elqm0JIALA2qVJkA/Hr4VzLQ81EwDQM/kVIIrThxMsxBpvSSPw31rVb27GLcVUvuT8jV TMjB2saspMjdDesVILsEkNvI/GpfpshNYnvau1LNqWee1FODaDCn6ViLnZcJtKpNWoeUhfqbGtbk zG1mmGtTwaqrMjC4INPD/GqQsdRXDe9MH6fNXKUWSYan412qyA1j+7sQZXDyOBdofWvyrF1KOnBf bdPucHHLoKsK1xWak1m18aspMfOvLEH0tS6p1qwjVSV71PG9DLRfhPnW/wAFk7Ze2TpJ+euciYaV pYchR1ZTYg3rdHDOHLWUdheiqP8AMP7F/torvuPLsObCiloJAqDIyY4UZ5GCIouzMbACvIeskZgK ryOKZgI3MZ5xIMjsIMWbL7qqHv2mhULY+B7tUcbO7+PFK2hkRWIHhcXrTo0k+4q07OvYq+48UZWA wtd4/UtcC9+leiZMyFCD0ItXH5fEZM+aVwYmmDa+kGw+ZrvwW6M5f2ePSyMg0ldhjewzLwB5Cedo swZq4ZgsCgDKrbr9b+qtHC/y4wjrPO7+YFhXeTznn4JtSpDLJ/dozH+iCa9axPY3A49j2RIw8W1r R+g4zCiMhSOGKMXZjZVAHiSaklg8ej4blJNVxZTf+iauQ+1OYksWi7YP7WleuwpjyxrLEQ0bgMrK bgg+VVs14IFDSMqAkKCdNT0FRtlUdTziL2Xl29bgGrUfs6Jf7xifka6uSKWTCzeSEu1MHJxsbsbQ Q4yGhQsW6i3e/JUeUjDHkeEXkA9Ol/t2jrby8ay9x0q6djAj9r4Y6Lf5mrcftvGHRK0xFjrlTR4m S2Zips7eS6GMsxF3W1lvt8wPh4VOpI6GsNOTauowZ6e3se34alHtzFI8avicrUqZI8qQHdmZ/wAN 43gWpp9txeDsK21nXxFPE0fjVhGXyW/COeb235SH7RTD7bf/ALQfaK6cSxGj+EabET3X+Ecufbsw 6Ov3Un8hyx+Eqa6rYh6GmMgHjTaX3X2OWPEZ6/qg/I1E2HmJ+KM11RWmMDTaVcr7I5ftzjqlJaQd Vro3RD1X8lVJoorE2tU2s17ifRGKx80pqSduRXC6owYfYb1o43HHPPIbJjD/AC/DfLFlDbyl7Ib9 BpWftZkDDqRe1WGkVcicpLQ6FOR47JjMhkWIr+NX/F9lMx5lycUvGbr3Hsfhu9NYORDhomG2Jktl STQdzOjaMp2JvR/DBIF+refS/jVjAy58TcNncjf8SXtr5g20rLqK3lSXZ8WFpohPIkcW4Fmf03t+ rW7BKmHiqiRpLc33rY3+Ncs653OchjcfjRhJJ2KRh/wrYF2djboqqaZg4/Ix43KZkUo+g4uUQyMy kGWRpRCg2bvRodz6+kffUXG9UL8qbh6HSZvJyEAKm1vC3W32VTbPyitiDfz1qknJTRqT2VNvDWoc jm8vbeOONfmCf01hts7KiWiRpRZubboakbMyQLm//LWFDy3M5GRDiQLC02TIkMQKkDc7BRc3Ogvr Vv3FmfyXNXCxs0cjkxhlz1MXbjik9BRYzre92v6jWlVtSYs6qyrCl+BfOXmP1uR4gX6VJHkvGRe/ wFzXPQcxymW6rFFEoboTe356v/8AjKaWxpPiGI/Q1Zg00o0XyNxeQKjrYmnDk1tZhesOSbmEW74S yDzicH84FQx5s8hs2NJEfHfUh9zO1HR/zaF/Rs+2pFnkXobjwrn4pSr6g3qxk5Ld2Jd7QQu6LLkB S+yMkb32jrYV04209THLSsYN5cy+ji9I8eJNrbY3mKxIc9lklRJDkwJIywZDIUMiDo5Ww+Xx61YH Ip+sLGujZwVS8Y8qDWJt6j76kh5ix2y3VvjpVFeQj6o+tJJlQSC0oB/pDrSexY8DeizInFw1r1JM 4lxpIX1DqR+SuTZ3i9WPJvUeHjVjD9wG4jmBv0NNy6k9tymuhxGYTBkPGdNjEfcabHmheprQ5Ph8 rL5CeWIhIna6k/H4VXPtyCHb9VkkFzZRcLc+Qrk1WdT2K7SQ+LOjI61bhyo26NSD2hh/8PZHNpkq ZMWftTYbAkohlEKszK17m4fp0061p5ftXj+KyseBZlzsfMx/qIMhBtBAIB/C7AqdylTR8bSkyv7F W4GQzrca1pYsgJqp/JMawMMjxH53FIsGXjMN/rQfrLXNGrNNG73h+S1FZn1I+PS/SitbmcthM7AK SaZwMOLyHuSDGzGPbiU5EUNiVlkQ3AYjS0dt1j1NvjUIM2Qe3AhkY+XSrnt3jp8T3RgyTkbnjnG0 eHoFXiq9ybROVpVa3ZKns5OP/wCLcmDi8iTIwhxeQEmyF7ZDGbHDD8K+kaa2qkeF45OCXkeI5GfK TFmixMsTIqL/ABdiI8I2K20mRbbidKt+x0jXkwyWu3F5m+3n3cXr99Q8ShHsbkV8Tl8Z+VsKvTtU Q0edWacpsdx/t/jsmLCfPz5cbJ5VpBxsSIroyxkKJJ9yto5IsAV6jXy1uNRTi7WiWKaJ3hmjT8Ik iYxvt8bbl0+FRnOgxOI9ry/QY+VNFhjt5ORI0YilxxCHW6q3q3a6+Rq5xaGaCXMLIxzJXyCIjuRT IblVbS+vwpCWiJazerM+c9v2/lG34eZQ2Hwijo4o4ee2LAeXmiz8xAUjxoUbFjkZO72ZHkRmZgAb 2dfso5CRYPb2bK+ixcwrtbyWGMmn8ZDHxvuHh8WeL6nkstfqHuSIsaORJtoijW25/wCG2526eHWq QZiZU2WmdJmZEmFDxKhc04qo8rTGWSDbH3ldQgaI3JXx6in8DInKc5Dh5ryNjQs82PvjMZyTG107 i29PbtuI03G1tKo8fyWNge4M4ZG2TEzszNw8/Hb9aJ8uYK9vHtl9R+yx+FaHCYj4HvSPjXcyDCM6 RyHq0bRJLHu+IV9p+IvQBxHaUPFhSy5HHRqgxppk7bk+rettq3UaWNLHjcXm4/M5PKyyQ/SIsKhF LGKJzfuqCCGaRltpeyj4mne2yj8RjhWDFUAYA3sfI0zKW2B7lH/8DE/ty1CFTiY4Mj2xz65WS+Pj ryMDLksn8QxxSY7w/wAOw/iSKqgC34jUHLovG4+PlYOVJmYfIY7y40mQqiRHjKh1ftrGp/GLenwN SwhX9rc1sIZW5HA2sDcG8mH0qvzak+1+AH7OPl/keOqUtTcXInuiH279XIY5XAOVtTugHHmyLW27 OsdulNl4+BcPkp8TlDl5fDAyZeP2tsfaUsG2yWXcyhGuQbXFrVpZSn/6n4jeHcUf/wBjlVkcWpGL 7zP7WDln/wDmZtSEWWGLjY8mLjZvK574EGfM0ODHBGHdgjdtpZGcMFXd8OljfWn5+OnHcrNx8GRL lDHAE7zIqFZGAdVXYqggowNMGFBy3t/jPqcqHjo+Imnw5pspu2kkUrpJugaxDyARhdvnf4VPkTpy nK53JRKVhyZF7G4FSY440iDEHUbipIv4WqNKCpuSv25m4vM5RJ2L4GQkU+LtXZ2JdoWUG27Qvrr4 Gj6PkGPCQw5BbN55XlELqO3DDo6v6bMT2zc3bWx6Vc4VIv5xLxmVf6Tm8aTDmANvWqs8Zv8AumQD 4kVPBlxS/wCZkQWy42IjcfigfhBihZzb5Euv2VUkG2VcvGxYMTKzeJ5OTkRxsqxclDMirtDNs7kJ SOP0qwPXdcA66VWnbKxYOFf6lpG5vGhnbcqfwmleBSI9qi4AmP4r9Kh4COWHhvdvfBG3CONJf/3i +SgX94O35am5RXeH2OiAsz4eKqgaklXwywHyAuaQSTSvJhchn8fJK2QMOZI0lcKGYPBDPqECjQyE dKbFC+fLyLfWfRRcbjwz7iqmM9xp95kupayiH9U03lb/APEvM/8AzEX/AOUxqihB/l3uv/8A1uP+ fMp1HQMuSLBwcTlMfObO4/MeSFnli7TxyxB2I22U7bRvoRfTqasR4EsxixTnvDzuTi/WwccUQ44Q 3KxSPs37yFNyH08vPH5dHb/LzERfxnkssD59rOroPcXuDH4znYM3H43HmlOJHLBnSytGe2/cTau1 GXQfnqkMrDyoM3Bn5XMypMDisXtpJJCivO00oVhGodZANqsC3pPX4VJlY+XByY4RXXJyJ3i+jnK7 Q8MwLLKyr+wEfdbrtpOKnxsf2byDTYcWcsfIo0kLsUjAljgCSbkBO0brXp/Fcr/MvePF5s0UOOsI +jRIXMgXbDkmO7Mq2/vCopAktYeDw+LH7hTCz5szKgwJ4clZUVVuocMYmRV0V1Kka6+NZ+NxsDY6 ErqVH5qOChmif3PHKp7kGFlRzk30cvKwv+8PUPMa1exh/usf7g/NUaEtGJJwxH8iSKcmXn8eKYmQ LtiaTtFtuwLcASG1/IVPLxuBFyZwsDIyslYWmiymyYgoWSJlT+G8aIpVju0Ovj0p3MSdrjPasok7 MkXExyRS/svGMaRW/wBXbc/CtSeeLMbj+fgXtjlmbGzYAbquXCjnep8QVhZb+IC0hF3PuVIuPy8L Lgz8J1XJxmLR71LIdytGysAQSCredJJme4om5NhJB/4wP96UxEqh2dndCO5+wAPVfpfzv0UUQZBc VWzcdAhJ0AFyaQHaXk5jIwcXE4PCyZsvJ+uz8b6vDxUjV8fZ6SkcjbO5uIYAtusD1p2HxfGScc/K cznScdgNOcbHMChnkdQd7EtHJ6F2t4fqnWrcSQczwOZxCOGyeJR83i5l/wCxN98DfAX2/IqfCsjm l73+XfBvFcxRZGUkoH/aM0xW482sfv8AjWXVawbV7abmpZocbxCcV73xePzpWKwyLLizIv8Aelx/ BuNbA+sH4ir3F8VwmX/mJmHvPMIHkyVgdCAcpZP4nqsBtiJFvM/Ko+XDr799uxP/AH0GPipkeJ3X msCfhqftpvtfuf8A1L5K59G7N2j/ANrHeqkljxI3Z5b/AI/rBhw4mEjW4uWXI49UT6eeZNjsNut1 2rp5G1aGJjYsuNk8nyubLgcZiSJjb4FVpXmYBzbejgKikE+nz8q5fAzM9MKAR5G1FjUAaECyjSus 4/kMeL2BPk5eFHyvZ5EjIikYooLqoWQlAfB1H21zqk7NtHfk314651hShMjD5PH58e345BNkSSKu POw0aJ1MvdYD9lVa9vKrU3GYD4fMT4PMyZU3CwSyyxGFUvJEshtuKWaMtGR6dR59Kre2/cJ533/g 5s2OmIPpnxo40cuC8ayuG3FV12sR9lVfbAnXjfecU4tJBx00T+e5RlA7vjcGtqte2pxta/VxCFyZ JcT27ic6shds2bJi+nZV2IIDOqFSFDa9oXuavZuLPgczi8MmU8i5qYj95lTen1MssThQqhdBHpcV m8oGb/LjhQNWOZmLp+0z5e1fmfCtr3CrL764ZSLFYeNDA+f1ORTau3Ym59+5FhYMubzmfxEma0Mf HJM/1OxCW7bRqO4CLWs+u21RzpBFx8XK8fm/zLAeX6bIMkXZkilI3Idth6GuNCL6jU1Z40E+7vc4 Gt8XLsPtirL4jT2LzLNqkmThRxfGUNjk2+V1NNqjTuNz79i6vGYAwuJzuQ5VsReXS4iWFXYO2zaI 9qGyDd6me/h51NF7eT+ay8LkcskfJ2ZsSGKEsjIBuVp2bozAX2KwsNb61nc4CeH9nfDEf/vMKtm3 /wD1e/x//wAOrC7El9zF4qOPOhyczNlbAwePjQ5kkKh5TLI3bSGPeGW+4akg+HnU2RgtDzWDxceS ZcXkxDLi5wVQ5hm3aldu3cNvlaxGlP4GeCH2z7kM2ImeIsuOaTGkJVTGZFAZmUEgIUZvsqHE5kcv 7k4ELjw4icdImNHDBIZAE/UBuq22hdKm2uEXdbJbk4aEfzPGxOWOTyXFpJMcXsgI0ceuxpLLeS1g xU2UnpTOFxuEzuC5XkeSnkjKGOEmNCzQRmRHQoCpDNKygm19LDzqThx/+qPcx84M/wD75az+F09l 86TpZ8L+1HSEnKS6ibNQ2+hFj4+XNjz4xnZcWaYzBQu13KWSFpP3Qu8LYerrV+GKX+GZ3DtFEmPE qjakcUQ2pHGtyQB8Tc03DkBQMpBUi4IqcyEi5Fea17PHTseivGsMkDAAWPSnK1+n21VLkVNGOhrK RpqCfZH5f+minafkorcGZN/GxIYI9kKBF8hVfKwcgTwZmG6xZWMxaNnUuhDKyMrqGU2IPnWoq2p2 0GvSeRucnNrxPKfzJ+WSaCDMmhbGkWKA9rtOyu1kMt95Kj1X+yiP25NDjHBhnAwZHx5ZomTc7Ni9 sx7ZNw2/3S39JrpQq+VLYVZBgLxufjxPi4pxpMN5DL9PmQGdY5GO5nitIlrk3sfHyq/x/HDFxu0X Mjs8kskjAAtJK7SyNYaC7OdPCtCy+VKLUBz2XwEsxlgaYNgTzjKkxynqMoQR/wB5u/DZem37aOx7 iRIIosyJBiWWGfsBp2jUgiKWRnsV0G7aAW866GwpNi+VJBzcWDzMWTNmCTEmmyHWWSKbFBhSRL7Z IVSRXVterMxpY+Jz48sckmQrcn3Wned0ujF07WwxqwOwJZR6tLCuj2L5UbF8qSDIw+PyFyJ8vJMX eyAoZMeMxRgJuOiszncd2pvTJcTOx8qXJ49ob5Maw5MOTGZI3VCxQ2V0II3t8xWztFIVHlUIcrBw GZHDPjHIQ4+blLm5cYiteVJVnURHuHYgKAW10pZvb00+PHhzT7sXGjlixVVArIJirMXa53W26aCu mKjypjAVZKYD8dyT568s2Sh5OOQOsva/haRSY9u13L/gkP63WqcvEZePBlxwTqByMMkGcWj3bkla R32esbDeVvOuoIWopogwpIOWOfx+D7c4zE5bDXPjzRJn4g7n05hglbuWE19zP/EubWt0JqdcSDGy oo8UyNh5mLHm46T6yxiQm8chOptpa+vXyq9Hj8rhxDGwpoHxUYtFBmQfUCIk3/hFZIiAL6XJtUmP gZDTy5mXM2Tlz2EkrAABVvtREGiqu42Hx1uaAo8ekUPN/XT/AOH4jFmzpj5HaYk+9TIfsrNxeKy3 ijyGdoc4v9SZl/Es7N3WYX/pk/Otyfict2yY45kXGz+0uWrRlpCkJ3CNJBIqqrXa90PU1pRY6qNR QSYPISc3ycIxs54Fx94lkjx4jH3ZFsVeUs73sQDYeNRwSc9h4iYGLliPFiN4gYg0iAnd21kuPR4W te2l66U48Z6rUTYkZ6CglGDHDky5GRmZjLJk5biSVkXYt1jSEWXc1vTGPGmzYeVbLjglWOHkIUx8 tGTcxSMyFdjbhtP8VvA1uHFA8KaYLeFQsowv5flNBFhNIpwsfIfKji2evuyLIrXfdqP4rabaswHl sfGhw4Wxngxv8HJkQd2bHHgInLhdP1brp8a1Ox8KOzbwoDI4/AyuLAHGugRoVx5oMhO7FLGgsvcU MhuATrfx1BpW4iSd3nnKJMe2I/pU7CQiEl4uyoLW2sS1yetbAS3hUii1WSGdO3uTLhlx589Ginia CRewoujjazelh67ePT+jU8fHhI1QdFAA+yry28qeLUBzn8nzlbAY5Kl+IiEHHntaKgCpaVS533Vb HpVxYM3IeA5nYSLE3fTY+LEYYlZ9GfaXe7WJHwua2NqGk7aDwoQjQWW1R5EQkjZGFwwII+Bq1tWj Yhqg59sblRhPxySwJjSRLjSZCQbcpoEGwRtLv2/h03bfy60YcPJ8WZF45oexMyu+NkRmSMSLa0ib GjIb0jx8POt/tRil7cdQpyx4bLfPHKvkF+SEonE7qCu9RtUdsbfSF0AvSQ8ZyuFyX83xZo2zjJLJ IXQ9t+9cyJsV7gXNx6vCuq7cflSiGM+ApBdz7TiDjMrhs3Ny5czLgiEstgUx02RgKLCylmN/M3pM KHlOGeZsJIzDkqEycXIjMkEluhKhlINjb89dp2E62prY6HQi4PW9Z2NOZybXLNVR19JwOTjZ0mYO S3pBmIyNAcdBHHF2vwKia+keIN71rwc3yHJcT7oizIseIpxckrHGj7Zkdo5lLyFmYk2TzqfNwnxp nQ6qdUPmKzmgzFjzosWSOOPksY4eT3I2c9shxeMrIm1v4h6g/KsVs0/Uzdqq1VC0IOIyubwMOTCw coRY8rF7NGrsjsLFomb8J8dQdadmHk8nNi5TJmRs3GEKwOsZCgY7vKm9S53epzfUVoRRBR0ps4G0 gVl3tGpVSrehF7YyMpee5XPdgct8DInZ1Wy9zfGbhTfTSqpz+Q5jGxVyRBBiw/xkxsWLtIZHB/iP dmufUelutET5uJkSzYZjVsiB8WUSozjtyFSSu2SOzenqb/KpsPG7ESRjUIoUX+GlV8j2pTnqPa9T fTEFefGy8iDDx55VaHjY2hwwqbWUM0bes7ju/ul8BUhm5Qct/O+9H/Mt27f2/wCFbt9i3b33/D/S 61bI8KYVNZ327mvbr2KfHvncVkHKwZFEsilJ0lXfFKrEsQ6Bl6Em1jpRJJmS50PIgQY+Ri7fpo4I tkCBCzAdvdc3Lm+tWxH4kUdsa6U320kvt01gpxNyGPlZOZDMgyM5ZkymMd1KzsHfYu4bdRpqak4v Kz+G7y4IhkhyURJoclDIh7dwrel01sdfOptmtL2wfCpvt3Ht07FfGjMYN9WZmdrCwu7FzYa2Gugq ZvLwqQJYUlqzE5NSlhEYXzqeIdKYR40hmCkVUHLLlFVfq086K1JnaduBTqLUtdzyCUlLTJG2rehB 1xRuHnWBJzeSrGZoFXCGS2J3u5dxKASN8ezQNbQ7vEVWf3Blr9I30pdeUBbjUjcNJKAyKCyEKEB3 g33dNTarBTqQ486Nw865/LzuX4wJJymNHHBK2xZseUzKr2JCS7o4ipNtLXF9L9KhPuDMjXHE2MqS 5yQSYSCS4ZcmRIY+42z0Hc4voaQDp9wouK5xOX5CXM/lkeMh5JZGjeIy2jBRFlY93Zf8Lj9WpMDm cuYYkmTitjQ8grNiszhmOwXO5APSCNV1N/hSAbxIpCR51l5XIzd+PExIxPlyhmRGbYoRLb5JHs21 V3DwPWqGTzeVgl4c+BUn2LJD2ZO7FKjnarRylUuNxsbqLfdQHQEjzqCeQKOtZbN7l3Sq3HC8Gr7J 1JcWDfwAVUvbdre2ugvVPJzOXTBXkZ8JosFigLF17yCQhUaWHqoO4eNxfUDWkAtQcvJJJEzwNHjZ TSpjTFlO8wMVe6jVehtWmjqResDGwOQzeA4WbB7O6GbL3HIl7SXklkVRuCu1z4WU0sOfyAyjxf0r fzNGKnG3KBtADd3uHTt2Yer7LX0pAN+ynyp6haxJczkcIwNnxQiHJYpDkYs3fiLqC2xi0cRDWU+B GnWkxM3mswYv0+ErHOxxmY571l7JCm8hMfpb1j060Bveml9Nczhc7yGfi42bg4Zmx8yVceH+IFk7 rJ3TuW1giqDdr/ZViHk+RyZsjEgxlGThG2Y00ojx4tWUXm2sTfabWT52oQ3SBTSBWJkctl4Epx+R hEeQVV4RA/eSYO2xO0+1CTvstio6jzpMzlszjW/8USCJDu/uJ+8yMqGXZMvbTaSgJFrj40BtHbTS FrGyeS5HCWOXkMeKCOXaO2s4fIj3glO9DsULe1vSzU6B/cWVHDJDgJsyYlnidpwqlHG5VJKX7hH6 oBHxoDWstNIFZSZHONjyZX8udYccMZkkdVm/hkhzHFrvAIOu7XwvSRcjkZ0hi41I5WSMTSSzSdqF I2uEZ5Arn1WNrKelAapAo9IrFfkuQXMHFvjhOSaUQiBn9BLI0iuJQpuhVTY7fhanzSc5jY0uZl4Q ixsYsMhhKGdQhKmQJYEx6Xv1trahTX3r50PKFUsToBc1iQYfJcxiTcliSLEuLKiYiPJ20lKyx/UO 7AGw2Bo1uPEnyq1h5wysZZgCu4HQ+BBsfzUIS4fJSyvjiaDspmwHKw33h98I2asB+Fv4i6fHr1rS DAiuShyUwhj5K4KRNykCz4SwsGeRJGQRx2KpsLNKvpva5rXjy87Gy0xM9IFeXcFOPP3trIAxjlBj jKNtN/EfGqCznZz45jSJDNNPIsUMYIW7t0ux0AqkOZyDIMQQEZ5mON9KWUWkUF/x9LFRuB8qTKcn luLHnmR/man81hmL3zw2dB6sfOlZZiOgnx4pYzf4shA/1aABzf8ADIkjZchZmxjjrZnMyuY9iWNm uRpUuRkcxgxjI5HC7GMSAZUkWTZc2HdAtt+YuPjWfwOxvdnLZMo3RcW2bkAHwkklZVbx/UVx9tQe zy03JDHzP4qc3hy/Xq3SWU7G3N1/VZx8vlQpq4uRzmfCMrBwRLjMzrHI0yITsZoyduttVqzj5WfD mR4fI4300s8byw2kWQMsRjWS+3pburXO+zIRD7hwRtAm2ZMeQ4Fi7xjY7H5sCat+3IIURskIBNI8 geW3qI7jeP2VAdWGW2pppljHjWLlZ2c874+BB9TLDCciVd+w7AbWT0tuYnoNPnUGRl8phdluRxex FksUhkWRZAHAZu3Jt/C1lPS4060Ia2YkOTH230I/C3kayzxs4ay7WHne1MhyOYysX6/GxEkxCrPG DLtyJY0Nmkhg2HcvldgT9opMblJ86SODjIvqpZY+8CWCRJHpZ5HINgb6WBPw61l0TN1u1gfJg5Kj ov3iqkkTg2IuaJ8/kfrk4zsxTZ06o8CY0wlidXMg3d1kjsF7LbtKhzpszi2A5OONEkjeSKfHk7sT iP8AGocpG25b9NvyvWXxmlyMRiUP4bU36kedqXNj5LCjjn5CKGFJSoMQmDzxbwSvei2ALe1vSzVU yMLPjwo+TniijxplSRYzN/vPblZUSUwbbbfUP1r/AAqe0b91dS19QBrcGmtloPKosPguV5GJZ8OK BIZSwgbJm7TTbNG7KKkhPT9a33VVx8HKzcp8GCADLhSaSeKZ9mwY7JHILqHudzi3n51Pafcvu1Lv 10dMk5CJfGqqcLyEk/HwDHSOXl43mwVllKlliVXbeAjbW2uCBVKPi8rOOQIECHDhknyzJIUEaxNs cXCtdrhvup7TL7texqNk5EMOLlZMDQ42ehkw5WKkOq21spJW4YEX6injkMe34h99WeaxhyPtr2li hhGWxkdio1Hbx41YD7WpuP7OwTGN8kjHzJq24l0M15VHqRXPIQ+DCoTy0A03AGtse1eJWEoIzut+ Ikk03A9q8VjSGVou6/gX1tU9vxNe7XsYUnKwW/GNPjUEWblZ7NHgxNM69bdK7FuE41pC5gS5+Aqz iYGNjEmCNUv1AAFaXH3Mvn7I4z+Te4/+xHTd1HX9mivQr/AdKKu1djHvXLdFFFaOQVHMLoafTZPw GgOaOEc7I5Tg9wjPKQLlYrt0XJxiq7jb4dr7FNGIYZP8wsfFjH+68RiHFxRpo8ca7iD+7PtP7tTq U/4ixZnbZFgRZGbO/kip2dp+fd3f6tZnHY/IIcbmYUBz+4+ZJE5sH+o3NLCW8NJLDyIFUpm8E7ze 1/cHe134mJnG/jkuZpGbXxLRL8auckSMv2qPPH4y/wD/AFWNV2XHilxZuP4zjpsDHzJlnz5MhkJI Rt6wRLHJJ6dw+Ate170qpJGnGjI4o5uXw4jjgyu8FRooytiYyy3kAXTcNobW9UBx5P8A9RMgeHfn /wDy0FLwkMeSDyjIDPkFyjnUrEWPajW/RUQKooxo8+LnH576N27k0jnEDoJAskUcQ9RbZoUv+KtP hOPlxOMx8eYDuxxgPbUX8dajBn7MaSb3AM2VoIF4yJXlQbmWOVsrvFV8dEWsXlpsGTB4rF49p5v5 cXjlmnhaH0TSxOAN4HQqBYV0uZiyQZbZSQfWQTwvi5uGCFMsL/sliq7l1tcgWJrFl4V5yWwIcmGF ENxnSKzyOHidAqxllQIEYXOp3a9KAvEsf8zg5JJU9pSfBPozJsHw3EtbzrG4os3E+7nbV5MRJHY9 Wcy513PmdOtbG3kP5/8A8Q/RPbvbvpN8fd2/TfTX3btn4tfxdKpw8ZyOJh8liDGMp5bFSDuKyBYm WTJcl9zAnScfhB6VQUuUVX9o8JG+qGTOJB6XDS6/MXqzz2NmcpyXEpDGZc/P4qL6kFjGuy5ZzOw1 Ed2O7z0GvSrSwxnisfieR4iXMjw5JXEsU6xFhK7tZLOpIKvZgxH208T5yc2/MZWH3oMjHbBlwoWG 6PGO1lCFtgYhgd2o/Fp0FAUpFwY/Z+3Bn+pVeVTfKqduMuVW/ZW5Oy1rE9etS5hM/Be18DXtycZH POASN3ajgSJTbqLys3zApZI0bhJOFw+KnhRpO9h5DzJdZLbRJlWa9167UuCLDSrGDh5kqcZFPjtA OLwBhMzMrCRgIhvTYzWX+H40BBAxh9ptjRfwzkco0ClfSVQ+qQLbpujVk+RqjJxkLNMsISDHxY1l y5pdzY8QBbtkwqf4knqbYvWtf6HN2R4HYPaTPbOOTuXZsaN02bb79128rfGiXHWCPOxMrEmzMLkT FLfGZFljmh27P7x0G26KQb6EaixqAz+dEa4ftduNZnWDDllxWmAViYJMGWLeFJA9SCk5/ExMwrzW IoGLzaNGWKjuY+UFIkQnwvs6ftKfOps+OTkMfjIDxD454u6dsZC9lsYtGTCrL62dhEoJYKBrqaTM xmm4pOK4vCyIIVnOXkSZ7xlpJAu1Yl7TSaHS7fDxJqgj53tZ+JD7ojjXuOBicnHoTBlAdtXU9bNc J8QUNHKFjme0RckRw8cyD9kvkYyMR5XGhqeSCM8bPxfG4OVjDNmjlypsuSN1RYirqkRR3ZtUAuR0 6m+lMmxs/JPGTnFaNuIiw4zGWQmU400UzmMhrAMI9N1qAt8WS3+ZeczeolJo7nX0LHiEJ8gT0rH9 uQ4E/sPOHIzvjxPkYcbyRoZW2rDiPEuwakGRjWritm4vPy8+cN3E7S3xVePuKJEgRbksE/6o+NVe KwJOL444GZjPm4WVjwR5UMBVZEmgA2zRb2UHoPHwFqAVMvEzPdvAS4TSyRQJHiyyzRtEzNFHkFTZ wCdGNR8aWbP93s5LGTH5AOTruEc88aX/AHVG0fCnY2HJi8nByWJjZBxsWRHXHyJEaeRgs6vJo3bT cJFAUHovmaWCDOxzycwxWduXiy4xGGQGI5M0syGQlrEKJNdt6AgwUV/aXLo6hlfkOPDKRcENJh3u PjWwg2RBVFgBYAdAKqYkKYmLm8bnYeRlYma0EyviMius0G3T+JJHbWJGB+d6u4GNkjDjXJ1lt6rm 5+AJHUgdaEMXkWmjwPac8ADTY/FwzxKdAzRHFkCk+TbbVozR4S8nDzWGith82GaKUgB45wN80DHr 6tha1/xK1U8jBzMiDh4ZsRu3w+LHiTxGRV+oC9pWMbRsSukdxe2tulXoYUkgw+Pw8TJx8PFnfLll zGjMrysrIqgRO4t6ySdOnjc0KOm15Pim/wDjIvzNVvgciLM9wctxmTcvg5xz8InwuOzKF+C7v+fT MvGmV8XJhjMrYk6TmIEAsFvdVLWF9fGqePBn43LHnY4CJmyJJXxdy7mhlXa0Ra+zdcK3W1x1oQZ7 eUye5vcuIPx5q5Qj/wDZzOp/74VB7KJn5njGGgjw5Zm+A2xR6/a9Tw4fIwZh5eBBFmfVTZCQu2hj mdi0MjJuGqnwvY2PhUvp2ZcXFcXLxk3IDZl5U0qsEjYkyLjLHJIRu3G2iW6+AFClP2i3d9wYOQPw 5H1k6fuykyr+Rqt8F/gR+/J/3jVJj40vG52JnY+OZ0xVdDBGVVrOu0bd5VdLedWOKwZcfDSOUASX ZmA1tuYtb7L1AVkkkjy+YkjYpInEysjKbEEFiCDWBJeH/L3JEQ29rkh21H6v8FDp99dBnQ5cMuY0 EByBnYUmENrKuxnvZ23kenXw1qiOPy/5c/Dtjlo3zFyzkbl2bFjRCm2+/ddfK1UGhmS8HxfPcTmz 5WQkmFgRLHiQwNLG0RWeJWLoptfcdP6IrF45e37U5tkBXu8jBiG4s30ZaAopHgGEzKfmavyQxzYu Njcng5eRlYMf08OViSxxrNCPwLMzurqR4kC/Ug62pONxcjjIJIMrHPI4WbCsWfjqwEm9Pwyxs7KC dbH1A9CDcUAz2xjYsfOZDBRj247IbfGoDC7wqzgAalR0rPzBxEvtzC4Xipsicw5LzLNJA0SrHJFK p2lhb8Tg2vqa0MSCXB5hOU4vFyBDHGInx82UNJMrlu6BZ5FTTZbzK61Xy+IjlCrxGLlYsaXLJmSp t229OPGsTSem/VmudPGgH87FByuPj+5ViXdLtwuUi0JgybdpXU9bNuCfEFDSZkUPJcPi8uY0kzeE VMLkkYAntIbxZCXH6u7d8i37NTZUCvxGVxPFYWViNnyJJk5GXJG6xiIhkWLY7s2qAXPh1N9KdHDB Fx+fhYXHZONk8rCMbKeWSN8eOMhg/Zs+8/3jbQV0+A0oDN43Bxhl8XyGdI2NjS5sEfHKbyTzFJkK 9tWNooA7Dc3j5agnZ4nYP8x+YMgvGMfJ3D4W4+9Qh1jxOLil4qXL5DhFWLEk7ix47pGU2M53Ftw7 atbb+LxtTo5chPceTzmPx06xZmNJjvjvJF3BLIYbymz7Au2ECwYmgMaF8hI4OfIL5oZM5jcknUSP Et+ilPQAPCug57Ax+PweSycVw49zZMCRBfCEqZ5v695T/rCqskP8t4Ze8NxxMcb7eJjTW3ztUubi zJLxXDs248RgRiU9R3pgE/5ixG3waoCvxgnn+hx5EZU4qHIgDMLA96YMm3ztFGn32866GNLJasbj MRk+iWLFnxp4oyOSyJpBIk77QBsAkf8AW9V9q2Gny30XSjAwrSBbVLto21AR2pQaftpNtAJuopdt FUGhRRRUIJTZBdbU6g0BzOXi5zy8ljLiyOOTEGMMkNH2lxVN51YNIJNzdyQaIR0rcgx1A1FWNgpQ AKFGdhPKjsJ5VJRQgwRIPCnBQKWigGsinrSCFKdRegE7S+VIYk8qdei9AQtAnlUZgTyqwTTDQpEI I79KlWNRQKcKEDYtNaFD1p9BoCE48flTewlTGmk1QRGFPKjtLTzSE0BGY1ppiU1IabQDOytL2l8q dS0AzsrTggFOoFAN7SmnLEopwFOAoBNgo7a06kJoBhjU00Qp5VJSUA3YtKFApaKAaUB60naXyp9F AR9lKOylSUUBH2E8qOwlSUUBH2E8qOwnlUlFARfTx+VKIEHQVJRQGTy2NI6RFYmnjSeKSaJCodo4 3EhVe4yL6ttjdhpRhwTz5OVn5MZilzJjJ2nKlkRQsUStsLLfYgJsSL3rVKg0BQKFGrGoFOtS0UIJ ai1LRQCWotS0UA21FOooC3SUtFQCUUUUAUUUUAUUlFAFFFFAFJS0lAJegmlNNNCiE00mgmm0A4U8 UxaeKEFppNLTTVAE000pppoBCaaTSmmmgCkoooBaKKWqApQKBTgKgACnUAUUAE00mlNNoAooooAo oooAooooAooooAooooAooooAooooAooooAooooAooooAooooAooooC3RRRUAlFFFAFJS0lAFFFFA FFFFAJRS0UAVHJJGmjMFJ6XIFMzMj6fHeX9YaKPielcyMTm+TeSbGkihhVivdmBYyMPxWA6KDpXO /I01Wq3WeTrTjTTtZ7a6fE6c/Cmbl8xWbwf8xTv4+fF25Iiu1lJMbg7vUhPy6VltDymSQMBYnexa TvEqPDptqW5WlX0ZtOPIteJN29WKxnzOpBW17i3nTt6eY++sKDC5teJyYZFg+rdlMKhm7dgVvuNr 361Q7HKRqYZlhGYSBGqljH6rbbnr41LctqpejXx69hXhrZv16eHTudXuB6G9Z3MSzRiExuUViVJB IN7XA0+ANN4SDkYIJF5ARq7NdRESVtbx3eNP5hQ2Jv8AGN1I+09v8zVq824m42uJjyM0ivKlO5TE +ZLizk4SzOblVJJ8TtuP0VR46ed8va7sy7GY7iTqCo/TTseUrxct+gJUf61v/WpvEKd80nh6UHwI ux/OK5qztbiU/wAZZ0dVWvK4/lCG4uTM2YoZyVctdSTYaE6fdWlI+yNn/ZBP3CsjD/xsfzb+y1aO c+3FfWxNgPtNa4bNcd2+jsTlqnyVS6pFLByJTkqrOzBrixJPhetNmVFLMbBRc1g48jJkBmPpDBlI /ZB2m/8ArK1a3JOVxrD9dgD8uv6Kzw3a47t5dc/PQ1zUT5Kpfyx8jK5Dlpu4scSSSySX7ePCLsQO pPw+JpmHzM8WSkGVHLiSOfTHONHHjsboTWnw+MqrJlEXeY7Q3iETTb/W3Gr02NBkKEnQSKrB1BHR lNwR5EUpxWsld3e55JflrVuiotqwV+Td0x1KMVO8C4NvA1k4/NSLlNj737i6hZAdrgdSpPW3wrW5 f/DL++PzNVV44n4iF3A3xuxjPjcs6n8hqcsvktFmttdxrihcdZqnuttNXHmWeFZV0DeHkajzpWjx ZGU2a1gfmbVX4ZycaQfsyED+qp/TScu4EKJ4s1/sA/5a6u79nc9dv1OSove2rTd9BnF5EjyOkjM9 13DcSbWNvH51o1hcVIwyIy5A336fsuNyD7iK3an9dt0h9G0X+wkryuqTEJA6m1G5fMffWVzWNy07 xHj1hZQCHExYWPhbaKzTDyk6oMFYWktulEpYAdPw7aX5bVttVJnTOopxVtXc7xGvgdR+amq6MSFY NbrY3rKzsmfHwYYHH8YRKZVj6FgLbVv5tVGFOYwJkfNEQEusbQliFYamN93W4/MaluZp4rKrG59h XhTWbQ7TtXc6X50gIPQ3qrmy7+PaRdN4X8rC9YEr8nAzZKY3cwk/FNG3rWwuzFOpA+FW/M6tJV3S t2Owpxbk27bYe3J1VISB10qrx2UZ4iHN3S2vmD0NV+YkF40vbqSPnoK0+VLj3rJlcTfJseDSuALk 0txa/hWXkM78OJF6xWLD+irWa/yXWgT/APhRW+u7t/l3fmqPmjp/Hev2KuKev8tj/c07i176UtYY ZxxsdzpNIzKP6I9K/f8AirWxHL40bHrax+zSrTk3OIjCt8yX49qmZy6/ImooorocwooooAooooAo oooAooooAooooC1RRRUAUUUlAFFFFAFFFFAJS0UUKFFFIaEMznJLRRR/tMW/qi3/AEqkx5YcXjsc v6QUW9tbsw3H7zVfnRpA56bmQfMjd+ZDRkYC8lxkEHekg2hG7kRAa6rttreuOfcvGu1Qd8e3SdNz kuwZUORcxG+3rpbrWNx+UuMxdlLbltYVZ4X8c/yT/p1Qx+J4/k2CZ0XeWNboNzLYmw/UZaw7Wv7T UKz3eRtVrT3U5dVt8zexcpcmPuKLWNiDWbl/+aJ+/H+davYPH4nH44xsOPtQglgt2bU9dWJNUMv/ AM0T9+P86105Z2VnXdWTnxRvtGm20GteocyNpcWaNfxMjBfnbT8tT0ldmpUHFYcmFFN/ucig3V2S 35Tf8lXuKUDFL+MjsT/qnt/9GsogRbo+ixMya+SErf8AJW3hoY8SFG0YIu7962v5a8v9dN2c/wAF t+p6v7DW1R/N7voZmF/jY/m39lqt8q1o408yT9wt+mqmF/jY/m39lqfzEyxuWc+iJNzeNupP5Kic cF/G0Fanmr4VkhliCQYrqP72NmY/MhwP+eas8jIXixif11LH5+n/AE1kR83jZLx44ZzbSMMjKBYe ZFaWQwPHwP8A9nIY2PkHuR+XaKzuT9xLE1X/AGmtrWxvMWf/AHFzEkEPFNL07ayP9xZqpYvNSZAW SKVZIy1iQBrbqOlaPGMkmJ2yAdpIYHxDa/prPy44486RI1CKGWyqAB+FfKt3dvb47Vs0sKEc6JO/ JW1U3lyzQ5j/AAy/vj8zVhDLWV3xVciSIXCsDYX/AFl8xfrat3mP8Mv74/M1UJoA/FQZAHrx3Y3/ AKDuUcfLXd9lTmq7clo6Vk1w2VeOs9bQaHFwR4+BFHGxk03PIerOxu5P21T5qRt4VRcohYfM/wDo qfiZLxPGf1DcfI/+is7lsuKGaWeQnYjAaAsbiw6D41eS6fDXxhfIzx0a5reEv5k2Si4ueNvRRG/9 X0W/5lbNcrDy8GfNtVnaQLe7qV9IPmQPOumxn348bXuSoufjbWtcFk7XjE5Jz1arScxgkrK4f+9b 9z9IrVrK4f8AvW/c/SK3yf8Ak4/Oxjj/APHyeVRZk7vKhT0VkYf6oD/oqzyig4hY6lGUr8ydv5mq q0hXmGJ/aVR8mRR+mrfJEfSMD+sVA+YIP6Kwvs5vOxt/dw+VStuB4cj9lgD/AFwf01Pxf+FIP7R/ MKrJrw7N+0/9mQJ/0as8X/hj+8fzCnH99P8A1oX+y/8A7CvxUfZyXhHSNCtv3SBUXKKcjKMIGu2y keaqZR+UVJx8hfkJGHRkdj9rLaqz58GNmnIkdPUW2B2C9T1F/IVzle3VP7Xd/JHSH7lmvuVF82Xu M2TYskLepSTcf0WFqyt06wHH3XkD9sX6GUHtA/a1X+EkS5SNg0ZQWYG4O3Tw+dOCIeYYEC24Nb4h A1/vpG7j4/8Ads+ZJ28nJ/t3/IdyUSQ42OiaJGRGo+AXT+zVzBFsOEj9ZA39b1fpqDmEkbCLQoZJ Y2VkQeJPoP5Gq3FGIokiXoihR8gLV6FWOSz/ANKODtPHVeLH0UlFdDmLRSUUAtFJRQC0UlFALRSU tAFFFFAWqKKSoAooooAoopKAKWiihQopskkcSGSVgiL1ZiAB4dTQJYjI0QdTIgBZARuAPQkfGgHU 1jSk0xjQhT5XEfMw3ijYJMLPC56B11F/geh+Fc9B7kXC3Y+V/usyfjgmB0PmrDQg/CuqJqOSGGW3 dRXt03AG331zvxOzVqvbZYk605FVOtluq+hk+3MqLLGRLCGMXoVZCpVWI3X2362rIi9y8dhyMonC yL6HBRzYg6/q/Cuv0AsNB4CmiRGZlVgWSwYA3IJFxf7Ky+D01StDrOY7lXN6rN1lWjHkZ/CcxFyk crxOJFiIBYKV1I6eoCqudm40fOw4jPaeRo2RLHUX87W/VNbdNWRHBKMGsSpsb2I0I+ytvjbrWrtL Tme5lciVnZVhNRA+9ITSXpK6HM5/kZIF5NsJ3CyZLL208SHAUt/W3V0FRSrjKRPMEBWwEj2BFzYD cfialrFOPa7P/Jybvfcqr/FQc9xnI4c/LDFik3TRF96WYW2hlOpFutOfkMTJ5z6JJL5Cyi6Wb/qr M3qtbovnXQUhdFdUZgHe+xSdTbrYVj2Iqlu0tu0+ht80tvbrXbr9SDklBwJieiL3D/7P1/orM4fI weYwsvFik3oNu5gCpUtfaw3AagrcVugU4Ct245urTommu5ivJFHWNWmn2OSPJZHETdnkN2PKPSs4 UmGUeanUfMHpQnMQZ2aqY5bKnlZQwiUkAaDcxtYACutdEdSrqGU9QRcU1I44l2xIqL5KAB+SuX/H zCs9szB1/wCRj7VuiJM33Fm42HhJJkv20MoUGxOpVj+qD5U7jTFm8Mvba8U6yKGsRozMOhrRpK6+ 363edVtg5b/QqRo5k53guWxJs84qSfx9rB47MLFevUW0o4fkMTkeSJgk3tEGlfRgAT6P1h/SroHd EsXYLuIUXNrk6AfbS1ivDG1bp2OdDduadz2xuUamdz0kcGCMiVtsUDhnaxOhBQaC/iwpeDzYMzAW XHbfGrMu6xGoN+ht51oUlb2evfPSIMb/AEbI6zItYfAZuNk5E0cL7ngXbKLEWN7eIHlW3SPIkaF5 GCIurMxsAPiTS1JtW0/bP1FbxW1Y+6DI51ZcaRORRWeJV2ZGwXZQCWSQDyFzf/kqhJz38yMeLhEZ OQ/4FUEKP6ch8AK6empFFGSY0VC2rbQBc/G1Yvw7rNqzSt9y7m6822qTqm6/a+xRzliweGZWb+Hj om5yNSFK3Y2++sKP3JjNGcfEaSdmP91FGxYk+GqiutpaX4dzTVtuNuOwpy7U067s7s9zI46GbCws jPzQI5nQu0d7iOOMEqpI6nqTVbiMfiuYjkyniTKiUiNDInQj1NYOP6QrdeWJCFd1UkFgGIBIX8R1 8vGnKysoZSCpFwRqCDV9qs17UTx5k920W73az5GDFkYOBzacaloST/BhAIG1lvpYW/FepfrsUe4/ oy/+8NqEsena3dbW6Ctmins+P89+n0Hu+H8Nmv1M7muSTj4Y3kk7SyNt7ltLgXtfwvVvByPqsOLI FyJVDAkWuD0Nvj1qV0R12uoZT1Vhcflpa0qve7ThrQy7LaqxlPUWiiitmAooooAooooAooooAooo oAooooC1RRRUAUUUUAlLRRQBRRQTQGN7w/8A23nfur/bWsfi+XaDJ5LMyVMmRjY+PBNGDYtMjvBa /hua3310PN4L8lxeRgo4jaYAB21Aswbw+VZ+R7dWXJ5KVZe2vIrERYapLEdwf4+oA1yvW2+V2/c6 0tXZD7/sX+O5CXL78WREIMrFftzRq29dVDqytYaEN5Vm43uLIlKtPiiOKYT/AE8iybtzY5bcrLtF rhTar3G4U+MZ5sqRZcrLcSSsgKoNqhFVQSTYBaxuG43Jy8WKaWZOxCcsY8YUhg8skkbF2vqAL2sP Gq3f0rrn8+oSr6n5fl0J29yzrg4+U+PGjZY3wq8u0FVTe9yV0N9FHjercHM9/KRERVgOOmUzuxD7 HBIKJtIYLax18ajl4ef6PjlglQZXHIqK0ilo2GwRuCoIOvWnT8VkZGdjTTSxmDHRgVVCrsXTtuu7 dbYetrVV7nnp2+JHs8tf+hXbn80Y0GT9EBHmSpHiDuephIrspYbfT+Eff8KJOXlx3yAuJH9UJ8aC QK1t7zIh1fb+rusDToeHzkjxMeXISSDAmR4DtIcxosibXNyCfUOg8Kg5jCmhd8hJFDZediNFcEhS myMbhpfUXqPelOfp2KtjcY+vckk5nkJTixwxRxznKfGyY3ckBkQvZWCHQjW9qcvLsoMOHiIcmXKn hSMMEVuySXldgvU28utKOFy1SGVZozlrlNlysVPbJdTGVVQ1wAtra0HhcpLTY8yJlR5M+REzKWTb OTuRgCD0NPX4/Qejw+ox/cMzxxyYmMrh8V8thI+wqI2Cumitc+Fa+PMs8Ec6ghZUVwD1swvWVHwJ iRY45QVXCkxLsNS8rBy/yuKs8amfDK+LNtbFgihWBwCCWC7ZBr11F61V2n1dSWVY9PQyuUy86fG5 RJEQw4+RjpEFY7r9yFgNVA1v1vVyTn5YonSWGNMtMj6YKZbRXKd3cZGQWG34dadkcLkynORZUEOZ LFMt1O5WjMRIJvaxEdLkcHNJJNPFKiznJXKg3qWUWjERRxcXBF+lZi6ban8NlmjSTj8QWk5bHPED lmBWHtd4r1PT8PzvpWdkz8pJn8ZI+LHHlE5HbhMpK7TGpuzhLgi50tWtPg/Vca+FksCZYykjxjaL kdVXW1j0qCDjuQbIw8jNnjlfEMoJRCu5XRUF7lvVcXNWys4X+35zkzV1Uvz/ACwU391RLFiyiJQs 8STzK0gVlV37Voxb1kG58NBVg85kxZM+Pk4qxFMeXJhAkDMVi8JFA9O696jxeAysQYbwTRdyGEY0 /cQurIGLhk9QswuarTcJmYsc+VJPHKscGWrHYRI4lG/czbvxaAfIVmeTr+hqOPp+pYX3JJHjSy5m MIZFgjyIVEm5XSVu2t22jbZiL0sfuCSaOARxRmWWeTHYmQ9rdGL+iQIb7x+HQVXxODnzeO35c6l5 sWGLHMaWCKhEylgWO5t1r/KrWZxXI5uAmLLPAjM15mSIgAAgq0XruGFupqp8kTnTwDXHPx8SXjsv OyOQz45lQQY8gjj2sS34VbptHUNfr8KhHOTjNaJ8YDFXK+j74f1dxlVkum3oS1utWsTCnxs7MmLq 0GU4kC2O8MFVDre1vT5Vl4WDkZeflkyquJByJmaPad7SRpGV9V7bdR4eFV7lCzMsi2uXiIRInNSZ UMU0uGhhbKTHQs24iTumPeoK/qixB86mk5yRI8vKGODg4peNZS9meRDssF26KW0velThpV4/GxO4 u7HyhklrGxAmabb9xtTX4SdoszC76jByi8iLtPcjkc79G3WKhtelT1/Tw1L6Pr46DU5+SSGPtxRG Z8hsVj3T2d6rvG2UIb7xbbpWjnz5MEIfGhWZybHe4jRVsSXZiDoLVQy+L5LL436OWaAPI38VliIU LpZk9dw4IverPJ4M+XFAsMiqYZFkKygsjhQRZwCt7E7vmK0t0PXRRoR7ZWmrnUpD3DkSw40mLjKz ZEEs7K8m0L2SFYblVr/CqvO8vLmcTPHiwbo2xI8jIkZ7GMTaooFjuOlW8TgsiBIVeZH7MGRACFIv 3mDKep6WqHI9uZjYn0+PkRoJcWLFyt6lrmEWVksRa96w1yOr1yvDsaT401ph+Pc1c/P+ifGLqOxN J2pJCbbCVZlNvG5Fqzf+Jyv0xkhVO8kcsqmSzKk79uPYu31n9ZvKtLlcBOSwJcNjt7lir+IKkMD+ SoJuLmXkI8vEeONO2sM0ciF/Qh3KU1Fm1Irdt84eDFdkZ1Kzc/lCLMyVxQcbBleKR953HZIEYqu3 wT1fkrQ4/P8ArvqHVQIoZmhjcG+/YBub+tcVVkx047iuRbIIkjkbInYdPTKWbZ+W1T8Hh/Q8Ri4x FmWMFx/Tb1t+U0ru3JN9JZbbdraXWEY8vJyZebjZsmMoxRj5jY4ZtxlRQl967fTe3x61pYnKl5oo FhSGFcaPIe7EEIyk/wANAliqkWOoqrH7ey02RHIjbGx4ciDHXaQ4WcC283IO3pVgcNO8+EZZUMGH F29qqRIxMfaZd+78B69KzVX17tToVumnZPuRtz2YuJFmNhgRZUsaYq9y7usu7aWG30nQffTv5+yc hHgzRIr7o4prSXYSyqXGxdo3INLn40RcPnLBjYsuQkkOFNE+OdpD9uLcNrm5BNiBoKsfy6ePlZMy GSMQ5Gwzo6bn3RjaDG1xa4ter68a9J0+JPRnTrGvwM5vc0k+HmyYyRiSKA5GOd+70Bin8QBfSwtf b8etbmI07Y0bZAUSlQWCEsv2EhfzVlw8HkR8dk8aZozjvG8WMwQh1D3I7jbvVt6aVexIuQR1ORLG 0QiC9uNSP4gJ9W4km22lN0+qdBbbHpjUt0UUV0OYUUUUAUUUUAUUUUAUUUUAtFJRQFuiiioAoooo UKKKaTQgpNNJpC1NJoUCaaTRekvQAajiiigjEcKCNASQqiwuxLH7yaeaSqQDSUUUAUyWGKUKJUDh GDrcXsym6sPiKfRQBRSUtAFLRRQCgUoFAFOAoBCVVSzEKqi5J0AFEU0UyCSF1kQ9HQhgbfEVW5fF ky+Nnx4j/EZbqPMqQ237bWqrDy0ZixjjxKqTRTOydNrxBbrYfE10rx7qSsuWo7JKfrky7Q4ekGqT UciJIjRuAyOCrKehB0IrKk5nLCpJHAjoMWPLmuxBCtfcq6G9reNOk5eZcmS0StiQvEjybiHtMqlW 22toWq/8fk7L5r8dSe5Uvxy4qhIYnQAExoikdUGqAf0bdKkrHwsgRTCMord3MyhvPVdu9rj7qIuf MsE8oRCY0WVQjbrI7bT3LDQr1Iqv+vefSpSj6uEFyLq/xqbFMjhiiLmNAhlbe9hbcxAG4/Gwpncn +l7ioskxW6qrekk9LMR0rOHMziEkxI8y5C45EbXRiwuCrW+ysV4rWmEnDjU07pa9TWprSxq6ozAP JfYpIBawubDxtWcvLuM5MOVYw24RPte7bym/cqkA7PC9Ozv/ADXjf3pv+7Na9myaVsTW118E2Teo ld1X6lxsnHXfulRe3YSXYDaW/Du8r30pXnhRiryKrKpcgkAhB1b5DzrA5MBl5lT0L4o/sVH28tcj MOYbynj5lH7sZEYP+tbd9tda/wBarqnujTHnWtv1MPlacR+Ja/Q335DAjO18mJCQCAzqDYi4Op8a cMzEM3YE8fevbtbhuv8Au3vWUYomyOG3Ip3I264GtodL0/ji38yzAMfevfN8i6+j0DSx9X3Vl8NV VuXirtql/Lb+hVdzGNY+kmnFlY05IhlSUr+IIwa3ztT0dHUOjBlPRgbiuew0SLE4vJRQJmyXiZgN SjtLcHz6Vocej4fBgah4kkYX63uzU5OFVmLT6tiT82n+QryN6rpP5FqeXj5o5Yp5InjS3eRmWw10 366a+dTNJGrqjMFd77FJALWFzYeNqw8nHhj9sdxUAkeCMs9huJcq7XPzq5yDbeT45utjObf+yNT2 azhvXkX/AOdZLvfX/S//AJOC99VjBnQypuiG6RdwuoHiwvpSpNDISsbq5ADEKQTZvwnTzrIx4Yv+ HZJyoM0mPM7yWG4lwxa561J7ds+PLMf7xnVGHksaKqD7taW4aqt7Jv0W2fEiu26qPuUmkcnHAYmV AEYI5LDRj0U/HWkOZiCbsGePvXt29y7r/u3vXP5Urg50QiYo2ZGTKLbQbpodb1ewi383zQMfuL3V vNdfR6B4H1fdWn/XSq7N/wAd2q/0/uRcjbiOsfn+xpx5GPKzLFKkjIbOqsCQfjbpSQ5mJOxWCeOV gLkI6sbfYaweJs3LAbe2UbJO8/8AW3cDaP3etXPbZb6CK+P21Cm0919fqPl6vvpycCorOW429l90 /PQteR2aUaz9I/c2KKSivMdBaKSigFopKKAWikooBaL0lFALeikooC5RRRUAUUUhNAITTCaVjTCa FAmkpKQmqBb0hNITSUILSUUUAUUUUAUlLRQBRRS0AU4CkApwFAAFOooNAR5CzNEywOIpdNrsu4aG +ouOvSsv+SSqiGPIAnvM0rlLqe/bftUMLWtpWsTSVunLaiirS+C8jLqnqYTcfM2YMFJgirgxQzNt uWQM6tt10Jp6YT5HI5kQkCYySwGSLbctsjRlAa+guNa2O3H3DJtHcI2l7DdYa2v5UgjjVmdVCs9i 7AWJIFhc+OldP+RbP+2NFrKbf0J7a+v0KMfFlJo5DICEnmmK26iYMNvXw3UsGBl4+K+MmQrIoCwb o72UG+1/V6tNKv0Vh8t3q09NUujn9S7KlEccV4r+XrKQdmzu2+3pfp4W8qhj4mZW3PMhvPHkWVNo GxdpUeo6dLVp0UXNdTn7m28LVjZXGNMFRMOaLNknilCwzENLEVuSwXbdWvpfS9NzsOeebHnx5Fjk xy5G9SwO9dvgRVyiouS0q2JS26LSIz8C7VEeMmXLxE00eWJJl7mWYSWCkAGLbfS/jtqbL45sieWU OF7mK+Na17FzfdV6ite9fGdPDwS/RE2V7fj8MpfQHuYL7/8ABKykW/FdO39lJj4WVBlzSrKhgnkM jxlDu6W0bd8PKr1FT3bQ13W3TpM/mNq+s/oZmFxEsBh784ljxi7Qxqu0bnJJZjc3tu0q7BFKMcRZ LidyCHfaFBBJ/VHwqail+S13Nn9EvxqFVLQym4jJbBkwDkgwFdkIKepQGDDcb62taplwst8nGyMm ZHbGZyAiFbh02W1Y1foqvmu50zP8V/JQ/mNlfy69tDNTi548ebDScfSukiRIU9S9y/Vr6hb1LhYD YkrOr3R441dbfrxjbuHzFXaKj5btNN/drhZCpVR4aGbLxLOmQncA+onWcG3Tbt06/wBGpIsLKhzp p45U7M7hnjKEtooXRt36KvUU968NSmmo0Xh+w2V1M2LiWjeGQSjfDPJNe3VZb7k61JxeFlYUK48k ySQxghAqFWuTfU7jV6kpbmvZNNpp+C8f3CpVOULRSUtczQUUlFALRSUUAtFJRQC0UlFALRSUUBdo vSE00moBxNNJpC1MJoUUmmGlJppqkC9JeikoAootS2oBKKW1FqASiltSUAUUUtAFKKAKUUAoFOAp AKWgCkJoJppoAoopKAKKKKAKSiigCkoooApKWkqgKKWkoAopaKASilpKAKKWigEopaKASilpKAKW kooAopaSgCilpKAKKWigCiiigEopaKAKKKKgLJvTDeiioUQ3pKKKASmmiiqQKNKKKAWw86LDzooo BbDzo+2iigEpNKKKAKWiigAU4UUUA6kN6KKASkoooBKKKKAKSiigCkoooAo0oooBdKTSiigF0o0o ooA0o0oooA0o0oooA0o0oooA0o0oooA0pNKKKANKXSiigDSjSiigDSjSiigDSjSiigDSjSiigDTz osPOiigDTzooooD/2Q== --%OLATTACH1-- From oktdjlna@alchemy.net Sat Feb 26 15:41:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00023; Sat, 26 Feb 2005 15:41:18 -0500 (EST) Message-Id: <200502262041.PAA00023@ietf.org> Received: from cpe-66-24-215-40.stny.res.rr.com ([66.24.215.40]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D58k4-0002Em-Da; Sat, 26 Feb 2005 15:41:45 -0500 Received: from TKQBV-LM83 (80.38.160.162) by 80.38.160.162; Sat, 26 Feb 2005 12:40:21 -0800 From: "St. Daryl Osp." To: simple@ietf.org, simple-admin@ietf.org, simple-archive@ietf.org, simple-web-archive@ietf.org, sip@ietf.org, sip-admin@ietf.org, sipping@ietf.org, sipping-admin@ietf.org, sipping-bounces@ietf.org Subject: Absolutely No Doctors Appointments needed Date: Sat, 26 Feb 2005 12:40:21 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="%OLATTACH1" X-Priority: 3 X-Mailer: RGI Mail v3.2 X-Spam-Score: 29.4 (+++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 72be645574b2b4b84446d27f730bf563 This is a multi-part message in MIME format. --%OLATTACH1 Content-Type: multipart/alternative; boundary="%OLATTACH2" --%OLATTACH2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit %URL %PARAGRAPH --%OLATTACH2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 3D"" %PARAGRAPH --%OLATTACH2-- --%OLATTACH1 Content-Type: image/jpeg; name="%ATTNAME.jpg" Content-Transfer-Encoding: base64 Content-ID: <%RNDATTID@%MNAME> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAKAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBcSFBQUFBIXFxscHhwbFyQkJyckJDUzMzM1 Ozs7Ozs7Ozs7OwENCwsNDg0QDg4QFA4PDhQUEBEREBQdFBQVFBQdJRoXFxcXGiUgIx4eHiMgKCgl JSgoMjIwMjI7Ozs7Ozs7Ozs7/8AAEQgCJgHCAwEiAAIRAQMRAf/EALsAAAEFAQEAAAAAAAAAAAAA AAABAgMEBQYHAQEBAQEBAQAAAAAAAAAAAAAAAQIDBAUQAAIBAwMCBAMDCAYFCAcGBwECAwARBCES BTETQVEiBmFxFIGRMqGxwUJSciMVYpKyMzQH0YJzJBbhosJDU7MlNfHSg1RkdBfwk8O0JjZjo5Sk xHUnEQACAgEDAgQEBgEDBAMAAAAAARECITESA0FRYXEiE4GRoTLwscHRQgRSYnIU4aIzc5Ijk//a AAwDAQACEQMRAD8A6bKwos58eCaSSKJplDtC+x/UGRRf95hVjPhj4xGQMzxY8QIZzdiFXqx8TpUO QWETOgu8f8SMf00O9fyip/d6ibERYjrnhMeMjx7zqn5nrywttnGVB6Je5LoyHj+IOFw2NlPLLLPl Kkk4lbcFZ13EKPAVFx/Ew8pyWZlZM0yRYDRJGkTlULBe8+8WN/xCujz+0+JLAn4scKdvkPD8lZHB nt+38rK8c3ImcfLf2F/5sdadErJRhKfkZVm6t9W4+ZVwOKhzc7MzJZZlbECduJHtGboT6ktrUR42 LleTxsOaWaKIxyyEwPsYle2Bc6+daHDSJGvMSObIiozHyAjYmqHt7k8HO5+EYsolKQTFrAi1zFbq BWUq+hf5PPjk1L9T/wAV+gclhpPlxYBeSOKTKETNG219t26N9lTTe0fb8DmOXkM1XHUd4+P+pS5X /neP/wDPD87VH7h5GOHmHxzFMzWQbkjZl1UfrDSnpSbaT9UZGW0k2sTghzMLHzM3GwFlkXHlyNnc jba5UI7D1W+FO5zDPHwzwIzFUhJjkY+ogKdSR43FLjf+bccP/iP/AMKWtT3fCsnFzzpq0KOklvAM t9fvH30VU6WcZTLui9V0aM7J4bG4rFxxBJLL39zuZn3m9k0BsNKozY6ZQXHkkaGN3j7kiEhggdS9 iP6INbvPm2Pg/uN+ZKw2NS6Ss0ljBaNuqbeS9j+0fbmUZRBn5jmEAyWmOga9uqf0TVDk+N4nEwxD x2VNN3nAkaRyWUEqvpO1bVqe2fx8r/s4vzS1h5B9A/fT+2tW23amqpbpFZ3P1N7YNHlOJxuIeLGx 3kkQoWLStva5Y+NhUEXDY2JwGLySSSyT5nbMgkfcoursdotpVv3ryGJi58CTyBGaK4BBOm5vIVJM QfZ3FkdCIv8Au3qutd11/iseAVntpn7nkyON4dudypzkTNj8Vg+mdkO1pJLbiu7wCjrWl/w9xRxp J+Cmc9jWXHkZmBHmu/1A6fI0/EX6X2VERo+Y5kc+JMsjP/ZAFR+1pzHzKxX9M0Mgt/SUowP3Xoq1 W1NZspb65DdmrWT+1wl0wZmNxs3M8lFxqSNBBtabKlTRu2pChVPmxNXcrjPbeFA44uSQzoQrKzuy tbqfVp91aHDCPE9yZMBFg4kjT7GDqP6oNY2fith5kuO36jHb8VOqn7qm1Kswm5ansVNu+rSSTS7k /Fe2uLz8Gfkc/JyYtszqe3JtQKpAHp2nzpZ+L4HBgL8dlTZEzMAVlcsAuuouq1a4+Tt+0M59rPaZ /SgLMfWnQCsWCbvKWEckYBt/EQpc/DdR7Uq4UtTIrLtabPFognBq1xftvjc/Dn5HNysmErM6ntSl VAUgCw2nzqmK18CeLH9pZ00zbY0ncs2pt6k8qlEm3KmE3kXbSUOJaQ1vbsmNCcjBzDn4gvuWXaZF t4h0A3fEEVUweHj5rlXx55ZooMWAOew+wl5Hst9D4Iav+z8iWeDkc51ZMBlRccuLbtgkMjgHwO4D 7KbwE30mBzHLWtaZY1v4rAij+07VpVq9riE5bXkYdrLcplqEn5iZeOMbJkgBJCGwLdbdRemcZw0a 8Q3KLLK80zuZEd9yALI6DYttPvq/z8ezOD+EiA/aPT+irftxUfgYY36SNMtvO8slWtE72Xg4I7NU T8VJicbxEGfyGVkTSzKcNImjjR9qEt3L7ltr+GmRcDw84fI5DPyYpZZbKkUjKoDEKigbW8TWpwkT Q5vLxN1RIlP2CasrJPpj/wBvB/3qVmElVtJ6zPmalttS1oXm9qcHgzo75uZ3Es6o8xZT5XG3ppVb jeJgfHzOVaWYzLK8axl/4QAKj8Fq0+f/AMYn+zH9pqi4r/yHN/8AmJP7S1pqu5qEoTMy9qcvLRnY fBYvL5uW2VPkRLjpFtEEhQeruFiRY/s1OvB8Fhhp8bNyZpgpCJLIWUk/AqKscC22blW1NooTYanQ TVkYvIR5bMqRTJtG4mSNkHW3U1n0qtcKXJrLs8uFA/B4SHmZMrP5WaSPjcRzDDAjFA7Lbe7ldTqb C1T5GNx2KEi453eGxNpGLEG50u+taPHRCfhsrFjHrRzIqjqdx7n5W3Vjk0aSSwsqZ6hNtvOj06DZ HVEZ2NlUEk/AUcb7dxMzCXmfcMsix5HqxcRGZAsZ/ATs1LEa6VX5BDLiPCL3m2xadf4jBP010HuY qjY2Og2xxodqjoBoo/s0qlltTt6eLK25VU4nr5GNykHG8bAJcOZ5sYKznuNuZbfq3IB++nYPtjAG HHyXuWaTv5VmixkZlWNTqBZPVuA61WeAZU2LisLpPkwo4/ob1Z/yCtn3VKWz0j/VjjGnxYkn9FEl mzSxELpIcyqpvMtvqUuS4ccescuPKcjDm/uZG1YXF9rN4/A03h/b8Wdh5nICSX6qOR444938MhUR rbLdda0MI/Ve1MiNtTiyvY+VmEv5nqX2tkJjcPmTv+CPJYt8tkV60q1dl2anyI7WVXnKtHmc1FiP yfI4vFxsyCdt+Q6GzLDH6nsfAnQCrHuDjYONL4eO8hRYxZ3a76/0tK6LF42HhuTzOTkIb66aHGw1 HVY5Cu4f12J+QrI95f46X/ZrUdIo2/un6FrfdfH2x9SbL9n+2cNlXJzcuNnF1BlJuPsQ1mZuPgY0 wh4+VpsdVFnc3YnxuSBWr73yO1lYw7Usl421jQuBr47awxewJBUkA7WFiL66g0vtTaSSgcctKzs3 PQjmlWGJ5X/CgLH7K0sH2vxyYUXI+5ZpO/lWaLHRmVY1IuBZPVuA61RWAZWTi4rC6T5EKOP6G8M3 5BW37ulL8ikd/THGNPixJP6KlUobamNE+5bNtqqcTltFTlOGHHLHNjynIwpv7mRtWFxfazePwNM4 f25xvKY+bnZ8+REIJu3/AApNqhFiie9tp8WNaWCfqvaM8batiyPtPlZhL+Z7VHwTbfbnNNYtaZzZ Rcn/AHeDoBWttZWMNTBl2ttanKttkoZmBw2FGi8ZkS5BdiZO6xYjQWtdVqbB9q8G3D4nIZ+XlRNk orMRKdu5husAFPlWXDIZU39t4xcqO4pQkix03fOtvOl7Xsvim2PJftC0alz/AHb+ArK2uW0oS06G rStqVnl6lDMx8DGlEOBK00CqLO5uxPjckCq9C3ZVYqybgCFYFTY+YNOC1Da07iAU4ClApbUAlhRS 2ooDaJq3DiNnYnDFR6MHIPd89sCSxqftdVqma0+Bl2R5cbdEcSg+G1lA/OhNb443Q+v6ZPPfSUJD IZeXzoev1ENl+HZJT/8AFqqIWwvb/G4TArIsSGQHrvCjff8A1mNMwpWHK40n7bujn4OrH+2FqfnJ d2WE8I1A+060maN9Za+eRHqS8J+WBnt5tknKORuC9s2PjaM1ZweXSbkY8RcZI+5HI/cXqNhTTp47 qq8ErBeVYghWCbSRobRm9qg4dWPOQMASqwzAtbQEmK1/uq1s0qJdf3Fkm7vt+wzJ/wDO8f8A+eH5 2rV5LmMnEymhjVCqgEFgb6i/gwrLnVm5yHaC23NubC9gC2tP53j/AHFPyUkmBjwyY5C7Xkk2tcKL 6fOonZVttmd3QrVd1d0fb1KuO5fmOPY9WyST9sctbMoTKzuS4qU2TLiG34N21Un52t91Y+NBPHzO BHIv8SOf+KF1A/hSX18rmrPJ5BxeebIF/wCEyMQOpXYoYD5qSKlXFc/5Z+RbKbY/xx8yf3Kpjiwk PVVcG3wCVgk1v+6yCMUjUHuf9CueJqcv3v4GuL7F8TX9sfi5X/ZxfmlrCnPpX99P7a1u+11a3KsQ dpjjAPgbCW9YUgZtqqCSXSwGp/EKW+yvx/Mtfuv8PyOv5vl1wMiOM4yT7k3bmPTUi3Q1S5jL+t9t 4WXsEXfaN+2NQt0c28Kh93/42H/Zf9I03LVl9n8WrAqwEQIOh/u3rpazm66Qc61SXG+rY+YX9nYQ XpFsQ/NNyH8oqh7bu3uLGUfqxTOfkAi/nar/ABP/AIhweTxSMoyEu8CtoDc7/wC1e/zqP27xmdxD 5nM8yi47CPsY8AdXO2+9juXS7sBasxLo+kKX5Gpit69ZcLzKfKZDR81PNEbPHNdT/SQ/6RWl7gSP P4/H5eAdRskHkCbf81risEY/LcjlSnCiWeTa00iM2wsSwFlY6X9XjW1Fj5nGe1JYOT2rlZMpZIVI bYCykLcXBsFvUrL3YcOXPiW0J0h+pNKPAl9v5UmJ7bycmMAvHPIQGuRqyjwIrO5HmsrkURJ1jUIb jYCOvzY1d4jGzJ/amXBioGyJJn7Sudqn1KevyrKbh+cxImm5CGKOIWAMb7jc/Clt22qUxtz2Fdu6 0xu3YIxXQe3pxje38mcoJAmRIdh6HVRXPitvi1Zfa+ZuBF5nIv4jcutTj1f+1l5Vhf7kR53OZWZG Y2tFD1ZV8beZpkS5EPsvFEWLNlyZzmWSOFdzbZmebcfhawrLze6cOZYVLyuhVFUXJZvSOnzrqeSy 5uKhxMPEYKI4gpuAdFAVevyq1c7nZvSPmZso2qqWs/Ih5ITScXx+ROjJMY1EysLMHZASGHmCDTMG Rova+PKn4o5ndR4ErPIbGpjPPn8BJLkeqaKVrta1wG9PTyRqgx1ZPakIYFT3HNjodZZCK11bXWkm eiT6Xg148ePuZXIRG6ZsEZA/cEmv2q4rlcg+mL/bwf8AepXQ8LkGTjJoT1g3AfusCw/LcVzsoZzE qAse/CbDU6SoTU5GmqtdZHGmnZPobXuA/wC+J/sh/aaoeKP/AOn80/8AxEn9pak9xG2an+yH9pqj 4xWX27mFgRedyLi1wWXWr/O3kx/Cvmhfbblcnk3HVY4SPsEtMy+ZycqAwyKgVrElQb6G/ixp3txJ Wfkyi3LxxLGToC1pdL/bWanFe5IyZMzHgjx0Us7JJuYWHgKk22Viesx5liu+0x0gt8XmjEzFdjaN /RJ8AfH7DRzmJ9LmsVFo5fWn29R99Zbcd7jzYH+ixY5YpWaJZWkCFB03Mrfi6/q/dW37icL9LjM/ clhj/iP5k7R/0b1FOxyniGviXG9Q9ZT+Biva8ZPRJYnPyR1Y/mrb90g/VQnwMf6TWGwDKVPQix+2 t3l4c3leMxs3jo1ycmMbZYS4jvceqzNoCCPHwpXNbLyZbYtVvTKMbEsOQwmPRciL/nNs/wClV/3O COTJ80Uj8orP/l/K4MEU3JbI8iaRnjhQhu2qbNt2GhN9a1vcOLyHKY2Pn8PEmTIybHjLhCviDdrA 7STcXok9tlDnDjqG1uracOVPQj4Nre2eSc9GmlA+xUj/ADik4b/9tcn/ALd/7EVLkw/yf27jcOzh 8l/XkEebMZHP9c2FHDqy+2uSuCN0zkX8Rsi1rS1S7VyZ6N97qCq/JvlScPim4GPkQhyfEhwq/ctJ 7y/x0v8As1qpiKzchhbQTbJhJtroHFzV33grNnSKoLMY1sBqTWW26Oe6NwldJdmbfPc1lcbNEkCR sJFLHeCeht4MK5XMyZMzJfJlADyEEhbgaC2lya6D3VxnM5uRA3GwxSoiEOZH2EG/hXPz4WbhlYs1 VScruZUO4C5Ntfsq8jtL1j6GeLbCiN31F4+y8nhOei5Ef3s2wf2q0fdSkcqSfGNSPyispSVZXXRl IZT5EG4Nb3uHEz+Vx8fkOHiTJkZNjxFwhXxBu1gdpJuL1F9tl5M1bF6t6Q0RcEbe1+Rc9GmmA/qp H+cVJ7XnfG4flJ0ALxZDMobpcY8HW1qbkQfyf29jcOzh8l/XkEebMZHP9Y2FLwKMvBcvcEBpnKk+ I+ngFx9orSw6rqq/Uw81b6Wt9ChyXK5PJ9vvqi9rdt2Aj8Vr33MfKtjE5Cfj/avGzQqrM0caEOCR YoT4EeVc8FralRl9pcYrAqwEYIOhHoapVubPrBq6XpUYkzM3KlzchsiUKrsACFuBoLeJNQ7afjcZ zHI5ZjwTFFBCgeSSa53MxICDb8utPj4nmszkJMbEMMUWMP40ktzufcy7F2/u9azl5huTU1WJSgi2 0oWpU4nmszkHx8QwxRYwvNJLc7n3Muxdv7vWlkiaKR4m/EjFWt5g2qQ+wlaSRbaKfaigLQY+ZqSP ImjVlRyqyCzgeI/+xqMUV6oR5JYLJIjh0YhlNwR502aaWVy8jFmbqb0GmNUhdiyxBk5EasqSuit+ JVYgH52qJcjIibdFK6N0urEG32UrVE1IKjN5zOzYcZ54ciWOYeoSK7Br+e4G9cJL7q9zhyBzGcNf /eZv/XrtPcH+Ak+VebS/3jfOt1SMXL3/ABF7g7nd/meZ3b37nfk3X+e69I/P87K5eXkcp3PVmnkJ Ph1LVn0orULsZl9zRk9w8/KFWXksuQILIGnkIA+F20qM8zzH/v2T/wDev/61VKSpC7IsvuzRh9w8 /EGWLksuNX/EFnkAPzs1NHMcuGuM7IBGoIlfr/WqktOGtzSF2JL7svS89zuQ4afkcqVgLAvPIxt9 rU9+f514lhfkcpokttjM8hUW0FgWtWcguaf40hditvuWV5vmYZRJFn5MbrqGWZwR/wA6pcz3R7jz ipyuSyZNv4R3GAH2KQKzWNzekqwuxJfcv43uDncWUS4/IZMbjxEr/lF9afl+4ufzJO7k8jkyP0F5 WAA+ABAFZ1qWkLsJfc0IvcfuKFNkPKZkaddqZEqj7g9LL7j9xTJsm5TMkTrtfIlYfcXrPtRakISW /wCccv8A++5H/wB6/wD61SL7g58RGEclliI9YxPJt/q7rVRtS2pC7Ibn3ZaHNcypDLn5II1BE0lw f61Pl9wc9M26XksuRgLAtPIxt5atVK1Jam1dkJfcvL7h9wLGYk5PMWNvxIJ5Apv5jdatX257g5t8 +KDI5DIkwo7ySxSSs6bV+DlvE1zlq0uFQPK8JJDToVUqAT6SslgCR+xWbJQ8Fq3uR7XjgRB3U7A2 hC6A/MC1Qv2ozvCqCDdbADWq3HyscCAsxJ7a/jPq1A61XzMopfcen61eK1oO6q2xnI5kjlnd2ZgL Akk2+FY7Z+esJiGTKIz1QO20/ZepJskS3Cm4NQMl6wk25PTRJLKEi5HkobiHKmjDddkjLf7jTn5b lnQo+ZkMp0IMrkEf1qhKEUhFdMlaXZEkPM8rigrBlyordVDG35arNm5jsXeeRmbUsXYkn76V47eF VZCFPqYCjkqjWC1HnTK1nlYqfEsdK1eO5bKxpCsc7pu6kE2Ncu+TGDYMKmxs0aLc3H4akEtVNaHU ZMuTLKZJpXlD6bmYkj5eVQY/I5/HTkRzyLG1gwDGx+Nqjws1ZFCH8Q8KnngWRDbUeHwrLbTmTnHR kPJS5Kyrm9x5Uf8AHck1oQZc0mJsikYRNqUUkKfmvSqGO49WLPqraC9OwVbGkbHY6A+n4ipLI1iO xYErRTRyISpB0YaEGtAZCTvuyP4r6DuNq33mqGRHoR9opVfaw+NqqbMs20my21jyJWX4u1/z0Osc rb8gd1hpuf1G3lc1Xx5dtm++rLSKLSWBU11mTnlDXgxY4jK0KAH8I2j/AEUmBlzRISiCBHP6ug+e lT7sWUfiIPx6UkkIB8hbQ9VrVURvuVpxFO7OF3St1Zxe/wBpqMSPBG0RcrG/WJDYHzuKnZdtwPxD oT0+yq9iTZj99bgzIyRVZAVRVv4ACoZJchoxFJI7Rr+FCx2i2mg6VLttfyB0o2g9daqSLJDDPkY7 FoJGjYixKm2lLFkZMDF4ZWR20Yg6m/nTyov0pNlWBIyHIyoHZ4pXRmFmIJub1H62NyxJOpN6m2UB KQJItp8zRU+yim1dhu8SUUUCiqZGmmNTzTGoCJqiepmqFqFRj+4P8BJ8q8zf8R+deme4f/L5P3a8 zbrW6mbCU4U2nCqZCgUUCgHA2FJSjWnLG7sFRSzHQKBcn5UAqaCkY3rosb2J7kmxu+uNtBFwrGzH 7KxM3CysLIOPlRmGVeqsLfaKSpDKwFOAre4T2XzXMxiaCMRQHpJJcA/LzpnOe0uX4MB8uMNCdBMh uuvnUkQzFtSgUtvv8R40WrRMiUU61IRagFFAoFFAKaSlooBtiR0q9w3cGdGVXdYg2IBHUeBvVZU3 WBIXXqav8dl4mD3H7b5EjAKQGMRtuUmzIbjpWbaQarrJ6fx/MY2XEIEUxullZSQbkKNbKbCoOSgM 4ADWjt+qeprjeN9yZsmWsOLCIcZB/E2XOltp7krXbTzvr+bqcPPibAuLdopuFtxLf0hu8zXj5ONn p47dUZcvHdtrxz7T4KaElnjIWX1D9oVjcgeRzs58PHch0Yg2baiqNL3GtY+XJncZktEcqR2jNmKs xAPl661XicanS3NGqx3O79LruFNCgVgcDzs2ROMXI2uXB2SKLEta9iK3DJtYgms2Tq8mq2VlNRk6 ysLKOtQLxSMbzNqatNlAaA61zvKctmyTGLEJG3qfGiTZXZJG0ONwo/wi5+NI2Gq/hArmJP59DEs8 mQyKxsATrf5UYvuTPhNpCsyg2YHRv010fEzmuesw8HTpE6kEekjUGtPEytw2sfV+esXD5mHJTcq6 +KnwNXELON1rXrlasHRxZYyac0KyEMujCkO59rEWkj6/EVXgzAf4ch18DVpWVyAeo6GuUMw00Wix aHzNqrTMAiPfpqanhJ2EH4ioJBeIKfiKsmVqXcLIDKCNQavwuCGib7KwcKXYCvivhWmjnSQfq9DW lpJLVclvHlxy7IL9wfiW9WBICNoN1PVT4VRMQGQcgaBwL/OpVLXF/mDXarwcrakzLc2H2VEygnpU 49QB60jgdR+t1rojDK5UdKZtqfbSba0Qh20bal20baCSHbQFqXbQFoWRmyipdtFBJAKKBRQCGo2p 5pjUBG1Qt1qVqjahUY3uIH+Wy/umvMyNa9K9zsU4yU/CvNj1rVTNxLUopKWtmRaKPn99a+D7V53O iE8GI5iPRzpcVG0hqdP7L9j4edjLyHKglZNYo72Fjpc10mH7N4fjuaTIxUG3ZcITuUMPHWqvNtyP H+2IG49Ss8Gz0AXOhFxasLj/AHXzPGcqs/PxOkU6gKStgAD1rnLZo7Ucry7802FHjrFhxqCJJPxO T12/AVW9x+2cfmMnCkkWzROO5b9ZddD9tOwud4/nsknDY3gANwCLk/OtqNmvGG1egMv3Jk8pxHEr /Jok3ptVVI8OnoUWpBBlcz7aMfKx9rInTa6kdCdAadz/ACeHxM2Nm8hKdrPtVPAfG3wtWF7k97jk Ej4325ebImIJdQbADWoDZwPY3t/AwljmgWVnADySasSdK8495cBHwfK9mD/DzDfECb281rtODzPd nJcrHjcrF9Pj4oDvYW3n9X1X1pvu72pyvuDk43xysePAm3e/ixNzYVpYZGjy80vWt7nfZfMcNGZp lEuOOsketvmKwPH4eFblGYCltS0hqgUUUlPRWdgiKSx6Aan7qmmWxDEF7W++rGMMdCGmUyMNVS9l NtfUbXPTppWzxvsX3HnqJFx/p4z0eY7b/Z1rbi/yqznF582ND5ICw/OKxa9dGzapbsclFLlzR9xT 2ceG9whCLvP2gk28ya6X260marRMy+prjVZNsaa7bqbfbV1v8rsyOMRrmq6A7igBXcbEdQxrRbhs riuO+lw8Yq0uk8qeravkOn5q5cl6tYOtatEXNYc8JM2JGjX0cEa+ZsR865TNweQy3eZ/4Zk/EAAe n71eiZaqyEHTzB61z+TEFJsdPCuau66Hata31RyXD8JNHyuOwYja9z8a2uQn7eSUHh/prR4vFH1Z nYaRqT9vT9NYnIkyZsjKdLmlrO2putVVwitl5Ds1laxqh9PmNJuVx1uPnVuWJi16sY6lbGqnCDrL IZJuQbE7EuKsljcOT+i1ZjcZmTkbcdYVvqVvrXXwSDaNwvT3ZLWAsKq5bRgxbhrMsxsDGlxwCw1H XStJZ3I1P2U2RwDYVGASa5tt6nWtUtCa9+lWIZnQjXTxvVdFNTxpestGsdTSxptxtfQ1MV3ECs+F tkgt08q0gNyaGx86zBysoclAQTQ5ul+1KrAMOl7VZ47IkMq31iaMC3kVJU/mqzCyjRtbdac2C/cE yMBAFuVHncn9NaSww7rqaEQ3w38j0pT+EHypMW4jANTMARY6Gu1dEea2o6E2kXyp8g6jyNNsUAJ6 04m+vnXSphke2k20+1LatEI9tBFSWpCKpCPbQFp9qULrQDdtFSbaKAoWpKfaktUKMNRtUpFMYUKQ mo2GtSmmEC9CnP8Au024mT5V5xXpPu9R/KZL+VebeNaqZsLRS+FIBWjBq+2MKLO5vGgmF4y25gfG 3hXqvuLlp+D49cjFhR4owA6nTTppXnPsnhc7kOTXIx37UeMbvJ8bfhrt/emBn5HDu0U9xD62TqHC 9VrnZ5N10NJ+exYeLj5LJjIgcBttrnX4fOsP3Xi5fNycfJHjhcMSguD+OzfoqLiOcTnoocGTDdMV Aole3oJX9UGuh5XncHgVi+sU9hzZSBcAgXHn5VJclhFnB4qDGyEkhjWNVQBrC17dBWJle8cdfdce ArDsIpR3HTuG2n3XrK5z/MTIzovo+Ehcd/0iYjU3/ZFcaeK5eSSVhjyF4LtIbWIvqTeqkZk9gzuE xuVyRlZKiaNIyI1OoBPU1yvtv2xyGFy+TykMQXGikkSKI9Su7rrVDgP8xcrAhTHz4mlRRYSDQkD4 H/TXfe3+dg53HaeBGjguVO4WufGjkshwXOxcuZjFEYlx2Mb7rD1LoR8qxM73Py+d7hPBcQoxxGbS zutzYddo086ZzvuTjvbfIf7rAWEwYyhBZd3xqj7Vx+T5znZPce8Y0f4Qlr3Xy8KiB2PIY2zhMiPP kEo7Tb5CB4LevCW6kDp/6a9q914HJcpw82PhTqGI9agfiA6r4WvXi7xPHI0cg2yISrg+Y61qhLCC 1J407aPtrR4Lgc7m81cXFWwuO5KeiDxv8a23GWRKdA4LgM/nMwY2Glwp/iyn8KDzY1617d9m8Twk QZIxPlH8eQ4BN/6N72q7wnCYPC4KYeIlgNXc/iZvEtV9pAB8fE+dcLXnyOqrA/T7fPxoJqq2SB40 wZJJrG5aGoZbNMNr6/bUHf8APr5UGe46G1TDLoY2fdZXQ+Z/KSaypYdxrc5eIgrL+0NfnWHK5BtW Xg7UyiZI1iwpnXwHWuLnyAs7E9Sa7Lk5liwxjxn8Qux89K4+XCmlkJVdKGqLqETrIbEdasiHaOlV HxJ4QLCxrSxS0kYDD1DrSTcCIzIunSjuO3SpjF4dKRYbdNaFwR9onUipFjt4VKsZp6pSBIxEvU6g AUKth0pRqQKyyNkuPHuJbwq2qNceRFrUkMQWK3nU6W7gA6AVDlawuNjF23M2inoKuZBCxiNf1uo+ FJCygaixH5aVI2kcuRoeg+FdYUYODs28k2OlkvT3BJA8z+SnoNo29BT9oJua6JYhGBFNiL9B0pdD cjpSn9FRY9yG+dVKGZJbaUWp1qLVsg21Fqdai1AMtS2p1qAKAS1FPsKKAzyKS1PIpLUKRkUwipSK YagIWFRnrU5qMrehTlPfLMvG7QdCQDXn9ta7/wB+enAX4sK4LStrQzbUTwoFGtH56pk9H9hsYPb0 8kWsl3OnW46VXxOX5/kuCkx4cYlmvHJMxFtdGNvhWf7B52HCyWwMprRTn0E9L16PgYGJEH+n29mU liotYFq5tZOkmf7c47J4vjosYKkoA/EBbr1vVT3lhJy0+DxjXXe5dyoBsoFvH51vPLg8TC8084SM C9idNKx+Ell5bNl5UODjSWXHQ9Qq+P21GOpocV7fwsHFjx9gftaqx1rSXAgYyekHuaNp4UDculWY AwW/hQhzPun2bg8hhKIwIDACQ6gAmwOhqD/LuULwRx0H8aFmVhaxvfqR8a6+UK6EEbr+FcDPnz+3 PdLS5W2PBzyCgT9UrpcimQbfuTiMjmeNkxkijidte44vaxv5Vj+1eaPDcVPhZONK7YLMryRKWVtd LGunmil5RFfDze1E34iliSp8jfSrLcakHHHCw1ALgi5826k/GhTkvYfKZPJclyc4LfSO94la+l71 xPu4RJ7kzhF+DuflsL/lr0aWTh/ZHBsisDMQbL+s7mvNeM4rkfcnKskQJeZy88ngoY61pOMkanCG 8HwmbzWauLip1I7j+Cj417LwXB4fDYa4+Og3EDuP4sw8TTeB4HC4TCXFxl1t/EkP4mYdSTWizgVy vefI6VrArsAKqTS2p0klU5W61ztY2qjJJjrUQyGB/FY0yQka1WeU6+FcXY6Kpqx5pkAEm028accz HRS172+e0fPSuelzREpZmIAGvhXPPyUnK8j9M04jxALOzEbQSfj42rpxt2Zm9Est/A6/J5QZMTyR lWx4GCyy3sL+O0eNr1m5CWbX5EfGuTyw82e3H8fkvJh/9XY2UkgB2sPnXXdphBCGJZgiqxPmBa9X kXia48Z6BFA2RH6huK6A/CoJY2T0xBRbqfEVpRyw48JeRgqL1NYeTmB8h5InAi10PU1Fk6UlvwIk yHjZ1zmEik+g7QD+Sq0MoWclNIydKhnyWdvWungbVJAgexBvT4G2aYCuLikCU2EMotU4/LQyMAtS 04gUh0FWQIelOgUFxTRrVrGj8T0FRkbLBIVQPE1Nix73qqTuc+V9K0MBRu/MaVU2SON8KScRgMI7 a9TVjYFAIBA+FDgCQOeh0NSMtl8xXXbk4uwxXudfGpfEeXnUSi1yNfhUygDT7a3UyxH/AAH5GkhW y/G//LTwt1K3pUGlvjV6kFotTrUVSDbUWp1FANtRanUUAWop1FAZ9qS1SWptqpSMimFamIppoCAr TSDUpppFQHC/5gynbDF5sfyVxFdh/mFKDPBGOo3E1x1dFoZeo4UvypBS+FCHW+xvakfKynOzbjEi PoTpuI8/gK9LwJeOO6LEsY4PSzD8It5VyCzPxfsjuYp2uYgQR1u+hNZ3BcrzHCcfAM7GK8dI15Mj qwDeLD41zbNwdT7g4TB9xY7qpYSRfhlFwLj89S+0uOw+Oxfo4iWmQnug6+o1exuRXJx0bCgJia3r Olx51AmYcTl0xdoU5QZy/wC4QCPy1Cm+kQ3a9aRiEJUHSlR1IuDcDxqJ7Fr0IOJshPhXC+4vbUnu LnIRj5BMKAic9QlyNB8TXT81y8fFYL5Tjci6FR11Nh+Wn8HjLjYBnijtJkEyOPEltaBFXjeM4PgF TEWUo7dA7k3/AEVqZM2OgCvIY0fQNfT76yee5Ph8aFhykYikYHtlhckj9n41iZ/JchyPtoQJgy96 eyRMR+HXRr+FRliSt7p9ichm5iZWJlNkCRrMsrX2A+KnyrsPb/A4fB4C4uOPV/1snizUnA4WVg8X Bj5cpmmRRvY+dqvtJasOxutYHu9qgeQUySWoHlrDsbSHu96ruaHl+NQtKPOubZtJiSC9UplOvjVw tcVh85yc2O8eNir3Mib8PjbwH31FTe4Rqdqkxea5B8gvh4atI97My30C6+FZ3IZXGNxkHH4URbJJ V8jII6tY+ka+F6uHI5HgJZ8Yxp9ZkoGaQ6sm691+ZqPhOKlmbuMvVr+dvOvQ3XiroYqnyWl6LV9j Q9v8aIT3tt3YDcx63rqosYyQmw1GoqPBwtiqoHStzHxwiaCxrhWrs22bvdKEtDi+YXMZSmOglb/s ybA2rCOdlYTbeSxDjszdUFxtPjeu75PEVJGK6LIPuNcxyozchBjTWZI/wG2lq6UhYZ147OyhODOH Mcb233s19doIqg3uGGMgpCXPiBpark/Eid7hdt9AANBRH7ZLEGU2UdfM1tuvUtk1/Il4jnp82cxt AEiH699b/dW58R0qjDhQ46BIVso8ato2luprk4nBl/MkpCtKCKNetCBGhLWqdpAvoTQDrUPc2iw8 aj7mtRsNSWkb1CtTjrFreIrGie7XrX4g7pPsNON+pHLlXpNYKDofKksVO3wp6C5JoIF/n4V6jyjA pBPlTlHqHypwBOpoTqaAVR1NOApVGlKKpBKKW1FAJRS0UAlApTQOtCC0UtFAUaQ0tFWCjTTCKeSB UbMvnQo0imEUpdP2hTHkQKfUPvpqMnmXvp93L2v0QVzlq6L3LiZebzkogjZwAAD4Vi5GDk40hjlQ hgL9K0iNPsQUooANAFUznsei+zea4/P45eKziN6DbtbxArS915uM2CvBceFkysgBEX9lf2q5j/Li LHk5SUygFwo238vGutzuGycj3Fi5ONGIooQRLKfEG3pFcmdFoWvamFyWNhpDmyqTENqqvio6XrK9 3+3ec5LMTNwZViGOto1BIJJ6nTztXRzd/Fy/qGXdEqWa3W9Z3Ee4v5tnZgjNosdtihtL/ZpQGVje +5OPmTA5fGbEaJPU51DEC3p+dOzf8wMY8eJML+LkyOFjg/W6+VWfc/D4/NcPJMqgZEAJjcdbrfQG q/sX2pjYGGOX5BA2S43KCL7B/RvVIZObxnvbm3XKlg7eKzK30xaxsDfUV6BjyZY45EitFMqi4caX Aqj7l9wPxPFrnQrdd6jb/RY2/wCWq2bzWXn8Ms3GQMZpdtiBbS43HWowjh/dmZz+ZnJJnQXxsSTa jRrdCd3n8a9RwJBJgQkx9u6g7SOn2UkMEMuHFHJGG0uQw8fj9tT9B+msWsbrUVmqF3odtagke165 NnRISSSwqtJMBTZpbVnZWYFvrXNs6Vq3gsy5QGt6pyZ67goNyxsB86yMvkG1ANRcbkhp3yXJKQ6I Ot3/AOSspOzhHbYqqbG1yvJjDxyqkd4+m3kTpWFlwS42LFyn1Y+vkIMcI9RVQOpqxjzceJJ5+SRp ZyN0MJB8f1m+FVeJ4CbmJbRELiI1pJNbsfIXPSvXWq41PU8r9b7Ih4zj8rl83uys8iXuZH6n43rt sDio8aMKorQw+Nx8SFYolACiwt8Ks7F8K4ubOWbd4xXBDBDtq0WCi1IoAFV8iQBTWtEY1IcsrKpU 1iZmPoSDYgdK0BNdjeq+cpILKLqdKxOTrWamBI86H0m1qb9VKdGuTWgYlPhULYik3ANIOsoqiR2N WIw1PGMFNKzxpoKEeXgUaanSmtJfRaiZy3ypN5A+FSSqo5mtUPd1pHkquZdTWWaSLsUwv1rc4aZE fc5sCCK5VJCWFbnHP6CT08qtXDkxy0lHWJKtgRrTlUk3NZOFyBiuri6Hw8q14ZI5Yw8eo8a9VLqx 4b0dR1tKAv3U+x+ygDwrZiQtRalFFqEEpbUWooBLUWpaKASgCilFAOooooCmImNSLjr1NTBacBXN 2Z12pFaXj8eUeoG/wNq5DMjniynjfdGL2TcTa1d0BWT7mUDjmZYw7aAsRqB50TcmsHLeoNZ3v16G 9NMrp/DcEE9fO1SSmNMBCqHdf8dVmzZWJZiGJFr+NdFkF2KOOQk48Wn6zHreq0cUMmZJBMFJtpuF QrysmCjMpJB6nrY1Um5ETZBmHpkAG743oq2Eo0IuH4/KDqMdUvpvAsDWXmey8MPsRmic63BuDW5h 5zERLN6Y7WAGmtOaaXHybuN6ObKTqLGs7rJ5K6JnHQcbyvC5gzMBhKY9CPMXrrfbvu7keTzvpJYB AIl3O3iT91N5SA48ystgsnVfjVTEy/ocxJTGLuLMf6NalNSYdILPuDnfciZk4wsRpMNLIsnxbS9R Y3svlMLCObDntFky+qYADab6sNemldRLzHFR4Kyll/iWAHjc/Cs73PyGcMOAYm1sdmAnW/q2fCoQ 1caGJePTHj9YKC7dfnUspRcZcVjsRl236aUkU2Pj8Z3SO1GqXJbSwA8aqtn4+RxgnsZUKkjbqT+7 U+JMnPe4Pb3NcnxjJHlLJDAd0cVrbgvQbt1bvtKTNk4mEZMJg2Ls2sACdul7VF7XfkZoZHyY+3jM x7CP+Ir8RXRKoUWFYduiN7VItrDQVGxpzNaq8kgHjWLM0kxsj2vVKeYC9LPOBfWsrMzAAda5tnWt ZYuXlbQdawM3MuTY0Zufa5vWBk8iryiIOFLnbu8BfzqKjs8Ho9NFLLDyyZU640Let+p8h51v4eBN xCY8skPciJLIshtc21Y9dLms3hsaFBlGeZUnQKMeNBq39Ik+FTPlZvMciMCNi/RZX+HkvkK9Faqi PPa75XjFVqW8eKf3PyMi6rDcd+VBtBA02LXc4OBjYGOuPjIEjQWFN4zjsfj8RIIEChQAbDqfM1ZJ NYb3amH2WgE0wsBQxtUEj2qNkSJJJgBVHIlLA0sknWoXJK1G8G6oqAtvveruODIuwi6nreooo9z2 q3NJHi4zyHSwvUSjJuzlwtTn+cy4sOYJjKoPiDrWfDyc0nWwPwFZ/IZpnyXkY9TpTMaUbwKzlnpV Eqruaxlkc6k/Km6g61ahxt6bradb1TmkVHK9bVDKaeEh4NRSTW0qJ5vKq7yXPWqIJWkvc1VeXU2p JJiAdbVWUySvsjG5m8KsCS7il3lVRcknQCuswII4YrufVbU+Arn+Ox+ybdX/AOsfy+AqlyPuKLIm GJuePjkJXIlj0ZyAfSp+NWld1sHPltCy/gb2XzsYWaXFCyJjna0rMFTcP1V8zV/27zU+QUnETCB9 Ga1h91cjwvDJymUZ2gaDj1O6KG5sb28/Pqa7jHiSKNY41CIugUeVasq0eNTim7LOh0Ec0MhsjA/A 9aktWGrMOmnlar2Fms7CGU6n8LH81da8qepxvxNZReopbUWrochKSlpKECiikoApRSUooB1FFFAK BTqbTq5HYBSSIkqNG67lYWINKKNPOgOM9x8eOOIWCT+DOSe2dbW8qwC5uOlq7H3jjGTDTJVbmEkt +6a42LMOPMsqqrkD8J6a10o8FIchgUZW6W6Vly5qhwpHRQFYdauzzBizHzvYVhvMqylT5m3311Od uh2ePyWHJBDI6sqxLZrj9atPIzIJMVCGGliBb4+FclBkTdtYO5vRrFlPlUsfJk5Lm+6NBtQHQAjx rhtlnaVGTdzpmyslmNlZE3Rh9LnS9ZEeU+U3cICgXCfZoapZfKtNtgVt19Xa3qB8r1axiCRpZR1F dK1hZMO3Y0cYI6kSMAEBPzq9xXHS8k4s/wDDS3WsTcCxI87Cuo9owymaWUiyKAvwNZvKWGaRvSYE MmKMWZe5FbaVbofnVPE4iHAPbxiRB4R9QPlWpK+30jrUQ0F/GuEuSj4wqiwFvhSs4qNmqF5LUmBE j5JbVSyJwAaJ57Vm5WSADc1zbOla5IszLtfWsDOzTc61LnZfXXSub5DPa5VdWOgA6mpWrs4R3UUU sZyPIWU660vC4jvfKlg3Sk3haQ+n5hLfpqbi+DeWQZWcu49Vh8vLdW8o+nYPMPQLgJa3yAr10qqH l5LO78DNi47LS0eMpnyshiNzdQLn1fCu+9q+2V4jG3SgNkyau/xNQ+0sD0HIZRdjoeuldXYAWrnb 1OQ7ba7V8SArTCKsNaoJDRowivIbVVkarEzVSleubOiUjGNRNIOlNklAHWqjzC51rEnRVL8Eq3vW T7m5YLj9hTq3Wp0l061Um4b+ZSXc2Xzq5ZuqqnNuhx0043aGtHg8HJzcldintjq3hXTw+yuKi9ch ZiNdTpU+T2MTHMGKBGAPCrg2+VNwmUuRzIsWH6aE+voxHhWGZNSSaTL7zSMRcms+cZx0A2jpUiWa SVVgty5KL1NU5M8XITU1XGDkOfXf41YgwVBsRp41qEjM2YyMZOU3p9K+Ln9FauJAkQEcXU/jfxNR qoRQo0FSGePGhaWQ2VBcmsty4RdsKX0K3O8jJBEvG4YJmlF5bdQo63+dVuLgl5p4McIsHH4NgVHV msLknS5NqyxyOUZp5Y1tLn+hXPUIfTZfzXrseCwFwMRYgbu3rkP9I13f/wBdIWrPGp5Ltv7Ub+Nt RAiaKBYD4CrkbXsPCqEbWtrVqGTWvMpk6NYLyqG6UjxOpDDqDpT8ci2tXQsZFq7VpPWIOe7ox+Ll LOnX+IPxD5VPWTPGY5N8ZsR0Iq5h5omGx9JB+Wt0vL2vocr8cepFqkpbikJrqchKbelNJQBSg0lA 60A+5ooooB9JeikJrkdxb00sKQtTCajYgSdUmiaKQXRwQR868553jpOPy+xb+Gb9tvMGvQ2esH3Z GkvFyyEDfFYo3iKVvDNJdDz/ACe4u5bfh/EaxJZP4pv01Irby+QFmC2YOg3XFvVXOfjmNvPWvSng 4XWTVwlbYZCTv/V1qRZIY8Ji5PeYkVElzDodq+B+VVnPeYi/Q2ArNU5N2cJIucchaT1G1+proDjp BEAx0YizX6j5Vj4FomTpu+OorTJmecyLGSf1R1AFV9EWmjfU0+Kwk5CcY8S7V6lr62FdxiwQ8fjL FELG2vxNch7YZm5NpVG1FWxHhc2rrCSzbm+yuHJbLUm0h4Nzc9TSlhUd7VG7+NcpLAsknlVWWa3U 0kso86o5E3xrLZutQyMiwNY+Zlddafk5XUXrEz8oAHWsrLO9axllPks3aCAb/CjhOMeaXvzLdyer ahB5mocHFkzcruWuE/DfpfzrqUysHExQQQCNLdSz/wBL5V6a12V0yzz8lnd9qomV8OPCYR3ujBiX 0LbTrf4VmzTiewFyykkE9OvSq2TywfeS1t/UdDYaWA+NV4ZcmeQCKM2ksqgmxJPjW1VrLOe9aI9N 9p7jw8Za1tzbT8Aa2Car8fix4eHFjxiyoLW+J1NSO1YI9RHYVXkcUsklqpzTa2vWLMtUNnkGtZs8 9r61Lk5Fr1jZmWNbGuTZ6KUHz5fxqt9RvOlZs2WSTrTYJyWGulZhnfYkjfxxetGJ9grNwmXaLmrr TIF61tM42lsTMziiGxrn8nLdybmrmdKHuAax5b3PjQ6cdVGg7veN6A4Y3bpVX130qWOGV+gNINkr MgGmlMGvTrU8eAzdb1aTEVOo1pBNxSETdTWP7iyFEK4iG8jsGZRr6RXRyGONS8hsi6k/AVxzcjEn IZWXt7pcMmPfUA3ADfYK6cNJt5HD+xyRSO5Z4mOTleRjlZdsGGihVHw6flua7GK6/KsX2pgvDgGZ xYznco8dorZY2pyNWfkTiUV8WWVktarEeQB1rK7hpRMb6GufU06yb0eaANDU45AjxrnVyGBqdchv OruZl8aN0Ze/qfvoEhVxIp9S6g1kR5B0q3HNuFZ3PUm2MHSxyiSNXH6wvS3NUeLYyRtHfVOg+FXD FJ4G9eurlJnjsos0OuaL1GVmFMLTjwvWiE9xS1V+omB1Sj6th1Q/dQFy9FVPrB+yfuooC7TDQTTS 1cmdhCajZqGeoWesWZpIV3rJ58dzislevoJFXpHqnmWkx5EOoKkVzVvUjaR5NmyWLH4afmqpjRl/ UNLnrUmfuEzQk6hiPupvdKx9tNAOpr36pHkf3PzJ5Xue0nRBa/xp2NEFO4jWocfdtBvcmrsakoCf PSqlAmWW4lAUk6eVX8cZrvHjxk/xBoB5GqMIZmHj5rXc8BxSWXLkWxsAgNcuS+3J2oi7wXFDBxQG H8Q6sfGtM2FKLAU1nANeZ95Og1iBVaWS3jT5ZRVDJmtfWo2aqmyOecAkXrMy8gdL03LygL3NZWRl X1vXOZZ3px9RcrI661hZcrzyrCn4nIGnxqzlZB11rLinaOR511cDbH828fsFd+Gkszz3Vam3FnR4 eM2FjJumclN/kRVPJjmMT912LbgihfTqevzFVcWdMUtKfVIRZPHXxNaXGSmSZpJRuI1UHwr0W9Oh 5K+vUlh4mHDgHjLa8oXSxPQfGr3t+MT8vjLGpujBmXy2nWs7K5B4chyvq7lib/CrfEZQwubxSr/j KmRv3+oqNuBicHqplt41BJMPOqz5Px6/oqrLki/WuDsaVck0s/XWqM+T11qKfKsDrWZkZR865Nyd q8bkkycs62NY2XkXvrTp8i99aoyt1JrJ6aUghdydanwySwqi8ovarvH6kGttQis2oJCq69KdNkWH Wo1jYrTHx5CfGsnPBDJKSfnSLBv6+NWExHPhVyHD22uK0g7JaFOLAW97VbTFUeFXFjUCkewpJje2 QdsLr41XlYA66VNJJVRzuNyft+2plstVq30MX3RkKmB2lazyso2g6letYE7Y+RDh4WIm6b/rWH6z vbT7LVZyZcbJ55jlvbGjYjTyUdB8zT/bEST82ZkW0Ue51B8NfT+evVVbaHkvbfyKPI7KKMQwRxdN ihbDpoKa1Kz0wnWvO3k9dVCG7L9KTtkVMoFO2g1A2QBSKeulSFRTTaqQerEVZilN7VSualjaxFZa Izd47J7M6t4dGrpNPDoda46B+hrpuMyO9jAE3ZNDXbht/E83PT+RapLU40ldzgN2qfCjtofCnWot Qgnaj8qKfRQFZjao2eh2qFmrz2Z6UgZqhd6VmqB2+Nc2zaQyR7VUyJbIxv4GpJnrF5zkBi4E0l9Q unzNYiWkjcQp7HnOYyy5+S9/SZG2/K5qIb/wj76TxB6k6mpoVsfVqD0r6dVheR4bfc34lnGB0Unr VtEIcKNQKrx2LWIsFrU4nEXLyOzc7z+G1LOFLLVS4Nr23w8eTKJ3B2qbnw1ruEUKLLoBpWfgY6Ye OkS9QNfnV5ZFvc14rX3M9KrCgdIs1v4YLVRm/mC3btMR8LGtSNwakBvU2ysMK0dJOXkz5FJWUFG8 jpVGfOJ8etdflYkGQhSVA4Pn1rkuZ4XIwy0sF3g628RXO1WjvxXpZw8Mx8qdnJF6z5W+NOnmsSb6 VRysxYkJPU9BVpVt4PReyqpZDmzhFNz8qpxeqMOddTpTZFkyRvNz5CjHYiMqdCpr18SS8z53O3Z+ BZe30ynxDkDw0GtXuPyRsMo6+H2VmRkSP22J2kaVYRu0APA0s8QONdRsk7PM0t9N3pv41Zwp2l5f GjyCBd1Bt5D1D81UclwigD5ijj8xcfkIsiUb1B6+VV5qY0vB6tLlgDrVGbM+NUDll0BBuCLj7arv KxNeJvLPdXiUItS5RPjVOSUsaZcnrSEEVDokkROfGqWZOI1IvqatTuqKSa53Kyu9OdpuoNhW6Udn 5E5Lqq8XoWVcuw8Sa6PisVyoO2svg+KlyHEjDS+ld1gcesSjSrdp4XQw7xXOoyDD9IuKsjDUeFXk gAHSnNGBSDg7tlD6ZR4U0xWq29hVeQmxqMKSs9lqpLJ1qeYmqMpNzWTrVDJHB0rM53JfF4yWVDtc 2Vf9Y2/NWhtuda5X3LPLk8lHx6tZF2j4bm866cVZsTlttp4vQynhx147vM27IleyqfBV6n7a6f2z jiHAElrPLck+Nq52HDx35YYkbdyFXtu87fi/LXZIBHGFXQAaAeVdua0KDjwUluxPvFKpvUKk9alj ua856oJVp4pliKcKGWKaYadbWmkUIJcXpyHWmEU4aVGUuwydBWzw2T28gITZZND865+NtRV/HkKl Sp1BuKtHFpOfJWawdiRSU3GmE0CSDW41+fjUletHhahjaKWgVQFFLRQGazVXd6VnqB31ryWZ6kgd 6gkfrSO9QSSCxrm2dEiOeSwv0riPd3Id1lw1b+k4/RXR8vyK42O8rGwUG1ec5GU+RkPM5uzm9d/6 /HL3NGOe+2sLqRL+O/xq1oLfOqwB3AedWImYOCLEA9DXsPGWY2JY2Bt0tXoHtTg3xMb6qcWmmA2g /qrXNe1sCLOzi0oukNnPkfhXoQyFChR0Gg+yvPzcn8T0cVIyO7QGgpwUCo+8CNKTuDzrznTJaVhb XrU8badaoo4t1qVZR51UyNMvg3HShoY5FKsoIPWoI5gfGrCuLamtqGjLwc/ynsrAy9zwHsSEanwr huU/y/5+F2kVRkRj8LIbm3yr1wMD8qUhTWko0L7jeLZSPF8DjMiFu1kxtG3kwtVTmOMfEfvIPQ3W vbZsTGm/vY1f4sNazsz2txWYjI8e0N5GotytJq3JW1Yg8UicMQ/iKsQyCUW8V0tXfZH+VeES7Y2X JHuN1VgCBWbk/wCV/KR7mxcmORrXCn0kmulrJ+Bik1mDiJgd7qxva+w1FY9u56KdK6fI/wAv/csd 90BktqO2Q36azMn2/wA3hrIJcGcR2/F22sPj0raso1Odk5nxNzh3aXBjO69hqau9s31++uY4rmH4 xBFJHujY3JvY/lFbH/FXGEdHv4Dbp99681uJzhN+R7ac9ISbS8zQaO1QSuFBvWbJ7qxSSoicjz0q hm81JkntwKyBtLtWfavOkLxNe/xrR7n2QcpyDOxgh1J6kVPwPBS5Ugd19INJw3DnImBYE6+o16Hx XGRwRqoAFq1ayqttfmYc/ff4IdxnFxwRhQoFq2I4QopYogoqRmAFK1OFryxpsKid6V5BVaSSlmEp B3HjVWRqc71Xdya5s6JEUpvVR11q05qG1EjomUsuUYuNLkH/AKpC33CuEZJcqLI5KaSzbgF8yx8P sFdJ7uzmjgjwo/x5H4rfsg2t9prnk45/r48B23C4aQL0BOpr08VdtXZnn5nusksx08zT9t4cYiGU ReRyQCfACt/bcW8qZiYawRrGi2Vegq0Iq4WtLbPVWuyu35kQUgWqZFtan9u5GlPIVB6j9lZEhYWp LWNNEqdKk3LfTWqQbQRTra0GhCMii1qeRSEUKKnWrcLW1qkOtTxtUaIzq+Cn3RtCT01UVqmuW4nJ 7WVGSdCbH5GuptXq43KPFy1iwlLS0Vs5iUUtFAc471Czihn0qB30vXhbPakI7dapZEwUHX41JNKA DrXJ+5+b7CHGhb+K/wCL4ClauzhG21VbmZfuTlvqp/p4yTEh18iaxAF3U3cTqTqakUC1zX0KVVap I8N7u1m2OU6hvCnnTUHrTQAelBvrWjB13snICJkC+ptXS/W+FcP7XlYZUkd9GW/3WrqFuRevFzL1 Hv4ErUTNNcvSnjKF+tZo3eBp43GuRt1RpDMHnUq5Q86ygTb404O1VEdTZTLA8amXL+NYiyNUn1DV TDobq5lvGpVzR0Jrnhkt4Xp4yiPHWruaI+M6NctTUizqa5xcxl8anj5AjxrSuzDob4daXcPOsZOQ B6tU4z4rfirW8mxmjp5A26aCmm500186oNyUQFgdarvkSTGyvtB8am5FVWT8hxPF5htl4kM5/aZQ W++16wMv/Lr25kndCs2Kx/7Nrj7nDV0WLjqo9UvcarVgKqdujaI47I8y5X/LDNjG/i8hckDXtyWj f7+n31y+VxfJ8XJ2s/Gkhkv6WYaH5N0P2V7rtUm9tabLjwypslQOh/VYBh9x0rSvbR5MpJOUoOE9 s4qdhH0JIBPnXWwgAdLVMOKwl/uYli+CDaPuGlI2K6/hNctrTO1r7he4B0qN5bikeCfwt9ptVeSH MHSMkeY1o2ZVUEkw86rvMKhyHliv3EZfiRpVN8gk/CstnStS28oNRFjVfu04Pp161I8DUEm4Go5H VFLMbAC5NI8iIpZzYedcn7j59mD4mObAizEda3Srs4glrKqbbMnm+SOdyLTIbRx+mI/Aa/nrd9u8 en06ZbjdNLdmY9bGud4vjzm5ccN9Dq/wUV3mNEkMSxoLKgCgfAV15ntSqjl/XTdrXfkWEjFgBQxV Oup8qdu2r86hJua4PB31HF2PQ2+FRta+v30pZwvpXcfADxrTwOAzs2zbO3H4u9VJvoRtVy9DHNuv hSq5XSu8wvbfHYsZV07zsLM7fHyrj+Z4qTjMxoSCYWu0LeYNW1HVSZpzUu4REr3FLe9QJUu6sI6w P6UHpSXvS30qkG1KlRinKdaELuO9mGvSu0xpO5BG/iyi9cNCbGuu4SXuYKi+qEg114nk839hYkv0 UUorsecLUU6igOMd6rSy0sj28azOT5CHEx2llayr4efwFeKG3g+gl1bKnOcxFgQFybyNoi+N68/y J5J5mllN3c3NT8lyE3IZLTynr+FfIVUr2cXGqLxPLy8m540Fp1zb4U0Ut66nEduYaijc1tabS+FA X+HzPpc6ORj6D6W+RrvYl3KGU7lPQjyNeZ1ue3+Wy4shMYyExNoFbW1cebjlSej+vyx6H10O2C2u KeF0rLlzchNVsfgaZFzzo22aLTxK15T1urNkL91KE1+dV8bksPI0RwD+y2hq8trefyqwYeCMJTgg NSqtqftqwZ3EPbFNMYverFhRtpAkgKAimhR0qzsFJ2xQSQAUuvnUwio7NBJDrT1ZrCxp/aFqBHap AnwLODI+7U9OtbKOCKxMZtr7TWkkoFq3XBysuxdoJNV/rI1Nm8qrZHLQgeg9K22oJtbNC9xVXKyn i1SxrKPJyu11a4+FLJkHbuc6VjfJpUa1JjykjNskGpqaHKK6HT41UhZJV3KL/GkzRImLJIg1RSw+ zWpk1CwjQmQZERDeoMK8+9yyZ/EZnaO1YJADDI17N5rex1r0PBdJMdGQ7lZQQfMVm+6OETmOMlxO kv4oWPg46ffW0lOUY3OspHmo90zrIfSCvT7fupkvujONwhA18ulY80UkMjQSoUljYq6+IINiDSpG 59QBt8BXb26djn7vJpP0L+Tz+flQiGQhVP4tuhI8qzj51JLfdqNR4eVRt5VutUtDnaztqdD7Px7t NkMOlkU/nrqo0ub+FZXt7F+n42IEep/Wx+dbClj6IwSx0sOteS/qu2e3jUUSmBsrXO0eFWOP4rKz 3CxL6AfU56CtTi/bjyWmzPSnXt+J+ddLDFFDGI4lCoPAVqvHOWc+TnVcV+ZR472/g4dmZe9KOrN4 fKtQG3TSmXFLeuySR5nZ2ctjwdapcvxsXJYbQuPWBeJvEGrV6W9GpCs00zzOaKTGmeGVdskZ2sD8 KA1xXU+7OI70f8wgX+JGLSgeK+dckp8PKvLau1n0OK++q7kwNOvTAdKW9Q0PBpQaZTgapIJ42NxX Te3ZvU8XmLj5iuWQ2tWvxGR2cmNidL6/bWqOLHHmrNTrqBSDUUor0HjHUUUUB5xmZcWPE0srbY0F y3hXnnN8zLyeQT0gTSNP0mtr3CM3kwPpz/AT9Tzt41yjKyMVYWI0INc+Ci1nJ6ee1tOg2lFJRXc8 7F6UCi+lFUgtKBekFOjYBrnwoBNeh0q1xt/r4bftCoR2ihJJDA1Yxp1gyosi11XUis2+1mqQr1fY 7R03KL1WfHFWYZ0yIVlQ3VhcU4revA1DZ9RPBn/TjdcdavY08yCwYi3xppQGlA2m9CvJeTPyB4g/ MVMvIy+KiqAvanKTSTDouxf+vl8hR9fN5CqYNPFWWTauxbGdMfAfdTxmSfD7qpXtTgdKSTauxaOf KPBaaeQn8Av3H/TVYmmX1qyNq7E7Z+UTowHyFMbJyXQjuspPipsaiuKOmtRuCqq0MtOf5jieT2Zz PlcexsXKruAPjuAvpXa4+VHNEk0LiSKQArIOhHzrnpYYp4jFKu5GFiKxM9OQ4LbkcNI8MB/vYwdy k/utcV1q1bCwzjelq51R38rK6m5sPCqJgFit73rC9te65OWmbCzURMjbuidLgPYXYEXtf5V0Cyxq 9m6Vm1WnDRKOVNTN42VkzMjDb8cbXF/I+NbD45lhZf2hasrLj7XO42Wg9E0ZjkI6XBuCa1+7st5a aedIg3foytwjt9OYpP7yB2Rvzg/dWo21kIOoNZcTiPknHQTqD/rL/wAlXTIw/D9tVaGLL1JlfgZ/ pxJgOT/uzEJ+5+r+Stl3RlDAgA9a5TNyfouUiyWBCyN2pCOgV+jH/WAFSZuVNfaGIXoLU3YhmnSb Sjnff/CIucnKY9gmR6JgOm8dD9oFcmGaDcu7XoK7vmw03A5Qc7miUSKfipFeesxY9b31rvw23J+B 5+euxqNWIxN/0025DXv/AKKtYPG52fIExYi48W8B8zXdcB7L47EKZGeRkzjXZ+oD8vGujskcUmUP b/8AxFnQqsGDujACiZ/Qth46g16Lw/Fx4eOhlVWybfxH6i/9GlgmiVQiAKo6KOg+VWUlB8awqV1R u17NQ2Wg1OBqAPenhqpglvSg1GDTgaAfelpl6WoBSAwIYXBFiPDWuC5/ijxuaSg/3eW7Rn84rvQa pcvx0fI4LwEXcC8ZPg1Z5K7kdOHk2WT6dTgFanVE6PDK0UgsyHaR8qdurzRB79c98j70oNMDA6U4 GgJ0NXMZrMNaoIatwnpbrVWpi6wztePn72KjHVhoatA1h8DkWYxH9bUD41tivTVyjw2TVmPopKKp k8nx4ABasH3Jw5im+sjS8cg9dvA+ddXHFbwqUwRyIUkXcraEGvLS21yfQ5ErqDy1oWC7wDbwqPrX Xc/7cGFC2XjE9rqyHWwPlXMPA1t4Fga9lbKylHhvV0cMgHlS9KQiitEHUlJRQg61Le32Ugp270bb Dre9OgOh9s5pIfFY6DVa37261xfDSFORiI8TY12BevJzViyfc+h/Wtupl6D2I8KUEEVAXtTe7auJ 3gtA0brVW71HeFCNFwMDT1e1URL8aeJhSCQXdw604NpVRZgakEgPjVJBOTTWNMD0FqAW4pfDrUd6 N1UhKGtSnYwKsAQfCot1IZKCDMb2+cfLTOwZtk0cgkVT066/krpp0dyHj/CQDprp1FZLTfGtPClO ThtGG9cRt8bGtbm9TO1J4xJV5x504xZ42ZHx2WTTxCm5H3VpRz/VY8c8Rusiht3XrrWflQSPA0TG 4III+B0p3CRSQcYMZZNxgYqG+F7inQlq6FjKR4WjnLf3bBj8vH8lXTmxxX3a/wD2vWPnmWRHEjEg i1qmBMuLFIerIpJ+NqiNOihNiZnIxz5EQKDYx2OD5HSlybMoK6C9Z2YoVSb9NQasxzbsYN56/fQ0 64UDeQikm4fKhhF5JE2rfzJFZPF+1MCMBs4maT9kfhFa3eP0swHUL+kVUGRIp6/ZXXjbScHDl41M m5j4uJGgSEBFHRRpVtIT1U1gw50i21++r8HJN41pQcnVmsiSDpViN5VqlBnowFzarsWQh8RWl5nO 09iymQ/Q1YjnB61XRlapQq1r4mPgWlkBqQG9VAPKpVLChCxS3qIMfGnhhQDr0oIpNDRagOS948Z2 5E5CIemTSS3n4Vzqtp5GvR8/FTMxJcdxcODb4HwrzaaNsed4X0ZCQRXDlrGUe3+teaur1RIKcp1q NGBFPHW9cZPRBOnWrEZ1FVVaxqwh6VTFtDV4/IMUyOPA11qMGAYdCLiuIgkANdXxM/dxACfUmhrv xW6Hk5qxkv3optFdcHA4FY6lCW8KcFp9jXhPe2QZGPHkQNBILqwsa8/5nhsrj5jGyk49yY3GoAPn Xo9qiyIoZoykqhlP6p1FdOPkdHPQxbjV1B5M8a621PnUBFq6P3NxkWDlboV2xSg28r1z7L99exW3 KTy2W1wxgF6KOlLcEfGqQQGlvQV0vSVAPjdkcMpsw6EV0PG8t302Sf3g/LXNg1LjzGGTfWOSisjp xcjo/A6s5I86YckedYoz7+NJ9dXD2n1PX79TZ+qHnSfVDzrGOafOk+qY9KvtE9+ptfVjzpwzR51i d+Y9FJ+yjflHpG33U9oe94Sb65q+dTx5anxrmwc3/s2p6y5q/wDVt91Pa8SrmXU6hchT4045Cjxr m0zModUYfZUn10/ijfdWfbZfcqbxyl86T6pfOsA5c5/Ub7qO/knpG/3U9tj3Km8ctfOkOUvnWH3s zwhc/ZTTLn+ED/dV9se6jbbKQ+NWOM5WLGzUZz/Df0SeVj0rmGfkv+xe3yqFv5k2nZf7qq4/Ew+Z M9OyY0toeoG0+YPjWdxcix8lNhk+qaISqt/FDY/nrleP5r3Jh2COWjAsI5RuX8utXOInzpPcEGfl MTI7bWsLABgVsB5a09uOpPclQkdLmJYN4ikw0vxsXmtx91Tcg4UMALnw+QqvAXTj00N7nQ/E1z0O vRGbyp7cLk9LUQyZbYcQxsd5ywAG3pf50nIHuoEkHpZgGFxexOvW1WeGys+HA+mjhkUwSt2wVOqN 01tROs5OjnaojzZLh8NnyX+utimQaL+I9fsFWhweCjASzuR8LD/TULpz+UVtAyoDf1m356l+g5z8 JjQfEsKu5r7Uc7cbt916fBl+Di+EhF9m8+bm9S9rjxftQIxHgOtZq8JzUmpeNR8X/wCSpB7czrh3 zFjYfs3P+im+3Yz7dFryVL8aYoOsAU+R0qwBijogHyrLbg8xdRnBz/SUj9Jph4zlR+CeN7eG43/K Km+3Ynt0elqm0JIALA2qVJkA/Hr4VzLQ81EwDQM/kVIIrThxMsxBpvSSPw31rVb27GLcVUvuT8jV TMjB2saspMjdDesVILsEkNvI/GpfpshNYnvau1LNqWee1FODaDCn6ViLnZcJtKpNWoeUhfqbGtbk zG1mmGtTwaqrMjC4INPD/GqQsdRXDe9MH6fNXKUWSYan412qyA1j+7sQZXDyOBdofWvyrF1KOnBf bdPucHHLoKsK1xWak1m18aspMfOvLEH0tS6p1qwjVSV71PG9DLRfhPnW/wAFk7Ze2TpJ+euciYaV pYchR1ZTYg3rdHDOHLWUdheiqP8AMP7F/torvuPLsObCiloJAqDIyY4UZ5GCIouzMbACvIeskZgK ryOKZgI3MZ5xIMjsIMWbL7qqHv2mhULY+B7tUcbO7+PFK2hkRWIHhcXrTo0k+4q07OvYq+48UZWA wtd4/UtcC9+leiZMyFCD0ItXH5fEZM+aVwYmmDa+kGw+ZrvwW6M5f2ePSyMg0ldhjewzLwB5Cedo swZq4ZgsCgDKrbr9b+qtHC/y4wjrPO7+YFhXeTznn4JtSpDLJ/dozH+iCa9axPY3A49j2RIw8W1r R+g4zCiMhSOGKMXZjZVAHiSaklg8ej4blJNVxZTf+iauQ+1OYksWi7YP7WleuwpjyxrLEQ0bgMrK bgg+VVs14IFDSMqAkKCdNT0FRtlUdTziL2Xl29bgGrUfs6Jf7xifka6uSKWTCzeSEu1MHJxsbsbQ Q4yGhQsW6i3e/JUeUjDHkeEXkA9Ol/t2jrby8ay9x0q6djAj9r4Y6Lf5mrcftvGHRK0xFjrlTR4m S2Zips7eS6GMsxF3W1lvt8wPh4VOpI6GsNOTauowZ6e3se34alHtzFI8avicrUqZI8qQHdmZ/wAN 43gWpp9txeDsK21nXxFPE0fjVhGXyW/COeb235SH7RTD7bf/ALQfaK6cSxGj+EabET3X+Ecufbsw 6Ov3Un8hyx+Eqa6rYh6GmMgHjTaX3X2OWPEZ6/qg/I1E2HmJ+KM11RWmMDTaVcr7I5ftzjqlJaQd Vro3RD1X8lVJoorE2tU2s17ifRGKx80pqSduRXC6owYfYb1o43HHPPIbJjD/AC/DfLFlDbyl7Ib9 BpWftZkDDqRe1WGkVcicpLQ6FOR47JjMhkWIr+NX/F9lMx5lycUvGbr3Hsfhu9NYORDhomG2Jktl STQdzOjaMp2JvR/DBIF+refS/jVjAy58TcNncjf8SXtr5g20rLqK3lSXZ8WFpohPIkcW4Fmf03t+ rW7BKmHiqiRpLc33rY3+Ncs653OchjcfjRhJJ2KRh/wrYF2djboqqaZg4/Ix43KZkUo+g4uUQyMy kGWRpRCg2bvRodz6+kffUXG9UL8qbh6HSZvJyEAKm1vC3W32VTbPyitiDfz1qknJTRqT2VNvDWoc jm8vbeOONfmCf01hts7KiWiRpRZubboakbMyQLm//LWFDy3M5GRDiQLC02TIkMQKkDc7BRc3Ogvr Vv3FmfyXNXCxs0cjkxhlz1MXbjik9BRYzre92v6jWlVtSYs6qyrCl+BfOXmP1uR4gX6VJHkvGRe/ wFzXPQcxymW6rFFEoboTe356v/8AjKaWxpPiGI/Q1Zg00o0XyNxeQKjrYmnDk1tZhesOSbmEW74S yDzicH84FQx5s8hs2NJEfHfUh9zO1HR/zaF/Rs+2pFnkXobjwrn4pSr6g3qxk5Ld2Jd7QQu6LLkB S+yMkb32jrYV04209THLSsYN5cy+ji9I8eJNrbY3mKxIc9lklRJDkwJIywZDIUMiDo5Ww+Xx61YH Ip+sLGujZwVS8Y8qDWJt6j76kh5ix2y3VvjpVFeQj6o+tJJlQSC0oB/pDrSexY8DeizInFw1r1JM 4lxpIX1DqR+SuTZ3i9WPJvUeHjVjD9wG4jmBv0NNy6k9tymuhxGYTBkPGdNjEfcabHmheprQ5Ph8 rL5CeWIhIna6k/H4VXPtyCHb9VkkFzZRcLc+Qrk1WdT2K7SQ+LOjI61bhyo26NSD2hh/8PZHNpkq ZMWftTYbAkohlEKszK17m4fp0061p5ftXj+KyseBZlzsfMx/qIMhBtBAIB/C7AqdylTR8bSkyv7F W4GQzrca1pYsgJqp/JMawMMjxH53FIsGXjMN/rQfrLXNGrNNG73h+S1FZn1I+PS/SitbmcthM7AK SaZwMOLyHuSDGzGPbiU5EUNiVlkQ3AYjS0dt1j1NvjUIM2Qe3AhkY+XSrnt3jp8T3RgyTkbnjnG0 eHoFXiq9ybROVpVa3ZKns5OP/wCLcmDi8iTIwhxeQEmyF7ZDGbHDD8K+kaa2qkeF45OCXkeI5GfK TFmixMsTIqL/ABdiI8I2K20mRbbidKt+x0jXkwyWu3F5m+3n3cXr99Q8ShHsbkV8Tl8Z+VsKvTtU Q0edWacpsdx/t/jsmLCfPz5cbJ5VpBxsSIroyxkKJJ9yto5IsAV6jXy1uNRTi7WiWKaJ3hmjT8Ik iYxvt8bbl0+FRnOgxOI9ry/QY+VNFhjt5ORI0YilxxCHW6q3q3a6+Rq5xaGaCXMLIxzJXyCIjuRT IblVbS+vwpCWiJazerM+c9v2/lG34eZQ2Hwijo4o4ee2LAeXmiz8xAUjxoUbFjkZO72ZHkRmZgAb 2dfso5CRYPb2bK+ixcwrtbyWGMmn8ZDHxvuHh8WeL6nkstfqHuSIsaORJtoijW25/wCG2526eHWq QZiZU2WmdJmZEmFDxKhc04qo8rTGWSDbH3ldQgaI3JXx6in8DInKc5Dh5ryNjQs82PvjMZyTG107 i29PbtuI03G1tKo8fyWNge4M4ZG2TEzszNw8/Hb9aJ8uYK9vHtl9R+yx+FaHCYj4HvSPjXcyDCM6 RyHq0bRJLHu+IV9p+IvQBxHaUPFhSy5HHRqgxppk7bk+rettq3UaWNLHjcXm4/M5PKyyQ/SIsKhF LGKJzfuqCCGaRltpeyj4mne2yj8RjhWDFUAYA3sfI0zKW2B7lH/8DE/ty1CFTiY4Mj2xz65WS+Pj ryMDLksn8QxxSY7w/wAOw/iSKqgC34jUHLovG4+PlYOVJmYfIY7y40mQqiRHjKh1ftrGp/GLenwN SwhX9rc1sIZW5HA2sDcG8mH0qvzak+1+AH7OPl/keOqUtTcXInuiH279XIY5XAOVtTugHHmyLW27 OsdulNl4+BcPkp8TlDl5fDAyZeP2tsfaUsG2yWXcyhGuQbXFrVpZSn/6n4jeHcUf/wBjlVkcWpGL 7zP7WDln/wDmZtSEWWGLjY8mLjZvK574EGfM0ODHBGHdgjdtpZGcMFXd8OljfWn5+OnHcrNx8GRL lDHAE7zIqFZGAdVXYqggowNMGFBy3t/jPqcqHjo+Imnw5pspu2kkUrpJugaxDyARhdvnf4VPkTpy nK53JRKVhyZF7G4FSY440iDEHUbipIv4WqNKCpuSv25m4vM5RJ2L4GQkU+LtXZ2JdoWUG27Qvrr4 Gj6PkGPCQw5BbN55XlELqO3DDo6v6bMT2zc3bWx6Vc4VIv5xLxmVf6Tm8aTDmANvWqs8Zv8AumQD 4kVPBlxS/wCZkQWy42IjcfigfhBihZzb5Euv2VUkG2VcvGxYMTKzeJ5OTkRxsqxclDMirtDNs7kJ SOP0qwPXdcA66VWnbKxYOFf6lpG5vGhnbcqfwmleBSI9qi4AmP4r9Kh4COWHhvdvfBG3CONJf/3i +SgX94O35am5RXeH2OiAsz4eKqgaklXwywHyAuaQSTSvJhchn8fJK2QMOZI0lcKGYPBDPqECjQyE dKbFC+fLyLfWfRRcbjwz7iqmM9xp95kupayiH9U03lb/APEvM/8AzEX/AOUxqihB/l3uv/8A1uP+ fMp1HQMuSLBwcTlMfObO4/MeSFnli7TxyxB2I22U7bRvoRfTqasR4EsxixTnvDzuTi/WwccUQ44Q 3KxSPs37yFNyH08vPH5dHb/LzERfxnkssD59rOroPcXuDH4znYM3H43HmlOJHLBnSytGe2/cTau1 GXQfnqkMrDyoM3Bn5XMypMDisXtpJJCivO00oVhGodZANqsC3pPX4VJlY+XByY4RXXJyJ3i+jnK7 Q8MwLLKyr+wEfdbrtpOKnxsf2byDTYcWcsfIo0kLsUjAljgCSbkBO0brXp/Fcr/MvePF5s0UOOsI +jRIXMgXbDkmO7Mq2/vCopAktYeDw+LH7hTCz5szKgwJ4clZUVVuocMYmRV0V1Kka6+NZ+NxsDY6 ErqVH5qOChmif3PHKp7kGFlRzk30cvKwv+8PUPMa1exh/usf7g/NUaEtGJJwxH8iSKcmXn8eKYmQ LtiaTtFtuwLcASG1/IVPLxuBFyZwsDIyslYWmiymyYgoWSJlT+G8aIpVju0Ovj0p3MSdrjPasok7 MkXExyRS/svGMaRW/wBXbc/CtSeeLMbj+fgXtjlmbGzYAbquXCjnep8QVhZb+IC0hF3PuVIuPy8L Lgz8J1XJxmLR71LIdytGysAQSCredJJme4om5NhJB/4wP96UxEqh2dndCO5+wAPVfpfzv0UUQZBc VWzcdAhJ0AFyaQHaXk5jIwcXE4PCyZsvJ+uz8b6vDxUjV8fZ6SkcjbO5uIYAtusD1p2HxfGScc/K cznScdgNOcbHMChnkdQd7EtHJ6F2t4fqnWrcSQczwOZxCOGyeJR83i5l/wCxN98DfAX2/IqfCsjm l73+XfBvFcxRZGUkoH/aM0xW482sfv8AjWXVawbV7abmpZocbxCcV73xePzpWKwyLLizIv8Aelx/ BuNbA+sH4ir3F8VwmX/mJmHvPMIHkyVgdCAcpZP4nqsBtiJFvM/Ko+XDr799uxP/AH0GPipkeJ3X msCfhqftpvtfuf8A1L5K59G7N2j/ANrHeqkljxI3Z5b/AI/rBhw4mEjW4uWXI49UT6eeZNjsNut1 2rp5G1aGJjYsuNk8nyubLgcZiSJjb4FVpXmYBzbejgKikE+nz8q5fAzM9MKAR5G1FjUAaECyjSus 4/kMeL2BPk5eFHyvZ5EjIikYooLqoWQlAfB1H21zqk7NtHfk314651hShMjD5PH58e345BNkSSKu POw0aJ1MvdYD9lVa9vKrU3GYD4fMT4PMyZU3CwSyyxGFUvJEshtuKWaMtGR6dR59Kre2/cJ533/g 5s2OmIPpnxo40cuC8ayuG3FV12sR9lVfbAnXjfecU4tJBx00T+e5RlA7vjcGtqte2pxta/VxCFyZ JcT27ic6shds2bJi+nZV2IIDOqFSFDa9oXuavZuLPgczi8MmU8i5qYj95lTen1MssThQqhdBHpcV m8oGb/LjhQNWOZmLp+0z5e1fmfCtr3CrL764ZSLFYeNDA+f1ORTau3Ym59+5FhYMubzmfxEma0Mf HJM/1OxCW7bRqO4CLWs+u21RzpBFx8XK8fm/zLAeX6bIMkXZkilI3Idth6GuNCL6jU1Z40E+7vc4 Gt8XLsPtirL4jT2LzLNqkmThRxfGUNjk2+V1NNqjTuNz79i6vGYAwuJzuQ5VsReXS4iWFXYO2zaI 9qGyDd6me/h51NF7eT+ay8LkcskfJ2ZsSGKEsjIBuVp2bozAX2KwsNb61nc4CeH9nfDEf/vMKtm3 /wD1e/x//wAOrC7El9zF4qOPOhyczNlbAwePjQ5kkKh5TLI3bSGPeGW+4akg+HnU2RgtDzWDxceS ZcXkxDLi5wVQ5hm3aldu3cNvlaxGlP4GeCH2z7kM2ImeIsuOaTGkJVTGZFAZmUEgIUZvsqHE5kcv 7k4ELjw4icdImNHDBIZAE/UBuq22hdKm2uEXdbJbk4aEfzPGxOWOTyXFpJMcXsgI0ceuxpLLeS1g xU2UnpTOFxuEzuC5XkeSnkjKGOEmNCzQRmRHQoCpDNKygm19LDzqThx/+qPcx84M/wD75az+F09l 86TpZ8L+1HSEnKS6ibNQ2+hFj4+XNjz4xnZcWaYzBQu13KWSFpP3Qu8LYerrV+GKX+GZ3DtFEmPE qjakcUQ2pHGtyQB8Tc03DkBQMpBUi4IqcyEi5Fea17PHTseivGsMkDAAWPSnK1+n21VLkVNGOhrK RpqCfZH5f+minafkorcGZN/GxIYI9kKBF8hVfKwcgTwZmG6xZWMxaNnUuhDKyMrqGU2IPnWoq2p2 0GvSeRucnNrxPKfzJ+WSaCDMmhbGkWKA9rtOyu1kMt95Kj1X+yiP25NDjHBhnAwZHx5ZomTc7Ni9 sx7ZNw2/3S39JrpQq+VLYVZBgLxufjxPi4pxpMN5DL9PmQGdY5GO5nitIlrk3sfHyq/x/HDFxu0X Mjs8kskjAAtJK7SyNYaC7OdPCtCy+VKLUBz2XwEsxlgaYNgTzjKkxynqMoQR/wB5u/DZem37aOx7 iRIIosyJBiWWGfsBp2jUgiKWRnsV0G7aAW866GwpNi+VJBzcWDzMWTNmCTEmmyHWWSKbFBhSRL7Z IVSRXVterMxpY+Jz48sckmQrcn3Wned0ujF07WwxqwOwJZR6tLCuj2L5UbF8qSDIw+PyFyJ8vJMX eyAoZMeMxRgJuOiszncd2pvTJcTOx8qXJ49ob5Maw5MOTGZI3VCxQ2V0II3t8xWztFIVHlUIcrBw GZHDPjHIQ4+blLm5cYiteVJVnURHuHYgKAW10pZvb00+PHhzT7sXGjlixVVArIJirMXa53W26aCu mKjypjAVZKYD8dyT568s2Sh5OOQOsva/haRSY9u13L/gkP63WqcvEZePBlxwTqByMMkGcWj3bkla R32esbDeVvOuoIWopogwpIOWOfx+D7c4zE5bDXPjzRJn4g7n05hglbuWE19zP/EubWt0JqdcSDGy oo8UyNh5mLHm46T6yxiQm8chOptpa+vXyq9Hj8rhxDGwpoHxUYtFBmQfUCIk3/hFZIiAL6XJtUmP gZDTy5mXM2Tlz2EkrAABVvtREGiqu42Hx1uaAo8ekUPN/XT/AOH4jFmzpj5HaYk+9TIfsrNxeKy3 ijyGdoc4v9SZl/Es7N3WYX/pk/Otyfict2yY45kXGz+0uWrRlpCkJ3CNJBIqqrXa90PU1pRY6qNR QSYPISc3ycIxs54Fx94lkjx4jH3ZFsVeUs73sQDYeNRwSc9h4iYGLliPFiN4gYg0iAnd21kuPR4W te2l66U48Z6rUTYkZ6CglGDHDky5GRmZjLJk5biSVkXYt1jSEWXc1vTGPGmzYeVbLjglWOHkIUx8 tGTcxSMyFdjbhtP8VvA1uHFA8KaYLeFQsowv5flNBFhNIpwsfIfKji2evuyLIrXfdqP4rabaswHl sfGhw4Wxngxv8HJkQd2bHHgInLhdP1brp8a1Ox8KOzbwoDI4/AyuLAHGugRoVx5oMhO7FLGgsvcU MhuATrfx1BpW4iSd3nnKJMe2I/pU7CQiEl4uyoLW2sS1yetbAS3hUii1WSGdO3uTLhlx589Ginia CRewoujjazelh67ePT+jU8fHhI1QdFAA+yry28qeLUBzn8nzlbAY5Kl+IiEHHntaKgCpaVS533Vb HpVxYM3IeA5nYSLE3fTY+LEYYlZ9GfaXe7WJHwua2NqGk7aDwoQjQWW1R5EQkjZGFwwII+Bq1tWj Yhqg59sblRhPxySwJjSRLjSZCQbcpoEGwRtLv2/h03bfy60YcPJ8WZF45oexMyu+NkRmSMSLa0ib GjIb0jx8POt/tRil7cdQpyx4bLfPHKvkF+SEonE7qCu9RtUdsbfSF0AvSQ8ZyuFyX83xZo2zjJLJ IXQ9t+9cyJsV7gXNx6vCuq7cflSiGM+ApBdz7TiDjMrhs3Ny5czLgiEstgUx02RgKLCylmN/M3pM KHlOGeZsJIzDkqEycXIjMkEluhKhlINjb89dp2E62prY6HQi4PW9Z2NOZybXLNVR19JwOTjZ0mYO S3pBmIyNAcdBHHF2vwKia+keIN71rwc3yHJcT7oizIseIpxckrHGj7Zkdo5lLyFmYk2TzqfNwnxp nQ6qdUPmKzmgzFjzosWSOOPksY4eT3I2c9shxeMrIm1v4h6g/KsVs0/Uzdqq1VC0IOIyubwMOTCw coRY8rF7NGrsjsLFomb8J8dQdadmHk8nNi5TJmRs3GEKwOsZCgY7vKm9S53epzfUVoRRBR0ps4G0 gVl3tGpVSrehF7YyMpee5XPdgct8DInZ1Wy9zfGbhTfTSqpz+Q5jGxVyRBBiw/xkxsWLtIZHB/iP dmufUelutET5uJkSzYZjVsiB8WUSozjtyFSSu2SOzenqb/KpsPG7ESRjUIoUX+GlV8j2pTnqPa9T fTEFefGy8iDDx55VaHjY2hwwqbWUM0bes7ju/ul8BUhm5Qct/O+9H/Mt27f2/wCFbt9i3b33/D/S 61bI8KYVNZ327mvbr2KfHvncVkHKwZFEsilJ0lXfFKrEsQ6Bl6Em1jpRJJmS50PIgQY+Ri7fpo4I tkCBCzAdvdc3Lm+tWxH4kUdsa6U320kvt01gpxNyGPlZOZDMgyM5ZkymMd1KzsHfYu4bdRpqak4v Kz+G7y4IhkhyURJoclDIh7dwrel01sdfOptmtL2wfCpvt3Ht07FfGjMYN9WZmdrCwu7FzYa2Gugq ZvLwqQJYUlqzE5NSlhEYXzqeIdKYR40hmCkVUHLLlFVfq086K1JnaduBTqLUtdzyCUlLTJG2rehB 1xRuHnWBJzeSrGZoFXCGS2J3u5dxKASN8ezQNbQ7vEVWf3Blr9I30pdeUBbjUjcNJKAyKCyEKEB3 g33dNTarBTqQ486Nw865/LzuX4wJJymNHHBK2xZseUzKr2JCS7o4ipNtLXF9L9KhPuDMjXHE2MqS 5yQSYSCS4ZcmRIY+42z0Hc4voaQDp9wouK5xOX5CXM/lkeMh5JZGjeIy2jBRFlY93Zf8Lj9WpMDm cuYYkmTitjQ8grNiszhmOwXO5APSCNV1N/hSAbxIpCR51l5XIzd+PExIxPlyhmRGbYoRLb5JHs21 V3DwPWqGTzeVgl4c+BUn2LJD2ZO7FKjnarRylUuNxsbqLfdQHQEjzqCeQKOtZbN7l3Sq3HC8Gr7J 1JcWDfwAVUvbdre2ugvVPJzOXTBXkZ8JosFigLF17yCQhUaWHqoO4eNxfUDWkAtQcvJJJEzwNHjZ TSpjTFlO8wMVe6jVehtWmjqResDGwOQzeA4WbB7O6GbL3HIl7SXklkVRuCu1z4WU0sOfyAyjxf0r fzNGKnG3KBtADd3uHTt2Yer7LX0pAN+ynyp6haxJczkcIwNnxQiHJYpDkYs3fiLqC2xi0cRDWU+B GnWkxM3mswYv0+ErHOxxmY571l7JCm8hMfpb1j060Bveml9Nczhc7yGfi42bg4Zmx8yVceH+IFk7 rJ3TuW1giqDdr/ZViHk+RyZsjEgxlGThG2Y00ojx4tWUXm2sTfabWT52oQ3SBTSBWJkctl4Epx+R hEeQVV4RA/eSYO2xO0+1CTvstio6jzpMzlszjW/8USCJDu/uJ+8yMqGXZMvbTaSgJFrj40BtHbTS FrGyeS5HCWOXkMeKCOXaO2s4fIj3glO9DsULe1vSzU6B/cWVHDJDgJsyYlnidpwqlHG5VJKX7hH6 oBHxoDWstNIFZSZHONjyZX8udYccMZkkdVm/hkhzHFrvAIOu7XwvSRcjkZ0hi41I5WSMTSSzSdqF I2uEZ5Arn1WNrKelAapAo9IrFfkuQXMHFvjhOSaUQiBn9BLI0iuJQpuhVTY7fhanzSc5jY0uZl4Q ixsYsMhhKGdQhKmQJYEx6Xv1trahTX3r50PKFUsToBc1iQYfJcxiTcliSLEuLKiYiPJ20lKyx/UO 7AGw2Bo1uPEnyq1h5wysZZgCu4HQ+BBsfzUIS4fJSyvjiaDspmwHKw33h98I2asB+Fv4i6fHr1rS DAiuShyUwhj5K4KRNykCz4SwsGeRJGQRx2KpsLNKvpva5rXjy87Gy0xM9IFeXcFOPP3trIAxjlBj jKNtN/EfGqCznZz45jSJDNNPIsUMYIW7t0ux0AqkOZyDIMQQEZ5mON9KWUWkUF/x9LFRuB8qTKcn luLHnmR/man81hmL3zw2dB6sfOlZZiOgnx4pYzf4shA/1aABzf8ADIkjZchZmxjjrZnMyuY9iWNm uRpUuRkcxgxjI5HC7GMSAZUkWTZc2HdAtt+YuPjWfwOxvdnLZMo3RcW2bkAHwkklZVbx/UVx9tQe zy03JDHzP4qc3hy/Xq3SWU7G3N1/VZx8vlQpq4uRzmfCMrBwRLjMzrHI0yITsZoyduttVqzj5WfD mR4fI4300s8byw2kWQMsRjWS+3pburXO+zIRD7hwRtAm2ZMeQ4Fi7xjY7H5sCat+3IIURskIBNI8 geW3qI7jeP2VAdWGW2pppljHjWLlZ2c874+BB9TLDCciVd+w7AbWT0tuYnoNPnUGRl8phdluRxex FksUhkWRZAHAZu3Jt/C1lPS4060Ia2YkOTH230I/C3kayzxs4ay7WHne1MhyOYysX6/GxEkxCrPG DLtyJY0Nmkhg2HcvldgT9opMblJ86SODjIvqpZY+8CWCRJHpZ5HINgb6WBPw61l0TN1u1gfJg5Kj ov3iqkkTg2IuaJ8/kfrk4zsxTZ06o8CY0wlidXMg3d1kjsF7LbtKhzpszi2A5OONEkjeSKfHk7sT iP8AGocpG25b9NvyvWXxmlyMRiUP4bU36kedqXNj5LCjjn5CKGFJSoMQmDzxbwSvei2ALe1vSzVU yMLPjwo+TniijxplSRYzN/vPblZUSUwbbbfUP1r/AAqe0b91dS19QBrcGmtloPKosPguV5GJZ8OK BIZSwgbJm7TTbNG7KKkhPT9a33VVx8HKzcp8GCADLhSaSeKZ9mwY7JHILqHudzi3n51Pafcvu1Lv 10dMk5CJfGqqcLyEk/HwDHSOXl43mwVllKlliVXbeAjbW2uCBVKPi8rOOQIECHDhknyzJIUEaxNs cXCtdrhvup7TL7texqNk5EMOLlZMDQ42ehkw5WKkOq21spJW4YEX6injkMe34h99WeaxhyPtr2li hhGWxkdio1Hbx41YD7WpuP7OwTGN8kjHzJq24l0M15VHqRXPIQ+DCoTy0A03AGtse1eJWEoIzut+ Ikk03A9q8VjSGVou6/gX1tU9vxNe7XsYUnKwW/GNPjUEWblZ7NHgxNM69bdK7FuE41pC5gS5+Aqz iYGNjEmCNUv1AAFaXH3Mvn7I4z+Te4/+xHTd1HX9mivQr/AdKKu1djHvXLdFFFaOQVHMLoafTZPw GgOaOEc7I5Tg9wjPKQLlYrt0XJxiq7jb4dr7FNGIYZP8wsfFjH+68RiHFxRpo8ca7iD+7PtP7tTq U/4ixZnbZFgRZGbO/kip2dp+fd3f6tZnHY/IIcbmYUBz+4+ZJE5sH+o3NLCW8NJLDyIFUpm8E7ze 1/cHe134mJnG/jkuZpGbXxLRL8auckSMv2qPPH4y/wD/AFWNV2XHilxZuP4zjpsDHzJlnz5MhkJI Rt6wRLHJJ6dw+Ate170qpJGnGjI4o5uXw4jjgyu8FRooytiYyy3kAXTcNobW9UBx5P8A9RMgeHfn /wDy0FLwkMeSDyjIDPkFyjnUrEWPajW/RUQKooxo8+LnH576N27k0jnEDoJAskUcQ9RbZoUv+KtP hOPlxOMx8eYDuxxgPbUX8dajBn7MaSb3AM2VoIF4yJXlQbmWOVsrvFV8dEWsXlpsGTB4rF49p5v5 cXjlmnhaH0TSxOAN4HQqBYV0uZiyQZbZSQfWQTwvi5uGCFMsL/sliq7l1tcgWJrFl4V5yWwIcmGF ENxnSKzyOHidAqxllQIEYXOp3a9KAvEsf8zg5JJU9pSfBPozJsHw3EtbzrG4os3E+7nbV5MRJHY9 Wcy513PmdOtbG3kP5/8A8Q/RPbvbvpN8fd2/TfTX3btn4tfxdKpw8ZyOJh8liDGMp5bFSDuKyBYm WTJcl9zAnScfhB6VQUuUVX9o8JG+qGTOJB6XDS6/MXqzz2NmcpyXEpDGZc/P4qL6kFjGuy5ZzOw1 Ed2O7z0GvSrSwxnisfieR4iXMjw5JXEsU6xFhK7tZLOpIKvZgxH208T5yc2/MZWH3oMjHbBlwoWG 6PGO1lCFtgYhgd2o/Fp0FAUpFwY/Z+3Bn+pVeVTfKqduMuVW/ZW5Oy1rE9etS5hM/Be18DXtycZH POASN3ajgSJTbqLys3zApZI0bhJOFw+KnhRpO9h5DzJdZLbRJlWa9167UuCLDSrGDh5kqcZFPjtA OLwBhMzMrCRgIhvTYzWX+H40BBAxh9ptjRfwzkco0ClfSVQ+qQLbpujVk+RqjJxkLNMsISDHxY1l y5pdzY8QBbtkwqf4knqbYvWtf6HN2R4HYPaTPbOOTuXZsaN02bb79128rfGiXHWCPOxMrEmzMLkT FLfGZFljmh27P7x0G26KQb6EaixqAz+dEa4ftduNZnWDDllxWmAViYJMGWLeFJA9SCk5/ExMwrzW IoGLzaNGWKjuY+UFIkQnwvs6ftKfOps+OTkMfjIDxD454u6dsZC9lsYtGTCrL62dhEoJYKBrqaTM xmm4pOK4vCyIIVnOXkSZ7xlpJAu1Yl7TSaHS7fDxJqgj53tZ+JD7ojjXuOBicnHoTBlAdtXU9bNc J8QUNHKFjme0RckRw8cyD9kvkYyMR5XGhqeSCM8bPxfG4OVjDNmjlypsuSN1RYirqkRR3ZtUAuR0 6m+lMmxs/JPGTnFaNuIiw4zGWQmU400UzmMhrAMI9N1qAt8WS3+ZeczeolJo7nX0LHiEJ8gT0rH9 uQ4E/sPOHIzvjxPkYcbyRoZW2rDiPEuwakGRjWritm4vPy8+cN3E7S3xVePuKJEgRbksE/6o+NVe KwJOL444GZjPm4WVjwR5UMBVZEmgA2zRb2UHoPHwFqAVMvEzPdvAS4TSyRQJHiyyzRtEzNFHkFTZ wCdGNR8aWbP93s5LGTH5AOTruEc88aX/AHVG0fCnY2HJi8nByWJjZBxsWRHXHyJEaeRgs6vJo3bT cJFAUHovmaWCDOxzycwxWduXiy4xGGQGI5M0syGQlrEKJNdt6AgwUV/aXLo6hlfkOPDKRcENJh3u PjWwg2RBVFgBYAdAKqYkKYmLm8bnYeRlYma0EyviMius0G3T+JJHbWJGB+d6u4GNkjDjXJ1lt6rm 5+AJHUgdaEMXkWmjwPac8ADTY/FwzxKdAzRHFkCk+TbbVozR4S8nDzWGith82GaKUgB45wN80DHr 6tha1/xK1U8jBzMiDh4ZsRu3w+LHiTxGRV+oC9pWMbRsSukdxe2tulXoYUkgw+Pw8TJx8PFnfLll zGjMrysrIqgRO4t6ySdOnjc0KOm15Pim/wDjIvzNVvgciLM9wctxmTcvg5xz8InwuOzKF+C7v+fT MvGmV8XJhjMrYk6TmIEAsFvdVLWF9fGqePBn43LHnY4CJmyJJXxdy7mhlXa0Ra+zdcK3W1x1oQZ7 eUye5vcuIPx5q5Qj/wDZzOp/74VB7KJn5njGGgjw5Zm+A2xR6/a9Tw4fIwZh5eBBFmfVTZCQu2hj mdi0MjJuGqnwvY2PhUvp2ZcXFcXLxk3IDZl5U0qsEjYkyLjLHJIRu3G2iW6+AFClP2i3d9wYOQPw 5H1k6fuykyr+Rqt8F/gR+/J/3jVJj40vG52JnY+OZ0xVdDBGVVrOu0bd5VdLedWOKwZcfDSOUASX ZmA1tuYtb7L1AVkkkjy+YkjYpInEysjKbEEFiCDWBJeH/L3JEQ29rkh21H6v8FDp99dBnQ5cMuY0 EByBnYUmENrKuxnvZ23kenXw1qiOPy/5c/Dtjlo3zFyzkbl2bFjRCm2+/ddfK1UGhmS8HxfPcTmz 5WQkmFgRLHiQwNLG0RWeJWLoptfcdP6IrF45e37U5tkBXu8jBiG4s30ZaAopHgGEzKfmavyQxzYu Njcng5eRlYMf08OViSxxrNCPwLMzurqR4kC/Ug62pONxcjjIJIMrHPI4WbCsWfjqwEm9Pwyxs7KC dbH1A9CDcUAz2xjYsfOZDBRj247IbfGoDC7wqzgAalR0rPzBxEvtzC4Xipsicw5LzLNJA0SrHJFK p2lhb8Tg2vqa0MSCXB5hOU4vFyBDHGInx82UNJMrlu6BZ5FTTZbzK61Xy+IjlCrxGLlYsaXLJmSp t229OPGsTSem/VmudPGgH87FByuPj+5ViXdLtwuUi0JgybdpXU9bNuCfEFDSZkUPJcPi8uY0kzeE VMLkkYAntIbxZCXH6u7d8i37NTZUCvxGVxPFYWViNnyJJk5GXJG6xiIhkWLY7s2qAXPh1N9KdHDB Fx+fhYXHZONk8rCMbKeWSN8eOMhg/Zs+8/3jbQV0+A0oDN43Bxhl8XyGdI2NjS5sEfHKbyTzFJkK 9tWNooA7Dc3j5agnZ4nYP8x+YMgvGMfJ3D4W4+9Qh1jxOLil4qXL5DhFWLEk7ix47pGU2M53Ftw7 atbb+LxtTo5chPceTzmPx06xZmNJjvjvJF3BLIYbymz7Au2ECwYmgMaF8hI4OfIL5oZM5jcknUSP Et+ilPQAPCug57Ax+PweSycVw49zZMCRBfCEqZ5v695T/rCqskP8t4Ze8NxxMcb7eJjTW3ztUubi zJLxXDs248RgRiU9R3pgE/5ixG3waoCvxgnn+hx5EZU4qHIgDMLA96YMm3ztFGn32866GNLJasbj MRk+iWLFnxp4oyOSyJpBIk77QBsAkf8AW9V9q2Gny30XSjAwrSBbVLto21AR2pQaftpNtAJuopdt FUGhRRRUIJTZBdbU6g0BzOXi5zy8ljLiyOOTEGMMkNH2lxVN51YNIJNzdyQaIR0rcgx1A1FWNgpQ AKFGdhPKjsJ5VJRQgwRIPCnBQKWigGsinrSCFKdRegE7S+VIYk8qdei9AQtAnlUZgTyqwTTDQpEI I79KlWNRQKcKEDYtNaFD1p9BoCE48flTewlTGmk1QRGFPKjtLTzSE0BGY1ppiU1IabQDOytL2l8q dS0AzsrTggFOoFAN7SmnLEopwFOAoBNgo7a06kJoBhjU00Qp5VJSUA3YtKFApaKAaUB60naXyp9F AR9lKOylSUUBH2E8qOwlSUUBH2E8qOwnlUlFARfTx+VKIEHQVJRQGTy2NI6RFYmnjSeKSaJCodo4 3EhVe4yL6ttjdhpRhwTz5OVn5MZilzJjJ2nKlkRQsUStsLLfYgJsSL3rVKg0BQKFGrGoFOtS0UIJ ai1LRQCWotS0UA21FOooC3SUtFQCUUUUAUUUUAUUlFAFFFFAFJS0lAJegmlNNNCiE00mgmm0A4U8 UxaeKEFppNLTTVAE000pppoBCaaTSmmmgCkoooBaKKWqApQKBTgKgACnUAUUAE00mlNNoAooooAo oooAooooAooooAooooAooooAooooAooooAooooAooooAooooAooooC3RRRUAlFFFAFJS0lAFFFFA FFFFAJRS0UAVHJJGmjMFJ6XIFMzMj6fHeX9YaKPielcyMTm+TeSbGkihhVivdmBYyMPxWA6KDpXO /I01Wq3WeTrTjTTtZ7a6fE6c/Cmbl8xWbwf8xTv4+fF25Iiu1lJMbg7vUhPy6VltDymSQMBYnexa TvEqPDptqW5WlX0ZtOPIteJN29WKxnzOpBW17i3nTt6eY++sKDC5teJyYZFg+rdlMKhm7dgVvuNr 361Q7HKRqYZlhGYSBGqljH6rbbnr41LctqpejXx69hXhrZv16eHTudXuB6G9Z3MSzRiExuUViVJB IN7XA0+ANN4SDkYIJF5ARq7NdRESVtbx3eNP5hQ2Jv8AGN1I+09v8zVq824m42uJjyM0ivKlO5TE +ZLizk4SzOblVJJ8TtuP0VR46ed8va7sy7GY7iTqCo/TTseUrxct+gJUf61v/WpvEKd80nh6UHwI ux/OK5qztbiU/wAZZ0dVWvK4/lCG4uTM2YoZyVctdSTYaE6fdWlI+yNn/ZBP3CsjD/xsfzb+y1aO c+3FfWxNgPtNa4bNcd2+jsTlqnyVS6pFLByJTkqrOzBrixJPhetNmVFLMbBRc1g48jJkBmPpDBlI /ZB2m/8ArK1a3JOVxrD9dgD8uv6Kzw3a47t5dc/PQ1zUT5Kpfyx8jK5Dlpu4scSSSySX7ePCLsQO pPw+JpmHzM8WSkGVHLiSOfTHONHHjsboTWnw+MqrJlEXeY7Q3iETTb/W3Gr02NBkKEnQSKrB1BHR lNwR5EUpxWsld3e55JflrVuiotqwV+Td0x1KMVO8C4NvA1k4/NSLlNj737i6hZAdrgdSpPW3wrW5 f/DL++PzNVV44n4iF3A3xuxjPjcs6n8hqcsvktFmttdxrihcdZqnuttNXHmWeFZV0DeHkajzpWjx ZGU2a1gfmbVX4ZycaQfsyED+qp/TScu4EKJ4s1/sA/5a6u79nc9dv1OSove2rTd9BnF5EjyOkjM9 13DcSbWNvH51o1hcVIwyIy5A336fsuNyD7iK3an9dt0h9G0X+wkryuqTEJA6m1G5fMffWVzWNy07 xHj1hZQCHExYWPhbaKzTDyk6oMFYWktulEpYAdPw7aX5bVttVJnTOopxVtXc7xGvgdR+amq6MSFY NbrY3rKzsmfHwYYHH8YRKZVj6FgLbVv5tVGFOYwJkfNEQEusbQliFYamN93W4/MaluZp4rKrG59h XhTWbQ7TtXc6X50gIPQ3qrmy7+PaRdN4X8rC9YEr8nAzZKY3cwk/FNG3rWwuzFOpA+FW/M6tJV3S t2Owpxbk27bYe3J1VISB10qrx2UZ4iHN3S2vmD0NV+YkF40vbqSPnoK0+VLj3rJlcTfJseDSuALk 0txa/hWXkM78OJF6xWLD+irWa/yXWgT/APhRW+u7t/l3fmqPmjp/Hev2KuKev8tj/c07i176UtYY ZxxsdzpNIzKP6I9K/f8AirWxHL40bHrax+zSrTk3OIjCt8yX49qmZy6/ImooorocwooooAooooAo oooAooooAooooC1RRRUAUUUlAFFFFAFFFFAJS0UUKFFFIaEMznJLRRR/tMW/qi3/AEqkx5YcXjsc v6QUW9tbsw3H7zVfnRpA56bmQfMjd+ZDRkYC8lxkEHekg2hG7kRAa6rttreuOfcvGu1Qd8e3SdNz kuwZUORcxG+3rpbrWNx+UuMxdlLbltYVZ4X8c/yT/p1Qx+J4/k2CZ0XeWNboNzLYmw/UZaw7Wv7T UKz3eRtVrT3U5dVt8zexcpcmPuKLWNiDWbl/+aJ+/H+davYPH4nH44xsOPtQglgt2bU9dWJNUMv/ AM0T9+P86105Z2VnXdWTnxRvtGm20GteocyNpcWaNfxMjBfnbT8tT0ldmpUHFYcmFFN/ucig3V2S 35Tf8lXuKUDFL+MjsT/qnt/9GsogRbo+ixMya+SErf8AJW3hoY8SFG0YIu7962v5a8v9dN2c/wAF t+p6v7DW1R/N7voZmF/jY/m39lqt8q1o408yT9wt+mqmF/jY/m39lqfzEyxuWc+iJNzeNupP5Kic cF/G0Fanmr4VkhliCQYrqP72NmY/MhwP+eas8jIXixif11LH5+n/AE1kR83jZLx44ZzbSMMjKBYe ZFaWQwPHwP8A9nIY2PkHuR+XaKzuT9xLE1X/AGmtrWxvMWf/AHFzEkEPFNL07ayP9xZqpYvNSZAW SKVZIy1iQBrbqOlaPGMkmJ2yAdpIYHxDa/prPy44486RI1CKGWyqAB+FfKt3dvb47Vs0sKEc6JO/ JW1U3lyzQ5j/AAy/vj8zVhDLWV3xVciSIXCsDYX/AFl8xfrat3mP8Mv74/M1UJoA/FQZAHrx3Y3/ AKDuUcfLXd9lTmq7clo6Vk1w2VeOs9bQaHFwR4+BFHGxk03PIerOxu5P21T5qRt4VRcohYfM/wDo qfiZLxPGf1DcfI/+is7lsuKGaWeQnYjAaAsbiw6D41eS6fDXxhfIzx0a5reEv5k2Si4ueNvRRG/9 X0W/5lbNcrDy8GfNtVnaQLe7qV9IPmQPOumxn348bXuSoufjbWtcFk7XjE5Jz1arScxgkrK4f+9b 9z9IrVrK4f8AvW/c/SK3yf8Ak4/Oxjj/APHyeVRZk7vKhT0VkYf6oD/oqzyig4hY6lGUr8ydv5mq q0hXmGJ/aVR8mRR+mrfJEfSMD+sVA+YIP6Kwvs5vOxt/dw+VStuB4cj9lgD/AFwf01Pxf+FIP7R/ MKrJrw7N+0/9mQJ/0as8X/hj+8fzCnH99P8A1oX+y/8A7CvxUfZyXhHSNCtv3SBUXKKcjKMIGu2y keaqZR+UVJx8hfkJGHRkdj9rLaqz58GNmnIkdPUW2B2C9T1F/IVzle3VP7Xd/JHSH7lmvuVF82Xu M2TYskLepSTcf0WFqyt06wHH3XkD9sX6GUHtA/a1X+EkS5SNg0ZQWYG4O3Tw+dOCIeYYEC24Nb4h A1/vpG7j4/8Ads+ZJ28nJ/t3/IdyUSQ42OiaJGRGo+AXT+zVzBFsOEj9ZA39b1fpqDmEkbCLQoZJ Y2VkQeJPoP5Gq3FGIokiXoihR8gLV6FWOSz/ANKODtPHVeLH0UlFdDmLRSUUAtFJRQC0UlFALRSU tAFFFFAWqKKSoAooooAoopKAKWiihQopskkcSGSVgiL1ZiAB4dTQJYjI0QdTIgBZARuAPQkfGgHU 1jSk0xjQhT5XEfMw3ijYJMLPC56B11F/geh+Fc9B7kXC3Y+V/usyfjgmB0PmrDQg/CuqJqOSGGW3 dRXt03AG331zvxOzVqvbZYk605FVOtluq+hk+3MqLLGRLCGMXoVZCpVWI3X2362rIi9y8dhyMonC yL6HBRzYg6/q/Cuv0AsNB4CmiRGZlVgWSwYA3IJFxf7Ky+D01StDrOY7lXN6rN1lWjHkZ/CcxFyk crxOJFiIBYKV1I6eoCqudm40fOw4jPaeRo2RLHUX87W/VNbdNWRHBKMGsSpsb2I0I+ytvjbrWrtL Tme5lciVnZVhNRA+9ITSXpK6HM5/kZIF5NsJ3CyZLL208SHAUt/W3V0FRSrjKRPMEBWwEj2BFzYD cfialrFOPa7P/Jybvfcqr/FQc9xnI4c/LDFik3TRF96WYW2hlOpFutOfkMTJ5z6JJL5Cyi6Wb/qr M3qtbovnXQUhdFdUZgHe+xSdTbrYVj2Iqlu0tu0+ht80tvbrXbr9SDklBwJieiL3D/7P1/orM4fI weYwsvFik3oNu5gCpUtfaw3AagrcVugU4Ct245urTommu5ivJFHWNWmn2OSPJZHETdnkN2PKPSs4 UmGUeanUfMHpQnMQZ2aqY5bKnlZQwiUkAaDcxtYACutdEdSrqGU9QRcU1I44l2xIqL5KAB+SuX/H zCs9szB1/wCRj7VuiJM33Fm42HhJJkv20MoUGxOpVj+qD5U7jTFm8Mvba8U6yKGsRozMOhrRpK6+ 363edVtg5b/QqRo5k53guWxJs84qSfx9rB47MLFevUW0o4fkMTkeSJgk3tEGlfRgAT6P1h/SroHd EsXYLuIUXNrk6AfbS1ivDG1bp2OdDduadz2xuUamdz0kcGCMiVtsUDhnaxOhBQaC/iwpeDzYMzAW XHbfGrMu6xGoN+ht51oUlb2evfPSIMb/AEbI6zItYfAZuNk5E0cL7ngXbKLEWN7eIHlW3SPIkaF5 GCIurMxsAPiTS1JtW0/bP1FbxW1Y+6DI51ZcaRORRWeJV2ZGwXZQCWSQDyFzf/kqhJz38yMeLhEZ OQ/4FUEKP6ch8AK6empFFGSY0VC2rbQBc/G1Yvw7rNqzSt9y7m6822qTqm6/a+xRzliweGZWb+Hj om5yNSFK3Y2++sKP3JjNGcfEaSdmP91FGxYk+GqiutpaX4dzTVtuNuOwpy7U067s7s9zI46GbCws jPzQI5nQu0d7iOOMEqpI6nqTVbiMfiuYjkyniTKiUiNDInQj1NYOP6QrdeWJCFd1UkFgGIBIX8R1 8vGnKysoZSCpFwRqCDV9qs17UTx5k920W73az5GDFkYOBzacaloST/BhAIG1lvpYW/FepfrsUe4/ oy/+8NqEsena3dbW6Ctmins+P89+n0Hu+H8Nmv1M7muSTj4Y3kk7SyNt7ltLgXtfwvVvByPqsOLI FyJVDAkWuD0Nvj1qV0R12uoZT1Vhcflpa0qve7ThrQy7LaqxlPUWiiitmAooooAooooAooooAooo oAooooC1RRRUAUUUUAlLRRQBRRQTQGN7w/8A23nfur/bWsfi+XaDJ5LMyVMmRjY+PBNGDYtMjvBa /hua3310PN4L8lxeRgo4jaYAB21Aswbw+VZ+R7dWXJ5KVZe2vIrERYapLEdwf4+oA1yvW2+V2/c6 0tXZD7/sX+O5CXL78WREIMrFftzRq29dVDqytYaEN5Vm43uLIlKtPiiOKYT/AE8iybtzY5bcrLtF rhTar3G4U+MZ5sqRZcrLcSSsgKoNqhFVQSTYBaxuG43Jy8WKaWZOxCcsY8YUhg8skkbF2vqAL2sP Gq3f0rrn8+oSr6n5fl0J29yzrg4+U+PGjZY3wq8u0FVTe9yV0N9FHjercHM9/KRERVgOOmUzuxD7 HBIKJtIYLax18ajl4ef6PjlglQZXHIqK0ilo2GwRuCoIOvWnT8VkZGdjTTSxmDHRgVVCrsXTtuu7 dbYetrVV7nnp2+JHs8tf+hXbn80Y0GT9EBHmSpHiDuephIrspYbfT+Eff8KJOXlx3yAuJH9UJ8aC QK1t7zIh1fb+rusDToeHzkjxMeXISSDAmR4DtIcxosibXNyCfUOg8Kg5jCmhd8hJFDZediNFcEhS myMbhpfUXqPelOfp2KtjcY+vckk5nkJTixwxRxznKfGyY3ckBkQvZWCHQjW9qcvLsoMOHiIcmXKn hSMMEVuySXldgvU28utKOFy1SGVZozlrlNlysVPbJdTGVVQ1wAtra0HhcpLTY8yJlR5M+REzKWTb OTuRgCD0NPX4/Qejw+ox/cMzxxyYmMrh8V8thI+wqI2Cumitc+Fa+PMs8Ec6ghZUVwD1swvWVHwJ iRY45QVXCkxLsNS8rBy/yuKs8amfDK+LNtbFgihWBwCCWC7ZBr11F61V2n1dSWVY9PQyuUy86fG5 RJEQw4+RjpEFY7r9yFgNVA1v1vVyTn5YonSWGNMtMj6YKZbRXKd3cZGQWG34dadkcLkynORZUEOZ LFMt1O5WjMRIJvaxEdLkcHNJJNPFKiznJXKg3qWUWjERRxcXBF+lZi6ban8NlmjSTj8QWk5bHPED lmBWHtd4r1PT8PzvpWdkz8pJn8ZI+LHHlE5HbhMpK7TGpuzhLgi50tWtPg/Vca+FksCZYykjxjaL kdVXW1j0qCDjuQbIw8jNnjlfEMoJRCu5XRUF7lvVcXNWys4X+35zkzV1Uvz/ACwU391RLFiyiJQs 8STzK0gVlV37Voxb1kG58NBVg85kxZM+Pk4qxFMeXJhAkDMVi8JFA9O696jxeAysQYbwTRdyGEY0 /cQurIGLhk9QswuarTcJmYsc+VJPHKscGWrHYRI4lG/czbvxaAfIVmeTr+hqOPp+pYX3JJHjSy5m MIZFgjyIVEm5XSVu2t22jbZiL0sfuCSaOARxRmWWeTHYmQ9rdGL+iQIb7x+HQVXxODnzeO35c6l5 sWGLHMaWCKhEylgWO5t1r/KrWZxXI5uAmLLPAjM15mSIgAAgq0XruGFupqp8kTnTwDXHPx8SXjsv OyOQz45lQQY8gjj2sS34VbptHUNfr8KhHOTjNaJ8YDFXK+j74f1dxlVkum3oS1utWsTCnxs7MmLq 0GU4kC2O8MFVDre1vT5Vl4WDkZeflkyquJByJmaPad7SRpGV9V7bdR4eFV7lCzMsi2uXiIRInNSZ UMU0uGhhbKTHQs24iTumPeoK/qixB86mk5yRI8vKGODg4peNZS9meRDssF26KW0velThpV4/GxO4 u7HyhklrGxAmabb9xtTX4SdoszC76jByi8iLtPcjkc79G3WKhtelT1/Tw1L6Pr46DU5+SSGPtxRG Z8hsVj3T2d6rvG2UIb7xbbpWjnz5MEIfGhWZybHe4jRVsSXZiDoLVQy+L5LL436OWaAPI38VliIU LpZk9dw4IverPJ4M+XFAsMiqYZFkKygsjhQRZwCt7E7vmK0t0PXRRoR7ZWmrnUpD3DkSw40mLjKz ZEEs7K8m0L2SFYblVr/CqvO8vLmcTPHiwbo2xI8jIkZ7GMTaooFjuOlW8TgsiBIVeZH7MGRACFIv 3mDKep6WqHI9uZjYn0+PkRoJcWLFyt6lrmEWVksRa96w1yOr1yvDsaT401ph+Pc1c/P+ifGLqOxN J2pJCbbCVZlNvG5Fqzf+Jyv0xkhVO8kcsqmSzKk79uPYu31n9ZvKtLlcBOSwJcNjt7lir+IKkMD+ SoJuLmXkI8vEeONO2sM0ciF/Qh3KU1Fm1Irdt84eDFdkZ1Kzc/lCLMyVxQcbBleKR953HZIEYqu3 wT1fkrQ4/P8ArvqHVQIoZmhjcG+/YBub+tcVVkx047iuRbIIkjkbInYdPTKWbZ+W1T8Hh/Q8Ri4x FmWMFx/Tb1t+U0ru3JN9JZbbdraXWEY8vJyZebjZsmMoxRj5jY4ZtxlRQl967fTe3x61pYnKl5oo FhSGFcaPIe7EEIyk/wANAliqkWOoqrH7ey02RHIjbGx4ciDHXaQ4WcC283IO3pVgcNO8+EZZUMGH F29qqRIxMfaZd+78B69KzVX17tToVumnZPuRtz2YuJFmNhgRZUsaYq9y7usu7aWG30nQffTv5+yc hHgzRIr7o4prSXYSyqXGxdo3INLn40RcPnLBjYsuQkkOFNE+OdpD9uLcNrm5BNiBoKsfy6ePlZMy GSMQ5Gwzo6bn3RjaDG1xa4ter68a9J0+JPRnTrGvwM5vc0k+HmyYyRiSKA5GOd+70Bin8QBfSwtf b8etbmI07Y0bZAUSlQWCEsv2EhfzVlw8HkR8dk8aZozjvG8WMwQh1D3I7jbvVt6aVexIuQR1ORLG 0QiC9uNSP4gJ9W4km22lN0+qdBbbHpjUt0UUV0OYUUUUAUUUUAUUUUAUUUUAtFJRQFuiiioAoooo UKKKaTQgpNNJpC1NJoUCaaTRekvQAajiiigjEcKCNASQqiwuxLH7yaeaSqQDSUUUAUyWGKUKJUDh GDrcXsym6sPiKfRQBRSUtAFLRRQCgUoFAFOAoBCVVSzEKqi5J0AFEU0UyCSF1kQ9HQhgbfEVW5fF ky+Nnx4j/EZbqPMqQ237bWqrDy0ZixjjxKqTRTOydNrxBbrYfE10rx7qSsuWo7JKfrky7Q4ekGqT UciJIjRuAyOCrKehB0IrKk5nLCpJHAjoMWPLmuxBCtfcq6G9reNOk5eZcmS0StiQvEjybiHtMqlW 22toWq/8fk7L5r8dSe5Uvxy4qhIYnQAExoikdUGqAf0bdKkrHwsgRTCMord3MyhvPVdu9rj7qIuf MsE8oRCY0WVQjbrI7bT3LDQr1Iqv+vefSpSj6uEFyLq/xqbFMjhiiLmNAhlbe9hbcxAG4/Gwpncn +l7ioskxW6qrekk9LMR0rOHMziEkxI8y5C45EbXRiwuCrW+ysV4rWmEnDjU07pa9TWprSxq6ozAP JfYpIBawubDxtWcvLuM5MOVYw24RPte7bym/cqkA7PC9Ozv/ADXjf3pv+7Na9myaVsTW118E2Teo ld1X6lxsnHXfulRe3YSXYDaW/Du8r30pXnhRiryKrKpcgkAhB1b5DzrA5MBl5lT0L4o/sVH28tcj MOYbynj5lH7sZEYP+tbd9tda/wBarqnujTHnWtv1MPlacR+Ja/Q335DAjO18mJCQCAzqDYi4Op8a cMzEM3YE8fevbtbhuv8Au3vWUYomyOG3Ip3I264GtodL0/ji38yzAMfevfN8i6+j0DSx9X3Vl8NV VuXirtql/Lb+hVdzGNY+kmnFlY05IhlSUr+IIwa3ztT0dHUOjBlPRgbiuew0SLE4vJRQJmyXiZgN SjtLcHz6Vocej4fBgah4kkYX63uzU5OFVmLT6tiT82n+QryN6rpP5FqeXj5o5Yp5InjS3eRmWw10 366a+dTNJGrqjMFd77FJALWFzYeNqw8nHhj9sdxUAkeCMs9huJcq7XPzq5yDbeT45utjObf+yNT2 azhvXkX/AOdZLvfX/S//AJOC99VjBnQypuiG6RdwuoHiwvpSpNDISsbq5ADEKQTZvwnTzrIx4Yv+ HZJyoM0mPM7yWG4lwxa561J7ds+PLMf7xnVGHksaKqD7taW4aqt7Jv0W2fEiu26qPuUmkcnHAYmV AEYI5LDRj0U/HWkOZiCbsGePvXt29y7r/u3vXP5Urg50QiYo2ZGTKLbQbpodb1ewi383zQMfuL3V vNdfR6B4H1fdWn/XSq7N/wAd2q/0/uRcjbiOsfn+xpx5GPKzLFKkjIbOqsCQfjbpSQ5mJOxWCeOV gLkI6sbfYaweJs3LAbe2UbJO8/8AW3cDaP3etXPbZb6CK+P21Cm0919fqPl6vvpycCorOW429l90 /PQteR2aUaz9I/c2KKSivMdBaKSigFopKKAWikooBaL0lFALeikooC5RRRUAUUUhNAITTCaVjTCa FAmkpKQmqBb0hNITSUILSUUUAUUUUAUlLRQBRRS0AU4CkApwFAAFOooNAR5CzNEywOIpdNrsu4aG +ouOvSsv+SSqiGPIAnvM0rlLqe/bftUMLWtpWsTSVunLaiirS+C8jLqnqYTcfM2YMFJgirgxQzNt uWQM6tt10Jp6YT5HI5kQkCYySwGSLbctsjRlAa+guNa2O3H3DJtHcI2l7DdYa2v5UgjjVmdVCs9i 7AWJIFhc+OldP+RbP+2NFrKbf0J7a+v0KMfFlJo5DICEnmmK26iYMNvXw3UsGBl4+K+MmQrIoCwb o72UG+1/V6tNKv0Vh8t3q09NUujn9S7KlEccV4r+XrKQdmzu2+3pfp4W8qhj4mZW3PMhvPHkWVNo GxdpUeo6dLVp0UXNdTn7m28LVjZXGNMFRMOaLNknilCwzENLEVuSwXbdWvpfS9NzsOeebHnx5Fjk xy5G9SwO9dvgRVyiouS0q2JS26LSIz8C7VEeMmXLxE00eWJJl7mWYSWCkAGLbfS/jtqbL45sieWU OF7mK+Na17FzfdV6ite9fGdPDwS/RE2V7fj8MpfQHuYL7/8ABKykW/FdO39lJj4WVBlzSrKhgnkM jxlDu6W0bd8PKr1FT3bQ13W3TpM/mNq+s/oZmFxEsBh784ljxi7Qxqu0bnJJZjc3tu0q7BFKMcRZ LidyCHfaFBBJ/VHwqail+S13Nn9EvxqFVLQym4jJbBkwDkgwFdkIKepQGDDcb62taplwst8nGyMm ZHbGZyAiFbh02W1Y1foqvmu50zP8V/JQ/mNlfy69tDNTi548ebDScfSukiRIU9S9y/Vr6hb1LhYD YkrOr3R441dbfrxjbuHzFXaKj5btNN/drhZCpVR4aGbLxLOmQncA+onWcG3Tbt06/wBGpIsLKhzp p45U7M7hnjKEtooXRt36KvUU968NSmmo0Xh+w2V1M2LiWjeGQSjfDPJNe3VZb7k61JxeFlYUK48k ySQxghAqFWuTfU7jV6kpbmvZNNpp+C8f3CpVOULRSUtczQUUlFALRSUUAtFJRQC0UlFALRSUUBdo vSE00moBxNNJpC1MJoUUmmGlJppqkC9JeikoAootS2oBKKW1FqASiltSUAUUUtAFKKAKUUAoFOAp AKWgCkJoJppoAoopKAKKKKAKSiigCkoooApKWkqgKKWkoAopaKASilpKAKKWigEopaKASilpKAKW kooAopaSgCilpKAKKWigCiiigEopaKAKKKKgLJvTDeiioUQ3pKKKASmmiiqQKNKKKAWw86LDzooo BbDzo+2iigEpNKKKAKWiigAU4UUUA6kN6KKASkoooBKKKKAKSiigCkoooAo0oooBdKTSiigF0o0o ooA0o0oooA0o0oooA0o0oooA0o0oooA0pNKKKANKXSiigDSjSiigDSjSiigDSjSiigDSjSiigDTz osPOiigDTzooooD/2Q== --%OLATTACH1-- From oktdjlna@alchemy.net Sat Feb 26 15:41:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00060; Sat, 26 Feb 2005 15:41:26 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D58l5-0002Hd-U2; Sat, 26 Feb 2005 15:41:54 -0500 Received: from modemcable143.114-201-24.mc.videotron.ca ([24.201.114.143]) by mx2.foretec.com with smtp (Exim 4.24) id 1D58ke-00058j-AI; Sat, 26 Feb 2005 15:41:24 -0500 Received: from TKQBV-LM83 (80.38.160.162) by 80.38.160.162; Sat, 26 Feb 2005 12:40:21 -0800 From: "St. Daryl Osp." To: simple@ietf.org, simple-admin@ietf.org, simple-archive@ietf.org, simple-web-archive@ietf.org, sip@ietf.org, sip-admin@ietf.org, sipping@ietf.org, sipping-admin@ietf.org, sipping-bounces@ietf.org Subject: Absolutely No Doctors Appointments needed Date: Sat, 26 Feb 2005 12:40:21 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="%OLATTACH1" X-Priority: 3 X-Mailer: RGI Mail v3.2 Message-Id: X-Spam-Score: 30.8 (++++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 72be645574b2b4b84446d27f730bf563 This is a multi-part message in MIME format. --%OLATTACH1 Content-Type: multipart/alternative; boundary="%OLATTACH2" --%OLATTACH2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit %URL %PARAGRAPH --%OLATTACH2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 3D"" %PARAGRAPH --%OLATTACH2-- --%OLATTACH1 Content-Type: image/jpeg; name="%ATTNAME.jpg" Content-Transfer-Encoding: base64 Content-ID: <%RNDATTID@%MNAME> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAKAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBcSFBQUFBIXFxscHhwbFyQkJyckJDUzMzM1 Ozs7Ozs7Ozs7OwENCwsNDg0QDg4QFA4PDhQUEBEREBQdFBQVFBQdJRoXFxcXGiUgIx4eHiMgKCgl JSgoMjIwMjI7Ozs7Ozs7Ozs7/8AAEQgCJgHCAwEiAAIRAQMRAf/EALsAAAEFAQEAAAAAAAAAAAAA AAABAgMEBQYHAQEBAQEBAQAAAAAAAAAAAAAAAQIDBAUQAAIBAwMCBAMDCAYFCAcGBwECAwARBCES BTETQVEiBmFxFIGRMqGxwUJSciMVYpKyMzQH0YJzJBbhosJDU7MlNfHSg1RkdBfwk8O0JjZjo5Sk xHUnEQACAgEDAgQEBgEDBAMAAAAAARECITESA0FRYXEiE4GRoTLwscHRQgRSYnIU4aIzc5Ijk//a AAwDAQACEQMRAD8A6bKwos58eCaSSKJplDtC+x/UGRRf95hVjPhj4xGQMzxY8QIZzdiFXqx8TpUO QWETOgu8f8SMf00O9fyip/d6ibERYjrnhMeMjx7zqn5nrywttnGVB6Je5LoyHj+IOFw2NlPLLLPl Kkk4lbcFZ13EKPAVFx/Ew8pyWZlZM0yRYDRJGkTlULBe8+8WN/xCujz+0+JLAn4scKdvkPD8lZHB nt+38rK8c3ImcfLf2F/5sdadErJRhKfkZVm6t9W4+ZVwOKhzc7MzJZZlbECduJHtGboT6ktrUR42 LleTxsOaWaKIxyyEwPsYle2Bc6+daHDSJGvMSObIiozHyAjYmqHt7k8HO5+EYsolKQTFrAi1zFbq BWUq+hf5PPjk1L9T/wAV+gclhpPlxYBeSOKTKETNG219t26N9lTTe0fb8DmOXkM1XHUd4+P+pS5X /neP/wDPD87VH7h5GOHmHxzFMzWQbkjZl1UfrDSnpSbaT9UZGW0k2sTghzMLHzM3GwFlkXHlyNnc jba5UI7D1W+FO5zDPHwzwIzFUhJjkY+ogKdSR43FLjf+bccP/iP/AMKWtT3fCsnFzzpq0KOklvAM t9fvH30VU6WcZTLui9V0aM7J4bG4rFxxBJLL39zuZn3m9k0BsNKozY6ZQXHkkaGN3j7kiEhggdS9 iP6INbvPm2Pg/uN+ZKw2NS6Ss0ljBaNuqbeS9j+0fbmUZRBn5jmEAyWmOga9uqf0TVDk+N4nEwxD x2VNN3nAkaRyWUEqvpO1bVqe2fx8r/s4vzS1h5B9A/fT+2tW23amqpbpFZ3P1N7YNHlOJxuIeLGx 3kkQoWLStva5Y+NhUEXDY2JwGLySSSyT5nbMgkfcoursdotpVv3ryGJi58CTyBGaK4BBOm5vIVJM QfZ3FkdCIv8Au3qutd11/iseAVntpn7nkyON4dudypzkTNj8Vg+mdkO1pJLbiu7wCjrWl/w9xRxp J+Cmc9jWXHkZmBHmu/1A6fI0/EX6X2VERo+Y5kc+JMsjP/ZAFR+1pzHzKxX9M0Mgt/SUowP3Xoq1 W1NZspb65DdmrWT+1wl0wZmNxs3M8lFxqSNBBtabKlTRu2pChVPmxNXcrjPbeFA44uSQzoQrKzuy tbqfVp91aHDCPE9yZMBFg4kjT7GDqP6oNY2fith5kuO36jHb8VOqn7qm1Kswm5ansVNu+rSSTS7k /Fe2uLz8Gfkc/JyYtszqe3JtQKpAHp2nzpZ+L4HBgL8dlTZEzMAVlcsAuuouq1a4+Tt+0M59rPaZ /SgLMfWnQCsWCbvKWEckYBt/EQpc/DdR7Uq4UtTIrLtabPFognBq1xftvjc/Dn5HNysmErM6ntSl VAUgCw2nzqmK18CeLH9pZ00zbY0ncs2pt6k8qlEm3KmE3kXbSUOJaQ1vbsmNCcjBzDn4gvuWXaZF t4h0A3fEEVUweHj5rlXx55ZooMWAOew+wl5Hst9D4Iav+z8iWeDkc51ZMBlRccuLbtgkMjgHwO4D 7KbwE30mBzHLWtaZY1v4rAij+07VpVq9riE5bXkYdrLcplqEn5iZeOMbJkgBJCGwLdbdRemcZw0a 8Q3KLLK80zuZEd9yALI6DYttPvq/z8ezOD+EiA/aPT+irftxUfgYY36SNMtvO8slWtE72Xg4I7NU T8VJicbxEGfyGVkTSzKcNImjjR9qEt3L7ltr+GmRcDw84fI5DPyYpZZbKkUjKoDEKigbW8TWpwkT Q5vLxN1RIlP2CasrJPpj/wBvB/3qVmElVtJ6zPmalttS1oXm9qcHgzo75uZ3Es6o8xZT5XG3ppVb jeJgfHzOVaWYzLK8axl/4QAKj8Fq0+f/AMYn+zH9pqi4r/yHN/8AmJP7S1pqu5qEoTMy9qcvLRnY fBYvL5uW2VPkRLjpFtEEhQeruFiRY/s1OvB8Fhhp8bNyZpgpCJLIWUk/AqKscC22blW1NooTYanQ TVkYvIR5bMqRTJtG4mSNkHW3U1n0qtcKXJrLs8uFA/B4SHmZMrP5WaSPjcRzDDAjFA7Lbe7ldTqb C1T5GNx2KEi453eGxNpGLEG50u+taPHRCfhsrFjHrRzIqjqdx7n5W3Vjk0aSSwsqZ6hNtvOj06DZ HVEZ2NlUEk/AUcb7dxMzCXmfcMsix5HqxcRGZAsZ/ATs1LEa6VX5BDLiPCL3m2xadf4jBP010HuY qjY2Og2xxodqjoBoo/s0qlltTt6eLK25VU4nr5GNykHG8bAJcOZ5sYKznuNuZbfq3IB++nYPtjAG HHyXuWaTv5VmixkZlWNTqBZPVuA61WeAZU2LisLpPkwo4/ob1Z/yCtn3VKWz0j/VjjGnxYkn9FEl mzSxELpIcyqpvMtvqUuS4ccescuPKcjDm/uZG1YXF9rN4/A03h/b8Wdh5nICSX6qOR444938MhUR rbLdda0MI/Ve1MiNtTiyvY+VmEv5nqX2tkJjcPmTv+CPJYt8tkV60q1dl2anyI7WVXnKtHmc1FiP yfI4vFxsyCdt+Q6GzLDH6nsfAnQCrHuDjYONL4eO8hRYxZ3a76/0tK6LF42HhuTzOTkIb66aHGw1 HVY5Cu4f12J+QrI95f46X/ZrUdIo2/un6FrfdfH2x9SbL9n+2cNlXJzcuNnF1BlJuPsQ1mZuPgY0 wh4+VpsdVFnc3YnxuSBWr73yO1lYw7Usl421jQuBr47awxewJBUkA7WFiL66g0vtTaSSgcctKzs3 PQjmlWGJ5X/CgLH7K0sH2vxyYUXI+5ZpO/lWaLHRmVY1IuBZPVuA61RWAZWTi4rC6T5EKOP6G8M3 5BW37ulL8ikd/THGNPixJP6KlUobamNE+5bNtqqcTltFTlOGHHLHNjynIwpv7mRtWFxfazePwNM4 f25xvKY+bnZ8+REIJu3/AApNqhFiie9tp8WNaWCfqvaM8batiyPtPlZhL+Z7VHwTbfbnNNYtaZzZ Rcn/AHeDoBWttZWMNTBl2ttanKttkoZmBw2FGi8ZkS5BdiZO6xYjQWtdVqbB9q8G3D4nIZ+XlRNk orMRKdu5husAFPlWXDIZU39t4xcqO4pQkix03fOtvOl7Xsvim2PJftC0alz/AHb+ArK2uW0oS06G rStqVnl6lDMx8DGlEOBK00CqLO5uxPjckCq9C3ZVYqybgCFYFTY+YNOC1Da07iAU4ClApbUAlhRS 2ooDaJq3DiNnYnDFR6MHIPd89sCSxqftdVqma0+Bl2R5cbdEcSg+G1lA/OhNb443Q+v6ZPPfSUJD IZeXzoev1ENl+HZJT/8AFqqIWwvb/G4TArIsSGQHrvCjff8A1mNMwpWHK40n7bujn4OrH+2FqfnJ d2WE8I1A+060maN9Za+eRHqS8J+WBnt5tknKORuC9s2PjaM1ZweXSbkY8RcZI+5HI/cXqNhTTp47 qq8ErBeVYghWCbSRobRm9qg4dWPOQMASqwzAtbQEmK1/uq1s0qJdf3Fkm7vt+wzJ/wDO8f8A+eH5 2rV5LmMnEymhjVCqgEFgb6i/gwrLnVm5yHaC23NubC9gC2tP53j/AHFPyUkmBjwyY5C7Xkk2tcKL 6fOonZVttmd3QrVd1d0fb1KuO5fmOPY9WyST9sctbMoTKzuS4qU2TLiG34N21Un52t91Y+NBPHzO BHIv8SOf+KF1A/hSX18rmrPJ5BxeebIF/wCEyMQOpXYoYD5qSKlXFc/5Z+RbKbY/xx8yf3Kpjiwk PVVcG3wCVgk1v+6yCMUjUHuf9CueJqcv3v4GuL7F8TX9sfi5X/ZxfmlrCnPpX99P7a1u+11a3KsQ dpjjAPgbCW9YUgZtqqCSXSwGp/EKW+yvx/Mtfuv8PyOv5vl1wMiOM4yT7k3bmPTUi3Q1S5jL+t9t 4WXsEXfaN+2NQt0c28Kh93/42H/Zf9I03LVl9n8WrAqwEQIOh/u3rpazm66Qc61SXG+rY+YX9nYQ XpFsQ/NNyH8oqh7bu3uLGUfqxTOfkAi/nar/ABP/AIhweTxSMoyEu8CtoDc7/wC1e/zqP27xmdxD 5nM8yi47CPsY8AdXO2+9juXS7sBasxLo+kKX5Gpit69ZcLzKfKZDR81PNEbPHNdT/SQ/6RWl7gSP P4/H5eAdRskHkCbf81risEY/LcjlSnCiWeTa00iM2wsSwFlY6X9XjW1Fj5nGe1JYOT2rlZMpZIVI bYCykLcXBsFvUrL3YcOXPiW0J0h+pNKPAl9v5UmJ7bycmMAvHPIQGuRqyjwIrO5HmsrkURJ1jUIb jYCOvzY1d4jGzJ/amXBioGyJJn7Sudqn1KevyrKbh+cxImm5CGKOIWAMb7jc/Clt22qUxtz2Fdu6 0xu3YIxXQe3pxje38mcoJAmRIdh6HVRXPitvi1Zfa+ZuBF5nIv4jcutTj1f+1l5Vhf7kR53OZWZG Y2tFD1ZV8beZpkS5EPsvFEWLNlyZzmWSOFdzbZmebcfhawrLze6cOZYVLyuhVFUXJZvSOnzrqeSy 5uKhxMPEYKI4gpuAdFAVevyq1c7nZvSPmZso2qqWs/Ih5ITScXx+ROjJMY1EysLMHZASGHmCDTMG Rova+PKn4o5ndR4ErPIbGpjPPn8BJLkeqaKVrta1wG9PTyRqgx1ZPakIYFT3HNjodZZCK11bXWkm eiT6Xg148ePuZXIRG6ZsEZA/cEmv2q4rlcg+mL/bwf8AepXQ8LkGTjJoT1g3AfusCw/LcVzsoZzE qAse/CbDU6SoTU5GmqtdZHGmnZPobXuA/wC+J/sh/aaoeKP/AOn80/8AxEn9pak9xG2an+yH9pqj 4xWX27mFgRedyLi1wWXWr/O3kx/Cvmhfbblcnk3HVY4SPsEtMy+ZycqAwyKgVrElQb6G/ixp3txJ Wfkyi3LxxLGToC1pdL/bWanFe5IyZMzHgjx0Us7JJuYWHgKk22Viesx5liu+0x0gt8XmjEzFdjaN /RJ8AfH7DRzmJ9LmsVFo5fWn29R99Zbcd7jzYH+ixY5YpWaJZWkCFB03Mrfi6/q/dW37icL9LjM/ clhj/iP5k7R/0b1FOxyniGviXG9Q9ZT+Biva8ZPRJYnPyR1Y/mrb90g/VQnwMf6TWGwDKVPQix+2 t3l4c3leMxs3jo1ycmMbZYS4jvceqzNoCCPHwpXNbLyZbYtVvTKMbEsOQwmPRciL/nNs/wClV/3O COTJ80Uj8orP/l/K4MEU3JbI8iaRnjhQhu2qbNt2GhN9a1vcOLyHKY2Pn8PEmTIybHjLhCviDdrA 7STcXok9tlDnDjqG1uracOVPQj4Nre2eSc9GmlA+xUj/ADik4b/9tcn/ALd/7EVLkw/yf27jcOzh 8l/XkEebMZHP9c2FHDqy+2uSuCN0zkX8Rsi1rS1S7VyZ6N97qCq/JvlScPim4GPkQhyfEhwq/ctJ 7y/x0v8As1qpiKzchhbQTbJhJtroHFzV33grNnSKoLMY1sBqTWW26Oe6NwldJdmbfPc1lcbNEkCR sJFLHeCeht4MK5XMyZMzJfJlADyEEhbgaC2lya6D3VxnM5uRA3GwxSoiEOZH2EG/hXPz4WbhlYs1 VScruZUO4C5Ntfsq8jtL1j6GeLbCiN31F4+y8nhOei5Ef3s2wf2q0fdSkcqSfGNSPyispSVZXXRl IZT5EG4Nb3uHEz+Vx8fkOHiTJkZNjxFwhXxBu1gdpJuL1F9tl5M1bF6t6Q0RcEbe1+Rc9GmmA/qp H+cVJ7XnfG4flJ0ALxZDMobpcY8HW1qbkQfyf29jcOzh8l/XkEebMZHP9Y2FLwKMvBcvcEBpnKk+ I+ngFx9orSw6rqq/Uw81b6Wt9ChyXK5PJ9vvqi9rdt2Aj8Vr33MfKtjE5Cfj/avGzQqrM0caEOCR YoT4EeVc8FralRl9pcYrAqwEYIOhHoapVubPrBq6XpUYkzM3KlzchsiUKrsACFuBoLeJNQ7afjcZ zHI5ZjwTFFBCgeSSa53MxICDb8utPj4nmszkJMbEMMUWMP40ktzufcy7F2/u9azl5huTU1WJSgi2 0oWpU4nmszkHx8QwxRYwvNJLc7n3Muxdv7vWlkiaKR4m/EjFWt5g2qQ+wlaSRbaKfaigLQY+ZqSP ImjVlRyqyCzgeI/+xqMUV6oR5JYLJIjh0YhlNwR502aaWVy8jFmbqb0GmNUhdiyxBk5EasqSuit+ JVYgH52qJcjIibdFK6N0urEG32UrVE1IKjN5zOzYcZ54ciWOYeoSK7Br+e4G9cJL7q9zhyBzGcNf /eZv/XrtPcH+Ak+VebS/3jfOt1SMXL3/ABF7g7nd/meZ3b37nfk3X+e69I/P87K5eXkcp3PVmnkJ Ph1LVn0orULsZl9zRk9w8/KFWXksuQILIGnkIA+F20qM8zzH/v2T/wDev/61VKSpC7IsvuzRh9w8 /EGWLksuNX/EFnkAPzs1NHMcuGuM7IBGoIlfr/WqktOGtzSF2JL7svS89zuQ4afkcqVgLAvPIxt9 rU9+f514lhfkcpokttjM8hUW0FgWtWcguaf40hditvuWV5vmYZRJFn5MbrqGWZwR/wA6pcz3R7jz ipyuSyZNv4R3GAH2KQKzWNzekqwuxJfcv43uDncWUS4/IZMbjxEr/lF9afl+4ufzJO7k8jkyP0F5 WAA+ABAFZ1qWkLsJfc0IvcfuKFNkPKZkaddqZEqj7g9LL7j9xTJsm5TMkTrtfIlYfcXrPtRakISW /wCccv8A++5H/wB6/wD61SL7g58RGEclliI9YxPJt/q7rVRtS2pC7Ibn3ZaHNcypDLn5II1BE0lw f61Pl9wc9M26XksuRgLAtPIxt5atVK1Jam1dkJfcvL7h9wLGYk5PMWNvxIJ5Apv5jdatX257g5t8 +KDI5DIkwo7ySxSSs6bV+DlvE1zlq0uFQPK8JJDToVUqAT6SslgCR+xWbJQ8Fq3uR7XjgRB3U7A2 hC6A/MC1Qv2ozvCqCDdbADWq3HyscCAsxJ7a/jPq1A61XzMopfcen61eK1oO6q2xnI5kjlnd2ZgL Akk2+FY7Z+esJiGTKIz1QO20/ZepJskS3Cm4NQMl6wk25PTRJLKEi5HkobiHKmjDddkjLf7jTn5b lnQo+ZkMp0IMrkEf1qhKEUhFdMlaXZEkPM8rigrBlyordVDG35arNm5jsXeeRmbUsXYkn76V47eF VZCFPqYCjkqjWC1HnTK1nlYqfEsdK1eO5bKxpCsc7pu6kE2Ncu+TGDYMKmxs0aLc3H4akEtVNaHU ZMuTLKZJpXlD6bmYkj5eVQY/I5/HTkRzyLG1gwDGx+Nqjws1ZFCH8Q8KnngWRDbUeHwrLbTmTnHR kPJS5Kyrm9x5Uf8AHck1oQZc0mJsikYRNqUUkKfmvSqGO49WLPqraC9OwVbGkbHY6A+n4ipLI1iO xYErRTRyISpB0YaEGtAZCTvuyP4r6DuNq33mqGRHoR9opVfaw+NqqbMs20my21jyJWX4u1/z0Osc rb8gd1hpuf1G3lc1Xx5dtm++rLSKLSWBU11mTnlDXgxY4jK0KAH8I2j/AEUmBlzRISiCBHP6ug+e lT7sWUfiIPx6UkkIB8hbQ9VrVURvuVpxFO7OF3St1Zxe/wBpqMSPBG0RcrG/WJDYHzuKnZdtwPxD oT0+yq9iTZj99bgzIyRVZAVRVv4ACoZJchoxFJI7Rr+FCx2i2mg6VLttfyB0o2g9daqSLJDDPkY7 FoJGjYixKm2lLFkZMDF4ZWR20Yg6m/nTyov0pNlWBIyHIyoHZ4pXRmFmIJub1H62NyxJOpN6m2UB KQJItp8zRU+yim1dhu8SUUUCiqZGmmNTzTGoCJqiepmqFqFRj+4P8BJ8q8zf8R+deme4f/L5P3a8 zbrW6mbCU4U2nCqZCgUUCgHA2FJSjWnLG7sFRSzHQKBcn5UAqaCkY3rosb2J7kmxu+uNtBFwrGzH 7KxM3CysLIOPlRmGVeqsLfaKSpDKwFOAre4T2XzXMxiaCMRQHpJJcA/LzpnOe0uX4MB8uMNCdBMh uuvnUkQzFtSgUtvv8R40WrRMiUU61IRagFFAoFFAKaSlooBtiR0q9w3cGdGVXdYg2IBHUeBvVZU3 WBIXXqav8dl4mD3H7b5EjAKQGMRtuUmzIbjpWbaQarrJ6fx/MY2XEIEUxullZSQbkKNbKbCoOSgM 4ADWjt+qeprjeN9yZsmWsOLCIcZB/E2XOltp7krXbTzvr+bqcPPibAuLdopuFtxLf0hu8zXj5ONn p47dUZcvHdtrxz7T4KaElnjIWX1D9oVjcgeRzs58PHch0Yg2baiqNL3GtY+XJncZktEcqR2jNmKs xAPl661XicanS3NGqx3O79LruFNCgVgcDzs2ROMXI2uXB2SKLEta9iK3DJtYgms2Tq8mq2VlNRk6 ysLKOtQLxSMbzNqatNlAaA61zvKctmyTGLEJG3qfGiTZXZJG0ONwo/wi5+NI2Gq/hArmJP59DEs8 mQyKxsATrf5UYvuTPhNpCsyg2YHRv010fEzmuesw8HTpE6kEekjUGtPEytw2sfV+esXD5mHJTcq6 +KnwNXELON1rXrlasHRxZYyac0KyEMujCkO59rEWkj6/EVXgzAf4ch18DVpWVyAeo6GuUMw00Wix aHzNqrTMAiPfpqanhJ2EH4ioJBeIKfiKsmVqXcLIDKCNQavwuCGib7KwcKXYCvivhWmjnSQfq9DW lpJLVclvHlxy7IL9wfiW9WBICNoN1PVT4VRMQGQcgaBwL/OpVLXF/mDXarwcrakzLc2H2VEygnpU 49QB60jgdR+t1rojDK5UdKZtqfbSba0Qh20bal20baCSHbQFqXbQFoWRmyipdtFBJAKKBRQCGo2p 5pjUBG1Qt1qVqjahUY3uIH+Wy/umvMyNa9K9zsU4yU/CvNj1rVTNxLUopKWtmRaKPn99a+D7V53O iE8GI5iPRzpcVG0hqdP7L9j4edjLyHKglZNYo72Fjpc10mH7N4fjuaTIxUG3ZcITuUMPHWqvNtyP H+2IG49Ss8Gz0AXOhFxasLj/AHXzPGcqs/PxOkU6gKStgAD1rnLZo7Ucry7802FHjrFhxqCJJPxO T12/AVW9x+2cfmMnCkkWzROO5b9ZddD9tOwud4/nsknDY3gANwCLk/OtqNmvGG1egMv3Jk8pxHEr /Jok3ptVVI8OnoUWpBBlcz7aMfKx9rInTa6kdCdAadz/ACeHxM2Nm8hKdrPtVPAfG3wtWF7k97jk Ej4325ebImIJdQbADWoDZwPY3t/AwljmgWVnADySasSdK8495cBHwfK9mD/DzDfECb281rtODzPd nJcrHjcrF9Pj4oDvYW3n9X1X1pvu72pyvuDk43xysePAm3e/ixNzYVpYZGjy80vWt7nfZfMcNGZp lEuOOsketvmKwPH4eFblGYCltS0hqgUUUlPRWdgiKSx6Aan7qmmWxDEF7W++rGMMdCGmUyMNVS9l NtfUbXPTppWzxvsX3HnqJFx/p4z0eY7b/Z1rbi/yqznF582ND5ICw/OKxa9dGzapbsclFLlzR9xT 2ceG9whCLvP2gk28ya6X260marRMy+prjVZNsaa7bqbfbV1v8rsyOMRrmq6A7igBXcbEdQxrRbhs riuO+lw8Yq0uk8qeravkOn5q5cl6tYOtatEXNYc8JM2JGjX0cEa+ZsR865TNweQy3eZ/4Zk/EAAe n71eiZaqyEHTzB61z+TEFJsdPCuau66Hata31RyXD8JNHyuOwYja9z8a2uQn7eSUHh/prR4vFH1Z nYaRqT9vT9NYnIkyZsjKdLmlrO2putVVwitl5Ds1laxqh9PmNJuVx1uPnVuWJi16sY6lbGqnCDrL IZJuQbE7EuKsljcOT+i1ZjcZmTkbcdYVvqVvrXXwSDaNwvT3ZLWAsKq5bRgxbhrMsxsDGlxwCw1H XStJZ3I1P2U2RwDYVGASa5tt6nWtUtCa9+lWIZnQjXTxvVdFNTxpestGsdTSxptxtfQ1MV3ECs+F tkgt08q0gNyaGx86zBysoclAQTQ5ul+1KrAMOl7VZ47IkMq31iaMC3kVJU/mqzCyjRtbdac2C/cE yMBAFuVHncn9NaSww7rqaEQ3w38j0pT+EHypMW4jANTMARY6Gu1dEea2o6E2kXyp8g6jyNNsUAJ6 04m+vnXSphke2k20+1LatEI9tBFSWpCKpCPbQFp9qULrQDdtFSbaKAoWpKfaktUKMNRtUpFMYUKQ mo2GtSmmEC9CnP8Au024mT5V5xXpPu9R/KZL+VebeNaqZsLRS+FIBWjBq+2MKLO5vGgmF4y25gfG 3hXqvuLlp+D49cjFhR4owA6nTTppXnPsnhc7kOTXIx37UeMbvJ8bfhrt/emBn5HDu0U9xD62TqHC 9VrnZ5N10NJ+exYeLj5LJjIgcBttrnX4fOsP3Xi5fNycfJHjhcMSguD+OzfoqLiOcTnoocGTDdMV Aole3oJX9UGuh5XncHgVi+sU9hzZSBcAgXHn5VJclhFnB4qDGyEkhjWNVQBrC17dBWJle8cdfdce ArDsIpR3HTuG2n3XrK5z/MTIzovo+Ehcd/0iYjU3/ZFcaeK5eSSVhjyF4LtIbWIvqTeqkZk9gzuE xuVyRlZKiaNIyI1OoBPU1yvtv2xyGFy+TykMQXGikkSKI9Su7rrVDgP8xcrAhTHz4mlRRYSDQkD4 H/TXfe3+dg53HaeBGjguVO4WufGjkshwXOxcuZjFEYlx2Mb7rD1LoR8qxM73Py+d7hPBcQoxxGbS zutzYddo086ZzvuTjvbfIf7rAWEwYyhBZd3xqj7Vx+T5znZPce8Y0f4Qlr3Xy8KiB2PIY2zhMiPP kEo7Tb5CB4LevCW6kDp/6a9q914HJcpw82PhTqGI9agfiA6r4WvXi7xPHI0cg2yISrg+Y61qhLCC 1J407aPtrR4Lgc7m81cXFWwuO5KeiDxv8a23GWRKdA4LgM/nMwY2Glwp/iyn8KDzY1617d9m8Twk QZIxPlH8eQ4BN/6N72q7wnCYPC4KYeIlgNXc/iZvEtV9pAB8fE+dcLXnyOqrA/T7fPxoJqq2SB40 wZJJrG5aGoZbNMNr6/bUHf8APr5UGe46G1TDLoY2fdZXQ+Z/KSaypYdxrc5eIgrL+0NfnWHK5BtW Xg7UyiZI1iwpnXwHWuLnyAs7E9Sa7Lk5liwxjxn8Qux89K4+XCmlkJVdKGqLqETrIbEdasiHaOlV HxJ4QLCxrSxS0kYDD1DrSTcCIzIunSjuO3SpjF4dKRYbdNaFwR9onUipFjt4VKsZp6pSBIxEvU6g AUKth0pRqQKyyNkuPHuJbwq2qNceRFrUkMQWK3nU6W7gA6AVDlawuNjF23M2inoKuZBCxiNf1uo+ FJCygaixH5aVI2kcuRoeg+FdYUYODs28k2OlkvT3BJA8z+SnoNo29BT9oJua6JYhGBFNiL9B0pdD cjpSn9FRY9yG+dVKGZJbaUWp1qLVsg21Fqdai1AMtS2p1qAKAS1FPsKKAzyKS1PIpLUKRkUwipSK YagIWFRnrU5qMrehTlPfLMvG7QdCQDXn9ta7/wB+enAX4sK4LStrQzbUTwoFGtH56pk9H9hsYPb0 8kWsl3OnW46VXxOX5/kuCkx4cYlmvHJMxFtdGNvhWf7B52HCyWwMprRTn0E9L16PgYGJEH+n29mU liotYFq5tZOkmf7c47J4vjosYKkoA/EBbr1vVT3lhJy0+DxjXXe5dyoBsoFvH51vPLg8TC8084SM C9idNKx+Ell5bNl5UODjSWXHQ9Qq+P21GOpocV7fwsHFjx9gftaqx1rSXAgYyekHuaNp4UDculWY AwW/hQhzPun2bg8hhKIwIDACQ6gAmwOhqD/LuULwRx0H8aFmVhaxvfqR8a6+UK6EEbr+FcDPnz+3 PdLS5W2PBzyCgT9UrpcimQbfuTiMjmeNkxkijidte44vaxv5Vj+1eaPDcVPhZONK7YLMryRKWVtd LGunmil5RFfDze1E34iliSp8jfSrLcakHHHCw1ALgi5826k/GhTkvYfKZPJclyc4LfSO94la+l71 xPu4RJ7kzhF+DuflsL/lr0aWTh/ZHBsisDMQbL+s7mvNeM4rkfcnKskQJeZy88ngoY61pOMkanCG 8HwmbzWauLip1I7j+Cj417LwXB4fDYa4+Og3EDuP4sw8TTeB4HC4TCXFxl1t/EkP4mYdSTWizgVy vefI6VrArsAKqTS2p0klU5W61ztY2qjJJjrUQyGB/FY0yQka1WeU6+FcXY6Kpqx5pkAEm028accz HRS172+e0fPSuelzREpZmIAGvhXPPyUnK8j9M04jxALOzEbQSfj42rpxt2Zm9Est/A6/J5QZMTyR lWx4GCyy3sL+O0eNr1m5CWbX5EfGuTyw82e3H8fkvJh/9XY2UkgB2sPnXXdphBCGJZgiqxPmBa9X kXia48Z6BFA2RH6huK6A/CoJY2T0xBRbqfEVpRyw48JeRgqL1NYeTmB8h5InAi10PU1Fk6UlvwIk yHjZ1zmEik+g7QD+Sq0MoWclNIydKhnyWdvWungbVJAgexBvT4G2aYCuLikCU2EMotU4/LQyMAtS 04gUh0FWQIelOgUFxTRrVrGj8T0FRkbLBIVQPE1Nix73qqTuc+V9K0MBRu/MaVU2SON8KScRgMI7 a9TVjYFAIBA+FDgCQOeh0NSMtl8xXXbk4uwxXudfGpfEeXnUSi1yNfhUygDT7a3UyxH/AAH5GkhW y/G//LTwt1K3pUGlvjV6kFotTrUVSDbUWp1FANtRanUUAWop1FAZ9qS1SWptqpSMimFamIppoCAr TSDUpppFQHC/5gynbDF5sfyVxFdh/mFKDPBGOo3E1x1dFoZeo4UvypBS+FCHW+xvakfKynOzbjEi PoTpuI8/gK9LwJeOO6LEsY4PSzD8It5VyCzPxfsjuYp2uYgQR1u+hNZ3BcrzHCcfAM7GK8dI15Mj qwDeLD41zbNwdT7g4TB9xY7qpYSRfhlFwLj89S+0uOw+Oxfo4iWmQnug6+o1exuRXJx0bCgJia3r Olx51AmYcTl0xdoU5QZy/wC4QCPy1Cm+kQ3a9aRiEJUHSlR1IuDcDxqJ7Fr0IOJshPhXC+4vbUnu LnIRj5BMKAic9QlyNB8TXT81y8fFYL5Tjci6FR11Nh+Wn8HjLjYBnijtJkEyOPEltaBFXjeM4PgF TEWUo7dA7k3/AEVqZM2OgCvIY0fQNfT76yee5Ph8aFhykYikYHtlhckj9n41iZ/JchyPtoQJgy96 eyRMR+HXRr+FRliSt7p9ichm5iZWJlNkCRrMsrX2A+KnyrsPb/A4fB4C4uOPV/1snizUnA4WVg8X Bj5cpmmRRvY+dqvtJasOxutYHu9qgeQUySWoHlrDsbSHu96ruaHl+NQtKPOubZtJiSC9UplOvjVw tcVh85yc2O8eNir3Mib8PjbwH31FTe4Rqdqkxea5B8gvh4atI97My30C6+FZ3IZXGNxkHH4URbJJ V8jII6tY+ka+F6uHI5HgJZ8Yxp9ZkoGaQ6sm691+ZqPhOKlmbuMvVr+dvOvQ3XiroYqnyWl6LV9j Q9v8aIT3tt3YDcx63rqosYyQmw1GoqPBwtiqoHStzHxwiaCxrhWrs22bvdKEtDi+YXMZSmOglb/s ybA2rCOdlYTbeSxDjszdUFxtPjeu75PEVJGK6LIPuNcxyozchBjTWZI/wG2lq6UhYZ147OyhODOH Mcb233s19doIqg3uGGMgpCXPiBpark/Eid7hdt9AANBRH7ZLEGU2UdfM1tuvUtk1/Il4jnp82cxt AEiH699b/dW58R0qjDhQ46BIVso8ato2luprk4nBl/MkpCtKCKNetCBGhLWqdpAvoTQDrUPc2iw8 aj7mtRsNSWkb1CtTjrFreIrGie7XrX4g7pPsNON+pHLlXpNYKDofKksVO3wp6C5JoIF/n4V6jyjA pBPlTlHqHypwBOpoTqaAVR1NOApVGlKKpBKKW1FAJRS0UAlApTQOtCC0UtFAUaQ0tFWCjTTCKeSB UbMvnQo0imEUpdP2hTHkQKfUPvpqMnmXvp93L2v0QVzlq6L3LiZebzkogjZwAAD4Vi5GDk40hjlQ hgL9K0iNPsQUooANAFUznsei+zea4/P45eKziN6DbtbxArS915uM2CvBceFkysgBEX9lf2q5j/Li LHk5SUygFwo238vGutzuGycj3Fi5ONGIooQRLKfEG3pFcmdFoWvamFyWNhpDmyqTENqqvio6XrK9 3+3ec5LMTNwZViGOto1BIJJ6nTztXRzd/Fy/qGXdEqWa3W9Z3Ee4v5tnZgjNosdtihtL/ZpQGVje +5OPmTA5fGbEaJPU51DEC3p+dOzf8wMY8eJML+LkyOFjg/W6+VWfc/D4/NcPJMqgZEAJjcdbrfQG q/sX2pjYGGOX5BA2S43KCL7B/RvVIZObxnvbm3XKlg7eKzK30xaxsDfUV6BjyZY45EitFMqi4caX Aqj7l9wPxPFrnQrdd6jb/RY2/wCWq2bzWXn8Ms3GQMZpdtiBbS43HWowjh/dmZz+ZnJJnQXxsSTa jRrdCd3n8a9RwJBJgQkx9u6g7SOn2UkMEMuHFHJGG0uQw8fj9tT9B+msWsbrUVmqF3odtagke165 NnRISSSwqtJMBTZpbVnZWYFvrXNs6Vq3gsy5QGt6pyZ67goNyxsB86yMvkG1ANRcbkhp3yXJKQ6I Ot3/AOSspOzhHbYqqbG1yvJjDxyqkd4+m3kTpWFlwS42LFyn1Y+vkIMcI9RVQOpqxjzceJJ5+SRp ZyN0MJB8f1m+FVeJ4CbmJbRELiI1pJNbsfIXPSvXWq41PU8r9b7Ih4zj8rl83uys8iXuZH6n43rt sDio8aMKorQw+Nx8SFYolACiwt8Ks7F8K4ubOWbd4xXBDBDtq0WCi1IoAFV8iQBTWtEY1IcsrKpU 1iZmPoSDYgdK0BNdjeq+cpILKLqdKxOTrWamBI86H0m1qb9VKdGuTWgYlPhULYik3ANIOsoqiR2N WIw1PGMFNKzxpoKEeXgUaanSmtJfRaiZy3ypN5A+FSSqo5mtUPd1pHkquZdTWWaSLsUwv1rc4aZE fc5sCCK5VJCWFbnHP6CT08qtXDkxy0lHWJKtgRrTlUk3NZOFyBiuri6Hw8q14ZI5Yw8eo8a9VLqx 4b0dR1tKAv3U+x+ygDwrZiQtRalFFqEEpbUWooBLUWpaKASgCilFAOooooCmImNSLjr1NTBacBXN 2Z12pFaXj8eUeoG/wNq5DMjniynjfdGL2TcTa1d0BWT7mUDjmZYw7aAsRqB50TcmsHLeoNZ3v16G 9NMrp/DcEE9fO1SSmNMBCqHdf8dVmzZWJZiGJFr+NdFkF2KOOQk48Wn6zHreq0cUMmZJBMFJtpuF QrysmCjMpJB6nrY1Um5ETZBmHpkAG743oq2Eo0IuH4/KDqMdUvpvAsDWXmey8MPsRmic63BuDW5h 5zERLN6Y7WAGmtOaaXHybuN6ObKTqLGs7rJ5K6JnHQcbyvC5gzMBhKY9CPMXrrfbvu7keTzvpJYB AIl3O3iT91N5SA48ystgsnVfjVTEy/ocxJTGLuLMf6NalNSYdILPuDnfciZk4wsRpMNLIsnxbS9R Y3svlMLCObDntFky+qYADab6sNemldRLzHFR4Kyll/iWAHjc/Cs73PyGcMOAYm1sdmAnW/q2fCoQ 1caGJePTHj9YKC7dfnUspRcZcVjsRl236aUkU2Pj8Z3SO1GqXJbSwA8aqtn4+RxgnsZUKkjbqT+7 U+JMnPe4Pb3NcnxjJHlLJDAd0cVrbgvQbt1bvtKTNk4mEZMJg2Ls2sACdul7VF7XfkZoZHyY+3jM x7CP+Ir8RXRKoUWFYduiN7VItrDQVGxpzNaq8kgHjWLM0kxsj2vVKeYC9LPOBfWsrMzAAda5tnWt ZYuXlbQdawM3MuTY0Zufa5vWBk8iryiIOFLnbu8BfzqKjs8Ho9NFLLDyyZU640Let+p8h51v4eBN xCY8skPciJLIshtc21Y9dLms3hsaFBlGeZUnQKMeNBq39Ik+FTPlZvMciMCNi/RZX+HkvkK9Faqi PPa75XjFVqW8eKf3PyMi6rDcd+VBtBA02LXc4OBjYGOuPjIEjQWFN4zjsfj8RIIEChQAbDqfM1ZJ NYb3amH2WgE0wsBQxtUEj2qNkSJJJgBVHIlLA0sknWoXJK1G8G6oqAtvveruODIuwi6nreooo9z2 q3NJHi4zyHSwvUSjJuzlwtTn+cy4sOYJjKoPiDrWfDyc0nWwPwFZ/IZpnyXkY9TpTMaUbwKzlnpV Eqruaxlkc6k/Km6g61ahxt6bradb1TmkVHK9bVDKaeEh4NRSTW0qJ5vKq7yXPWqIJWkvc1VeXU2p JJiAdbVWUySvsjG5m8KsCS7il3lVRcknQCuswII4YrufVbU+Arn+Ox+ybdX/AOsfy+AqlyPuKLIm GJuePjkJXIlj0ZyAfSp+NWld1sHPltCy/gb2XzsYWaXFCyJjna0rMFTcP1V8zV/27zU+QUnETCB9 Ga1h91cjwvDJymUZ2gaDj1O6KG5sb28/Pqa7jHiSKNY41CIugUeVasq0eNTim7LOh0Ec0MhsjA/A 9aktWGrMOmnlar2Fms7CGU6n8LH81da8qepxvxNZReopbUWrochKSlpKECiikoApRSUooB1FFFAK BTqbTq5HYBSSIkqNG67lYWINKKNPOgOM9x8eOOIWCT+DOSe2dbW8qwC5uOlq7H3jjGTDTJVbmEkt +6a42LMOPMsqqrkD8J6a10o8FIchgUZW6W6Vly5qhwpHRQFYdauzzBizHzvYVhvMqylT5m3311Od uh2ePyWHJBDI6sqxLZrj9atPIzIJMVCGGliBb4+FclBkTdtYO5vRrFlPlUsfJk5Lm+6NBtQHQAjx rhtlnaVGTdzpmyslmNlZE3Rh9LnS9ZEeU+U3cICgXCfZoapZfKtNtgVt19Xa3qB8r1axiCRpZR1F dK1hZMO3Y0cYI6kSMAEBPzq9xXHS8k4s/wDDS3WsTcCxI87Cuo9owymaWUiyKAvwNZvKWGaRvSYE MmKMWZe5FbaVbofnVPE4iHAPbxiRB4R9QPlWpK+30jrUQ0F/GuEuSj4wqiwFvhSs4qNmqF5LUmBE j5JbVSyJwAaJ57Vm5WSADc1zbOla5IszLtfWsDOzTc61LnZfXXSub5DPa5VdWOgA6mpWrs4R3UUU sZyPIWU660vC4jvfKlg3Sk3haQ+n5hLfpqbi+DeWQZWcu49Vh8vLdW8o+nYPMPQLgJa3yAr10qqH l5LO78DNi47LS0eMpnyshiNzdQLn1fCu+9q+2V4jG3SgNkyau/xNQ+0sD0HIZRdjoeuldXYAWrnb 1OQ7ba7V8SArTCKsNaoJDRowivIbVVkarEzVSleubOiUjGNRNIOlNklAHWqjzC51rEnRVL8Eq3vW T7m5YLj9hTq3Wp0l061Um4b+ZSXc2Xzq5ZuqqnNuhx0043aGtHg8HJzcldintjq3hXTw+yuKi9ch ZiNdTpU+T2MTHMGKBGAPCrg2+VNwmUuRzIsWH6aE+voxHhWGZNSSaTL7zSMRcms+cZx0A2jpUiWa SVVgty5KL1NU5M8XITU1XGDkOfXf41YgwVBsRp41qEjM2YyMZOU3p9K+Ln9FauJAkQEcXU/jfxNR qoRQo0FSGePGhaWQ2VBcmsty4RdsKX0K3O8jJBEvG4YJmlF5bdQo63+dVuLgl5p4McIsHH4NgVHV msLknS5NqyxyOUZp5Y1tLn+hXPUIfTZfzXrseCwFwMRYgbu3rkP9I13f/wBdIWrPGp5Ltv7Ub+Nt RAiaKBYD4CrkbXsPCqEbWtrVqGTWvMpk6NYLyqG6UjxOpDDqDpT8ci2tXQsZFq7VpPWIOe7ox+Ll LOnX+IPxD5VPWTPGY5N8ZsR0Iq5h5omGx9JB+Wt0vL2vocr8cepFqkpbikJrqchKbelNJQBSg0lA 60A+5ooooB9JeikJrkdxb00sKQtTCajYgSdUmiaKQXRwQR868553jpOPy+xb+Gb9tvMGvQ2esH3Z GkvFyyEDfFYo3iKVvDNJdDz/ACe4u5bfh/EaxJZP4pv01Irby+QFmC2YOg3XFvVXOfjmNvPWvSng 4XWTVwlbYZCTv/V1qRZIY8Ji5PeYkVElzDodq+B+VVnPeYi/Q2ArNU5N2cJIucchaT1G1+proDjp BEAx0YizX6j5Vj4FomTpu+OorTJmecyLGSf1R1AFV9EWmjfU0+Kwk5CcY8S7V6lr62FdxiwQ8fjL FELG2vxNch7YZm5NpVG1FWxHhc2rrCSzbm+yuHJbLUm0h4Nzc9TSlhUd7VG7+NcpLAsknlVWWa3U 0kso86o5E3xrLZutQyMiwNY+Zlddafk5XUXrEz8oAHWsrLO9axllPks3aCAb/CjhOMeaXvzLdyer ahB5mocHFkzcruWuE/DfpfzrqUysHExQQQCNLdSz/wBL5V6a12V0yzz8lnd9qomV8OPCYR3ujBiX 0LbTrf4VmzTiewFyykkE9OvSq2TywfeS1t/UdDYaWA+NV4ZcmeQCKM2ksqgmxJPjW1VrLOe9aI9N 9p7jw8Za1tzbT8Aa2Car8fix4eHFjxiyoLW+J1NSO1YI9RHYVXkcUsklqpzTa2vWLMtUNnkGtZs8 9r61Lk5Fr1jZmWNbGuTZ6KUHz5fxqt9RvOlZs2WSTrTYJyWGulZhnfYkjfxxetGJ9grNwmXaLmrr TIF61tM42lsTMziiGxrn8nLdybmrmdKHuAax5b3PjQ6cdVGg7veN6A4Y3bpVX130qWOGV+gNINkr MgGmlMGvTrU8eAzdb1aTEVOo1pBNxSETdTWP7iyFEK4iG8jsGZRr6RXRyGONS8hsi6k/AVxzcjEn IZWXt7pcMmPfUA3ADfYK6cNJt5HD+xyRSO5Z4mOTleRjlZdsGGihVHw6flua7GK6/KsX2pgvDgGZ xYznco8dorZY2pyNWfkTiUV8WWVktarEeQB1rK7hpRMb6GufU06yb0eaANDU45AjxrnVyGBqdchv OruZl8aN0Ze/qfvoEhVxIp9S6g1kR5B0q3HNuFZ3PUm2MHSxyiSNXH6wvS3NUeLYyRtHfVOg+FXD FJ4G9eurlJnjsos0OuaL1GVmFMLTjwvWiE9xS1V+omB1Sj6th1Q/dQFy9FVPrB+yfuooC7TDQTTS 1cmdhCajZqGeoWesWZpIV3rJ58dzislevoJFXpHqnmWkx5EOoKkVzVvUjaR5NmyWLH4afmqpjRl/ UNLnrUmfuEzQk6hiPupvdKx9tNAOpr36pHkf3PzJ5Xue0nRBa/xp2NEFO4jWocfdtBvcmrsakoCf PSqlAmWW4lAUk6eVX8cZrvHjxk/xBoB5GqMIZmHj5rXc8BxSWXLkWxsAgNcuS+3J2oi7wXFDBxQG H8Q6sfGtM2FKLAU1nANeZ95Og1iBVaWS3jT5ZRVDJmtfWo2aqmyOecAkXrMy8gdL03LygL3NZWRl X1vXOZZ3px9RcrI661hZcrzyrCn4nIGnxqzlZB11rLinaOR511cDbH828fsFd+Gkszz3Vam3FnR4 eM2FjJumclN/kRVPJjmMT912LbgihfTqevzFVcWdMUtKfVIRZPHXxNaXGSmSZpJRuI1UHwr0W9Oh 5K+vUlh4mHDgHjLa8oXSxPQfGr3t+MT8vjLGpujBmXy2nWs7K5B4chyvq7lib/CrfEZQwubxSr/j KmRv3+oqNuBicHqplt41BJMPOqz5Px6/oqrLki/WuDsaVck0s/XWqM+T11qKfKsDrWZkZR865Nyd q8bkkycs62NY2XkXvrTp8i99aoyt1JrJ6aUghdydanwySwqi8ovarvH6kGttQis2oJCq69KdNkWH Wo1jYrTHx5CfGsnPBDJKSfnSLBv6+NWExHPhVyHD22uK0g7JaFOLAW97VbTFUeFXFjUCkewpJje2 QdsLr41XlYA66VNJJVRzuNyft+2plstVq30MX3RkKmB2lazyso2g6letYE7Y+RDh4WIm6b/rWH6z vbT7LVZyZcbJ55jlvbGjYjTyUdB8zT/bEST82ZkW0Ue51B8NfT+evVVbaHkvbfyKPI7KKMQwRxdN ihbDpoKa1Kz0wnWvO3k9dVCG7L9KTtkVMoFO2g1A2QBSKeulSFRTTaqQerEVZilN7VSualjaxFZa Izd47J7M6t4dGrpNPDoda46B+hrpuMyO9jAE3ZNDXbht/E83PT+RapLU40ldzgN2qfCjtofCnWot Qgnaj8qKfRQFZjao2eh2qFmrz2Z6UgZqhd6VmqB2+Nc2zaQyR7VUyJbIxv4GpJnrF5zkBi4E0l9Q unzNYiWkjcQp7HnOYyy5+S9/SZG2/K5qIb/wj76TxB6k6mpoVsfVqD0r6dVheR4bfc34lnGB0Unr VtEIcKNQKrx2LWIsFrU4nEXLyOzc7z+G1LOFLLVS4Nr23w8eTKJ3B2qbnw1ruEUKLLoBpWfgY6Ye OkS9QNfnV5ZFvc14rX3M9KrCgdIs1v4YLVRm/mC3btMR8LGtSNwakBvU2ysMK0dJOXkz5FJWUFG8 jpVGfOJ8etdflYkGQhSVA4Pn1rkuZ4XIwy0sF3g628RXO1WjvxXpZw8Mx8qdnJF6z5W+NOnmsSb6 VRysxYkJPU9BVpVt4PReyqpZDmzhFNz8qpxeqMOddTpTZFkyRvNz5CjHYiMqdCpr18SS8z53O3Z+ BZe30ynxDkDw0GtXuPyRsMo6+H2VmRkSP22J2kaVYRu0APA0s8QONdRsk7PM0t9N3pv41Zwp2l5f GjyCBd1Bt5D1D81UclwigD5ijj8xcfkIsiUb1B6+VV5qY0vB6tLlgDrVGbM+NUDll0BBuCLj7arv KxNeJvLPdXiUItS5RPjVOSUsaZcnrSEEVDokkROfGqWZOI1IvqatTuqKSa53Kyu9OdpuoNhW6Udn 5E5Lqq8XoWVcuw8Sa6PisVyoO2svg+KlyHEjDS+ld1gcesSjSrdp4XQw7xXOoyDD9IuKsjDUeFXk gAHSnNGBSDg7tlD6ZR4U0xWq29hVeQmxqMKSs9lqpLJ1qeYmqMpNzWTrVDJHB0rM53JfF4yWVDtc 2Vf9Y2/NWhtuda5X3LPLk8lHx6tZF2j4bm866cVZsTlttp4vQynhx147vM27IleyqfBV6n7a6f2z jiHAElrPLck+Nq52HDx35YYkbdyFXtu87fi/LXZIBHGFXQAaAeVdua0KDjwUluxPvFKpvUKk9alj ua856oJVp4pliKcKGWKaYadbWmkUIJcXpyHWmEU4aVGUuwydBWzw2T28gITZZND865+NtRV/HkKl Sp1BuKtHFpOfJWawdiRSU3GmE0CSDW41+fjUletHhahjaKWgVQFFLRQGazVXd6VnqB31ryWZ6kgd 6gkfrSO9QSSCxrm2dEiOeSwv0riPd3Id1lw1b+k4/RXR8vyK42O8rGwUG1ec5GU+RkPM5uzm9d/6 /HL3NGOe+2sLqRL+O/xq1oLfOqwB3AedWImYOCLEA9DXsPGWY2JY2Bt0tXoHtTg3xMb6qcWmmA2g /qrXNe1sCLOzi0oukNnPkfhXoQyFChR0Gg+yvPzcn8T0cVIyO7QGgpwUCo+8CNKTuDzrznTJaVhb XrU8badaoo4t1qVZR51UyNMvg3HShoY5FKsoIPWoI5gfGrCuLamtqGjLwc/ynsrAy9zwHsSEanwr huU/y/5+F2kVRkRj8LIbm3yr1wMD8qUhTWko0L7jeLZSPF8DjMiFu1kxtG3kwtVTmOMfEfvIPQ3W vbZsTGm/vY1f4sNazsz2txWYjI8e0N5GotytJq3JW1Yg8UicMQ/iKsQyCUW8V0tXfZH+VeES7Y2X JHuN1VgCBWbk/wCV/KR7mxcmORrXCn0kmulrJ+Bik1mDiJgd7qxva+w1FY9u56KdK6fI/wAv/csd 90BktqO2Q36azMn2/wA3hrIJcGcR2/F22sPj0raso1Odk5nxNzh3aXBjO69hqau9s31++uY4rmH4 xBFJHujY3JvY/lFbH/FXGEdHv4Dbp99681uJzhN+R7ac9ISbS8zQaO1QSuFBvWbJ7qxSSoicjz0q hm81JkntwKyBtLtWfavOkLxNe/xrR7n2QcpyDOxgh1J6kVPwPBS5Ugd19INJw3DnImBYE6+o16Hx XGRwRqoAFq1ayqttfmYc/ff4IdxnFxwRhQoFq2I4QopYogoqRmAFK1OFryxpsKid6V5BVaSSlmEp B3HjVWRqc71Xdya5s6JEUpvVR11q05qG1EjomUsuUYuNLkH/AKpC33CuEZJcqLI5KaSzbgF8yx8P sFdJ7uzmjgjwo/x5H4rfsg2t9prnk45/r48B23C4aQL0BOpr08VdtXZnn5nusksx08zT9t4cYiGU ReRyQCfACt/bcW8qZiYawRrGi2Vegq0Iq4WtLbPVWuyu35kQUgWqZFtan9u5GlPIVB6j9lZEhYWp LWNNEqdKk3LfTWqQbQRTra0GhCMii1qeRSEUKKnWrcLW1qkOtTxtUaIzq+Cn3RtCT01UVqmuW4nJ 7WVGSdCbH5GuptXq43KPFy1iwlLS0Vs5iUUtFAc471Czihn0qB30vXhbPakI7dapZEwUHX41JNKA DrXJ+5+b7CHGhb+K/wCL4ClauzhG21VbmZfuTlvqp/p4yTEh18iaxAF3U3cTqTqakUC1zX0KVVap I8N7u1m2OU6hvCnnTUHrTQAelBvrWjB13snICJkC+ptXS/W+FcP7XlYZUkd9GW/3WrqFuRevFzL1 Hv4ErUTNNcvSnjKF+tZo3eBp43GuRt1RpDMHnUq5Q86ygTb404O1VEdTZTLA8amXL+NYiyNUn1DV TDobq5lvGpVzR0Jrnhkt4Xp4yiPHWruaI+M6NctTUizqa5xcxl8anj5AjxrSuzDob4daXcPOsZOQ B6tU4z4rfirW8mxmjp5A26aCmm500186oNyUQFgdarvkSTGyvtB8am5FVWT8hxPF5htl4kM5/aZQ W++16wMv/Lr25kndCs2Kx/7Nrj7nDV0WLjqo9UvcarVgKqdujaI47I8y5X/LDNjG/i8hckDXtyWj f7+n31y+VxfJ8XJ2s/Gkhkv6WYaH5N0P2V7rtUm9tabLjwypslQOh/VYBh9x0rSvbR5MpJOUoOE9 s4qdhH0JIBPnXWwgAdLVMOKwl/uYli+CDaPuGlI2K6/hNctrTO1r7he4B0qN5bikeCfwt9ptVeSH MHSMkeY1o2ZVUEkw86rvMKhyHliv3EZfiRpVN8gk/CstnStS28oNRFjVfu04Pp161I8DUEm4Go5H VFLMbAC5NI8iIpZzYedcn7j59mD4mObAizEda3Srs4glrKqbbMnm+SOdyLTIbRx+mI/Aa/nrd9u8 en06ZbjdNLdmY9bGud4vjzm5ccN9Dq/wUV3mNEkMSxoLKgCgfAV15ntSqjl/XTdrXfkWEjFgBQxV Oup8qdu2r86hJua4PB31HF2PQ2+FRta+v30pZwvpXcfADxrTwOAzs2zbO3H4u9VJvoRtVy9DHNuv hSq5XSu8wvbfHYsZV07zsLM7fHyrj+Z4qTjMxoSCYWu0LeYNW1HVSZpzUu4REr3FLe9QJUu6sI6w P6UHpSXvS30qkG1KlRinKdaELuO9mGvSu0xpO5BG/iyi9cNCbGuu4SXuYKi+qEg114nk839hYkv0 UUorsecLUU6igOMd6rSy0sj28azOT5CHEx2llayr4efwFeKG3g+gl1bKnOcxFgQFybyNoi+N68/y J5J5mllN3c3NT8lyE3IZLTynr+FfIVUr2cXGqLxPLy8m540Fp1zb4U0Ut66nEduYaijc1tabS+FA X+HzPpc6ORj6D6W+RrvYl3KGU7lPQjyNeZ1ue3+Wy4shMYyExNoFbW1cebjlSej+vyx6H10O2C2u KeF0rLlzchNVsfgaZFzzo22aLTxK15T1urNkL91KE1+dV8bksPI0RwD+y2hq8trefyqwYeCMJTgg NSqtqftqwZ3EPbFNMYverFhRtpAkgKAimhR0qzsFJ2xQSQAUuvnUwio7NBJDrT1ZrCxp/aFqBHap AnwLODI+7U9OtbKOCKxMZtr7TWkkoFq3XBysuxdoJNV/rI1Nm8qrZHLQgeg9K22oJtbNC9xVXKyn i1SxrKPJyu11a4+FLJkHbuc6VjfJpUa1JjykjNskGpqaHKK6HT41UhZJV3KL/GkzRImLJIg1RSw+ zWpk1CwjQmQZERDeoMK8+9yyZ/EZnaO1YJADDI17N5rex1r0PBdJMdGQ7lZQQfMVm+6OETmOMlxO kv4oWPg46ffW0lOUY3OspHmo90zrIfSCvT7fupkvujONwhA18ulY80UkMjQSoUljYq6+IINiDSpG 59QBt8BXb26djn7vJpP0L+Tz+flQiGQhVP4tuhI8qzj51JLfdqNR4eVRt5VutUtDnaztqdD7Px7t NkMOlkU/nrqo0ub+FZXt7F+n42IEep/Wx+dbClj6IwSx0sOteS/qu2e3jUUSmBsrXO0eFWOP4rKz 3CxL6AfU56CtTi/bjyWmzPSnXt+J+ddLDFFDGI4lCoPAVqvHOWc+TnVcV+ZR472/g4dmZe9KOrN4 fKtQG3TSmXFLeuySR5nZ2ctjwdapcvxsXJYbQuPWBeJvEGrV6W9GpCs00zzOaKTGmeGVdskZ2sD8 KA1xXU+7OI70f8wgX+JGLSgeK+dckp8PKvLau1n0OK++q7kwNOvTAdKW9Q0PBpQaZTgapIJ42NxX Te3ZvU8XmLj5iuWQ2tWvxGR2cmNidL6/bWqOLHHmrNTrqBSDUUor0HjHUUUUB5xmZcWPE0srbY0F y3hXnnN8zLyeQT0gTSNP0mtr3CM3kwPpz/AT9Tzt41yjKyMVYWI0INc+Ci1nJ6ee1tOg2lFJRXc8 7F6UCi+lFUgtKBekFOjYBrnwoBNeh0q1xt/r4bftCoR2ihJJDA1Yxp1gyosi11XUis2+1mqQr1fY 7R03KL1WfHFWYZ0yIVlQ3VhcU4revA1DZ9RPBn/TjdcdavY08yCwYi3xppQGlA2m9CvJeTPyB4g/ MVMvIy+KiqAvanKTSTDouxf+vl8hR9fN5CqYNPFWWTauxbGdMfAfdTxmSfD7qpXtTgdKSTauxaOf KPBaaeQn8Av3H/TVYmmX1qyNq7E7Z+UTowHyFMbJyXQjuspPipsaiuKOmtRuCqq0MtOf5jieT2Zz PlcexsXKruAPjuAvpXa4+VHNEk0LiSKQArIOhHzrnpYYp4jFKu5GFiKxM9OQ4LbkcNI8MB/vYwdy k/utcV1q1bCwzjelq51R38rK6m5sPCqJgFit73rC9te65OWmbCzURMjbuidLgPYXYEXtf5V0Cyxq 9m6Vm1WnDRKOVNTN42VkzMjDb8cbXF/I+NbD45lhZf2hasrLj7XO42Wg9E0ZjkI6XBuCa1+7st5a aedIg3foytwjt9OYpP7yB2Rvzg/dWo21kIOoNZcTiPknHQTqD/rL/wAlXTIw/D9tVaGLL1JlfgZ/ pxJgOT/uzEJ+5+r+Stl3RlDAgA9a5TNyfouUiyWBCyN2pCOgV+jH/WAFSZuVNfaGIXoLU3YhmnSb Sjnff/CIucnKY9gmR6JgOm8dD9oFcmGaDcu7XoK7vmw03A5Qc7miUSKfipFeesxY9b31rvw23J+B 5+euxqNWIxN/0025DXv/AKKtYPG52fIExYi48W8B8zXdcB7L47EKZGeRkzjXZ+oD8vGujskcUmUP b/8AxFnQqsGDujACiZ/Qth46g16Lw/Fx4eOhlVWybfxH6i/9GlgmiVQiAKo6KOg+VWUlB8awqV1R u17NQ2Wg1OBqAPenhqpglvSg1GDTgaAfelpl6WoBSAwIYXBFiPDWuC5/ijxuaSg/3eW7Rn84rvQa pcvx0fI4LwEXcC8ZPg1Z5K7kdOHk2WT6dTgFanVE6PDK0UgsyHaR8qdurzRB79c98j70oNMDA6U4 GgJ0NXMZrMNaoIatwnpbrVWpi6wztePn72KjHVhoatA1h8DkWYxH9bUD41tivTVyjw2TVmPopKKp k8nx4ABasH3Jw5im+sjS8cg9dvA+ddXHFbwqUwRyIUkXcraEGvLS21yfQ5ErqDy1oWC7wDbwqPrX Xc/7cGFC2XjE9rqyHWwPlXMPA1t4Fga9lbKylHhvV0cMgHlS9KQiitEHUlJRQg61Le32Ugp270bb Dre9OgOh9s5pIfFY6DVa37261xfDSFORiI8TY12BevJzViyfc+h/Wtupl6D2I8KUEEVAXtTe7auJ 3gtA0brVW71HeFCNFwMDT1e1URL8aeJhSCQXdw604NpVRZgakEgPjVJBOTTWNMD0FqAW4pfDrUd6 N1UhKGtSnYwKsAQfCot1IZKCDMb2+cfLTOwZtk0cgkVT066/krpp0dyHj/CQDprp1FZLTfGtPClO ThtGG9cRt8bGtbm9TO1J4xJV5x504xZ42ZHx2WTTxCm5H3VpRz/VY8c8Rusiht3XrrWflQSPA0TG 4III+B0p3CRSQcYMZZNxgYqG+F7inQlq6FjKR4WjnLf3bBj8vH8lXTmxxX3a/wD2vWPnmWRHEjEg i1qmBMuLFIerIpJ+NqiNOihNiZnIxz5EQKDYx2OD5HSlybMoK6C9Z2YoVSb9NQasxzbsYN56/fQ0 64UDeQikm4fKhhF5JE2rfzJFZPF+1MCMBs4maT9kfhFa3eP0swHUL+kVUGRIp6/ZXXjbScHDl41M m5j4uJGgSEBFHRRpVtIT1U1gw50i21++r8HJN41pQcnVmsiSDpViN5VqlBnowFzarsWQh8RWl5nO 09iymQ/Q1YjnB61XRlapQq1r4mPgWlkBqQG9VAPKpVLChCxS3qIMfGnhhQDr0oIpNDRagOS948Z2 5E5CIemTSS3n4Vzqtp5GvR8/FTMxJcdxcODb4HwrzaaNsed4X0ZCQRXDlrGUe3+teaur1RIKcp1q NGBFPHW9cZPRBOnWrEZ1FVVaxqwh6VTFtDV4/IMUyOPA11qMGAYdCLiuIgkANdXxM/dxACfUmhrv xW6Hk5qxkv3optFdcHA4FY6lCW8KcFp9jXhPe2QZGPHkQNBILqwsa8/5nhsrj5jGyk49yY3GoAPn Xo9qiyIoZoykqhlP6p1FdOPkdHPQxbjV1B5M8a621PnUBFq6P3NxkWDlboV2xSg28r1z7L99exW3 KTy2W1wxgF6KOlLcEfGqQQGlvQV0vSVAPjdkcMpsw6EV0PG8t302Sf3g/LXNg1LjzGGTfWOSisjp xcjo/A6s5I86YckedYoz7+NJ9dXD2n1PX79TZ+qHnSfVDzrGOafOk+qY9KvtE9+ptfVjzpwzR51i d+Y9FJ+yjflHpG33U9oe94Sb65q+dTx5anxrmwc3/s2p6y5q/wDVt91Pa8SrmXU6hchT4045Cjxr m0zModUYfZUn10/ijfdWfbZfcqbxyl86T6pfOsA5c5/Ub7qO/knpG/3U9tj3Km8ctfOkOUvnWH3s zwhc/ZTTLn+ED/dV9se6jbbKQ+NWOM5WLGzUZz/Df0SeVj0rmGfkv+xe3yqFv5k2nZf7qq4/Ew+Z M9OyY0toeoG0+YPjWdxcix8lNhk+qaISqt/FDY/nrleP5r3Jh2COWjAsI5RuX8utXOInzpPcEGfl MTI7bWsLABgVsB5a09uOpPclQkdLmJYN4ikw0vxsXmtx91Tcg4UMALnw+QqvAXTj00N7nQ/E1z0O vRGbyp7cLk9LUQyZbYcQxsd5ywAG3pf50nIHuoEkHpZgGFxexOvW1WeGys+HA+mjhkUwSt2wVOqN 01tROs5OjnaojzZLh8NnyX+utimQaL+I9fsFWhweCjASzuR8LD/TULpz+UVtAyoDf1m356l+g5z8 JjQfEsKu5r7Uc7cbt916fBl+Di+EhF9m8+bm9S9rjxftQIxHgOtZq8JzUmpeNR8X/wCSpB7czrh3 zFjYfs3P+im+3Yz7dFryVL8aYoOsAU+R0qwBijogHyrLbg8xdRnBz/SUj9Jph4zlR+CeN7eG43/K Km+3Ynt0elqm0JIALA2qVJkA/Hr4VzLQ81EwDQM/kVIIrThxMsxBpvSSPw31rVb27GLcVUvuT8jV TMjB2saspMjdDesVILsEkNvI/GpfpshNYnvau1LNqWee1FODaDCn6ViLnZcJtKpNWoeUhfqbGtbk zG1mmGtTwaqrMjC4INPD/GqQsdRXDe9MH6fNXKUWSYan412qyA1j+7sQZXDyOBdofWvyrF1KOnBf bdPucHHLoKsK1xWak1m18aspMfOvLEH0tS6p1qwjVSV71PG9DLRfhPnW/wAFk7Ze2TpJ+euciYaV pYchR1ZTYg3rdHDOHLWUdheiqP8AMP7F/torvuPLsObCiloJAqDIyY4UZ5GCIouzMbACvIeskZgK ryOKZgI3MZ5xIMjsIMWbL7qqHv2mhULY+B7tUcbO7+PFK2hkRWIHhcXrTo0k+4q07OvYq+48UZWA wtd4/UtcC9+leiZMyFCD0ItXH5fEZM+aVwYmmDa+kGw+ZrvwW6M5f2ePSyMg0ldhjewzLwB5Cedo swZq4ZgsCgDKrbr9b+qtHC/y4wjrPO7+YFhXeTznn4JtSpDLJ/dozH+iCa9axPY3A49j2RIw8W1r R+g4zCiMhSOGKMXZjZVAHiSaklg8ej4blJNVxZTf+iauQ+1OYksWi7YP7WleuwpjyxrLEQ0bgMrK bgg+VVs14IFDSMqAkKCdNT0FRtlUdTziL2Xl29bgGrUfs6Jf7xifka6uSKWTCzeSEu1MHJxsbsbQ Q4yGhQsW6i3e/JUeUjDHkeEXkA9Ol/t2jrby8ay9x0q6djAj9r4Y6Lf5mrcftvGHRK0xFjrlTR4m S2Zips7eS6GMsxF3W1lvt8wPh4VOpI6GsNOTauowZ6e3se34alHtzFI8avicrUqZI8qQHdmZ/wAN 43gWpp9txeDsK21nXxFPE0fjVhGXyW/COeb235SH7RTD7bf/ALQfaK6cSxGj+EabET3X+Ecufbsw 6Ov3Un8hyx+Eqa6rYh6GmMgHjTaX3X2OWPEZ6/qg/I1E2HmJ+KM11RWmMDTaVcr7I5ftzjqlJaQd Vro3RD1X8lVJoorE2tU2s17ifRGKx80pqSduRXC6owYfYb1o43HHPPIbJjD/AC/DfLFlDbyl7Ib9 BpWftZkDDqRe1WGkVcicpLQ6FOR47JjMhkWIr+NX/F9lMx5lycUvGbr3Hsfhu9NYORDhomG2Jktl STQdzOjaMp2JvR/DBIF+refS/jVjAy58TcNncjf8SXtr5g20rLqK3lSXZ8WFpohPIkcW4Fmf03t+ rW7BKmHiqiRpLc33rY3+Ncs653OchjcfjRhJJ2KRh/wrYF2djboqqaZg4/Ix43KZkUo+g4uUQyMy kGWRpRCg2bvRodz6+kffUXG9UL8qbh6HSZvJyEAKm1vC3W32VTbPyitiDfz1qknJTRqT2VNvDWoc jm8vbeOONfmCf01hts7KiWiRpRZubboakbMyQLm//LWFDy3M5GRDiQLC02TIkMQKkDc7BRc3Ogvr Vv3FmfyXNXCxs0cjkxhlz1MXbjik9BRYzre92v6jWlVtSYs6qyrCl+BfOXmP1uR4gX6VJHkvGRe/ wFzXPQcxymW6rFFEoboTe356v/8AjKaWxpPiGI/Q1Zg00o0XyNxeQKjrYmnDk1tZhesOSbmEW74S yDzicH84FQx5s8hs2NJEfHfUh9zO1HR/zaF/Rs+2pFnkXobjwrn4pSr6g3qxk5Ld2Jd7QQu6LLkB S+yMkb32jrYV04209THLSsYN5cy+ji9I8eJNrbY3mKxIc9lklRJDkwJIywZDIUMiDo5Ww+Xx61YH Ip+sLGujZwVS8Y8qDWJt6j76kh5ix2y3VvjpVFeQj6o+tJJlQSC0oB/pDrSexY8DeizInFw1r1JM 4lxpIX1DqR+SuTZ3i9WPJvUeHjVjD9wG4jmBv0NNy6k9tymuhxGYTBkPGdNjEfcabHmheprQ5Ph8 rL5CeWIhIna6k/H4VXPtyCHb9VkkFzZRcLc+Qrk1WdT2K7SQ+LOjI61bhyo26NSD2hh/8PZHNpkq ZMWftTYbAkohlEKszK17m4fp0061p5ftXj+KyseBZlzsfMx/qIMhBtBAIB/C7AqdylTR8bSkyv7F W4GQzrca1pYsgJqp/JMawMMjxH53FIsGXjMN/rQfrLXNGrNNG73h+S1FZn1I+PS/SitbmcthM7AK SaZwMOLyHuSDGzGPbiU5EUNiVlkQ3AYjS0dt1j1NvjUIM2Qe3AhkY+XSrnt3jp8T3RgyTkbnjnG0 eHoFXiq9ybROVpVa3ZKns5OP/wCLcmDi8iTIwhxeQEmyF7ZDGbHDD8K+kaa2qkeF45OCXkeI5GfK TFmixMsTIqL/ABdiI8I2K20mRbbidKt+x0jXkwyWu3F5m+3n3cXr99Q8ShHsbkV8Tl8Z+VsKvTtU Q0edWacpsdx/t/jsmLCfPz5cbJ5VpBxsSIroyxkKJJ9yto5IsAV6jXy1uNRTi7WiWKaJ3hmjT8Ik iYxvt8bbl0+FRnOgxOI9ry/QY+VNFhjt5ORI0YilxxCHW6q3q3a6+Rq5xaGaCXMLIxzJXyCIjuRT IblVbS+vwpCWiJazerM+c9v2/lG34eZQ2Hwijo4o4ee2LAeXmiz8xAUjxoUbFjkZO72ZHkRmZgAb 2dfso5CRYPb2bK+ixcwrtbyWGMmn8ZDHxvuHh8WeL6nkstfqHuSIsaORJtoijW25/wCG2526eHWq QZiZU2WmdJmZEmFDxKhc04qo8rTGWSDbH3ldQgaI3JXx6in8DInKc5Dh5ryNjQs82PvjMZyTG107 i29PbtuI03G1tKo8fyWNge4M4ZG2TEzszNw8/Hb9aJ8uYK9vHtl9R+yx+FaHCYj4HvSPjXcyDCM6 RyHq0bRJLHu+IV9p+IvQBxHaUPFhSy5HHRqgxppk7bk+rettq3UaWNLHjcXm4/M5PKyyQ/SIsKhF LGKJzfuqCCGaRltpeyj4mne2yj8RjhWDFUAYA3sfI0zKW2B7lH/8DE/ty1CFTiY4Mj2xz65WS+Pj ryMDLksn8QxxSY7w/wAOw/iSKqgC34jUHLovG4+PlYOVJmYfIY7y40mQqiRHjKh1ftrGp/GLenwN SwhX9rc1sIZW5HA2sDcG8mH0qvzak+1+AH7OPl/keOqUtTcXInuiH279XIY5XAOVtTugHHmyLW27 OsdulNl4+BcPkp8TlDl5fDAyZeP2tsfaUsG2yWXcyhGuQbXFrVpZSn/6n4jeHcUf/wBjlVkcWpGL 7zP7WDln/wDmZtSEWWGLjY8mLjZvK574EGfM0ODHBGHdgjdtpZGcMFXd8OljfWn5+OnHcrNx8GRL lDHAE7zIqFZGAdVXYqggowNMGFBy3t/jPqcqHjo+Imnw5pspu2kkUrpJugaxDyARhdvnf4VPkTpy nK53JRKVhyZF7G4FSY440iDEHUbipIv4WqNKCpuSv25m4vM5RJ2L4GQkU+LtXZ2JdoWUG27Qvrr4 Gj6PkGPCQw5BbN55XlELqO3DDo6v6bMT2zc3bWx6Vc4VIv5xLxmVf6Tm8aTDmANvWqs8Zv8AumQD 4kVPBlxS/wCZkQWy42IjcfigfhBihZzb5Euv2VUkG2VcvGxYMTKzeJ5OTkRxsqxclDMirtDNs7kJ SOP0qwPXdcA66VWnbKxYOFf6lpG5vGhnbcqfwmleBSI9qi4AmP4r9Kh4COWHhvdvfBG3CONJf/3i +SgX94O35am5RXeH2OiAsz4eKqgaklXwywHyAuaQSTSvJhchn8fJK2QMOZI0lcKGYPBDPqECjQyE dKbFC+fLyLfWfRRcbjwz7iqmM9xp95kupayiH9U03lb/APEvM/8AzEX/AOUxqihB/l3uv/8A1uP+ fMp1HQMuSLBwcTlMfObO4/MeSFnli7TxyxB2I22U7bRvoRfTqasR4EsxixTnvDzuTi/WwccUQ44Q 3KxSPs37yFNyH08vPH5dHb/LzERfxnkssD59rOroPcXuDH4znYM3H43HmlOJHLBnSytGe2/cTau1 GXQfnqkMrDyoM3Bn5XMypMDisXtpJJCivO00oVhGodZANqsC3pPX4VJlY+XByY4RXXJyJ3i+jnK7 Q8MwLLKyr+wEfdbrtpOKnxsf2byDTYcWcsfIo0kLsUjAljgCSbkBO0brXp/Fcr/MvePF5s0UOOsI +jRIXMgXbDkmO7Mq2/vCopAktYeDw+LH7hTCz5szKgwJ4clZUVVuocMYmRV0V1Kka6+NZ+NxsDY6 ErqVH5qOChmif3PHKp7kGFlRzk30cvKwv+8PUPMa1exh/usf7g/NUaEtGJJwxH8iSKcmXn8eKYmQ LtiaTtFtuwLcASG1/IVPLxuBFyZwsDIyslYWmiymyYgoWSJlT+G8aIpVju0Ovj0p3MSdrjPasok7 MkXExyRS/svGMaRW/wBXbc/CtSeeLMbj+fgXtjlmbGzYAbquXCjnep8QVhZb+IC0hF3PuVIuPy8L Lgz8J1XJxmLR71LIdytGysAQSCredJJme4om5NhJB/4wP96UxEqh2dndCO5+wAPVfpfzv0UUQZBc VWzcdAhJ0AFyaQHaXk5jIwcXE4PCyZsvJ+uz8b6vDxUjV8fZ6SkcjbO5uIYAtusD1p2HxfGScc/K cznScdgNOcbHMChnkdQd7EtHJ6F2t4fqnWrcSQczwOZxCOGyeJR83i5l/wCxN98DfAX2/IqfCsjm l73+XfBvFcxRZGUkoH/aM0xW482sfv8AjWXVawbV7abmpZocbxCcV73xePzpWKwyLLizIv8Aelx/ BuNbA+sH4ir3F8VwmX/mJmHvPMIHkyVgdCAcpZP4nqsBtiJFvM/Ko+XDr799uxP/AH0GPipkeJ3X msCfhqftpvtfuf8A1L5K59G7N2j/ANrHeqkljxI3Z5b/AI/rBhw4mEjW4uWXI49UT6eeZNjsNut1 2rp5G1aGJjYsuNk8nyubLgcZiSJjb4FVpXmYBzbejgKikE+nz8q5fAzM9MKAR5G1FjUAaECyjSus 4/kMeL2BPk5eFHyvZ5EjIikYooLqoWQlAfB1H21zqk7NtHfk314651hShMjD5PH58e345BNkSSKu POw0aJ1MvdYD9lVa9vKrU3GYD4fMT4PMyZU3CwSyyxGFUvJEshtuKWaMtGR6dR59Kre2/cJ533/g 5s2OmIPpnxo40cuC8ayuG3FV12sR9lVfbAnXjfecU4tJBx00T+e5RlA7vjcGtqte2pxta/VxCFyZ JcT27ic6shds2bJi+nZV2IIDOqFSFDa9oXuavZuLPgczi8MmU8i5qYj95lTen1MssThQqhdBHpcV m8oGb/LjhQNWOZmLp+0z5e1fmfCtr3CrL764ZSLFYeNDA+f1ORTau3Ym59+5FhYMubzmfxEma0Mf HJM/1OxCW7bRqO4CLWs+u21RzpBFx8XK8fm/zLAeX6bIMkXZkilI3Idth6GuNCL6jU1Z40E+7vc4 Gt8XLsPtirL4jT2LzLNqkmThRxfGUNjk2+V1NNqjTuNz79i6vGYAwuJzuQ5VsReXS4iWFXYO2zaI 9qGyDd6me/h51NF7eT+ay8LkcskfJ2ZsSGKEsjIBuVp2bozAX2KwsNb61nc4CeH9nfDEf/vMKtm3 /wD1e/x//wAOrC7El9zF4qOPOhyczNlbAwePjQ5kkKh5TLI3bSGPeGW+4akg+HnU2RgtDzWDxceS ZcXkxDLi5wVQ5hm3aldu3cNvlaxGlP4GeCH2z7kM2ImeIsuOaTGkJVTGZFAZmUEgIUZvsqHE5kcv 7k4ELjw4icdImNHDBIZAE/UBuq22hdKm2uEXdbJbk4aEfzPGxOWOTyXFpJMcXsgI0ceuxpLLeS1g xU2UnpTOFxuEzuC5XkeSnkjKGOEmNCzQRmRHQoCpDNKygm19LDzqThx/+qPcx84M/wD75az+F09l 86TpZ8L+1HSEnKS6ibNQ2+hFj4+XNjz4xnZcWaYzBQu13KWSFpP3Qu8LYerrV+GKX+GZ3DtFEmPE qjakcUQ2pHGtyQB8Tc03DkBQMpBUi4IqcyEi5Fea17PHTseivGsMkDAAWPSnK1+n21VLkVNGOhrK RpqCfZH5f+minafkorcGZN/GxIYI9kKBF8hVfKwcgTwZmG6xZWMxaNnUuhDKyMrqGU2IPnWoq2p2 0GvSeRucnNrxPKfzJ+WSaCDMmhbGkWKA9rtOyu1kMt95Kj1X+yiP25NDjHBhnAwZHx5ZomTc7Ni9 sx7ZNw2/3S39JrpQq+VLYVZBgLxufjxPi4pxpMN5DL9PmQGdY5GO5nitIlrk3sfHyq/x/HDFxu0X Mjs8kskjAAtJK7SyNYaC7OdPCtCy+VKLUBz2XwEsxlgaYNgTzjKkxynqMoQR/wB5u/DZem37aOx7 iRIIosyJBiWWGfsBp2jUgiKWRnsV0G7aAW866GwpNi+VJBzcWDzMWTNmCTEmmyHWWSKbFBhSRL7Z IVSRXVterMxpY+Jz48sckmQrcn3Wned0ujF07WwxqwOwJZR6tLCuj2L5UbF8qSDIw+PyFyJ8vJMX eyAoZMeMxRgJuOiszncd2pvTJcTOx8qXJ49ob5Maw5MOTGZI3VCxQ2V0II3t8xWztFIVHlUIcrBw GZHDPjHIQ4+blLm5cYiteVJVnURHuHYgKAW10pZvb00+PHhzT7sXGjlixVVArIJirMXa53W26aCu mKjypjAVZKYD8dyT568s2Sh5OOQOsva/haRSY9u13L/gkP63WqcvEZePBlxwTqByMMkGcWj3bkla R32esbDeVvOuoIWopogwpIOWOfx+D7c4zE5bDXPjzRJn4g7n05hglbuWE19zP/EubWt0JqdcSDGy oo8UyNh5mLHm46T6yxiQm8chOptpa+vXyq9Hj8rhxDGwpoHxUYtFBmQfUCIk3/hFZIiAL6XJtUmP gZDTy5mXM2Tlz2EkrAABVvtREGiqu42Hx1uaAo8ekUPN/XT/AOH4jFmzpj5HaYk+9TIfsrNxeKy3 ijyGdoc4v9SZl/Es7N3WYX/pk/Otyfict2yY45kXGz+0uWrRlpCkJ3CNJBIqqrXa90PU1pRY6qNR QSYPISc3ycIxs54Fx94lkjx4jH3ZFsVeUs73sQDYeNRwSc9h4iYGLliPFiN4gYg0iAnd21kuPR4W te2l66U48Z6rUTYkZ6CglGDHDky5GRmZjLJk5biSVkXYt1jSEWXc1vTGPGmzYeVbLjglWOHkIUx8 tGTcxSMyFdjbhtP8VvA1uHFA8KaYLeFQsowv5flNBFhNIpwsfIfKji2evuyLIrXfdqP4rabaswHl sfGhw4Wxngxv8HJkQd2bHHgInLhdP1brp8a1Ox8KOzbwoDI4/AyuLAHGugRoVx5oMhO7FLGgsvcU MhuATrfx1BpW4iSd3nnKJMe2I/pU7CQiEl4uyoLW2sS1yetbAS3hUii1WSGdO3uTLhlx589Ginia CRewoujjazelh67ePT+jU8fHhI1QdFAA+yry28qeLUBzn8nzlbAY5Kl+IiEHHntaKgCpaVS533Vb HpVxYM3IeA5nYSLE3fTY+LEYYlZ9GfaXe7WJHwua2NqGk7aDwoQjQWW1R5EQkjZGFwwII+Bq1tWj Yhqg59sblRhPxySwJjSRLjSZCQbcpoEGwRtLv2/h03bfy60YcPJ8WZF45oexMyu+NkRmSMSLa0ib GjIb0jx8POt/tRil7cdQpyx4bLfPHKvkF+SEonE7qCu9RtUdsbfSF0AvSQ8ZyuFyX83xZo2zjJLJ IXQ9t+9cyJsV7gXNx6vCuq7cflSiGM+ApBdz7TiDjMrhs3Ny5czLgiEstgUx02RgKLCylmN/M3pM KHlOGeZsJIzDkqEycXIjMkEluhKhlINjb89dp2E62prY6HQi4PW9Z2NOZybXLNVR19JwOTjZ0mYO S3pBmIyNAcdBHHF2vwKia+keIN71rwc3yHJcT7oizIseIpxckrHGj7Zkdo5lLyFmYk2TzqfNwnxp nQ6qdUPmKzmgzFjzosWSOOPksY4eT3I2c9shxeMrIm1v4h6g/KsVs0/Uzdqq1VC0IOIyubwMOTCw coRY8rF7NGrsjsLFomb8J8dQdadmHk8nNi5TJmRs3GEKwOsZCgY7vKm9S53epzfUVoRRBR0ps4G0 gVl3tGpVSrehF7YyMpee5XPdgct8DInZ1Wy9zfGbhTfTSqpz+Q5jGxVyRBBiw/xkxsWLtIZHB/iP dmufUelutET5uJkSzYZjVsiB8WUSozjtyFSSu2SOzenqb/KpsPG7ESRjUIoUX+GlV8j2pTnqPa9T fTEFefGy8iDDx55VaHjY2hwwqbWUM0bes7ju/ul8BUhm5Qct/O+9H/Mt27f2/wCFbt9i3b33/D/S 61bI8KYVNZ327mvbr2KfHvncVkHKwZFEsilJ0lXfFKrEsQ6Bl6Em1jpRJJmS50PIgQY+Ri7fpo4I tkCBCzAdvdc3Lm+tWxH4kUdsa6U320kvt01gpxNyGPlZOZDMgyM5ZkymMd1KzsHfYu4bdRpqak4v Kz+G7y4IhkhyURJoclDIh7dwrel01sdfOptmtL2wfCpvt3Ht07FfGjMYN9WZmdrCwu7FzYa2Gugq ZvLwqQJYUlqzE5NSlhEYXzqeIdKYR40hmCkVUHLLlFVfq086K1JnaduBTqLUtdzyCUlLTJG2rehB 1xRuHnWBJzeSrGZoFXCGS2J3u5dxKASN8ezQNbQ7vEVWf3Blr9I30pdeUBbjUjcNJKAyKCyEKEB3 g33dNTarBTqQ486Nw865/LzuX4wJJymNHHBK2xZseUzKr2JCS7o4ipNtLXF9L9KhPuDMjXHE2MqS 5yQSYSCS4ZcmRIY+42z0Hc4voaQDp9wouK5xOX5CXM/lkeMh5JZGjeIy2jBRFlY93Zf8Lj9WpMDm cuYYkmTitjQ8grNiszhmOwXO5APSCNV1N/hSAbxIpCR51l5XIzd+PExIxPlyhmRGbYoRLb5JHs21 V3DwPWqGTzeVgl4c+BUn2LJD2ZO7FKjnarRylUuNxsbqLfdQHQEjzqCeQKOtZbN7l3Sq3HC8Gr7J 1JcWDfwAVUvbdre2ugvVPJzOXTBXkZ8JosFigLF17yCQhUaWHqoO4eNxfUDWkAtQcvJJJEzwNHjZ TSpjTFlO8wMVe6jVehtWmjqResDGwOQzeA4WbB7O6GbL3HIl7SXklkVRuCu1z4WU0sOfyAyjxf0r fzNGKnG3KBtADd3uHTt2Yer7LX0pAN+ynyp6haxJczkcIwNnxQiHJYpDkYs3fiLqC2xi0cRDWU+B GnWkxM3mswYv0+ErHOxxmY571l7JCm8hMfpb1j060Bveml9Nczhc7yGfi42bg4Zmx8yVceH+IFk7 rJ3TuW1giqDdr/ZViHk+RyZsjEgxlGThG2Y00ojx4tWUXm2sTfabWT52oQ3SBTSBWJkctl4Epx+R hEeQVV4RA/eSYO2xO0+1CTvstio6jzpMzlszjW/8USCJDu/uJ+8yMqGXZMvbTaSgJFrj40BtHbTS FrGyeS5HCWOXkMeKCOXaO2s4fIj3glO9DsULe1vSzU6B/cWVHDJDgJsyYlnidpwqlHG5VJKX7hH6 oBHxoDWstNIFZSZHONjyZX8udYccMZkkdVm/hkhzHFrvAIOu7XwvSRcjkZ0hi41I5WSMTSSzSdqF I2uEZ5Arn1WNrKelAapAo9IrFfkuQXMHFvjhOSaUQiBn9BLI0iuJQpuhVTY7fhanzSc5jY0uZl4Q ixsYsMhhKGdQhKmQJYEx6Xv1trahTX3r50PKFUsToBc1iQYfJcxiTcliSLEuLKiYiPJ20lKyx/UO 7AGw2Bo1uPEnyq1h5wysZZgCu4HQ+BBsfzUIS4fJSyvjiaDspmwHKw33h98I2asB+Fv4i6fHr1rS DAiuShyUwhj5K4KRNykCz4SwsGeRJGQRx2KpsLNKvpva5rXjy87Gy0xM9IFeXcFOPP3trIAxjlBj jKNtN/EfGqCznZz45jSJDNNPIsUMYIW7t0ux0AqkOZyDIMQQEZ5mON9KWUWkUF/x9LFRuB8qTKcn luLHnmR/man81hmL3zw2dB6sfOlZZiOgnx4pYzf4shA/1aABzf8ADIkjZchZmxjjrZnMyuY9iWNm uRpUuRkcxgxjI5HC7GMSAZUkWTZc2HdAtt+YuPjWfwOxvdnLZMo3RcW2bkAHwkklZVbx/UVx9tQe zy03JDHzP4qc3hy/Xq3SWU7G3N1/VZx8vlQpq4uRzmfCMrBwRLjMzrHI0yITsZoyduttVqzj5WfD mR4fI4300s8byw2kWQMsRjWS+3pburXO+zIRD7hwRtAm2ZMeQ4Fi7xjY7H5sCat+3IIURskIBNI8 geW3qI7jeP2VAdWGW2pppljHjWLlZ2c874+BB9TLDCciVd+w7AbWT0tuYnoNPnUGRl8phdluRxex FksUhkWRZAHAZu3Jt/C1lPS4060Ia2YkOTH230I/C3kayzxs4ay7WHne1MhyOYysX6/GxEkxCrPG DLtyJY0Nmkhg2HcvldgT9opMblJ86SODjIvqpZY+8CWCRJHpZ5HINgb6WBPw61l0TN1u1gfJg5Kj ov3iqkkTg2IuaJ8/kfrk4zsxTZ06o8CY0wlidXMg3d1kjsF7LbtKhzpszi2A5OONEkjeSKfHk7sT iP8AGocpG25b9NvyvWXxmlyMRiUP4bU36kedqXNj5LCjjn5CKGFJSoMQmDzxbwSvei2ALe1vSzVU yMLPjwo+TniijxplSRYzN/vPblZUSUwbbbfUP1r/AAqe0b91dS19QBrcGmtloPKosPguV5GJZ8OK BIZSwgbJm7TTbNG7KKkhPT9a33VVx8HKzcp8GCADLhSaSeKZ9mwY7JHILqHudzi3n51Pafcvu1Lv 10dMk5CJfGqqcLyEk/HwDHSOXl43mwVllKlliVXbeAjbW2uCBVKPi8rOOQIECHDhknyzJIUEaxNs cXCtdrhvup7TL7texqNk5EMOLlZMDQ42ehkw5WKkOq21spJW4YEX6injkMe34h99WeaxhyPtr2li hhGWxkdio1Hbx41YD7WpuP7OwTGN8kjHzJq24l0M15VHqRXPIQ+DCoTy0A03AGtse1eJWEoIzut+ Ikk03A9q8VjSGVou6/gX1tU9vxNe7XsYUnKwW/GNPjUEWblZ7NHgxNM69bdK7FuE41pC5gS5+Aqz iYGNjEmCNUv1AAFaXH3Mvn7I4z+Te4/+xHTd1HX9mivQr/AdKKu1djHvXLdFFFaOQVHMLoafTZPw GgOaOEc7I5Tg9wjPKQLlYrt0XJxiq7jb4dr7FNGIYZP8wsfFjH+68RiHFxRpo8ca7iD+7PtP7tTq U/4ixZnbZFgRZGbO/kip2dp+fd3f6tZnHY/IIcbmYUBz+4+ZJE5sH+o3NLCW8NJLDyIFUpm8E7ze 1/cHe134mJnG/jkuZpGbXxLRL8auckSMv2qPPH4y/wD/AFWNV2XHilxZuP4zjpsDHzJlnz5MhkJI Rt6wRLHJJ6dw+Ate170qpJGnGjI4o5uXw4jjgyu8FRooytiYyy3kAXTcNobW9UBx5P8A9RMgeHfn /wDy0FLwkMeSDyjIDPkFyjnUrEWPajW/RUQKooxo8+LnH576N27k0jnEDoJAskUcQ9RbZoUv+KtP hOPlxOMx8eYDuxxgPbUX8dajBn7MaSb3AM2VoIF4yJXlQbmWOVsrvFV8dEWsXlpsGTB4rF49p5v5 cXjlmnhaH0TSxOAN4HQqBYV0uZiyQZbZSQfWQTwvi5uGCFMsL/sliq7l1tcgWJrFl4V5yWwIcmGF ENxnSKzyOHidAqxllQIEYXOp3a9KAvEsf8zg5JJU9pSfBPozJsHw3EtbzrG4os3E+7nbV5MRJHY9 Wcy513PmdOtbG3kP5/8A8Q/RPbvbvpN8fd2/TfTX3btn4tfxdKpw8ZyOJh8liDGMp5bFSDuKyBYm WTJcl9zAnScfhB6VQUuUVX9o8JG+qGTOJB6XDS6/MXqzz2NmcpyXEpDGZc/P4qL6kFjGuy5ZzOw1 Ed2O7z0GvSrSwxnisfieR4iXMjw5JXEsU6xFhK7tZLOpIKvZgxH208T5yc2/MZWH3oMjHbBlwoWG 6PGO1lCFtgYhgd2o/Fp0FAUpFwY/Z+3Bn+pVeVTfKqduMuVW/ZW5Oy1rE9etS5hM/Be18DXtycZH POASN3ajgSJTbqLys3zApZI0bhJOFw+KnhRpO9h5DzJdZLbRJlWa9167UuCLDSrGDh5kqcZFPjtA OLwBhMzMrCRgIhvTYzWX+H40BBAxh9ptjRfwzkco0ClfSVQ+qQLbpujVk+RqjJxkLNMsISDHxY1l y5pdzY8QBbtkwqf4knqbYvWtf6HN2R4HYPaTPbOOTuXZsaN02bb79128rfGiXHWCPOxMrEmzMLkT FLfGZFljmh27P7x0G26KQb6EaixqAz+dEa4ftduNZnWDDllxWmAViYJMGWLeFJA9SCk5/ExMwrzW IoGLzaNGWKjuY+UFIkQnwvs6ftKfOps+OTkMfjIDxD454u6dsZC9lsYtGTCrL62dhEoJYKBrqaTM xmm4pOK4vCyIIVnOXkSZ7xlpJAu1Yl7TSaHS7fDxJqgj53tZ+JD7ojjXuOBicnHoTBlAdtXU9bNc J8QUNHKFjme0RckRw8cyD9kvkYyMR5XGhqeSCM8bPxfG4OVjDNmjlypsuSN1RYirqkRR3ZtUAuR0 6m+lMmxs/JPGTnFaNuIiw4zGWQmU400UzmMhrAMI9N1qAt8WS3+ZeczeolJo7nX0LHiEJ8gT0rH9 uQ4E/sPOHIzvjxPkYcbyRoZW2rDiPEuwakGRjWritm4vPy8+cN3E7S3xVePuKJEgRbksE/6o+NVe KwJOL444GZjPm4WVjwR5UMBVZEmgA2zRb2UHoPHwFqAVMvEzPdvAS4TSyRQJHiyyzRtEzNFHkFTZ wCdGNR8aWbP93s5LGTH5AOTruEc88aX/AHVG0fCnY2HJi8nByWJjZBxsWRHXHyJEaeRgs6vJo3bT cJFAUHovmaWCDOxzycwxWduXiy4xGGQGI5M0syGQlrEKJNdt6AgwUV/aXLo6hlfkOPDKRcENJh3u PjWwg2RBVFgBYAdAKqYkKYmLm8bnYeRlYma0EyviMius0G3T+JJHbWJGB+d6u4GNkjDjXJ1lt6rm 5+AJHUgdaEMXkWmjwPac8ADTY/FwzxKdAzRHFkCk+TbbVozR4S8nDzWGith82GaKUgB45wN80DHr 6tha1/xK1U8jBzMiDh4ZsRu3w+LHiTxGRV+oC9pWMbRsSukdxe2tulXoYUkgw+Pw8TJx8PFnfLll zGjMrysrIqgRO4t6ySdOnjc0KOm15Pim/wDjIvzNVvgciLM9wctxmTcvg5xz8InwuOzKF+C7v+fT MvGmV8XJhjMrYk6TmIEAsFvdVLWF9fGqePBn43LHnY4CJmyJJXxdy7mhlXa0Ra+zdcK3W1x1oQZ7 eUye5vcuIPx5q5Qj/wDZzOp/74VB7KJn5njGGgjw5Zm+A2xR6/a9Tw4fIwZh5eBBFmfVTZCQu2hj mdi0MjJuGqnwvY2PhUvp2ZcXFcXLxk3IDZl5U0qsEjYkyLjLHJIRu3G2iW6+AFClP2i3d9wYOQPw 5H1k6fuykyr+Rqt8F/gR+/J/3jVJj40vG52JnY+OZ0xVdDBGVVrOu0bd5VdLedWOKwZcfDSOUASX ZmA1tuYtb7L1AVkkkjy+YkjYpInEysjKbEEFiCDWBJeH/L3JEQ29rkh21H6v8FDp99dBnQ5cMuY0 EByBnYUmENrKuxnvZ23kenXw1qiOPy/5c/Dtjlo3zFyzkbl2bFjRCm2+/ddfK1UGhmS8HxfPcTmz 5WQkmFgRLHiQwNLG0RWeJWLoptfcdP6IrF45e37U5tkBXu8jBiG4s30ZaAopHgGEzKfmavyQxzYu Njcng5eRlYMf08OViSxxrNCPwLMzurqR4kC/Ug62pONxcjjIJIMrHPI4WbCsWfjqwEm9Pwyxs7KC dbH1A9CDcUAz2xjYsfOZDBRj247IbfGoDC7wqzgAalR0rPzBxEvtzC4Xipsicw5LzLNJA0SrHJFK p2lhb8Tg2vqa0MSCXB5hOU4vFyBDHGInx82UNJMrlu6BZ5FTTZbzK61Xy+IjlCrxGLlYsaXLJmSp t229OPGsTSem/VmudPGgH87FByuPj+5ViXdLtwuUi0JgybdpXU9bNuCfEFDSZkUPJcPi8uY0kzeE VMLkkYAntIbxZCXH6u7d8i37NTZUCvxGVxPFYWViNnyJJk5GXJG6xiIhkWLY7s2qAXPh1N9KdHDB Fx+fhYXHZONk8rCMbKeWSN8eOMhg/Zs+8/3jbQV0+A0oDN43Bxhl8XyGdI2NjS5sEfHKbyTzFJkK 9tWNooA7Dc3j5agnZ4nYP8x+YMgvGMfJ3D4W4+9Qh1jxOLil4qXL5DhFWLEk7ix47pGU2M53Ftw7 atbb+LxtTo5chPceTzmPx06xZmNJjvjvJF3BLIYbymz7Au2ECwYmgMaF8hI4OfIL5oZM5jcknUSP Et+ilPQAPCug57Ax+PweSycVw49zZMCRBfCEqZ5v695T/rCqskP8t4Ze8NxxMcb7eJjTW3ztUubi zJLxXDs248RgRiU9R3pgE/5ixG3waoCvxgnn+hx5EZU4qHIgDMLA96YMm3ztFGn32866GNLJasbj MRk+iWLFnxp4oyOSyJpBIk77QBsAkf8AW9V9q2Gny30XSjAwrSBbVLto21AR2pQaftpNtAJuopdt FUGhRRRUIJTZBdbU6g0BzOXi5zy8ljLiyOOTEGMMkNH2lxVN51YNIJNzdyQaIR0rcgx1A1FWNgpQ AKFGdhPKjsJ5VJRQgwRIPCnBQKWigGsinrSCFKdRegE7S+VIYk8qdei9AQtAnlUZgTyqwTTDQpEI I79KlWNRQKcKEDYtNaFD1p9BoCE48flTewlTGmk1QRGFPKjtLTzSE0BGY1ppiU1IabQDOytL2l8q dS0AzsrTggFOoFAN7SmnLEopwFOAoBNgo7a06kJoBhjU00Qp5VJSUA3YtKFApaKAaUB60naXyp9F AR9lKOylSUUBH2E8qOwlSUUBH2E8qOwnlUlFARfTx+VKIEHQVJRQGTy2NI6RFYmnjSeKSaJCodo4 3EhVe4yL6ttjdhpRhwTz5OVn5MZilzJjJ2nKlkRQsUStsLLfYgJsSL3rVKg0BQKFGrGoFOtS0UIJ ai1LRQCWotS0UA21FOooC3SUtFQCUUUUAUUUUAUUlFAFFFFAFJS0lAJegmlNNNCiE00mgmm0A4U8 UxaeKEFppNLTTVAE000pppoBCaaTSmmmgCkoooBaKKWqApQKBTgKgACnUAUUAE00mlNNoAooooAo oooAooooAooooAooooAooooAooooAooooAooooAooooAooooAooooC3RRRUAlFFFAFJS0lAFFFFA FFFFAJRS0UAVHJJGmjMFJ6XIFMzMj6fHeX9YaKPielcyMTm+TeSbGkihhVivdmBYyMPxWA6KDpXO /I01Wq3WeTrTjTTtZ7a6fE6c/Cmbl8xWbwf8xTv4+fF25Iiu1lJMbg7vUhPy6VltDymSQMBYnexa TvEqPDptqW5WlX0ZtOPIteJN29WKxnzOpBW17i3nTt6eY++sKDC5teJyYZFg+rdlMKhm7dgVvuNr 361Q7HKRqYZlhGYSBGqljH6rbbnr41LctqpejXx69hXhrZv16eHTudXuB6G9Z3MSzRiExuUViVJB IN7XA0+ANN4SDkYIJF5ARq7NdRESVtbx3eNP5hQ2Jv8AGN1I+09v8zVq824m42uJjyM0ivKlO5TE +ZLizk4SzOblVJJ8TtuP0VR46ed8va7sy7GY7iTqCo/TTseUrxct+gJUf61v/WpvEKd80nh6UHwI ux/OK5qztbiU/wAZZ0dVWvK4/lCG4uTM2YoZyVctdSTYaE6fdWlI+yNn/ZBP3CsjD/xsfzb+y1aO c+3FfWxNgPtNa4bNcd2+jsTlqnyVS6pFLByJTkqrOzBrixJPhetNmVFLMbBRc1g48jJkBmPpDBlI /ZB2m/8ArK1a3JOVxrD9dgD8uv6Kzw3a47t5dc/PQ1zUT5Kpfyx8jK5Dlpu4scSSSySX7ePCLsQO pPw+JpmHzM8WSkGVHLiSOfTHONHHjsboTWnw+MqrJlEXeY7Q3iETTb/W3Gr02NBkKEnQSKrB1BHR lNwR5EUpxWsld3e55JflrVuiotqwV+Td0x1KMVO8C4NvA1k4/NSLlNj737i6hZAdrgdSpPW3wrW5 f/DL++PzNVV44n4iF3A3xuxjPjcs6n8hqcsvktFmttdxrihcdZqnuttNXHmWeFZV0DeHkajzpWjx ZGU2a1gfmbVX4ZycaQfsyED+qp/TScu4EKJ4s1/sA/5a6u79nc9dv1OSove2rTd9BnF5EjyOkjM9 13DcSbWNvH51o1hcVIwyIy5A336fsuNyD7iK3an9dt0h9G0X+wkryuqTEJA6m1G5fMffWVzWNy07 xHj1hZQCHExYWPhbaKzTDyk6oMFYWktulEpYAdPw7aX5bVttVJnTOopxVtXc7xGvgdR+amq6MSFY NbrY3rKzsmfHwYYHH8YRKZVj6FgLbVv5tVGFOYwJkfNEQEusbQliFYamN93W4/MaluZp4rKrG59h XhTWbQ7TtXc6X50gIPQ3qrmy7+PaRdN4X8rC9YEr8nAzZKY3cwk/FNG3rWwuzFOpA+FW/M6tJV3S t2Owpxbk27bYe3J1VISB10qrx2UZ4iHN3S2vmD0NV+YkF40vbqSPnoK0+VLj3rJlcTfJseDSuALk 0txa/hWXkM78OJF6xWLD+irWa/yXWgT/APhRW+u7t/l3fmqPmjp/Hev2KuKev8tj/c07i176UtYY ZxxsdzpNIzKP6I9K/f8AirWxHL40bHrax+zSrTk3OIjCt8yX49qmZy6/ImooorocwooooAooooAo oooAooooAooooC1RRRUAUUUlAFFFFAFFFFAJS0UUKFFFIaEMznJLRRR/tMW/qi3/AEqkx5YcXjsc v6QUW9tbsw3H7zVfnRpA56bmQfMjd+ZDRkYC8lxkEHekg2hG7kRAa6rttreuOfcvGu1Qd8e3SdNz kuwZUORcxG+3rpbrWNx+UuMxdlLbltYVZ4X8c/yT/p1Qx+J4/k2CZ0XeWNboNzLYmw/UZaw7Wv7T UKz3eRtVrT3U5dVt8zexcpcmPuKLWNiDWbl/+aJ+/H+davYPH4nH44xsOPtQglgt2bU9dWJNUMv/ AM0T9+P86105Z2VnXdWTnxRvtGm20GteocyNpcWaNfxMjBfnbT8tT0ldmpUHFYcmFFN/ucig3V2S 35Tf8lXuKUDFL+MjsT/qnt/9GsogRbo+ixMya+SErf8AJW3hoY8SFG0YIu7962v5a8v9dN2c/wAF t+p6v7DW1R/N7voZmF/jY/m39lqt8q1o408yT9wt+mqmF/jY/m39lqfzEyxuWc+iJNzeNupP5Kic cF/G0Fanmr4VkhliCQYrqP72NmY/MhwP+eas8jIXixif11LH5+n/AE1kR83jZLx44ZzbSMMjKBYe ZFaWQwPHwP8A9nIY2PkHuR+XaKzuT9xLE1X/AGmtrWxvMWf/AHFzEkEPFNL07ayP9xZqpYvNSZAW SKVZIy1iQBrbqOlaPGMkmJ2yAdpIYHxDa/prPy44486RI1CKGWyqAB+FfKt3dvb47Vs0sKEc6JO/ JW1U3lyzQ5j/AAy/vj8zVhDLWV3xVciSIXCsDYX/AFl8xfrat3mP8Mv74/M1UJoA/FQZAHrx3Y3/ AKDuUcfLXd9lTmq7clo6Vk1w2VeOs9bQaHFwR4+BFHGxk03PIerOxu5P21T5qRt4VRcohYfM/wDo qfiZLxPGf1DcfI/+is7lsuKGaWeQnYjAaAsbiw6D41eS6fDXxhfIzx0a5reEv5k2Si4ueNvRRG/9 X0W/5lbNcrDy8GfNtVnaQLe7qV9IPmQPOumxn348bXuSoufjbWtcFk7XjE5Jz1arScxgkrK4f+9b 9z9IrVrK4f8AvW/c/SK3yf8Ak4/Oxjj/APHyeVRZk7vKhT0VkYf6oD/oqzyig4hY6lGUr8ydv5mq q0hXmGJ/aVR8mRR+mrfJEfSMD+sVA+YIP6Kwvs5vOxt/dw+VStuB4cj9lgD/AFwf01Pxf+FIP7R/ MKrJrw7N+0/9mQJ/0as8X/hj+8fzCnH99P8A1oX+y/8A7CvxUfZyXhHSNCtv3SBUXKKcjKMIGu2y keaqZR+UVJx8hfkJGHRkdj9rLaqz58GNmnIkdPUW2B2C9T1F/IVzle3VP7Xd/JHSH7lmvuVF82Xu M2TYskLepSTcf0WFqyt06wHH3XkD9sX6GUHtA/a1X+EkS5SNg0ZQWYG4O3Tw+dOCIeYYEC24Nb4h A1/vpG7j4/8Ads+ZJ28nJ/t3/IdyUSQ42OiaJGRGo+AXT+zVzBFsOEj9ZA39b1fpqDmEkbCLQoZJ Y2VkQeJPoP5Gq3FGIokiXoihR8gLV6FWOSz/ANKODtPHVeLH0UlFdDmLRSUUAtFJRQC0UlFALRSU tAFFFFAWqKKSoAooooAoopKAKWiihQopskkcSGSVgiL1ZiAB4dTQJYjI0QdTIgBZARuAPQkfGgHU 1jSk0xjQhT5XEfMw3ijYJMLPC56B11F/geh+Fc9B7kXC3Y+V/usyfjgmB0PmrDQg/CuqJqOSGGW3 dRXt03AG331zvxOzVqvbZYk605FVOtluq+hk+3MqLLGRLCGMXoVZCpVWI3X2362rIi9y8dhyMonC yL6HBRzYg6/q/Cuv0AsNB4CmiRGZlVgWSwYA3IJFxf7Ky+D01StDrOY7lXN6rN1lWjHkZ/CcxFyk crxOJFiIBYKV1I6eoCqudm40fOw4jPaeRo2RLHUX87W/VNbdNWRHBKMGsSpsb2I0I+ytvjbrWrtL Tme5lciVnZVhNRA+9ITSXpK6HM5/kZIF5NsJ3CyZLL208SHAUt/W3V0FRSrjKRPMEBWwEj2BFzYD cfialrFOPa7P/Jybvfcqr/FQc9xnI4c/LDFik3TRF96WYW2hlOpFutOfkMTJ5z6JJL5Cyi6Wb/qr M3qtbovnXQUhdFdUZgHe+xSdTbrYVj2Iqlu0tu0+ht80tvbrXbr9SDklBwJieiL3D/7P1/orM4fI weYwsvFik3oNu5gCpUtfaw3AagrcVugU4Ct245urTommu5ivJFHWNWmn2OSPJZHETdnkN2PKPSs4 UmGUeanUfMHpQnMQZ2aqY5bKnlZQwiUkAaDcxtYACutdEdSrqGU9QRcU1I44l2xIqL5KAB+SuX/H zCs9szB1/wCRj7VuiJM33Fm42HhJJkv20MoUGxOpVj+qD5U7jTFm8Mvba8U6yKGsRozMOhrRpK6+ 363edVtg5b/QqRo5k53guWxJs84qSfx9rB47MLFevUW0o4fkMTkeSJgk3tEGlfRgAT6P1h/SroHd EsXYLuIUXNrk6AfbS1ivDG1bp2OdDduadz2xuUamdz0kcGCMiVtsUDhnaxOhBQaC/iwpeDzYMzAW XHbfGrMu6xGoN+ht51oUlb2evfPSIMb/AEbI6zItYfAZuNk5E0cL7ngXbKLEWN7eIHlW3SPIkaF5 GCIurMxsAPiTS1JtW0/bP1FbxW1Y+6DI51ZcaRORRWeJV2ZGwXZQCWSQDyFzf/kqhJz38yMeLhEZ OQ/4FUEKP6ch8AK6empFFGSY0VC2rbQBc/G1Yvw7rNqzSt9y7m6822qTqm6/a+xRzliweGZWb+Hj om5yNSFK3Y2++sKP3JjNGcfEaSdmP91FGxYk+GqiutpaX4dzTVtuNuOwpy7U067s7s9zI46GbCws jPzQI5nQu0d7iOOMEqpI6nqTVbiMfiuYjkyniTKiUiNDInQj1NYOP6QrdeWJCFd1UkFgGIBIX8R1 8vGnKysoZSCpFwRqCDV9qs17UTx5k920W73az5GDFkYOBzacaloST/BhAIG1lvpYW/FepfrsUe4/ oy/+8NqEsena3dbW6Ctmins+P89+n0Hu+H8Nmv1M7muSTj4Y3kk7SyNt7ltLgXtfwvVvByPqsOLI FyJVDAkWuD0Nvj1qV0R12uoZT1Vhcflpa0qve7ThrQy7LaqxlPUWiiitmAooooAooooAooooAooo oAooooC1RRRUAUUUUAlLRRQBRRQTQGN7w/8A23nfur/bWsfi+XaDJ5LMyVMmRjY+PBNGDYtMjvBa /hua3310PN4L8lxeRgo4jaYAB21Aswbw+VZ+R7dWXJ5KVZe2vIrERYapLEdwf4+oA1yvW2+V2/c6 0tXZD7/sX+O5CXL78WREIMrFftzRq29dVDqytYaEN5Vm43uLIlKtPiiOKYT/AE8iybtzY5bcrLtF rhTar3G4U+MZ5sqRZcrLcSSsgKoNqhFVQSTYBaxuG43Jy8WKaWZOxCcsY8YUhg8skkbF2vqAL2sP Gq3f0rrn8+oSr6n5fl0J29yzrg4+U+PGjZY3wq8u0FVTe9yV0N9FHjercHM9/KRERVgOOmUzuxD7 HBIKJtIYLax18ajl4ef6PjlglQZXHIqK0ilo2GwRuCoIOvWnT8VkZGdjTTSxmDHRgVVCrsXTtuu7 dbYetrVV7nnp2+JHs8tf+hXbn80Y0GT9EBHmSpHiDuephIrspYbfT+Eff8KJOXlx3yAuJH9UJ8aC QK1t7zIh1fb+rusDToeHzkjxMeXISSDAmR4DtIcxosibXNyCfUOg8Kg5jCmhd8hJFDZediNFcEhS myMbhpfUXqPelOfp2KtjcY+vckk5nkJTixwxRxznKfGyY3ckBkQvZWCHQjW9qcvLsoMOHiIcmXKn hSMMEVuySXldgvU28utKOFy1SGVZozlrlNlysVPbJdTGVVQ1wAtra0HhcpLTY8yJlR5M+REzKWTb OTuRgCD0NPX4/Qejw+ox/cMzxxyYmMrh8V8thI+wqI2Cumitc+Fa+PMs8Ec6ghZUVwD1swvWVHwJ iRY45QVXCkxLsNS8rBy/yuKs8amfDK+LNtbFgihWBwCCWC7ZBr11F61V2n1dSWVY9PQyuUy86fG5 RJEQw4+RjpEFY7r9yFgNVA1v1vVyTn5YonSWGNMtMj6YKZbRXKd3cZGQWG34dadkcLkynORZUEOZ LFMt1O5WjMRIJvaxEdLkcHNJJNPFKiznJXKg3qWUWjERRxcXBF+lZi6ban8NlmjSTj8QWk5bHPED lmBWHtd4r1PT8PzvpWdkz8pJn8ZI+LHHlE5HbhMpK7TGpuzhLgi50tWtPg/Vca+FksCZYykjxjaL kdVXW1j0qCDjuQbIw8jNnjlfEMoJRCu5XRUF7lvVcXNWys4X+35zkzV1Uvz/ACwU391RLFiyiJQs 8STzK0gVlV37Voxb1kG58NBVg85kxZM+Pk4qxFMeXJhAkDMVi8JFA9O696jxeAysQYbwTRdyGEY0 /cQurIGLhk9QswuarTcJmYsc+VJPHKscGWrHYRI4lG/czbvxaAfIVmeTr+hqOPp+pYX3JJHjSy5m MIZFgjyIVEm5XSVu2t22jbZiL0sfuCSaOARxRmWWeTHYmQ9rdGL+iQIb7x+HQVXxODnzeO35c6l5 sWGLHMaWCKhEylgWO5t1r/KrWZxXI5uAmLLPAjM15mSIgAAgq0XruGFupqp8kTnTwDXHPx8SXjsv OyOQz45lQQY8gjj2sS34VbptHUNfr8KhHOTjNaJ8YDFXK+j74f1dxlVkum3oS1utWsTCnxs7MmLq 0GU4kC2O8MFVDre1vT5Vl4WDkZeflkyquJByJmaPad7SRpGV9V7bdR4eFV7lCzMsi2uXiIRInNSZ UMU0uGhhbKTHQs24iTumPeoK/qixB86mk5yRI8vKGODg4peNZS9meRDssF26KW0velThpV4/GxO4 u7HyhklrGxAmabb9xtTX4SdoszC76jByi8iLtPcjkc79G3WKhtelT1/Tw1L6Pr46DU5+SSGPtxRG Z8hsVj3T2d6rvG2UIb7xbbpWjnz5MEIfGhWZybHe4jRVsSXZiDoLVQy+L5LL436OWaAPI38VliIU LpZk9dw4IverPJ4M+XFAsMiqYZFkKygsjhQRZwCt7E7vmK0t0PXRRoR7ZWmrnUpD3DkSw40mLjKz ZEEs7K8m0L2SFYblVr/CqvO8vLmcTPHiwbo2xI8jIkZ7GMTaooFjuOlW8TgsiBIVeZH7MGRACFIv 3mDKep6WqHI9uZjYn0+PkRoJcWLFyt6lrmEWVksRa96w1yOr1yvDsaT401ph+Pc1c/P+ifGLqOxN J2pJCbbCVZlNvG5Fqzf+Jyv0xkhVO8kcsqmSzKk79uPYu31n9ZvKtLlcBOSwJcNjt7lir+IKkMD+ SoJuLmXkI8vEeONO2sM0ciF/Qh3KU1Fm1Irdt84eDFdkZ1Kzc/lCLMyVxQcbBleKR953HZIEYqu3 wT1fkrQ4/P8ArvqHVQIoZmhjcG+/YBub+tcVVkx047iuRbIIkjkbInYdPTKWbZ+W1T8Hh/Q8Ri4x FmWMFx/Tb1t+U0ru3JN9JZbbdraXWEY8vJyZebjZsmMoxRj5jY4ZtxlRQl967fTe3x61pYnKl5oo FhSGFcaPIe7EEIyk/wANAliqkWOoqrH7ey02RHIjbGx4ciDHXaQ4WcC283IO3pVgcNO8+EZZUMGH F29qqRIxMfaZd+78B69KzVX17tToVumnZPuRtz2YuJFmNhgRZUsaYq9y7usu7aWG30nQffTv5+yc hHgzRIr7o4prSXYSyqXGxdo3INLn40RcPnLBjYsuQkkOFNE+OdpD9uLcNrm5BNiBoKsfy6ePlZMy GSMQ5Gwzo6bn3RjaDG1xa4ter68a9J0+JPRnTrGvwM5vc0k+HmyYyRiSKA5GOd+70Bin8QBfSwtf b8etbmI07Y0bZAUSlQWCEsv2EhfzVlw8HkR8dk8aZozjvG8WMwQh1D3I7jbvVt6aVexIuQR1ORLG 0QiC9uNSP4gJ9W4km22lN0+qdBbbHpjUt0UUV0OYUUUUAUUUUAUUUUAUUUUAtFJRQFuiiioAoooo UKKKaTQgpNNJpC1NJoUCaaTRekvQAajiiigjEcKCNASQqiwuxLH7yaeaSqQDSUUUAUyWGKUKJUDh GDrcXsym6sPiKfRQBRSUtAFLRRQCgUoFAFOAoBCVVSzEKqi5J0AFEU0UyCSF1kQ9HQhgbfEVW5fF ky+Nnx4j/EZbqPMqQ237bWqrDy0ZixjjxKqTRTOydNrxBbrYfE10rx7qSsuWo7JKfrky7Q4ekGqT UciJIjRuAyOCrKehB0IrKk5nLCpJHAjoMWPLmuxBCtfcq6G9reNOk5eZcmS0StiQvEjybiHtMqlW 22toWq/8fk7L5r8dSe5Uvxy4qhIYnQAExoikdUGqAf0bdKkrHwsgRTCMord3MyhvPVdu9rj7qIuf MsE8oRCY0WVQjbrI7bT3LDQr1Iqv+vefSpSj6uEFyLq/xqbFMjhiiLmNAhlbe9hbcxAG4/Gwpncn +l7ioskxW6qrekk9LMR0rOHMziEkxI8y5C45EbXRiwuCrW+ysV4rWmEnDjU07pa9TWprSxq6ozAP JfYpIBawubDxtWcvLuM5MOVYw24RPte7bym/cqkA7PC9Ozv/ADXjf3pv+7Na9myaVsTW118E2Teo ld1X6lxsnHXfulRe3YSXYDaW/Du8r30pXnhRiryKrKpcgkAhB1b5DzrA5MBl5lT0L4o/sVH28tcj MOYbynj5lH7sZEYP+tbd9tda/wBarqnujTHnWtv1MPlacR+Ja/Q335DAjO18mJCQCAzqDYi4Op8a cMzEM3YE8fevbtbhuv8Au3vWUYomyOG3Ip3I264GtodL0/ji38yzAMfevfN8i6+j0DSx9X3Vl8NV VuXirtql/Lb+hVdzGNY+kmnFlY05IhlSUr+IIwa3ztT0dHUOjBlPRgbiuew0SLE4vJRQJmyXiZgN SjtLcHz6Vocej4fBgah4kkYX63uzU5OFVmLT6tiT82n+QryN6rpP5FqeXj5o5Yp5InjS3eRmWw10 366a+dTNJGrqjMFd77FJALWFzYeNqw8nHhj9sdxUAkeCMs9huJcq7XPzq5yDbeT45utjObf+yNT2 azhvXkX/AOdZLvfX/S//AJOC99VjBnQypuiG6RdwuoHiwvpSpNDISsbq5ADEKQTZvwnTzrIx4Yv+ HZJyoM0mPM7yWG4lwxa561J7ds+PLMf7xnVGHksaKqD7taW4aqt7Jv0W2fEiu26qPuUmkcnHAYmV AEYI5LDRj0U/HWkOZiCbsGePvXt29y7r/u3vXP5Urg50QiYo2ZGTKLbQbpodb1ewi383zQMfuL3V vNdfR6B4H1fdWn/XSq7N/wAd2q/0/uRcjbiOsfn+xpx5GPKzLFKkjIbOqsCQfjbpSQ5mJOxWCeOV gLkI6sbfYaweJs3LAbe2UbJO8/8AW3cDaP3etXPbZb6CK+P21Cm0919fqPl6vvpycCorOW429l90 /PQteR2aUaz9I/c2KKSivMdBaKSigFopKKAWikooBaL0lFALeikooC5RRRUAUUUhNAITTCaVjTCa FAmkpKQmqBb0hNITSUILSUUUAUUUUAUlLRQBRRS0AU4CkApwFAAFOooNAR5CzNEywOIpdNrsu4aG +ouOvSsv+SSqiGPIAnvM0rlLqe/bftUMLWtpWsTSVunLaiirS+C8jLqnqYTcfM2YMFJgirgxQzNt uWQM6tt10Jp6YT5HI5kQkCYySwGSLbctsjRlAa+guNa2O3H3DJtHcI2l7DdYa2v5UgjjVmdVCs9i 7AWJIFhc+OldP+RbP+2NFrKbf0J7a+v0KMfFlJo5DICEnmmK26iYMNvXw3UsGBl4+K+MmQrIoCwb o72UG+1/V6tNKv0Vh8t3q09NUujn9S7KlEccV4r+XrKQdmzu2+3pfp4W8qhj4mZW3PMhvPHkWVNo GxdpUeo6dLVp0UXNdTn7m28LVjZXGNMFRMOaLNknilCwzENLEVuSwXbdWvpfS9NzsOeebHnx5Fjk xy5G9SwO9dvgRVyiouS0q2JS26LSIz8C7VEeMmXLxE00eWJJl7mWYSWCkAGLbfS/jtqbL45sieWU OF7mK+Na17FzfdV6ite9fGdPDwS/RE2V7fj8MpfQHuYL7/8ABKykW/FdO39lJj4WVBlzSrKhgnkM jxlDu6W0bd8PKr1FT3bQ13W3TpM/mNq+s/oZmFxEsBh784ljxi7Qxqu0bnJJZjc3tu0q7BFKMcRZ LidyCHfaFBBJ/VHwqail+S13Nn9EvxqFVLQym4jJbBkwDkgwFdkIKepQGDDcb62taplwst8nGyMm ZHbGZyAiFbh02W1Y1foqvmu50zP8V/JQ/mNlfy69tDNTi548ebDScfSukiRIU9S9y/Vr6hb1LhYD YkrOr3R441dbfrxjbuHzFXaKj5btNN/drhZCpVR4aGbLxLOmQncA+onWcG3Tbt06/wBGpIsLKhzp p45U7M7hnjKEtooXRt36KvUU968NSmmo0Xh+w2V1M2LiWjeGQSjfDPJNe3VZb7k61JxeFlYUK48k ySQxghAqFWuTfU7jV6kpbmvZNNpp+C8f3CpVOULRSUtczQUUlFALRSUUAtFJRQC0UlFALRSUUBdo vSE00moBxNNJpC1MJoUUmmGlJppqkC9JeikoAootS2oBKKW1FqASiltSUAUUUtAFKKAKUUAoFOAp AKWgCkJoJppoAoopKAKKKKAKSiigCkoooApKWkqgKKWkoAopaKASilpKAKKWigEopaKASilpKAKW kooAopaSgCilpKAKKWigCiiigEopaKAKKKKgLJvTDeiioUQ3pKKKASmmiiqQKNKKKAWw86LDzooo BbDzo+2iigEpNKKKAKWiigAU4UUUA6kN6KKASkoooBKKKKAKSiigCkoooAo0oooBdKTSiigF0o0o ooA0o0oooA0o0oooA0o0oooA0o0oooA0pNKKKANKXSiigDSjSiigDSjSiigDSjSiigDSjSiigDTz osPOiigDTzooooD/2Q== --%OLATTACH1-- From RQODFWU@hotmail.com Sun Feb 27 01:37:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04659; Sun, 27 Feb 2005 01:37:01 -0500 (EST) Received: from [61.75.138.102] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D5I3V-0002hi-MZ; Sun, 27 Feb 2005 01:37:31 -0500 Received: from anumail7.anu.edu.au ([142.203.5.79] helo=anu.edu.au) by smtp2.sepck.nl with esmtp ( 3.35 #1 ()) id 1A5nEM-0008Er-00 Date: Sun, 27 Feb 2005 10:29:53 +0400 Message-ID: From: "Arthur Stovall" To: simple@ietf.org Subject: Woww..8o-% 0ff Simple X-Spam-Score: 3.3 (+++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 This Months speciial: Vi-codinn - 199.00 Valiuum - 169.00 Viagraa - 199.00 Cia-llis - 269.00 Codeinne - 219.00 Xa-naax - 179.00 All orderrs are delivered by UPS with full tracking 24/7. Satisfactiionnss guaaranteeed... http://www.ilovemeds.com/index.php?aid=8 This is 1 -time mailing. N0-re m0val are re'qui-red jbH8BMbSGBcTptwxbGrur0JPNwaMQwqcFDYmBkLl2Ywqjq2CEVkv5jl0uWZJDJPO From Ahmed@gedris.org Sun Feb 27 14:56:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28141; Sun, 27 Feb 2005 14:56:47 -0500 (EST) Received: from spr1-stkp1-3-0-cust228.bagu.broadband.ntl.com ([80.5.18.228] helo=entireweb.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D5UXc-0004Xu-Kh; Sun, 27 Feb 2005 14:57:26 -0500 From: "Laalaoui Musty" To: "Hill Curtis" Subject: Amazing job offer for peoples who want have money in pocket Date: Sun, 27 Feb 2005 13:53:11 -0100 Message-ID: <4b7301c51d05$0c91b400$e4120550@entireweb.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Score: 6.4 (++++++) X-Spam-Flag: YES X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Do you want to find good, highly paid (a provisional or a constant) work? Wherever you would be, we can find for you the best offers of work. We offer employers for the companies worldwide. Send the contact information or curriculum vitaeon e-mail: manager@job-softservice.biz Shortly you will receive offers about work. No payments. Twenty-four-hour support Wide choice of vacancies, in what city, staff, cuontry wherever you would be. shadow: Our managers will help to pick up the best offers of work exactly for you From Dugan@yebox.com Sun Feb 27 21:55:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00161; Sun, 27 Feb 2005 21:55:25 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5b4p-0003Eq-M4; Sun, 27 Feb 2005 21:56:08 -0500 Received: from [83.168.48.158] (helo=netrun-48-158.cytanet.com.cy) by mx2.foretec.com with smtp (Exim 4.24) id 1D5b40-0002Bn-Rn; Sun, 27 Feb 2005 21:55:20 -0500 Received: from [1.67.40.64] by abutting%DIGITS.spencerian.83.168.48.158 via HTTP; Sun, 27 Feb 2005 18:58:13 -0800 Reply-To: "fastmail.fm" From: "fastmail.fm" To: Subject: There it is as promised Date: Sun, 27 Feb 2005 18:58:13 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9908508165ogyz9521" Message-Id: X-Spam-Score: 4.3 (++++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 ----9908508165ogyz9521 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable Here buddy password for that adult megasite. Username:Delgado24vc Password:qoa699qc %SITE: http://www.charmingnaughtyteens.com/d/h/1.php ----9908508165ogyz9521-- From Tran@hurting.com Sun Feb 27 23:10:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06200; Sun, 27 Feb 2005 23:10:22 -0500 (EST) Message-Id: <200502280410.XAA06200@ietf.org> Received: from 210.red-213-37-174.user.auna.net ([213.37.174.210]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D5cFH-0004UL-0A; Sun, 27 Feb 2005 23:11:06 -0500 Received: from [137.128.28.236] by complimentary%DIGITS.baptiste.218.80.161.108 via HTTP; Sun, 27 Feb 2005 20:05:29 -0800 Reply-To: "hush.com" From: "hush.com" To: Subject: Xrated membership Date: Sun, 27 Feb 2005 20:05:29 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--1813609083kyry3912" X-Spam-Score: 7.8 (+++++++) X-Spam-Flag: YES X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 ----1813609083kyry3912 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable Dear male :: mip6-web-archive@ietf.org:: .................... Obtain your access, to the biggest and badest adult website! (20 niches in1site) .................... * It doesn't cost a thing http://www.charmingnaughtyteens.com/d/r/1.php ----1813609083kyry3912-- From Gotzone@kcds.com Sun Feb 27 23:18:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06783 for ; Sun, 27 Feb 2005 23:18:16 -0500 (EST) Message-Id: <200502280418.XAA06783@ietf.org> Received: from 81-203-249-123.user.ono.com ([81.203.249.123] helo=kcds.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D5cMz-0004cT-0L for simple-archive@ietf.org; Sun, 27 Feb 2005 23:19:01 -0500 From: "Jill Smalley" To: "Fionn Champagne" Subject: CGF Pharmaaccy Date: Sun, 27 Feb 2005 23:13:49 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_00283BAB.50489972" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 3.8 (+++) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 This is a multi-part message in MIME format. ------=_NextPart_000_0012_00283BAB.50489972 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, district attorney to word this one act in such a way that it would lie against them. constructive and purchasing power of ten and a dozen times as muc The banking house of Jay Cooke & Co., in spite of its tremendous money so obtained used to take up the long-outstanding warrants my creditors, and notify the secretary of the exchange. I want buying and selling must be, and always was, incidental to the Fortunately for his own hopefulness of mind, he failed fully to Have a nice day. ------=_NextPart_000_0012_00283BAB.50489972 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hello, Visit our Amazing=20 Online SH0P!
 
NOW SPEC  OFF  Cia ls) Vi ra $200(120 = pil itra $300(50 = pil
IAL ER: lis $300(150 pil ag ls) Lev ls)
And MANY OTHER.
 
With each purchase you = get:
  • Home delivery
  • Total confidentiality
  • FDAApproved
  • Highest Quality
    •  
    Have a nice = day.
    ------=_NextPart_000_0012_00283BAB.50489972-- From simple-bounces@ietf.org Mon Feb 28 00:06:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10251; Mon, 28 Feb 2005 00:06:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5d7o-0005XP-Pw; Mon, 28 Feb 2005 00:07:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5d6l-0005Nw-9j; Mon, 28 Feb 2005 00:06:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5d6i-0005Nf-Kv for simple@megatron.ietf.org; Mon, 28 Feb 2005 00:06:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10227 for ; Mon, 28 Feb 2005 00:06:10 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5d7O-0005Wx-Pf for simple@ietf.org; Mon, 28 Feb 2005 00:06:55 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 27 Feb 2005 21:18:23 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1S55tq8014031; Sun, 27 Feb 2005 21:05:56 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-69.cisco.com [10.86.242.69]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIB57895; Sun, 27 Feb 2005 21:05:59 -0800 (PST) Message-ID: <4222A6B7.6080108@cisco.com> Date: Mon, 28 Feb 2005 00:05:59 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Anders Lindgren C (HF/EAB)" References: <2DC267ED40568D4F9AA4F5DF955AF16A115A29@esealmw107.eemea.ericsson.se> In-Reply-To: <2DC267ED40568D4F9AA4F5DF955AF16A115A29@esealmw107.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: [Simple] Re: draft-ietf-simple-xcap-package-03 How to indicate that a document is deleted or a new document is added during a subscription X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit The solution proposed below didn't make it into the xcap-diff-00 draft. I have already marked it for inclusion in the -01. -Jonathan R. Anders Lindgren C (HF/EAB) wrote: > Your solution seams reasonable. > I have also noticed that draft-ietf-simple-xcap-package-03 has been replaced by draft-ietf-simple-xcap-diff-00. I assume that my comment and your solution is also valid for that draft. > > Thanks > Anders > > > ----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: den 19 februari 2005 16:04 > To: Anders Lindgren C (HF/EAB) > Cc: simple@ietf.org > Subject: Re: draft-ietf-simple-xcap-package-03 How to indicate that a > document is deleted or a new document is added during a subscription > > > I was just now combing through the archives in the process of updating > the data model, and noticed this mail that I never responded to. My > apologies. Answers inline. > > Anders Lindgren C (HF/EAB) wrote: > > >>Hello all; In the draft draft-ietf-simple-xcap-package-03 I find it >>hard to see if and how it is possible to indicate that: >> >>1) A document has been added to a watched user's tree during the >>duration of the subscription. > > > This is a gap in the specification. Good catch! Thanks for finding it. > > I would propose the following solution. > > The element have an attribute called state, which can have a > value of "existing" or "deleted". When a document is added, an xcap-diff > would get sent with a value of "existing" and the patch elements > would basically contain the entire document. > > Modifications to the document would result in elements with > either no state attribute, else state with a value of "existing" (that > is, the default is existing). If the document is deleted, the > element would have a state of deleted, and there would be no patch > operations. > > It would be an error to send an xcap-diff with a state="deleted"> with patch operations. > > The recipient of xcap-diff knows a doc is added if the diff has a > element with a document locator that it doesnt know about. I > prefer this approach to having an explicit "added" state, as it reduces > the number of error cases. > > Does this seem reasonable? > > >>2) A document has been deleted from a watched user's tree during the >>duration of the subscription. > > > See above. > > >>Is a "deteted document" and an "added document" element missing or >> >>is it that every Notify also SHALL contain every unchanged existing >>documents with New Etag=previous Etag and that the Subscriber can at >>every Notify shall check the last received Notify to see if the >>document baseline has been changed. A Notify will also be send as >>soon as a document has been added deleted with all existing or >> >>does the draft contain a solution that I have missed? > > > It would be wasteful to have to send a for every document > covered by the subscription, just to figure out when something is > deleted. The problem you outline is a gap in the spec. > > Thanks, > Jonathan R. > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From service@paypal.com Mon Feb 28 08:06:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17235 for ; Mon, 28 Feb 2005 08:06:50 -0500 (EST) Received: from [216.117.150.44] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D5kcc-0006gC-5q for simple-archive@ietf.org; Mon, 28 Feb 2005 08:07:38 -0500 Received: from i1v.qvued5x.net [69.205.192.126] by 132.151.6.1 with SMTP for ; Mon, 28 Feb 2005 07:00:07 -0600 Message-ID: From: "PayPal" To: Subject: PayPal Account Security Measures Date: Mon, 28 Feb 05 07:00:07 GMT X-Mailer: MIME-tools 5.503 (Entity 5.501) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="B_A_._F._4" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Score: 21.5 (+++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 This is a multi-part message in MIME format. --B_A_._F._4 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
    3D"PayPal"
    Dear PayPal Member,

    Your account has been randomly flagged in our system as a part of our rout= ine security measures. This is a must to ensure that only you have access and use of your PayPal = account and to ensure a safe PayPal experience. We require all flagged acc= ounts to verify their information on file with us. To verify your Informat= ion at this time, please visit our secure server webform by clicking the h= yperlink below

    Click here to verify = your Information



    Thank you for using PayPal!
    The PayPal Team
    Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

    To receive email notifications in plain text instead of HTML, update your preferences here.

    PayPal Email ID PP478
    --B_A_._F._4-- From simple-bounces@ietf.org Mon Feb 28 10:10:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28321; Mon, 28 Feb 2005 10:10:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5mYV-0000cN-NF; Mon, 28 Feb 2005 10:11:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5mTB-0002ke-7L; Mon, 28 Feb 2005 10:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5mT9-0002kR-OY; Mon, 28 Feb 2005 10:05:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27650; Mon, 28 Feb 2005 10:05:58 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5mTu-0000X5-WB; Mon, 28 Feb 2005 10:06:47 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 28 Feb 2005 07:09:10 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,123,1107763200"; d="scan'208"; a="164034418:sNHT22209260" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1SF5iuC001114; Mon, 28 Feb 2005 07:05:44 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-50.cisco.com [10.86.240.50]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APK99850; Mon, 28 Feb 2005 10:05:45 -0500 (EST) Message-ID: <42233349.3020206@cisco.com> Date: Mon, 28 Feb 2005 10:05:45 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Geopriv] Re: [Simple] presence authorization issue: anonymous, authenticated, etc. References: <42146290.5090209@cisco.com> <4214ADD0.3070101@cs.columbia.edu> <4214B803.7070304@cisco.com> <4214FDA3.3060701@cisco.com> <421B01D4.3050507@nokia.com> <421BF247.5090903@cisco.com> <421C3B30.8050104@nokia.com> <421DFEEF.4070107@cs.columbia.edu> <421F0DAD.20907@nokia.com> <421F29E8.2010104@cs.columbia.edu> <421F3406.8020106@nokia.com> <421F6AB1.7040107@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Aki Niemi , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > > Aki Niemi wrote: > >> Exactly, but this is a limitation already inherent in the common >> policy domain wildcard conditions. I think in the general case >> determining this and being able to discriminate against "weak" domains >> will be hard for the average-joe. > > Agreed; this also seems much better handled in a general spam control > policy, which can take multiple factors, such as domain policies, into > account. I suspect that in many such cases, these policies, like today > for email, will be on an organization-wide basis, rather than individual > policy rules. It seems to me that there are a whole range of cases here. Lumping them all into the general category of SPAM is useful in some cases, but isn't helpful all the time. General mechanisms, managed by the organization, may be helpful for dealing with malicious spammers. But they aren't so helpful for dealing with "pests". Yet pests can be a significant problem. >> But then again maybe not that hard, since I think people already today >> have a pretty good idea about these policies in email accounts. >> Everyone knows that a username in gmail.com is in relative short >> supply compared to some other free email providers. Corporate email >> accounts usually have much tighter policies. > > > But see my example: We have very tight policies on handing on UNI > (university network IDs), but still an infinite supply of personal > email-style identifiers. I doubt that the outside world knows this (or > cares). People can be very resourceful. It won't take long for somebody to begin to discern the pattern of addresses you use. (e.g. hgs+*@cs.columbia.edu) I think there will continue to be a demand for flexible techniques to denote specific classes of addresses based on patterns in the address. >> Apologies if I missed this before. It is sort of obvious, must admit. >> >> There is one catch to this, however. I think such a condition should >> only ever be applied to something like a "confirm" permission. It >> would not work well with an "allow", quite naturally. That would be >> shooting oneself in the leg, like Jonathan was worried would happen. >> But this should be relatively easy to capture in specification writing. >> > > I'm not so sure. If things are defined as follows: > > - No rule => denied subscription; no access to any data > > - Bad apples list => polite block or deny > > - No positive identity ("anybody except"), with exceptions => the world > except the bad domains/names get the base level access and maybe > 'confirm', with the caveat that name-level exceptions are likely to be a > very crude and "leaky" privacy screen Yes. Its the bad apples list where you want a lot of flexibility in description. Note that I may not have to fully understand the domain name assignment policy to describe a matching algorithm sufficient for my needs. I may decide to simply exclude hgs*@cs.columbia.edu. This may overreach and exclude some I didn't intend to exclude, but that may still be ok, because I will never have need to correspond with them anyway. > A related question that we have never addressed is the following use case: > > "Random strangers can subscribe to my basic, public presence information > without confirmation, but I need to confirm subscriptions to more > detailed information" > > I think the best solution is to declare two different presentity names > for that. I agree it is a problem that we haven't dealt with. But I am not sure that two distinct presentity names is the right solution. Then I need to manange two names, and ensure that the right name gets in the hands of each person. It is also a problem when using phone numbers as identities. We've been struggling with how to use presence as an enabler for telephony when phone numbers are in use, and it is a problem because of this. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 28 10:11:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28612; Mon, 28 Feb 2005 10:11:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5mZc-0000eT-78; Mon, 28 Feb 2005 10:12:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5mUU-0002yJ-7J; Mon, 28 Feb 2005 10:07:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5mUR-0002xW-Ub for simple@megatron.ietf.org; Mon, 28 Feb 2005 10:07:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27866 for ; Mon, 28 Feb 2005 10:07:18 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5mVD-0000Yq-Av for simple@ietf.org; Mon, 28 Feb 2005 10:08:07 -0500 Received: from [192.168.0.106] (c-24-1-68-89.client.comcast.net [24.1.68.89]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j1SF7GTs049070 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 28 Feb 2005 09:07:18 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <49fee16c0c3b5106efbc40fd28d2fa3a@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Simple WG From: Robert Sparks Date: Mon, 28 Feb 2005 09:07:19 -0600 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Simple] SIMPLE testing at SIPIT X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit SIPIT 16 will take place in Banff during the first week of April. The registration deadline is looming (details are available at http://www.sipit.net). We test SIMPLE implementations at the SIPITs as well as the SIMPLEts. If you're bringing an implementation of XCAP, event-lists, MSRP, or making non-trivial use of RPID/cipid/future, please drop me a note. I'll set aside one of the multiparty test sessions if we have sufficient density on any of the above. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 28 11:10:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04547; Mon, 28 Feb 2005 11:10:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5nUT-0001yk-Rs; Mon, 28 Feb 2005 11:11:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5nSQ-0004zG-6g; Mon, 28 Feb 2005 11:09:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5nSM-0004z8-EQ for simple@megatron.ietf.org; Mon, 28 Feb 2005 11:09:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04452 for ; Mon, 28 Feb 2005 11:09:11 -0500 (EST) From: eric.slabbinck@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5nT7-0001wp-D0 for simple@ietf.org; Mon, 28 Feb 2005 11:10:02 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j1SG869C025354 for ; Mon, 28 Feb 2005 17:09:07 +0100 To: simple@ietf.org Subject: [SIMPLE] Mechanism for sending service-state notifications to a handset MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: Date: Mon, 28 Feb 2005 17:09:00 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 02/28/2005 17:09:07, Serialize complete at 02/28/2005 17:09:07 X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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="===============1652855122==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a This is a multipart message in MIME format. --===============1652855122== Content-Type: multipart/alternative; boundary="=_alternative 0058B714C1256FB6_=" This is a multipart message in MIME format. --=_alternative 0058B714C1256FB6_= Content-Type: text/plain; charset="US-ASCII" Hi, In TDM-networks, the service offering includes "supplementary services", such as call forwarding (on busy, no reply, unconditional, ...), CLIP/CLIR, call barring, etc. When call forwarding (CF) is activated, a user typically is notified of this situation when he lifts the hook, either by a stutter tone or by an announcement that informs him/her of the condition. As one possible use of SIP telephony is to replace a TDM-network, this CF notification should also be implemented in a SIP network. It will be impossible to implement this in the same way as in a TDM network, since in a TDM network, the switch is aware of the activation of the call forwarding service and the switch detects when a phone is off-hook, and thus can play the stutter dial-tone or the notification. In a SIP network, the softswitch is aware of the activation of the call forwarding, but the off-hook condition is typically not detected by the softswitch, but by the handset. But the handset may not be aware of the activation of the call forwarding condition. Two solutions seem evident: the handset notifies the softswitch of the off-hook condition, so the softswitch can play the notification or the stutter dial-tone the softswitch notifies the handset of the status of services, so the handset can show indicators or play notifications or tones The first solution could give rise to a lot of traffic (every off-hook condition is sent to the softswitch) and a number of complications may pop-up (e.g. if the notification/tone are played via an INVITE-dialog, special rules are valid, since a user can begin dialling another number, etc). The notification of "Message Waiting Indication" can be considered as a precedent for the second solution, so it seems evident to suggest the elaboration of a SIP event package for service-state-change, combined with a (XML-)document structure for the description of services. KR Eric Slabbinck Systems & Network Architecture Alcatel FSD/EA - IL23 Tel.: +32 3 240 4986 (Alcanet 605 4986) --=_alternative 0058B714C1256FB6_= Content-Type: text/html; charset="US-ASCII"
    Hi,

    In TDM-networks, the service offering includes "supplementary services", such as call forwarding (on busy, no reply, unconditional, ...), CLIP/CLIR, call barring, etc.  When call forwarding (CF) is activated, a user typically is notified of this situation when he lifts the hook, either by a stutter tone or by an announcement that informs him/her of the condition.

    As one possible use of SIP telephony is to replace a TDM-network, this CF notification should also be implemented in a SIP network.  It will be impossible to implement this in the same way as in a TDM network, since in a TDM network, the switch is aware of the activation of the call forwarding service and the switch detects when a phone is off-hook, and thus can play the stutter dial-tone or the notification.  In a SIP network, the softswitch is aware of the activation of the call forwarding, but the off-hook condition is typically not detected by the softswitch, but by the handset.  But the handset may not be aware of the activation of the call forwarding condition.
    Two solutions seem evident:
    1. the handset notifies the softswitch of the off-hook condition, so the softswitch can play the notification or the stutter dial-tone
    2. the softswitch notifies the handset of the status of services, so the handset can show indicators or play notifications or tones

    The first solution could give rise to a lot of traffic (every off-hook condition is sent to the softswitch) and a number of complications may pop-up (e.g. if the notification/tone are played via an INVITE-dialog, special rules are valid, since a user can begin dialling another number, etc).
    The notification of "Message Waiting Indication" can be considered as a precedent for the second solution, so it seems evident to suggest the elaboration of a SIP event package for service-state-change, combined with a (XML-)document structure for the description of services.

    KR
    Eric Slabbinck
    Systems & Network Architecture
    Alcatel FSD/EA - IL23
    Tel.: +32 3 240 4986 (Alcanet 605 4986)     --=_alternative 0058B714C1256FB6_=-- --===============1652855122== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1652855122==-- From simple-bounces@ietf.org Mon Feb 28 11:55:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08895; Mon, 28 Feb 2005 11:55:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5oCP-00031L-Ju; Mon, 28 Feb 2005 11:56:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5o9e-0000eY-8E; Mon, 28 Feb 2005 11:53:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5o9c-0000eQ-NO for simple@megatron.ietf.org; Mon, 28 Feb 2005 11:53:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08721 for ; Mon, 28 Feb 2005 11:53:54 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5oAP-0002yT-Bm for simple@ietf.org; Mon, 28 Feb 2005 11:54:45 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 28 Feb 2005 12:08:28 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,123,1107752400"; d="scan'208"; a="38695475:sNHT21506328" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1SGrghF000721; Mon, 28 Feb 2005 11:53:42 -0500 (EST) Received: from cisco.com ([161.44.79.169]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APL10620; Mon, 28 Feb 2005 11:53:40 -0500 (EST) Message-ID: <42234C95.1030605@cisco.com> Date: Mon, 28 Feb 2005 11:53:41 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: eric.slabbinck@alcatel.be Subject: Re: [SIMPLE] Mechanism for sending service-state notifications to a handset References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Eric, I don't see the relevance of this question to SIMPLE. This should probably be discussed on the sip-implementors list. So if you want to discuss further, please take it there. A brief comment - you seem to be assuming a softswitch environment. But the feature you describe isn't limited to such an environment. Nor does IETF characterize and standardize features like this specifically. If I try to characterize what you are talking about in more general terms, it is that you want certain aspects of configurable behavior to be reported in the user interface of a UA. And you want this to be the case even if the configured state resides somewhere in the network rather than in the UA itself. I would be inclined to hook such behavior to the config package. Either deliver information about the state directly in the config package, or else use the config package to inform the UA that it should subscribe to some other event package to get that information. Then have the UA adjust its user interface to report that state. In the case you cite, it could alter the dial tone it plays. (In general sip UAs that play a dial tone generate it themselves rather than receiving it in realtime.) Paul eric.slabbinck@alcatel.be wrote: > > Hi, > > In TDM-networks, the service offering includes "supplementary services", > such as call forwarding (on busy, no reply, unconditional, ...), > CLIP/CLIR, call barring, etc. When call forwarding (CF) is activated, a > user typically is notified of this situation when he lifts the hook, > either by a stutter tone or by an announcement that informs him/her of > the condition. > > As one possible use of SIP telephony is to replace a TDM-network, this > CF notification should also be implemented in a SIP network. It will be > impossible to implement this in the same way as in a TDM network, since > in a TDM network, the switch is aware of the activation of the call > forwarding service and the switch detects when a phone is off-hook, and > thus can play the stutter dial-tone or the notification. In a SIP > network, the softswitch is aware of the activation of the call > forwarding, but the off-hook condition is typically not detected by the > softswitch, but by the handset. But the handset may not be aware of the > activation of the call forwarding condition. > Two solutions seem evident: > > 1. the handset notifies the softswitch of the off-hook condition, so > the softswitch can play the notification or the stutter dial-tone > 2. the softswitch notifies the handset of the status of services, so > the handset can show indicators or play notifications or tones > > > The first solution could give rise to a lot of traffic (every off-hook > condition is sent to the softswitch) and a number of complications may > pop-up (e.g. if the notification/tone are played via an INVITE-dialog, > special rules are valid, since a user can begin dialling another number, > etc). > The notification of "Message Waiting Indication" can be considered as a > precedent for the second solution, so it seems evident to suggest the > elaboration of a SIP event package for service-state-change, combined > with a (XML-)document structure for the description of services. > > KR > Eric Slabbinck > Systems & Network Architecture > Alcatel FSD/EA - IL23 > Tel.: +32 3 240 4986 (Alcanet 605 4986) > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Feb 28 14:08:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23297; Mon, 28 Feb 2005 14:08:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5qGM-0006KT-7d; Mon, 28 Feb 2005 14:09:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5qFU-0005Mj-L3; Mon, 28 Feb 2005 14:08:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5qFT-0005MD-Fa for simple@megatron.ietf.org; Mon, 28 Feb 2005 14:08:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23261 for ; Mon, 28 Feb 2005 14:08:06 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5qGG-0006Jx-Ps for simple@ietf.org; Mon, 28 Feb 2005 14:08:57 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j1SJ6tSg004815; Mon, 28 Feb 2005 13:06:55 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j1SJ6sA22068; Mon, 28 Feb 2005 13:06:54 -0600 (CST) Message-ID: <42236BCF.4000308@lucent.com> Date: Mon, 28 Feb 2005 13:06:55 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] updated presence data model References: <8CA1128D59AD27429985B397118CEDDF04D19F2F@nj7460avexu1.global.avaya.com> <421D64E0.5030800@cisco.com> In-Reply-To: <421D64E0.5030800@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit [Resending because I don't see it on the list archives and nobody flamed me for it ;-). Not sure if it made it out or not] Jonathan Rosenberg wrote: > I've submitted an update to the presence data model. Until it appears > in the archives, you can pick up a copy at: > > http://www.jdrosen.net/papers/draft-ietf-simple-presence-data- > model-02.txt [...] Jonathan: This is excellent work and I think light years ahed of its predecessor (-00) in terms of specifying the model. Some comments follow. 1) In Section 2, it is stated that a Presentity URI is "a URI that acts as a unique identifier for a presentity..." However, this seems to contradict Section 3.1: "For each unique presentity in the network, there is one or more presentity URIs." The model implicitly assumes the latter anyway (see discussion in Section 3.1). 2) Should we mandate that _SIP_-based presence systems have their presentity URIs (i.e., the URI that appears in the entity parameter of the attribute) be sip URIs instead of pres URIs? What happens if a SIP-based PS is sent a document with a pres URI? How will it co-relate it with an existing user in the presence system? Section 3.1 does a good job of covering the case where the presentity URI is sip-based, but what if it is a pres URI? 3) In Section 3.2, a reference to rpid appears appropriate. 4) In Section 3.3.2, is prescaps one form of reach information? If so, maybe a reference to it would help. 5) In Section 3.3.4, the last phrase of the first paragraph appears to be too optimistic ("...and reach the desired target"). We have already taken pains to point out earlier that the system cannot authoratatively ensure that a session will be established with the desired target. A quick fix is to align that phrase by adding a "may," as in, "...and may reach the desired target." 6) Section 3.3.4, second paragraph -- I think we are skating on thin ice here. In my reading of the model, this paragraph appears to contradict the sixth paragraph of Section 3.3.2 ("Because the reach ... for a single service."). Here's why: In the paragraph of Section 3.3.2, we take pains to explain that it is not possible to describe a softphone that does audio and video as two services; it must be described as one service. However, in Section 3.3.4, we have a softphone that offers two services -- audio and IM -- and can select which of these services can be reached by deducing the status of one service from the other. Why can't we do the same for the softphone with an audio and video service? My suggestion would be to have some other example in Section 3.3.4. Nits: *) In section 2, under the definition of "Characteristics", the fourth line ("A status or characteristic...") appears to be a cut-and-paste error from -00...? *) Define "Attribute" as "A piece of data that provides a description about a service, person, or device." Then, the definition of "Presence Attribute" can simply refer to "Attribute". *) Section 3.3, s/Each service is/each service is *) Section 3.3.2, s/users SIP/user's SIP *) Same section, s/the user would/the watcher would *) Same section, it is stated that: Firstly, the service in the document might actually be modelling a number of actual services used by the user, and it may not be possible to connect the watcher to a service with all of the characteristics described in the presence document. Does it make more sense to rephrase that as: Firstly, the service tuple in the document might actually be modelling a number of actual services used by the presentity, and it may not be possible to connect the watcher to a single instance of a service that simultaneously exhibits all the characteristics described in the tuple. *) Same section, s/since a URI could/since a URN could *) Section 3.3.3, s/the user has/the presentity has *) Section 3.4, s/allow the user to/allow the watcher to *) Same section, s/a *model* if/a *model* of That's it for now. I will send comments for Section 5 to the end later. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 28 14:23:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25520; Mon, 28 Feb 2005 14:23:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5qUq-0006gR-MI; Mon, 28 Feb 2005 14:24:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5qQ0-0000H9-1y; Mon, 28 Feb 2005 14:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5qPy-0000Gt-HW; Mon, 28 Feb 2005 14:18:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24831; Mon, 28 Feb 2005 14:18:57 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5qQk-0006ZS-BD; Mon, 28 Feb 2005 14:19:48 -0500 Received: from lion.cs.columbia.edu (IDENT:KmaIWmoT1onlXbXgT/UyHLwwG/ooDpuV@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j1SJHhir011113 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 28 Feb 2005 14:17:44 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id j1SJHgRn022269 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 28 Feb 2005 14:17:43 -0500 Message-ID: <42236E51.1050705@cs.columbia.edu> Date: Mon, 28 Feb 2005 14:17:37 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Geopriv] Re: [Simple] presence authorization issue: anonymous, authenticated, etc. References: <42146290.5090209@cisco.com> <4214ADD0.3070101@cs.columbia.edu> <4214B803.7070304@cisco.com> <4214FDA3.3060701@cisco.com> <421B01D4.3050507@nokia.com> <421BF247.5090903@cisco.com> <421C3B30.8050104@nokia.com> <421DFEEF.4070107@cs.columbia.edu> <421F0DAD.20907@nokia.com> <421F29E8.2010104@cs.columbia.edu> <421F3406.8020106@nokia.com> <421F6AB1.7040107@cs.columbia.edu> <42233349.3020206@cisco.com> In-Reply-To: <42233349.3020206@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Aki Niemi , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit > People can be very resourceful. It won't take long for somebody to begin > to discern the pattern of addresses you use. (e.g. hgs+*@cs.columbia.edu) > > I think there will continue to be a demand for flexible techniques to > denote specific classes of addresses based on patterns in the address. Agreed, but we need to find a reasonable cut-off point of complexity and predictability. You seem to be arguing for supporting general regular expressions or at least "glob" style expressions, which is beyond what we're currently describing, for either black or whitelists. > Yes. Its the bad apples list where you want a lot of flexibility in > description. Note that I may not have to fully understand the domain > name assignment policy to describe a matching algorithm sufficient for > my needs. I may decide to simply exclude hgs*@cs.columbia.edu. This may > overreach and exclude some I didn't intend to exclude, but that may > still be ok, because I will never have need to correspond with them anyway. If they are polite blocked, I wouldn't know that these inviduals existed at all, even though I might want them to be able to "knock" (SUBCRIBE + confirm). > I agree it is a problem that we haven't dealt with. But I am not sure > that two distinct presentity names is the right solution. Then I need to > manange two names, and ensure that the right name gets in the hands of > each person. Unlike with unlisted phone numbers, getting the wrong one to a subscriber isn't as bad since the name doesn't convey authorization. I do agree that this name mapping is sub-optimal since it makes it fairly obvious that you're handing out different rights and makes it really difficult to change rights (upgrade or downgrade) without handing out a new name. You'd almost want some kind of caller preferences where the SUBSCRIBEr can say "I'd like to ask for confirmation" or "I'm not willing to authenticate so just give me what you are going to give to random strangers" or "I want the maximum possible information and am willing to jump through a ChoicePoint verification and lie detector test if I have to". (Might be easier to just pick up a suitable identity from your friendly identity retailer courtesy of that same company, but we'll leave that aside.) > > It is also a problem when using phone numbers as identities. We've been > struggling with how to use presence as an enabler for telephony when > phone numbers are in use, and it is a problem because of this. I don't quite see the connection. Are you saying that I want to subscribe to your presence, where you're identified by your phone number? ENUM would seem to solve that problem. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From nobody@host.riyadh-host.com Mon Feb 28 14:43:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27886; Mon, 28 Feb 2005 14:43:21 -0500 (EST) Received: from [207.44.236.104] (helo=host.riyadh-host.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5qoM-0007Bk-GB; Mon, 28 Feb 2005 14:44:13 -0500 Received: from nobody by host.riyadh-host.com with local (Exim 4.43) id 1D5qTG-0005Du-OP; Mon, 28 Feb 2005 22:22:29 +0300 Subject: CAN YOU BE SINCERE ? From: wangqin44 X-Priority: 3 (Normal) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: RLSP Mailer Message-Id: Date: Mon, 28 Feb 2005 22:22:22 +0300 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.riyadh-host.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - host.riyadh-host.com X-Spam-Score: 3.7 (+++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Dear , Thank you very much for your response, and your interest in this transaction.Like I said earlier,due to this issue on my hands now,it became neccesary for me to seek your assistance, I appreciate the fact that you are ready to assist me in executing this project,and also to help me in investing my money in your country. You should not have anything to worry about. I will do everything legally required to ensure that the project goes smoothly,it shall pass through all Laws of International Banking.Having resolved to entrust this transaction into your hands, I want to remind you that, it needs your commitment and diligent follow up.If you work seriously, the entire transaction should be over in a couple of days. READ THE FOLLOWING AND GET BACK TO ME: Firstly,I will want to know the type of occupation that you do and how old you are. You should note that this project is highly capital intensive.This is why,I have to be very careful. I need your total devotion and trust to see this through. I know we have not met before,but I am very confident that we will be able to establish the necessary trust that we need to execute this project. I am now in contact with a foreign online bank. I nowintend that you open an account inyour name in thisforeign bank.The money would be transfered to youraccount which you will open in the bank for both of us,this is the best way,I have found,it will protect usfrom my bank.I want us to enjoy this money in peace when we conclude. So you should listen to my instructions and follow them religiously.Also You have to know that I cannot transfer this money in my name as my bank will be aware that it isfrom me. This is where I need you.As result of this,you will have to open an account in the corresponding bank. I will obtain a certificate of deposit from this my bank,it will be issued in your name. This will make you the bonafide owner of the funds. After this,the money will be banked online for both of us. We can then instruct the bank to transfer our various shares into ourrespective home bank accounts. I will also perfect the documentations with the assistance of my attorney to give the transaction the legal right.Before I commence,I will need you to send me a copy of any form your identification (Driver's licence or International passport) . I want to be sure that I am transacting with the correct person. As soon as I get these from you,I will commence the paper work.I hope you will understand why I need all these The money in question is big and I want to ensure that I know you well before I proceed to give you all the details to commence the project. I am sending a copy of my passport to you for your perusal and trust.I will send the name and contact details of the bank and their website to you so that you can commence communic ation with them.Our local telephones lines could be intercepted easily,so they are not safe for the project.This is why I have installed a more private communication.Ensure that you keep this project confidential, do not discuss it withanybody,because of the confidential nature of this transaction and my work. Please reply soonest. Best Regards, Wang Qin. ___________________________________________________________________________ الجمعية العلمية السعودية للقرآن الكريم وعلومه http://www.alquran.org.sa.com From simple-bounces@ietf.org Mon Feb 28 18:28:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20697; Mon, 28 Feb 2005 18:28:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5uJz-0003jy-IU; Mon, 28 Feb 2005 18:29:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5uF3-0002s1-N0; Mon, 28 Feb 2005 18:23:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5uF2-0002rr-DR for simple@megatron.ietf.org; Mon, 28 Feb 2005 18:23:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20416 for ; Mon, 28 Feb 2005 18:23:53 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5uFq-0003eX-4m for simple@ietf.org; Mon, 28 Feb 2005 18:24:48 -0500 Received: from [192.168.0.108] (c-24-1-68-89.client.comcast.net [24.1.68.89]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j1SNNZZ3093605 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 28 Feb 2005 17:23:40 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: Simple WG From: Robert Sparks Date: Mon, 28 Feb 2005 17:23:22 -0600 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Subject: [Simple] Agenda for SIMPLE : IETF62 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit The agenda for next week's meetings is below. I've prepared pdfs of the drafts listed here. They're currently at http://www.nostrum.com/~rjsparks/simple-ietf62.pdf (1 up - 329 pages) http;//www.nostrum.com/~rjsparks/simple-ietf62-2up.pdf (2 up - 165 pages) I'll get these moved to softarmor soon as well. RjS ---------- Agenda: SIMPLE IETF 62 Monday 7 March 1300-1500 10m 1300-1310 Administrivia - Chairs 5m 1310-1315 RPID/cipid/future - Henning Schulzrinne draft-ietf-simple-rpid-05.txt draft-ietf-simple-cipid-03.txt draft-ietf-simple-future-02.txt 45m 1315-1400 Presence Data Model - Jonathan Rosenberg draft-ietf-simple-presence-data-model-02.txt 30m 1400-1430 Presence Rules - Jonathan Rosenberg draft-ietf-simple-presence-rules-02.txt 30m 1430-1500 Presence Processing - Jonathan Rosenberg draft-rosenberg-simple-presence-processing-model-00.txt Tuesday 8 March 0900-1130 30m 0900-0930 MSRP - Ben Campbell/Cullen Jennings draft-ietf-simple-message-sessions-10.txt draft-ietf-simple-msrp-relays-03.txt 15m 0930-0945 MSRP conferences - Miguel Garcia/Aki Niemi draft-niemi-simple-chat-02.txt 15m 0945-1000 Diff format for XCAP and partial notification - Jari Urpalainen draft-ietf-simple-xcap-diff-00.txt draft-urpalainen-simple-xcap-patch-ops-00.txt 15m 1000-1015 Policy capabilities / presence capabilities - Jonathan Rosenberg draft-rosenberg-simple-common-policy-caps-02.txt draft-rosenberg-simple-pres-policy-caps-02.txt 5m 1015-1020 Prescaps update - Mikko Lonnfors draft-ietf-simple-prescaps-ext-03.txt 60m 1030-1130 Schema design working session _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 28 19:39:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26753; Mon, 28 Feb 2005 19:39:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5vQx-0005Bt-LF; Mon, 28 Feb 2005 19:40:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5vPN-0006kJ-5y; Mon, 28 Feb 2005 19:38:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5vPM-0006k5-7Y; Mon, 28 Feb 2005 19:38:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26698; Mon, 28 Feb 2005 19:38:37 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5vQ8-0005B5-L4; Mon, 28 Feb 2005 19:39:33 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 28 Feb 2005 16:50:56 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j210cLq8023725; Mon, 28 Feb 2005 16:38:21 -0800 (PST) Received: from cisco.com ([161.44.79.169]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APL52535; Mon, 28 Feb 2005 19:38:22 -0500 (EST) Message-ID: <4223B97D.6090806@cisco.com> Date: Mon, 28 Feb 2005 19:38:21 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Geopriv] Re: [Simple] presence authorization issue: anonymous, authenticated, etc. References: <42146290.5090209@cisco.com> <4214ADD0.3070101@cs.columbia.edu> <4214B803.7070304@cisco.com> <4214FDA3.3060701@cisco.com> <421B01D4.3050507@nokia.com> <421BF247.5090903@cisco.com> <421C3B30.8050104@nokia.com> <421DFEEF.4070107@cs.columbia.edu> <421F0DAD.20907@nokia.com> <421F29E8.2010104@cs.columbia.edu> <421F3406.8020106@nokia.com> <421F6AB1.7040107@cs.columbia.edu> <42233349.3020206@cisco.com> <42236E51.1050705@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Aki Niemi , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: >> People can be very resourceful. It won't take long for somebody to >> begin to discern the pattern of addresses you use. (e.g. >> hgs+*@cs.columbia.edu) >> >> I think there will continue to be a demand for flexible techniques to >> denote specific classes of addresses based on patterns in the address. > > Agreed, but we need to find a reasonable cut-off point of complexity and > predictability. You seem to be arguing for supporting general regular > expressions or at least "glob" style expressions, which is beyond what > we're currently describing, for either black or whitelists. Yes, I think that something of that sort may be needed, or at least desirable. (glob style anyway.) Something else that hasn't been touched upon is watchers whose identity is a tel uri. I think we have to expect that there will be such. Its ugly, but I think there will be need for special matching on various parts of these. >> Yes. Its the bad apples list where you want a lot of flexibility in >> description. Note that I may not have to fully understand the domain >> name assignment policy to describe a matching algorithm sufficient for >> my needs. I may decide to simply exclude hgs*@cs.columbia.edu. This >> may overreach and exclude some I didn't intend to exclude, but that >> may still be ok, because I will never have need to correspond with >> them anyway. > > If they are polite blocked, I wouldn't know that these inviduals existed > at all, even though I might want them to be able to "knock" (SUBCRIBE + > confirm). Sure. But if I have already rejected hgs@cs.columbia.edu, and then I reject hgs+foo, and hgs+bar, and a few more, I am going to want a way to reject hgs+* even if I have to take a risk that there aren't some valid hgs+xxxs. >> I agree it is a problem that we haven't dealt with. But I am not sure >> that two distinct presentity names is the right solution. Then I need >> to manange two names, and ensure that the right name gets in the hands >> of each person. > > Unlike with unlisted phone numbers, getting the wrong one to a > subscriber isn't as bad since the name doesn't convey authorization. I > do agree that this name mapping is sub-optimal since it makes it fairly > obvious that you're handing out different rights and makes it really > difficult to change rights (upgrade or downgrade) without handing out a > new name. Yes, these are significant issues. Are you going to keep two different sets of business cards and make a decision about which one to give to someone? (The plain white ones, and the "platinum" ones.) > You'd almost want some kind of caller preferences where the SUBSCRIBEr > can say "I'd like to ask for confirmation" or "I'm not willing to > authenticate so just give me what you are going to give to random > strangers" or "I want the maximum possible information and am willing to > jump through a ChoicePoint verification and lie detector test if I have > to". (Might be easier to just pick up a suitable identity from your > friendly identity retailer courtesy of that same company, but we'll > leave that aside.) I haven't got a particular mechanism in mind. But I agree there is some similarity between saying "I calling but I just want your voicemail server", and saying "I want whatever presence I can get without going into pending and requesting approval". >> It is also a problem when using phone numbers as identities. We've >> been struggling with how to use presence as an enabler for telephony >> when phone numbers are in use, and it is a problem because of this. > > I don't quite see the connection. Are you saying that I want to > subscribe to your presence, where you're identified by your phone > number? ENUM would seem to solve that problem. The point was that phone numbers are somewhat scarce. You probably often won't be willing to have one for your buddies and another for everybody else. And then there will just be one on your business card. And as I mentioned above, authorization of subscribers known by a number is also an issue. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Feb 28 20:31:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00644; Mon, 28 Feb 2005 20:31:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5wFS-00066A-60; Mon, 28 Feb 2005 20:32:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5wCE-0005vM-GI; Mon, 28 Feb 2005 20:29:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5wCC-0005v4-FJ; Mon, 28 Feb 2005 20:29:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00393; Mon, 28 Feb 2005 20:29:07 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5wD2-00063L-Fw; Mon, 28 Feb 2005 20:30:01 -0500 Received: from [127.0.0.1] (IDENT:U2FsdGVkX1+MuJ2zZsMbrJR0rGeIoNTO121ETIQkzKc@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j211T1h3020981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Feb 2005 20:29:02 -0500 (EST) Message-ID: <4223C55B.8070303@cs.columbia.edu> Date: Mon, 28 Feb 2005 20:28:59 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Geopriv] Re: [Simple] presence authorization issue: anonymous, authenticated, etc. References: <42146290.5090209@cisco.com> <4214ADD0.3070101@cs.columbia.edu> <4214B803.7070304@cisco.com> <4214FDA3.3060701@cisco.com> <421B01D4.3050507@nokia.com> <421BF247.5090903@cisco.com> <421C3B30.8050104@nokia.com> <421DFEEF.4070107@cs.columbia.edu> <421F0DAD.20907@nokia.com> <421F29E8.2010104@cs.columbia.edu> <421F3406.8020106@nokia.com> <421F6AB1.7040107@cs.columbia.edu> <42233349.3020206@cisco.com> <42236E51.1050705@cs.columbia.edu> <4223B97D.6090806@cisco.com> In-Reply-To: <4223B97D.6090806@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: "'geopriv@ietf.org'" , Aki Niemi , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > Yes, I think that something of that sort may be needed, or at least > desirable. (glob style anyway.) So far, prefix (for user names) and postfix (for hosts) seems to be working for the examples (which is also similar to the SQL "LIKE %" facility). > > Something else that hasn't been touched upon is watchers whose identity > is a tel uri. I think we have to expect that there will be such. Its > ugly, but I think there will be need for special matching on various > parts of these. I don't see tel:12*15*7 as all that useful. > Yes, these are significant issues. Are you going to keep two different > sets of business cards and make a decision about which one to give to > someone? (The plain white ones, and the "platinum" ones.) I suspect this is more useful for the address you put on your web page ("is my shop open?") vs. your business card. > I haven't got a particular mechanism in mind. But I agree there is some > similarity between saying "I calling but I just want your voicemail > server", and saying "I want whatever presence I can get without going > into pending and requesting approval". I wonder if the caller preferences mechanism couldn't be extended to handle this type of mechanism pretty easily. > > The point was that phone numbers are somewhat scarce. You probably often > won't be willing to have one for your buddies and another for everybody > else. And then there will just be one on your business card. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple
    Protect Your Account I= nfo
    Make sure you never provide your password to fraudulent websites.

    To safely and securely access the PayPal website or your account, open up a new web browser (e.g. Internet Explorer or Netscape) and type in the PayPal URL (http://www.paypal.com/).

    PayPal will never ask you to enter your password in an email.

    For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips