From ben@nostrum.com Sun Nov 8 15:41:50 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD3873A67FA for ; Sun, 8 Nov 2009 15:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.381 X-Spam-Level: X-Spam-Status: No, score=-0.381 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPWACXscXPxa for ; Sun, 8 Nov 2009 15:41:50 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B12B43A67AD for ; Sun, 8 Nov 2009 15:41:49 -0800 (PST) Received: from [10.0.1.2] (host-112-100.meeting.ietf.org [133.93.112.100]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nA8NgAbI049285 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 8 Nov 2009 17:42:12 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 9 Nov 2009 08:42:09 +0900 Message-Id: To: Simple WG Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Received-SPF: pass (nostrum.com: 133.93.112.100 is authenticated by a trusted mechanism) Subject: [Simple] Slides X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 23:41:50 -0000 Hi Everyone, The slides for Tuesday's SIMPLE meeting are now available at https://datatracker.ietf.org/meeting/76/materials.html Thanks! Ben. From mfroman@estacado.net Mon Nov 9 12:36:32 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 436AB3A6916 for ; Mon, 9 Nov 2009 12:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvxQE5VDe8uV for ; Mon, 9 Nov 2009 12:36:31 -0800 (PST) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 6A66A3A6831 for ; Mon, 9 Nov 2009 12:36:31 -0800 (PST) Received: from dn3-128.estacado.net (dn3-128.estacado.net [172.16.3.128]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id nA9KZf4m007021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Nov 2009 14:35:42 -0600 (CST) (envelope-from mfroman@estacado.net) From: Michael Froman Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Mon, 9 Nov 2009 14:35:41 -0600 To: simple@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [Simple] WGLC review of draft-ietf-simple-intradomain-federation-04 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 20:36:32 -0000 In general I think the draft is ready to progress, but I have a few comments/suggestions and a few nits. Comments/Suggestions: Section 8.1.1 - I understand the routing rule, but I think an example of why the root node wouldn't always be the one to serve the initial request would be useful. Section 8.1.2.2 - It is difficult to see how "This means that a presence server cannot send notifications on its own until it has confirmed subscriptions from downstream servers." can be accomplished and still comply with "immediate" initial NOTIFY requirements and additionally keep the initiating watcher from starting retry logic. Section 8.1.2.2 - Distributed provisioning is making many assumptions about each of the potentially different vendors' presence servers making the same "unioned presence" approved decisions on what gets propagated. Given that some of these servers may not know that they're cooperating in a unioned presence environment, this might be a difficult section to realize in the field. I guess this is talked about some in section 9, but I think it would be fair to admit to the difficulty briefly in advance of section 9 in order to assure the reader the problem was considered, but is addressed elsewhere in the document. Section 8.1.2.4, 4th paragraph - "Standardized database interface" between various vendors - is this at all reasonable to expect? It seems like much of the document it geared toward dealing making "incompatible" implementations from different vendors work together. This seems like an odd place to assume they will be compatible. Section 8.2.1 "it rejects the second subscription with an indication of a loop" Does that indication exist for presence already? Section End of 8.2.1 - still an open issue? Nits: Section 2, 2nd to last paragraph, last sentence: "This is a consequence to their loose coupling." Should that be "This is a consequence of their loose coupling." ? Section 5, last paragraph: "In the exclusive model, its one at a time." its ==> it's Section 7.1.4, 2nd paragraph: "to terminate its ongoing subscriptions" its ==> it's Section 8.1.2.2, last (full) paragraph: "if these rules are followed" is missing leading capitalization. Section 8.2.1, 2nd to last paragraph: "basically knows its the child" its ==> it's Cheers, Michael. From deepanshu@huawei.com Tue Nov 10 19:24:50 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A04A93A6807 for ; Tue, 10 Nov 2009 19:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.873 X-Spam-Level: X-Spam-Status: No, score=0.873 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fU6e5o7pf2FG for ; Tue, 10 Nov 2009 19:24:47 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 760583A69D6 for ; Tue, 10 Nov 2009 19:22:34 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSX0041YDDZX7@szxga03-in.huawei.com> for simple@ietf.org; Wed, 11 Nov 2009 11:22:47 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSX0073ADDZMJ@szxga03-in.huawei.com> for simple@ietf.org; Wed, 11 Nov 2009 11:22:47 +0800 (CST) Received: from jys8055621 (host-17-129.meeting.ietf.org [133.93.17.129]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSX00BMUDDNND@szxml01-in.huawei.com>; Wed, 11 Nov 2009 11:22:47 +0800 (CST) Date: Wed, 11 Nov 2009 11:22:27 +0800 From: Deepanshu To: adam@nostrum.com, rjsparks@nostrum.com, hisham.khartabil@gmail.com, ben@nostrum.com, christer.holmberg@ericsson.com Message-id: <000b01ca627e$3da7aa00$81115d85@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_SpJCtddIYWH6CT0jv44+3Q)" Thread-index: AcpifjFeHjuspy/zTde8kcJqWnm9UA== Cc: simple@ietf.org Subject: [Simple] Quick Answer follow-up X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 03:24:50 -0000 This is a multi-part message in MIME format. --Boundary_(ID_SpJCtddIYWH6CT0jv44+3Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear All, As mentioned in the session, I would like to get your opinion by email. Basically I would like to know the following 1. Do you think that the concept of Quick Answer (as I explained while presenting) itself, is feasible/needed for current IM systems. In other words is it advantageous to have it in today IM service? 2. If your answer is "Yes" or even "May be". Then do you think something is needed to be defined (standardized) about that in IETF? 3. If you answer in "Yes" or even "May be". Then I kindly request you to please name some of those things (instead of the solution defined in the draft) which you expect to be used/extended for this purpose. e,g XCAP. This will assist me to provide some gap analyses, if any. Unfortunately, if your answer is "no" for the first question (which I seriously don't expect) then I try to provide some more reasoning. Regards Deepanshu --Boundary_(ID_SpJCtddIYWH6CT0jv44+3Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Dear = All,

 

As mentioned in the session, I would like to = get your opinion by email.

Basically I would like to know the = following

 

1.       = Do you think that the concept of Quick Answer (as I explained while = presenting) itself, is feasible/needed for current IM systems. In other words is it advantageous to have it in today IM = service?

2.       = If your answer is “Yes” or even “May be”. Then do = you think something is needed to be defined (standardized) about that in IETF? =

3.       = If you answer in “Yes” or even “May be”. Then I = kindly request you to please name some of those things (instead of the solution defined in the draft) which you expect to be used/extended for this = purpose. e,g XCAP. This will assist me to provide some gap analyses, if = any.

 

Unfortunately, if your answer is = “no” for the first question (which I seriously don’t expect) then I try to = provide some more reasoning.

 

Regards

Deepanshu

--Boundary_(ID_SpJCtddIYWH6CT0jv44+3Q)-- From adam@nostrum.com Tue Nov 10 19:44:04 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8720B3A6947 for ; Tue, 10 Nov 2009 19:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPu+tE3swueX for ; Tue, 10 Nov 2009 19:44:00 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 2C42D3A68CE for ; Tue, 10 Nov 2009 19:43:59 -0800 (PST) Received: from host-16-62.meeting.ietf.org (host-16-62.meeting.ietf.org [133.93.16.62]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nAB3huxf060681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Nov 2009 21:43:58 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4AFA32FC.9080109@nostrum.com> Date: Wed, 11 Nov 2009 12:43:56 +0900 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Deepanshu References: <000b01ca627e$3da7aa00$81115d85@china.huawei.com> In-Reply-To: <000b01ca627e$3da7aa00$81115d85@china.huawei.com> Content-Type: multipart/alternative; boundary="------------080505020803010900060701" Received-SPF: pass (nostrum.com: 133.93.16.62 is authenticated by a trusted mechanism) Cc: simple@ietf.org Subject: Re: [Simple] Quick Answer follow-up X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 03:44:04 -0000 This is a multi-part message in MIME format. --------------080505020803010900060701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > > > Dear All, > > As mentioned in the session, I would like to get your opinion by email. > > Basically I would like to know the following > > 1. Do you think that the concept of Quick Answer (as I explained while > presenting) itself, is feasible/needed for current IM systems. In > other words is it advantageous to have it in today IM service? > > 2. If your answer is "Yes" or even "May be". Then do you think > something is needed to be defined (standardized) about that in IETF? > > 3. If you answer in "Yes" or even "May be". Then I kindly request you > to please name some of those things (instead of the solution defined > in the draft) which you expect to be used/extended for this purpose. > e,g XCAP. This will assist me to provide some gap analyses, if any. > I'm not 100% convinced that we need this mechanism, but I'm willing to entertain requirements relating to it. If this mechanism is pursued, it would seem to make sense to have something standardized. In terms of existing mechanisms, I would think the most promising approaches would be either XCAP, or bare HTTP (PUT and GET). /a --------------080505020803010900060701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Dear All,

 

As mentioned in the session, I would like to get your opinion by email.

Basically I would like to know the following

 

1.       Do you think that the concept of Quick Answer (as I explained while presenting) itself, is feasible/needed for current IM systems. In other words is it advantageous to have it in today IM service?

2.       If your answer is “Yes” or even “May be”. Then do you think something is needed to be defined (standardized) about that in IETF?

3.       If you answer in “Yes” or even “May be”. Then I kindly request you to please name some of those things (instead of the solution defined in the draft) which you expect to be used/extended for this purpose. e,g XCAP. This will assist me to provide some gap analyses, if any.


I'm not 100% convinced that we need this mechanism, but I'm willing to entertain requirements relating to it.

If this mechanism is pursued, it would seem to make sense to have something standardized.

In terms of existing mechanisms, I would think the most promising approaches would be either XCAP, or bare HTTP (PUT and GET).

/a --------------080505020803010900060701-- From rbarnes@bbn.com Tue Nov 10 19:57:36 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59A273A6944 for ; Tue, 10 Nov 2009 19:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHWDhw2wKyh1 for ; Tue, 10 Nov 2009 19:57:35 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 44B7A3A6901 for ; Tue, 10 Nov 2009 19:57:35 -0800 (PST) Received: from [128.89.252.105] (helo=host-16-79.meeting.ietf.org) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1N84LJ-0006xx-Bk; Tue, 10 Nov 2009 22:58:02 -0500 Message-Id: <16092718-81E4-40C4-BB0E-CD38603AF141@bbn.com> From: Richard Barnes To: Deepanshu In-Reply-To: <000b01ca627e$3da7aa00$81115d85@china.huawei.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1-431805118 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 11 Nov 2009 12:57:59 +0900 References: <000b01ca627e$3da7aa00$81115d85@china.huawei.com> X-Mailer: Apple Mail (2.936) Cc: simple@ietf.org Subject: Re: [Simple] Quick Answer follow-up X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 03:57:36 -0000 --Apple-Mail-1-431805118 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Deepanshu, Like Adam, I'm not 100% clear that this is a required feature. It's =20 even less clear to me that it needs to be something that's done in the =20= network; surely a UA could be provisioned with the right QA to send =20 back? --Richard On Nov 11, 2009, at 12:22 PM, Deepanshu wrote: > Dear All, > > As mentioned in the session, I would like to get your opinion by =20 > email. > Basically I would like to know the following > > 1. Do you think that the concept of Quick Answer (as I =20 > explained while presenting) itself, is feasible/needed for current =20 > IM systems. In other words is it advantageous to have it in today IM =20= > service? > 2. If your answer is =93Yes=94 or even =93May be=94. Then do you = think =20 > something is needed to be defined (standardized) about that in IETF? > 3. If you answer in =93Yes=94 or even =93May be=94. Then I = kindly =20 > request you to please name some of those things (instead of the =20 > solution defined in the draft) which you expect to be used/extended =20= > for this purpose. e,g XCAP. This will assist me to provide some gap =20= > analyses, if any. > > Unfortunately, if your answer is =93no=94 for the first question = (which =20 > I seriously don=92t expect) then I try to provide some more reasoning. > > Regards > Deepanshu > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail-1-431805118 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
Dear = All,
 
As mentioned in the = session, I would like to get your opinion by = email.
Basically I would like to know the = following
 
1.       <= /font>Do you think that the = concept of Quick Answer (as I explained while presenting) itself, is = feasible/needed for current IM systems. In other words is it = advantageous to have it in today IM = service?
2. <= /font>If your answer is =93Yes=94= or even =93May be=94. Then do you think something is needed to be = defined (standardized) about that in = IETF?
3. <= /font>If you answer in =93Yes=94 = or even =93May be=94. Then I kindly request you to please name some of = those things (instead of the solution defined in the draft) which you = expect to be used/extended for this purpose. e,g XCAP. This will assist = me to provide some gap analyses, if = any.
 
Unfortunately, if your = answer is =93no=94 for the first question (which I seriously don=92t = expect) then I try to provide some more = reasoning.
 
Simple@ietf.org
In-Reply-To: <4AFA32FC.9080109@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Quick Answer follow-up thread-index: AcpigUqMMCImhw3ARbi6TPXy7R8aagASspLQ References: <000b01ca627e$3da7aa00$81115d85@china.huawei.com> <4AFA32FC.9080109@nostrum.com> From: "Smyth, Colm (Colm)" To: "Adam Roach" , "Deepanshu" Cc: simple@ietf.org Subject: Re: [Simple] Quick Answer follow-up X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 12:50:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA62CD.82FC3052 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Like Richard, I believe the Quick Answer (QA) requirement can be met entirely within the UA implementation, potentially using local storage. =20 There is some benefit in this proposal's central storage of the QA's, which enables mobility of the endpoint, or potentially sharing the QA's across a user's endpoints. However I agree with Adam that XCAP seems a more natural mechanism for this kind of data, more so than overloading the SIP REGISTER and INVITE methods. =20 BTW, the term "canned response" is used elsewhere: - http://en.wikipedia.org/wiki/Canned_response - http://gmailblog.blogspot.com/2008/10/new-in-labs-canned-responses.html =20 All the best, Colm. ________________________________ From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Adam Roach Sent: 11 November 2009 03:44 To: Deepanshu Cc: simple@ietf.org Subject: Re: [Simple] Quick Answer follow-up Dear All, =09 As mentioned in the session, I would like to get your opinion by email. Basically I would like to know the following =09 1. Do you think that the concept of Quick Answer (as I explained while presenting) itself, is feasible/needed for current IM systems. In other words is it advantageous to have it in today IM service? 2. If your answer is "Yes" or even "May be". Then do you think something is needed to be defined (standardized) about that in IETF?=20 3. If you answer in "Yes" or even "May be". Then I kindly request you to please name some of those things (instead of the solution defined in the draft) which you expect to be used/extended for this purpose. e,g XCAP. This will assist me to provide some gap analyses, if any. I'm not 100% convinced that we need this mechanism, but I'm willing to entertain requirements relating to it. If this mechanism is pursued, it would seem to make sense to have something standardized. In terms of existing mechanisms, I would think the most promising approaches would be either XCAP, or bare HTTP (PUT and GET). /a=20 ------_=_NextPart_001_01CA62CD.82FC3052 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Like Richard, I believe the Quick Answer (QA) = requirement can be=20 met entirely within the UA implementation, potentially using local=20 storage.
 
There is some benefit in this proposal's central storage = of the=20 QA's, which enables mobility of the endpoint, or potentially sharing the = QA's=20 across a user's endpoints. However I agree with Adam that XCAP seems a = more=20 natural mechanism for this kind of data, more so than overloading the=20 SIP REGISTER and INVITE methods.
 
BTW, the term "canned response" is used=20 elsewhere:
- http://gmailblog.blogspot.com/2008/10/new-in-labs-canned-response= s.html
 
All the=20 best,
Colm.

From: simple-bounces@ietf.org=20 [mailto:simple-bounces@ietf.org] On Behalf Of Adam = Roach
Sent:=20 11 November 2009 03:44
To: Deepanshu
Cc:=20 simple@ietf.org
Subject: Re: [Simple] Quick Answer=20 follow-up

Dear=20 All,

As mentioned in the = session, I=20 would like to get your opinion by email.

Basically I would like to = know the=20 following

<!--[if=20 !supportLists]-->1.      =20 <!--[endif]-->Do you=20 think that the concept of Quick Answer (as I explained while = presenting)=20 itself, is feasible/needed for current IM systems. In other words is = it=20 advantageous to have it in today IM = service?

<!--[if=20 !supportLists]-->2.      =20 <!--[endif]-->If your=20 answer is “Yes” or even “May be”. Then do you = think something is needed to be=20 defined (standardized) about that in IETF? =

<!--[if=20 !supportLists]-->3.      =20 <!--[endif]-->If you=20 answer in “Yes” or even “May be”. Then I = kindly request you to please name=20 some of those things (instead of the solution defined in the draft) = which you=20 expect to be used/extended for this purpose. e,g XCAP. This will = assist me to=20 provide some gap analyses, if=20 any.


I'm not 100% = convinced=20 that we need this mechanism, but I'm willing to entertain requirements = relating=20 to it.

If this mechanism is pursued, it would seem to make sense = to have=20 something standardized.

In terms of existing mechanisms, I would = think=20 the most promising approaches would be either XCAP, or bare HTTP (PUT = and=20 GET).

/a ------_=_NextPart_001_01CA62CD.82FC3052-- From deepanshu@huawei.com Wed Nov 11 05:17:58 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC4253A6AA6 for ; Wed, 11 Nov 2009 05:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adURA8BBZCT0 for ; Wed, 11 Nov 2009 05:17:57 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6991D3A6AA1 for ; Wed, 11 Nov 2009 05:17:56 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSY00JY44YDNN@szxga04-in.huawei.com> for simple@ietf.org; Wed, 11 Nov 2009 21:18:14 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSY009WL4YD82@szxga04-in.huawei.com> for simple@ietf.org; Wed, 11 Nov 2009 21:18:13 +0800 (CST) Received: from jys8055621 (222-151-138-069.jp.fiberbit.net [222.151.138.69]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSY00AW44WX6S@szxml01-in.huawei.com>; Wed, 11 Nov 2009 21:18:13 +0800 (CST) Date: Wed, 11 Nov 2009 21:17:21 +0800 From: Deepanshu In-reply-to: <4C607BEA097DF048BEA625B974A36618DC575D@306900ANEX2.global.avaya.com> To: "'Smyth, Colm (Colm)'" , 'Adam Roach' Message-id: <004d01ca62d1$6c10d5d0$0af01eac@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_wiQu2CVM90Dt+/KmmE9yTg)" Thread-index: AcpigUqMMCImhw3ARbi6TPXy7R8aagASspLQAADhRHA= Cc: simple@ietf.org Subject: Re: [Simple] Quick Answer follow-up X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 13:17:58 -0000 This is a multi-part message in MIME format. --Boundary_(ID_wiQu2CVM90Dt+/KmmE9yTg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Symth, =20 The benefits you mentioned for central storage is exactly what I had in = mind while coming up with this draft. What I said (in my mail to Richard only, sorry for not sending to the = list) is further echoed by you in terms of benefit for central storage.=20 As for XCAP, if that is the best way to do it then, so be it. =20 Regards Deepanshu =20 *********************************************** To: Richard > It's even less clear to me that it needs to be something that's done = in the network As I mentioned that today=A1=AFs IM systems allow different client = device to log-in IM system at different point of time. I=A1=AFm creating a QA today with my PDA (as my client device). Tomorrow = when I=A1=AFll be logging-in using my mobile phone I want that QA, created = using PDA, available in my mobile phone. How that can be done without storing that = QA somewhere in the network? > surely a UA could be provisioned with the right QA to send back? Yes, it can be, if device manufacturer pre-configured them into the = device. But here I=A1=AFm talking about *user* creating them and then using = them. ************************************************ =20 _____ =20 From: Smyth, Colm (Colm) [mailto:smythc@avaya.com]=20 Sent: 2009=C4=EA11=D4=C211=C8=D5 20:50 To: Adam Roach; Deepanshu Cc: simple@ietf.org Subject: RE: [Simple] Quick Answer follow-up =20 Like Richard, I believe the Quick Answer (QA) requirement can be met entirely within the UA implementation, potentially using local storage. =20 There is some benefit in this proposal's central storage of the QA's, = which enables mobility of the endpoint, or potentially sharing the QA's across = a user's endpoints. However I agree with Adam that XCAP seems a more = natural mechanism for this kind of data, more so than overloading the SIP = REGISTER and INVITE methods. =20 BTW, the term "canned response" is used elsewhere: - http://en.wikipedia.org/wiki/Canned_response - = http://gmailblog.blogspot.com/2008/10/new-in-labs-canned-responses.html =20 All the best, Colm. =20 _____ =20 From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf = Of Adam Roach Sent: 11 November 2009 03:44 To: Deepanshu Cc: simple@ietf.org Subject: Re: [Simple] Quick Answer follow-up Dear All, As mentioned in the session, I would like to get your opinion by email. Basically I would like to know the following 1. Do you think that the concept of Quick Answer (as I explained while presenting) itself, is feasible/needed for current IM systems. In other words is it = advantageous to have it in today IM service? 2. If your answer is = =A1=B0Yes=A1=B1 or even =A1=B0May be=A1=B1. Then do you think something is needed to be = defined (standardized) about that in IETF?=20 3. If you answer in = =A1=B0Yes=A1=B1 or even =A1=B0May be=A1=B1. Then I kindly request you to please name some = of those things (instead of the solution defined in the draft) which you expect = to be used/extended for this purpose. e,g XCAP. This will assist me to provide some gap analyses, if any. I'm not 100% convinced that we need this mechanism, but I'm willing to entertain requirements relating to it. If this mechanism is pursued, it would seem to make sense to have = something standardized. In terms of existing mechanisms, I would think the most promising = approaches would be either XCAP, or bare HTTP (PUT and GET). /a=20 --Boundary_(ID_wiQu2CVM90Dt+/KmmE9yTg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Symth,<= /span>

 <= /span>

The benefits you = mentioned for central storage is exactly what I had in mind while coming up with = this draft.

What I said (in = my mail to Richard only, sorry for not sending to the list) is further echoed by = you in terms of benefit for central storage.

As for XCAP, if = that is the best way to do it then, so be it.

 <= /span>

Regards=

Deepanshu

 <= /span>

******************= *****************************

To: = Richard

> It's even less clear to me = that it needs to be something that's done in the network

As I mentioned that today=A1=AFs IM systems allow different = client device to log-in IM system at different point of = time.

I=A1=AFm creating a QA today with my PDA (as my client = device). Tomorrow when I=A1=AFll be logging-in using my mobile phone I want that QA, = created using PDA, available in my mobile phone. How that can be done without storing = that QA somewhere in the network?

> surely a UA could be = provisioned with the right QA to send back?

Yes, it can be, if device manufacturer pre-configured them = into the device. But here I=A1=AFm talking about *user* creating them and then using them.

******************= ******************************

 <= /span>

From: Smyth, Colm (Colm) [mailto:smythc@avaya.com] =
Sent: = 2009=C4=EA11<= /font>=D4=C211<= /font>=C8=D5 = 20:50
To: Adam Roach; = Deepanshu
Cc: simple@ietf.org
Subject: RE: [Simple] = Quick Answer follow-up

=

 

Like Richard, I = believe the Quick Answer (QA) requirement can be met entirely within the UA = implementation, potentially using local storage.

 

There is some = benefit in this proposal's central storage of the QA's, which enables mobility = of the endpoint, or potentially sharing the QA's across a user's endpoints. = However I agree with Adam that XCAP seems a more natural mechanism for this kind = of data, more so than overloading the SIP REGISTER and INVITE = methods.

 

BTW, the term "canned response" is used elsewhere:

- http://en.wikipedia= .org/wiki/Canned_response

- http://gmailblog.blogspot.com/2008/10/new-in-labs-canned-response= s.html

 

All the = best,

Colm.

 

From: = simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On = Behalf Of Adam Roach
Sent: 11 November 2009 = 03:44
To: Deepanshu
Cc: simple@ietf.org
Subject: Re: [Simple] = Quick Answer follow-up

Dear All,

As mentioned in = the session, I would like to get your opinion by = email.

Basically I would like to = know the following

<!--[if !supportLists]-->1.       = <!--[endif]-->Do you think that the = concept of Quick Answer (as I explained while presenting) itself, is = feasible/needed for current IM systems. In other words is it advantageous to have it in = today IM service?

<!--[if !supportLists]-->2.       = <!--[endif]-->If your answer is = =A1=B0Yes=A1=B1 or even =A1=B0May be=A1=B1. Then do you think something is needed to be defined = (standardized) about that in IETF?

<!--[if !supportLists]-->3.       = <!--[endif]-->If you answer in = =A1=B0Yes=A1=B1 or even =A1=B0May be=A1=B1. Then I kindly request you to please name some of those things = (instead of the solution defined in the draft) which you expect to be used/extended = for this purpose. e,g XCAP. This will assist me to provide some gap = analyses, if any.


I'm not 100% convinced that we need this mechanism, but I'm willing to entertain requirements relating to it.

If this mechanism is pursued, it would seem to make sense to have = something standardized.

In terms of existing mechanisms, I would think the most promising = approaches would be either XCAP, or bare HTTP (PUT and GET).

/a

--Boundary_(ID_wiQu2CVM90Dt+/KmmE9yTg)-- From smythc@avaya.com Wed Nov 11 06:45:28 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B86928C0E5 for ; Wed, 11 Nov 2009 06:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDtfOJi1SVBp for ; Wed, 11 Nov 2009 06:45:26 -0800 (PST) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 329083A6ABB for ; Wed, 11 Nov 2009 06:45:25 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,723,1249272000"; d="scan'208,217";a="179912328" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 11 Nov 2009 09:45:53 -0500 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 11 Nov 2009 09:45:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA62DD.9ED0F7BC" Date: Wed, 11 Nov 2009 14:45:29 -0000 Message-ID: <4C607BEA097DF048BEA625B974A36618DC5801@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Quick Answer follow-up thread-index: AcpigUqMMCImhw3ARbi6TPXy7R8aagASspLQAADhRHAAALtHgAABUaog References: <4C607BEA097DF048BEA625B974A36618DC575D@306900ANEX2.global.avaya.com> <004d01ca62d1$6c10d5d0$0af01eac@china.huawei.com> From: "Smyth, Colm (Colm)" To: "Deepanshu" , "Adam Roach" Cc: simple@ietf.org Subject: Re: [Simple] Quick Answer follow-up X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 14:45:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA62DD.9ED0F7BC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 KHJlLXNlbmRpbmcgdG8gY29tZSB1bmRlciBtYWlsaW5nIGxpc3Qgc2l6ZSBsaW1pdCkNCg0KQWdy ZWVkLCBJIHRoaW5rIGl0IHdvdWxkIGJlIHdvcnRod2hpbGUgaWYgeW91IGNvdWxkIGFkYXB0IHlv dXIgcHJvcG9zYWwgdG8gWENBUCwgcHJlc2VydmluZyB0aGUgYmVuZWZpdCBvZiBjZW50cmFsIGFj Y2VzcyBhbmQgbWFuYWdlbWVudCBvZiB0aGUgUXVpY2sgQW5zd2VycyAoY2FubmVkIHJlc3BvbnNl cykuICBJdCB3b3VsZCBiZSBmcnVpdGZ1bCB0byBhZGQgc29tZSBtb3JlIGRpc2N1c3Npb24gb24g dGhlIGV4cGVjdGVkIHVzZXIgZXhwZXJpZW5jZSB3aXRoaW4gYSBVQS4gDQogDQpCVFcsIG15IHBy ZWZlcnJlZCBzaG9ydCBuYW1lIChhbmQgZmlyc3QgbmFtZSkgaXMgQ29sbS4gDQogDQpBbGwgdGhl IGJlc3QsDQpDb2xtLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpGcm9t OiBEZWVwYW5zaHUgW21haWx0bzpkZWVwYW5zaHVAaHVhd2VpLmNvbV0gDQpTZW50OiAxMSBOb3Zl bWJlciAyMDA5IDEzOjE3DQpUbzogU215dGgsIENvbG0gKENvbG0pOyAnQWRhbSBSb2FjaCcNCkNj OiBzaW1wbGVAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbU2ltcGxlXSBRdWljayBBbnN3ZXIgZm9s bG93LXVwDQoNCg0KDQpTeW10aCwNCg0KIA0KDQpUaGUgYmVuZWZpdHMgeW91IG1lbnRpb25lZCBm b3IgY2VudHJhbCBzdG9yYWdlIGlzIGV4YWN0bHkgd2hhdCBJIGhhZCBpbiBtaW5kIHdoaWxlIGNv bWluZyB1cCB3aXRoIHRoaXMgZHJhZnQuDQoNCldoYXQgSSBzYWlkIChpbiBteSBtYWlsIHRvIFJp Y2hhcmQgb25seSwgc29ycnkgZm9yIG5vdCBzZW5kaW5nIHRvIHRoZSBsaXN0KSBpcyBmdXJ0aGVy IGVjaG9lZCBieSB5b3UgaW4gdGVybXMgb2YgYmVuZWZpdCBmb3IgY2VudHJhbCBzdG9yYWdlLiAN Cg0KQXMgZm9yIFhDQVAsIGlmIHRoYXQgaXMgdGhlIGJlc3Qgd2F5IHRvIGRvIGl0IHRoZW4sIHNv IGJlIGl0Lg0KDQogDQoNClJlZ2FyZHMNCg0KRGVlcGFuc2h1DQoNCiANCg0KKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KVG86IFJpY2hhcmQNCg0KPiBJ dCdzIGV2ZW4gbGVzcyBjbGVhciB0byBtZSB0aGF0IGl0IG5lZWRzIHRvIGJlIHNvbWV0aGluZyB0 aGF0J3MgZG9uZSBpbiB0aGUgbmV0d29yaw0KDQpBcyBJIG1lbnRpb25lZCB0aGF0IHRvZGF54oCZ cyBJTSBzeXN0ZW1zIGFsbG93IGRpZmZlcmVudCBjbGllbnQgZGV2aWNlIHRvIGxvZy1pbiBJTSBz eXN0ZW0gYXQgZGlmZmVyZW50IHBvaW50IG9mIHRpbWUuDQoNCknigJltIGNyZWF0aW5nIGEgUUEg dG9kYXkgd2l0aCBteSBQREEgKGFzIG15IGNsaWVudCBkZXZpY2UpLiBUb21vcnJvdyB3aGVuIEni gJlsbCBiZSBsb2dnaW5nLWluIHVzaW5nIG15IG1vYmlsZSBwaG9uZSBJIHdhbnQgdGhhdCBRQSwg Y3JlYXRlZCB1c2luZyBQREEsIGF2YWlsYWJsZSBpbiBteSBtb2JpbGUgcGhvbmUuIEhvdyB0aGF0 IGNhbiBiZSBkb25lIHdpdGhvdXQgc3RvcmluZyB0aGF0IFFBIHNvbWV3aGVyZSBpbiB0aGUgbmV0 d29yaz8NCg0KPiBzdXJlbHkgYSBVQSBjb3VsZCBiZSBwcm92aXNpb25lZCB3aXRoIHRoZSByaWdo dCBRQSB0byBzZW5kIGJhY2s/DQoNClllcywgaXQgY2FuIGJlLCBpZiBkZXZpY2UgbWFudWZhY3R1 cmVyIHByZS1jb25maWd1cmVkIHRoZW0gaW50byB0aGUgZGV2aWNlLiBCdXQgaGVyZSBJ4oCZbSB0 YWxraW5nIGFib3V0ICp1c2VyKiBjcmVhdGluZyB0aGVtIGFuZCB0aGVuIHVzaW5nIHRoZW0uDQoN CioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQogDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkZyb206IFNteXRoLCBDb2xtIChD b2xtKSBbbWFpbHRvOnNteXRoY0BhdmF5YS5jb21dIA0KU2VudDogMjAwOeW5tDEx5pyIMTHml6Ug MjA6NTANClRvOiBBZGFtIFJvYWNoOyBEZWVwYW5zaHUNCkNjOiBzaW1wbGVAaWV0Zi5vcmcNClN1 YmplY3Q6IFJFOiBbU2ltcGxlXSBRdWljayBBbnN3ZXIgZm9sbG93LXVwDQoNCiANCg0KTGlrZSBS aWNoYXJkLCBJIGJlbGlldmUgdGhlIFF1aWNrIEFuc3dlciAoUUEpIHJlcXVpcmVtZW50IGNhbiBi ZSBtZXQgZW50aXJlbHkgd2l0aGluIHRoZSBVQSBpbXBsZW1lbnRhdGlvbiwgcG90ZW50aWFsbHkg dXNpbmcgbG9jYWwgc3RvcmFnZS4NCg0KIA0KDQpUaGVyZSBpcyBzb21lIGJlbmVmaXQgaW4gdGhp cyBwcm9wb3NhbCdzIGNlbnRyYWwgc3RvcmFnZSBvZiB0aGUgUUEncywgd2hpY2ggZW5hYmxlcyBt b2JpbGl0eSBvZiB0aGUgZW5kcG9pbnQsIG9yIHBvdGVudGlhbGx5IHNoYXJpbmcgdGhlIFFBJ3Mg YWNyb3NzIGEgdXNlcidzIGVuZHBvaW50cy4gSG93ZXZlciBJIGFncmVlIHdpdGggQWRhbSB0aGF0 IFhDQVAgc2VlbXMgYSBtb3JlIG5hdHVyYWwgbWVjaGFuaXNtIGZvciB0aGlzIGtpbmQgb2YgZGF0 YSwgbW9yZSBzbyB0aGFuIG92ZXJsb2FkaW5nIHRoZSBTSVAgUkVHSVNURVIgYW5kIElOVklURSBt ZXRob2RzLg0KDQogDQoNCkJUVywgdGhlIHRlcm0gImNhbm5lZCByZXNwb25zZSIgaXMgdXNlZCBl bHNld2hlcmU6DQoNCi0gaHR0cDovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9DYW5uZWRfcmVzcG9u c2UNCg0KLSBodHRwOi8vZ21haWxibG9nLmJsb2dzcG90LmNvbS8yMDA4LzEwL25ldy1pbi1sYWJz LWNhbm5lZC1yZXNwb25zZXMuaHRtbA0KDQogDQoNCkFsbCB0aGUgYmVzdCwNCg0KQ29sbS4NCg0K ------_=_NextPart_001_01CA62DD.9ED0F7BC Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4 bWxuczp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIj48SEVBRD4NCjxNRVRBIGh0dHAtZXF1 aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8TUVU QSBjb250ZW50PSJNU0hUTUwgNi4wMC4yOTAwLjM2MDMiIG5hbWU9R0VORVJBVE9SPjwhLS1baWYg IW1zb10+DQo8U1RZTEU+dlw6KiB7DQoJQkVIQVZJT1I6IHVybCgjZGVmYXVsdCNWTUwpDQp9DQpv XDoqIHsNCglCRUhBVklPUjogdXJsKCNkZWZhdWx0I1ZNTCkNCn0NCndcOiogew0KCUJFSEFWSU9S OiB1cmwoI2RlZmF1bHQjVk1MKQ0KfQ0KLnNoYXBlIHsNCglCRUhBVklPUjogdXJsKCNkZWZhdWx0 I1ZNTCkNCn0NCjwvU1RZTEU+DQo8IVtlbmRpZl0tLT4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglm b250LWZhbWlseTog5a6L5L2TOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFRhaG9t YTsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBA5a6L5L2TOw0KfQ0KQGZvbnQtZmFj ZSB7DQoJZm9udC1mYW1pbHk6IENhbGlicmk7DQp9DQpAcGFnZSBTZWN0aW9uMSB7c2l6ZTogNTk1 LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDsgbGF5b3V0 LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRl b2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgQ09MT1I6IGJs YWNrOyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJR046IGp1c3RpZnkN Cn0NCkxJLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGg7IEZPTlQt U0laRTogMTAuNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFN SUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0KfQ0KRElWLk1zb05v cm1hbCB7DQoJVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGg7IEZPTlQtU0laRTogMTAuNXB0 OyBNQVJHSU46IDBjbSAwY20gMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiAiVGltZXMg TmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0KfQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1 ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsNCglD T0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJ Q09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJs aW5lDQp9DQpQLk1zb0FjZXRhdGUgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBG T05ULVNJWkU6IDhwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgQ09MT1I6IGJsYWNrOyBGT05ULUZB TUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJR046IGp1c3RpZnkNCn0NCkxJLk1zb0Fj ZXRhdGUgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6IDhwdDsg TUFSR0lOOiAwY20gMGNtIDBwdDsgQ09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogIlRpbWVzIE5l dyBSb21hbiI7IFRFWFQtQUxJR046IGp1c3RpZnkNCn0NCkRJVi5Nc29BY2V0YXRlIHsNCglURVhU LUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiA4cHQ7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhU LUFMSUdOOiBqdXN0aWZ5DQp9DQpTUEFOLkVtYWlsU3R5bGUxOCB7DQoJQ09MT1I6IHdpbmRvd3Rl eHQ7IEZPTlQtRkFNSUxZOiBBcmlhbDsgbXNvLXN0eWxlLXR5cGU6IHBlcnNvbmFsDQp9DQpTUEFO LkVtYWlsU3R5bGUxOSB7DQoJQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbDsgbXNvLXN0 eWxlLXR5cGU6IHBlcnNvbmFsLXJlcGx5DQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rp b24xDQp9DQo8L1NUWUxFPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNyIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAg PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPjwvSEVBRD4NCjxCT0RZIGxhbmc9WkgtQ04gdkxpbms9cHVycGxlIGxpbms9 Ymx1ZSBiZ0NvbG9yPXdoaXRlPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9 MjE2MDgyNjEzLTExMTEyMDA5PjxTUEFOIA0KY2xhc3M9MjEyNTQwMzE0LTExMTEyMDA5PjxGT05U IGZhY2U9Q2FsaWJyaSBjb2xvcj0jMDAwMGZmPihyZS1zZW5kaW5nIA0KdG8mbmJzcDtjb21lIHVu ZGVyIG1haWxpbmcgbGlzdCBzaXplIGxpbWl0KTwvRk9OVD48L1NQQU4+PC9TUEFOPjwvRElWPg0K PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MjE2MDgyNjEzLTExMTEyMDA5PjxT UEFOIA0KY2xhc3M9MjEyNTQwMzE0LTExMTEyMDA5PjxGT05UIGZhY2U9Q2FsaWJyaSANCmNvbG9y PSMwMDAwZmY+PC9GT05UPjwvU1BBTj48QlI+PEZPTlQgZmFjZT1DYWxpYnJpPjxGT05UIGNvbG9y PSMwMDAwZmY+QWdyZWVkLCANCkkmbmJzcDt0aGluayBpdCB3b3VsZCBiZSA8U1BBTiANCmNsYXNz PTIxMjU0MDMxNC0xMTExMjAwOT53b3J0aHdoaWxlJm5ic3A7PC9TUEFOPmlmIHlvdSBjb3VsZCBh ZGFwdCB5b3VyIHByb3Bvc2FsIA0KdG8gWENBUCwgcHJlc2VydmluZyB0aGUgYmVuZWZpdCBvZiBj ZW50cmFsIGFjY2VzcyBhbmQgbWFuYWdlbWVudCBvZiB0aGUgUXVpY2sgDQpBbnN3ZXJzIChjYW5u ZWQgcmVzcG9uc2VzKS48U1BBTiBjbGFzcz0yMTI1NDAzMTQtMTExMTIwMDk+ICZuYnNwOzwvU1BB Tj48U1BBTiANCmNsYXNzPTIxMjU0MDMxNC0xMTExMjAwOT5JdCB3b3VsZCBiZSBmcnVpdGZ1bCZu YnNwO3RvIGFkZCBzb21lIG1vcmUgZGlzY3Vzc2lvbiANCm9uIHRoZSBleHBlY3RlZCB1c2VyIGV4 cGVyaWVuY2Ugd2l0aGluIGEgDQpVQS4mbmJzcDs8L1NQQU4+PC9GT05UPjwvRk9OVD48L1NQQU4+ PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0yMTYwODI2MTMtMTEx MTIwMDk+PEZPTlQgZmFjZT1DYWxpYnJpIA0KY29sb3I9IzAwMDBmZj48L0ZPTlQ+PC9TUEFOPiZu YnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MjE2MDgyNjEz LTExMTEyMDA5PjxGT05UIGZhY2U9Q2FsaWJyaT48Rk9OVCANCmNvbG9yPSMwMDAwZmY+QlRXLCBt eSBwcmVmZXJyZWQgc2hvcnQgbmFtZSAoYW5kIGZpcnN0IG5hbWUpIGlzIENvbG08U1BBTiANCmNs YXNzPTIxMjU0MDMxNC0xMTExMjAwOT4uJm5ic3A7PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9TUEFO PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNhbGlicmkgY29sb3I9IzAwMDBmZj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTIxNjA4MjYxMy0xMTExMjAwOT48Rk9OVCBmYWNl PUNhbGlicmkgY29sb3I9IzAwMDBmZj5BbGwgdGhlIA0KYmVzdCw8L0ZPTlQ+PC9TUEFOPjwvRElW Pg0KPERJVj48U1BBTiBjbGFzcz0yMTYwODI2MTMtMTExMTIwMDk+PEZPTlQgZmFjZT1DYWxpYnJp IA0KY29sb3I9IzAwMDBmZj5Db2xtLjwvRk9OVD48L1NQQU4+PC9ESVY+PEJSPg0KPERJViBjbGFz cz1PdXRsb29rTWVzc2FnZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD4NCjxI UiB0YWJJbmRleD0tMT4NCjxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48Qj5Gcm9tOjwvQj4gRGVl cGFuc2h1IFttYWlsdG86ZGVlcGFuc2h1QGh1YXdlaS5jb21dIA0KPEJSPjxCPlNlbnQ6PC9CPiAx MSBOb3ZlbWJlciAyMDA5IDEzOjE3PEJSPjxCPlRvOjwvQj4gU215dGgsIENvbG0gKENvbG0pOyAn QWRhbSANClJvYWNoJzxCUj48Qj5DYzo8L0I+IHNpbXBsZUBpZXRmLm9yZzxCUj48Qj5TdWJqZWN0 OjwvQj4gUkU6IFtTaW1wbGVdIFF1aWNrIA0KQW5zd2VyIGZvbGxvdy11cDxCUj48L0ZPTlQ+PEJS PjwvRElWPg0KPERJVj48L0RJVj4NCjxESVYgY2xhc3M9U2VjdGlvbjEgc3R5bGU9IkxBWU9VVC1H UklEOiAgMTUuNnB0IG5vbmUiPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9bmF2eSBzaXplPTE+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDlw dDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+U3ltdGgsPG86cD48L286cD48L1NQ QU4+PC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9y PW5hdnkgc2l6ZT0xPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IENP TE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwv Rk9OVD48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5 IHNpemU9MT48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogOXB0OyBDT0xPUjog bmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5UaGUgYmVuZWZpdHMgeW91IA0KbWVudGlvbmVkIGZv ciBjZW50cmFsIHN0b3JhZ2UgaXMgZXhhY3RseSB3aGF0IEkgaGFkIGluIG1pbmQgd2hpbGUgY29t aW5nIHVwIHdpdGggDQp0aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQo8 UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9MT48U1BB TiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogOXB0OyBDT0xPUjogbmF2eTsgRk9OVC1G QU1JTFk6IEFyaWFsIj5XaGF0IEkgc2FpZCAoaW4gbXkgbWFpbCANCnRvIFJpY2hhcmQgb25seSwg c29ycnkgZm9yIG5vdCBzZW5kaW5nIHRvIHRoZSBsaXN0KSBpcyBmdXJ0aGVyIGVjaG9lZCBieSB5 b3UgaW4gDQp0ZXJtcyBvZiBiZW5lZml0IGZvciBjZW50cmFsIHN0b3JhZ2UuIDxvOnA+PC9vOnA+ PC9TUEFOPjwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj1uYXZ5IHNpemU9MT48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogOXB0 OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5BcyBmb3IgWENBUCwgaWYgdGhhdCBp cyANCnRoZSBiZXN0IHdheSB0byBkbyBpdCB0aGVuLCBzbyBiZSBpdC48bzpwPjwvbzpwPjwvU1BB Tj48L0ZPTlQ+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 bmF2eSBzaXplPTE+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDlwdDsgQ09M T1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9G T05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkg c2l6ZT0xPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IENPTE9SOiBu YXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+ PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXpl PTE+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDlwdDsgQ09MT1I6IG5hdnk7 IEZPTlQtRkFNSUxZOiBBcmlhbCI+RGVlcGFuc2h1PG86cD48L286cD48L1NQQU4+PC9GT05UPjwv UD4NCjxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0x PjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IENPTE9SOiBuYXZ5OyBG T05ULUZBTUlMWTogQXJpYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQo8 UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9MT48U1BB TiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogOXB0OyBDT0xPUjogbmF2eTsgRk9OVC1G QU1JTFk6IEFyaWFsIj4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9MT48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9 IkZPTlQtU0laRTogOXB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5UbzogDQpS aWNoYXJkPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0iVEVYVC1BTElHTjogbGVmdCIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPUFyaWFsIA0KY29s b3I9bmF2eSBzaXplPTE+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDlwdDsg Q09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Jmd0OzwvU1BBTj48L0ZPTlQ+PEZPTlQg DQpjb2xvcj1ibGFjayBzaXplPTM+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAx MnB0OyBDT0xPUjogd2luZG93dGV4dCI+IA0KSXQncyBldmVuIGxlc3MgY2xlYXIgdG8gbWUgdGhh dCBpdCBuZWVkcyB0byBiZSBzb21ldGhpbmcgdGhhdCdzIGRvbmUgaW4gdGhlIA0KbmV0d29yazwv U1BBTj48L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9MT48U1BBTiBsYW5n PUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogOXB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6 IEFyaWFsIj48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0IiBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9QXJpYWwgDQpj b2xvcj1uYXZ5IHNpemU9MT48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogOXB0 OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5BcyBJIG1lbnRpb25lZCB0aGF0IA0K dG9kYXnigJlzIElNIHN5c3RlbXMgYWxsb3cgZGlmZmVyZW50IGNsaWVudCBkZXZpY2UgdG8gbG9n LWluIElNIHN5c3RlbSBhdCANCmRpZmZlcmVudCBwb2ludCBvZiB0aW1lLjxvOnA+PC9vOnA+PC9T UEFOPjwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9IlRFWFQtQUxJR046IGxl ZnQiIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1BcmlhbCANCmNvbG9yPW5hdnkgc2l6ZT0xPjxTUEFO IGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZB TUlMWTogQXJpYWwiPknigJltIGNyZWF0aW5nIGEgUUEgdG9kYXkgDQp3aXRoIG15IFBEQSAoYXMg bXkgY2xpZW50IGRldmljZSkuIFRvbW9ycm93IHdoZW4gSeKAmWxsIGJlIGxvZ2dpbmctaW4gdXNp bmcgbXkgDQptb2JpbGUgcGhvbmUgSSB3YW50IHRoYXQgUUEsIGNyZWF0ZWQgdXNpbmcgUERBLCBh dmFpbGFibGUgaW4gbXkgbW9iaWxlIHBob25lLiANCkhvdyB0aGF0IGNhbiBiZSBkb25lIHdpdGhv dXQgc3RvcmluZyB0aGF0IFFBIHNvbWV3aGVyZSBpbiB0aGUgDQpuZXR3b3JrPzxvOnA+PC9vOnA+ PC9TUEFOPjwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9IlRFWFQtQUxJR046 IGxlZnQiIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1BcmlhbCANCmNvbG9yPW5hdnkgc2l6ZT0xPjxT UEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IENPTE9SOiBuYXZ5OyBGT05U LUZBTUlMWTogQXJpYWwiPiZndDsgPC9TUEFOPjwvRk9OVD48Rk9OVCANCmNvbG9yPWJsYWNrIHNp emU9Mz48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgQ09MT1I6IHdp bmRvd3RleHQiPnN1cmVseSBhIFVBIGNvdWxkIGJlIHByb3Zpc2lvbmVkIHdpdGggDQp0aGUgcmln aHQgUUEgdG8gc2VuZCBiYWNrPzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQo8UCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQiIGFsaWduPWxlZnQ+PEZPTlQgZmFj ZT1BcmlhbCANCmNvbG9yPW5hdnkgc2l6ZT0xPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9O VC1TSVpFOiA5cHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPlllcywgaXQgY2Fu IGJlLCBpZiANCmRldmljZSBtYW51ZmFjdHVyZXIgcHJlLWNvbmZpZ3VyZWQgdGhlbSBpbnRvIHRo ZSBkZXZpY2UuIEJ1dCBoZXJlIEnigJltIHRhbGtpbmcgDQphYm91dCAqPEI+PFNQQU4gc3R5bGU9 IkZPTlQtV0VJR0hUOiBib2xkIj51c2VyPC9TUEFOPjwvQj4qIGNyZWF0aW5nIHRoZW0gYW5kIA0K dGhlbiB1c2luZyB0aGVtLjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQo8UCBjbGFzcz1N c29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9MT48U1BBTiBsYW5nPUVO LVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogOXB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFy aWFsIj4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8bzpw PjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9bmF2eSBzaXplPTE+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJ WkU6IDlwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJzcDs8L286 cD48L1NQQU4+PC9GT05UPjwvUD4NCjxESVYgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJURVhULUFM SUdOOiBjZW50ZXIiIGFsaWduPWNlbnRlcj48Rk9OVCANCmZhY2U9IlRpbWVzIE5ldyBSb21hbiIg Y29sb3I9YmxhY2sgc2l6ZT0zPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAx MnB0OyBDT0xPUjogd2luZG93dGV4dCI+DQo8SFIgdGFiSW5kZXg9LTEgYWxpZ249Y2VudGVyIHdp ZHRoPSIxMDAlIiBTSVpFPTI+DQo8L1NQQU4+PC9GT05UPjwvRElWPg0KPFAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0IiBhbGlnbj1sZWZ0PjxCPjxGT05UIGZhY2U9VGFo b21hIA0KY29sb3I9YmxhY2sgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1X RUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogMTBwdDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtRkFN SUxZOiBUYWhvbWEiPkZyb206PC9TUEFOPjwvRk9OVD48L0I+PEZPTlQgDQpmYWNlPVRhaG9tYSBj b2xvcj1ibGFjayBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IENPTE9SOiB3aW5kb3d0ZXh0OyBGT05ULUZBTUlMWTogVGFob21hIj4gU215dGgsIENvbG0g DQooQ29sbSkgW21haWx0bzpzbXl0aGNAYXZheWEuY29tXSA8QlI+PEI+PFNQQU4gDQpzdHlsZT0i Rk9OVC1XRUlHSFQ6IGJvbGQiPlNlbnQ6PC9TUEFOPjwvQj4gMjAwOTwvU1BBTj48L0ZPTlQ+PEZP TlQgZmFjZT3lrovkvZMgDQpjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4gDQpzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBDT0xPUjogd2luZG93dGV4dDsgRk9OVC1GQU1JTFk6IOWui+S9kyI+5bm0PC9T UEFOPjwvRk9OVD48Rk9OVCANCmZhY2U9VGFob21hIGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiBs YW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZP TlQtRkFNSUxZOiBUYWhvbWEiPjExPC9TUEFOPjwvRk9OVD48Rk9OVCANCmZhY2U95a6L5L2TIGNv bG9yPWJsYWNrIHNpemU9Mj48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiB3 aW5kb3d0ZXh0OyBGT05ULUZBTUlMWTog5a6L5L2TIj7mnIg8L1NQQU4+PC9GT05UPjxGT05UIA0K ZmFjZT1UYWhvbWEgY29sb3I9YmxhY2sgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogd2luZG93dGV4dDsgRk9OVC1GQU1JTFk6IFRhaG9tYSI+ MTE8L1NQQU4+PC9GT05UPjxGT05UIA0KZmFjZT3lrovkvZMgY29sb3I9YmxhY2sgc2l6ZT0yPjxT UEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtRkFN SUxZOiDlrovkvZMiPuaXpTwvU1BBTj48L0ZPTlQ+PEZPTlQgDQpmYWNlPVRhaG9tYSBjb2xvcj1i bGFjayBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENP TE9SOiB3aW5kb3d0ZXh0OyBGT05ULUZBTUlMWTogVGFob21hIj4gDQoyMDo1MDxCUj48Qj48U1BB TiBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPlRvOjwvU1BBTj48L0I+IEFkYW0gUm9hY2g7IA0K RGVlcGFuc2h1PEJSPjxCPjxTUEFOIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+Q2M6PC9TUEFO PjwvQj4gDQpzaW1wbGVAaWV0Zi5vcmc8QlI+PEI+PFNQQU4gc3R5bGU9IkZPTlQtV0VJR0hUOiBi b2xkIj5TdWJqZWN0OjwvU1BBTj48L0I+IFJFOiANCltTaW1wbGVdIFF1aWNrIEFuc3dlciBmb2xs b3ctdXA8L1NQQU4+PC9GT05UPjxGT05UIGNvbG9yPWJsYWNrIHNpemU9Mz48U1BBTiANCmxhbmc9 RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBDT0xPUjogd2luZG93dGV4dCI+PG86cD48 L286cD48L1NQQU4+PC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iVEVYVC1B TElHTjogbGVmdCIgYWxpZ249bGVmdD48Rk9OVCANCmZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29s b3I9YmxhY2sgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMC41 cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29Ob3Jt YWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4g DQpsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwLjVwdCI+PCEtLVtpZiBndGUgdm1sIDFd Pjx2OnNoYXBldHlwZSBpZD0iX3gwMDAwX3Q3NCIgDQogY29vcmRzaXplPSIyMTYwMCwyMTYwMCIg bzpzcHQ9Ijc0IiBwYXRoPSJtMTA4NjAsMjE4N2MxMDQ1MSwxNzQ2LDk1MjksMTAxOCw5MDE1LDcz MCw3ODY1LDE1Miw2Njg1LCw1NDE1LCw0MTc1LDE1MiwyOTk1LDU3NSwxOTY3LDEzMDUsMTE1MCwy MTg3LDU3NSwzMjIyLDI0Miw0MjIwLCw1NDEwLDI0Miw2NTYwLDU3NSw3NTk3bDEwODYwLDIxNjAw LDIwOTk1LDc1OTd2NDg1LC0xMDM3LDYwNSwtMjE4Nyw0ODUsLTMzNzdjMjExMTUsMzIyMiwyMDQy MCwyMTg3LDE5NjMyLDEzMDUsMTg1NzUsNTc1LDE3NDI1LDE1MiwxNjI3NSwsMTUwMDUsLDEzNzM1 LDE1MiwxMjcwNSw3MzB2LTUyOSwyODgsLTE0NTEsMTAxNiwtMTg0NSwxNDU3eGUiPg0KIDx2OnN0 cm9rZSBqb2luc3R5bGU9Im1pdGVyIiAvPg0KIDx2OnBhdGggZ3JhZGllbnRzaGFwZW9rPSJ0IiBv OmNvbm5lY3R0eXBlPSJjdXN0b20iIG86Y29ubmVjdGxvY3M9IjEwODYwLDIxODc7MjkyOCwxMDgw MDsxMDg2MCwyMTYwMDsxODY3MiwxMDgwMCIgDQogIG86Y29ubmVjdGFuZ2xlcz0iMjcwLDE4MCw5 MCwwIiB0ZXh0Ym94cmVjdD0iNTAzNywyMjc3LDE2NTU3LDEzNjc3IiAvPg0KPC92OnNoYXBldHlw ZT48djpzaGFwZSBpZD0iRHRzU2hhcGVOYW1lIiBvOnNwaWQ9Il94MDAwMF9zMTAyNiIgdHlwZT0i I194MDAwMF90NzQiIA0KIGFsdD0iU0xSXkdASE1eTlFETzI4QDY0QjI0RUQ1RTUwQDVDODgwODo3 QiZsdDs4OjtBQEtYUjkxNDQ3MzAhIUJJSE9AXUU0NjQyMCEhITk0NEUwMDkwMTEwRzJDQDRCNEM0 T25zbGBtL2VudSEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISExITEiIA0KIHN0eWxlPSdwb3NpdGlvbjphYnNvbHV0 ZTtsZWZ0OjA7dGV4dC1hbGlnbjpsZWZ0O21hcmdpbi1sZWZ0OjA7bWFyZ2luLXRvcDowOw0KIHdp ZHRoOi4wNXB0O2hlaWdodDouMDVwdDt6LWluZGV4OjE7dmlzaWJpbGl0eTpoaWRkZW4nPg0KIDx3 OmFuY2hvcmxvY2svPg0KPC92OnNoYXBlPjwhW2VuZGlmXS0tPjwvU1BBTj48L0ZPTlQ+PEZPTlQg ZmFjZT1DYWxpYnJpIGNvbG9yPWJsdWU+PFNQQU4gDQpsYW5nPUVOLVVTIHN0eWxlPSJDT0xPUjog Ymx1ZTsgRk9OVC1GQU1JTFk6IENhbGlicmkiPkxpa2UgUmljaGFyZCwgSSBiZWxpZXZlIHRoZSAN ClF1aWNrIEFuc3dlciAoUUEpIHJlcXVpcmVtZW50IGNhbiBiZSBtZXQgZW50aXJlbHkgd2l0aGlu IHRoZSBVQSBpbXBsZW1lbnRhdGlvbiwgDQpwb3RlbnRpYWxseSB1c2luZyBsb2NhbCBzdG9yYWdl LjwvU1BBTj48L0ZPTlQ+PFNQQU4gDQpsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4N CjxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPWJs YWNrIHNpemU9Mj48U1BBTiANCmxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTAuNXB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U9Q2FsaWJyaSBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5 bGU9IkZPTlQtU0laRTogMTAuNXB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IENhbGlicmki PlRoZXJlIGlzIHNvbWUgDQpiZW5lZml0IGluIHRoaXMgcHJvcG9zYWwncyBjZW50cmFsIHN0b3Jh Z2Ugb2YgdGhlIFFBJ3MsIHdoaWNoIGVuYWJsZXMgbW9iaWxpdHkgDQpvZiB0aGUgZW5kcG9pbnQs IG9yIHBvdGVudGlhbGx5IHNoYXJpbmcgdGhlIFFBJ3MgYWNyb3NzIGEgdXNlcidzIGVuZHBvaW50 cy4gDQpIb3dldmVyIEkgYWdyZWUgd2l0aCBBZGFtIHRoYXQgWENBUCBzZWVtcyBhIG1vcmUgbmF0 dXJhbCBtZWNoYW5pc20gZm9yIHRoaXMga2luZCANCm9mIGRhdGEsIG1vcmUgc28gdGhhbiBvdmVy bG9hZGluZyB0aGUgU0lQIFJFR0lTVEVSIGFuZCBJTlZJVEUgDQptZXRob2RzLjwvU1BBTj48L0ZP TlQ+PFNQQU4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29O b3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj1ibGFjayBzaXplPTI+PFNQ QU4gDQpsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwLjVwdCI+Jm5ic3A7PG86cD48L286 cD48L1NQQU4+PC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUNhbGli cmkgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6 IDEwLjVwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBDYWxpYnJpIj5CVFcsIHRoZSB0ZXJt IA0KImNhbm5lZCByZXNwb25zZSIgaXMgdXNlZCBlbHNld2hlcmU6PC9TUEFOPjwvRk9OVD48U1BB TiANCmxhbmc9RU4tVVM+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFs PjxGT05UIGZhY2U9Q2FsaWJyaSBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0K c3R5bGU9IkZPTlQtU0laRTogMTAuNXB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IENhbGli cmkiPi0gPEEgDQpocmVmPSJodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0Nhbm5lZF9yZXNw b25zZSI+aHR0cDovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9DYW5uZWRfcmVzcG9uc2U8L0E+PC9T UEFOPjwvRk9OVD48U1BBTiANCmxhbmc9RU4tVVM+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAg Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9Q2FsaWJyaSBjb2xvcj1ibHVlIHNpemU9Mj48U1BB TiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTAuNXB0OyBDT0xPUjogYmx1ZTsgRk9O VC1GQU1JTFk6IENhbGlicmkiPi0gPEEgDQpocmVmPSJodHRwOi8vZ21haWxibG9nLmJsb2dzcG90 LmNvbS8yMDA4LzEwL25ldy1pbi1sYWJzLWNhbm5lZC1yZXNwb25zZXMuaHRtbCI+aHR0cDovL2dt YWlsYmxvZy5ibG9nc3BvdC5jb20vMjAwOC8xMC9uZXctaW4tbGFicy1jYW5uZWQtcmVzcG9uc2Vz Lmh0bWw8L0E+PC9TUEFOPjwvRk9OVD48U1BBTiANCmxhbmc9RU4tVVM+PG86cD48L286cD48L1NQ QU4+PC9QPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iIGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiANCmxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTAuNXB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0K PERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUNhbGlicmkgY29sb3I9Ymx1ZSBz aXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEwLjVwdDsgQ09MT1I6 IGJsdWU7IEZPTlQtRkFNSUxZOiBDYWxpYnJpIj5BbGwgdGhlIA0KYmVzdCw8L1NQQU4+PC9GT05U PjxTUEFOIGxhbmc9RU4tVVM+PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KPERJVj4NCjxQ IGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUNhbGlicmkgY29sb3I9Ymx1ZSBzaXplPTI+PFNQ QU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEwLjVwdDsgQ09MT1I6IGJsdWU7IEZP TlQtRkFNSUxZOiBDYWxpYnJpIj5Db2xtLjwvU1BBTj48L0ZPTlQ+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQogPHUxOnNoYXBlZGVmYXVsdHMgdTI6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI3Ii8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8dTM6c2hhcGVs YXlvdXQgdTQ6ZXh0PSJlZGl0Ij4NCiAgPHUzOmlkbWFwIHU0OmV4dD0iZWRpdCIgZGF0YT0iMSIv Pg0KIDwvdTM6c2hhcGVsYXlvdXQ+DQo8L3htbD48IVtlbmRpZl0tLT48L1A+PC9ESVY+PC9ESVY+ PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01CA62DD.9ED0F7BC-- From deepanshu@huawei.com Wed Nov 11 06:52:51 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 402D83A68B5 for ; Wed, 11 Nov 2009 06:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.136 X-Spam-Level: X-Spam-Status: No, score=-0.136 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDy+Cw3jtWS3 for ; Wed, 11 Nov 2009 06:52:50 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 3D1523A67A1 for ; Wed, 11 Nov 2009 06:52:49 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSY001YD9CI8N@szxga03-in.huawei.com> for simple@ietf.org; Wed, 11 Nov 2009 22:53:06 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSY00FA19CILC@szxga03-in.huawei.com> for simple@ietf.org; Wed, 11 Nov 2009 22:53:06 +0800 (CST) Received: from jys8055621 (222-151-138-069.jp.fiberbit.net [222.151.138.69]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSY007IT9C8ZL@szxml02-in.huawei.com>; Wed, 11 Nov 2009 22:53:06 +0800 (CST) Date: Wed, 11 Nov 2009 22:53:04 +0800 From: Deepanshu In-reply-to: <4C607BEA097DF048BEA625B974A36618DC5801@306900ANEX2.global.avaya.com> To: "'Smyth, Colm (Colm)'" , 'Adam Roach' Message-id: <007801ca62de$ad654f40$0af01eac@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_TvyTdmBf3sHsiepWaMxqoQ)" Thread-index: AcpigUqMMCImhw3ARbi6TPXy7R8aagASspLQAADhRHAAALtHgAABUaogAAGrKrA= Cc: simple@ietf.org Subject: Re: [Simple] Quick Answer follow-up X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 14:52:51 -0000 This is a multi-part message in MIME format. --Boundary_(ID_TvyTdmBf3sHsiepWaMxqoQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable (resending, with less size) =20 Sure, I=A1=AFll do that. Thanks for your suggestion Colm (I go it).=20 In case anyone has any other suggestion/comments/opinion please let me = know. =20 Regards Deepanshu =20 _____ =20 From: Smyth, Colm (Colm) [mailto:smythc@avaya.com]=20 Sent: 2009=C4=EA11=D4=C211=C8=D5 22:45 To: Deepanshu; Adam Roach Cc: simple@ietf.org Subject: RE: [Simple] Quick Answer follow-up =20 (re-sending to come under mailing list size limit) Agreed, I think it would be worthwhile if you could adapt your proposal = to XCAP, preserving the benefit of central access and management of the = Quick Answers (canned responses). It would be fruitful to add some more discussion on the expected user experience within a UA.=20 =20 BTW, my preferred short name (and first name) is Colm.=20 =20 All the best, Colm. =20 _____ =20 From: Deepanshu [mailto:deepanshu@huawei.com]=20 Sent: 11 November 2009 13:17 To: Smyth, Colm (Colm); 'Adam Roach' Cc: simple@ietf.org Subject: RE: [Simple] Quick Answer follow-up Symth, =20 The benefits you mentioned for central storage is exactly what I had in = mind while coming up with this draft. What I said (in my mail to Richard only, sorry for not sending to the = list) is further echoed by you in terms of benefit for central storage.=20 As for XCAP, if that is the best way to do it then, so be it. =20 Regards Deepanshu =20 *********************************************** To: Richard > It's even less clear to me that it needs to be something that's done = in the network As I mentioned that today=A1=AFs IM systems allow different client = device to log-in IM system at different point of time. I=A1=AFm creating a QA today with my PDA (as my client device). Tomorrow = when I=A1=AFll be logging-in using my mobile phone I want that QA, created = using PDA, available in my mobile phone. How that can be done without storing that = QA somewhere in the network? > surely a UA could be provisioned with the right QA to send back? Yes, it can be, if device manufacturer pre-configured them into the = device. But here I=A1=AFm talking about *user* creating them and then using = them. ************************************************ =20 _____ =20 From: Smyth, Colm (Colm) [mailto:smythc@avaya.com]=20 Sent: 2009=C4=EA11=D4=C211=C8=D5 20:50 To: Adam Roach; Deepanshu Cc: simple@ietf.org Subject: RE: [Simple] Quick Answer follow-up =20 Like Richard, I believe the Quick Answer (QA) requirement can be met entirely within the UA implementation, potentially using local storage. =20 There is some benefit in this proposal's central storage of the QA's, = which enables mobility of the endpoint, or potentially sharing the QA's across = a user's endpoints. However I agree with Adam that XCAP seems a more = natural mechanism for this kind of data, more so than overloading the SIP = REGISTER and INVITE methods. =20 BTW, the term "canned response" is used elsewhere: - http://en.wikipedia.org/wiki/Canned_response - = http://gmailblog.blogspot.com/2008/10/new-in-labs-canned-responses.html =20 All the best, Colm. --Boundary_(ID_TvyTdmBf3sHsiepWaMxqoQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

(resending, with = less size)

 <= /span>

Sure, I=A1=AFll do that.

Thanks for your suggestion Colm (I go it). =

In case anyone has any other suggestion/comments/opinion = please let me know.

 

Regards

Deepanshu

 <= /span>

From: Smyth, Colm (Colm) [mailto:smythc@avaya.com] =
Sent: = 2009=C4=EA11<= /font>=D4=C211<= /font>=C8=D5 = 22:45
To: Deepanshu; Adam = Roach
Cc: simple@ietf.org
Subject: RE: [Simple] = Quick Answer follow-up

 

(re-sending to come under mailing list size limit)


= Agreed, = I think it would be worthwhile if you could adapt your proposal to XCAP, = preserving the benefit of central access and management of the Quick Answers = (canned responses).  It would be fruitful to add some more discussion = on the expected user experience within a UA. 

&nbs= p;

BTW, my preferred short name (and first name) is = Colm. 

&nbs= p;

All the best,

Colm.

 

From:= Deepanshu = [mailto:deepanshu@huawei.com]
Sent: 11 November 2009 = 13:17
To: Smyth, Colm (Colm); = 'Adam Roach'
Cc: simple@ietf.org
Subject: RE: [Simple] = Quick Answer follow-up

Symth,

 

The benefits you mentioned for central storage is exactly = what I had in mind while coming up with this = draft.

What I said (in my mail to Richard only, sorry for not = sending to the list) is further echoed by you in terms of benefit for central = storage.

As for XCAP, if that is the best way to do it then, so be = it.

 

Regards

Deepanshu

 

***********************************************

To: Richard

> It's even less = clear to me that it needs to be something that's done in the = network

As I mentioned that today=A1=AFs IM = systems allow different client device to log-in IM system at different point of = time.

I=A1=AFm creating a QA today with my PDA = (as my client device). Tomorrow when I=A1=AFll be logging-in using my mobile phone I = want that QA, created using PDA, available in my mobile phone. How that can be done = without storing that QA somewhere in the network?

> surely a UA = could be provisioned with the right QA to send back?

Yes, it can be, if device manufacturer pre-configured them into the device. But here I=A1=AFm talking about = *user* creating them and then using = them.

************************************************

 

From:= Smyth, Colm (Colm) [mailto:smythc@avaya.com]
Sent: = 2009=C4=EA11<= /font>=D4=C211<= /font>=C8=D5 = 20:50
To: Adam Roach; = Deepanshu
Cc: simple@ietf.org
Subject: RE: [Simple] = Quick Answer follow-up

=

 

Like Richard, I = believe the Quick Answer (QA) requirement can be met entirely within the UA = implementation, potentially using local storage.

 

There is some benefit in this proposal's central storage of = the QA's, which enables mobility of the endpoint, or potentially sharing the = QA's across a user's endpoints. However I agree with Adam that XCAP seems a = more natural mechanism for this kind of data, more so than overloading the SIP = REGISTER and INVITE methods.

 

BTW, the term "canned response" is used = elsewhere:

- http://en.wikipedia= .org/wiki/Canned_response

- http://gmailblog.blogspot.com/2008/10/new-in-labs-canned-response= s.html

 

All the best,

Colm.

--Boundary_(ID_TvyTdmBf3sHsiepWaMxqoQ)-- From smythc@avaya.com Wed Nov 11 05:30:32 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6805C3A69E4 for ; Wed, 11 Nov 2009 05:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2dN5dT+0EE1 for ; Wed, 11 Nov 2009 05:30:30 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 4D34A3A6895 for ; Wed, 11 Nov 2009 05:30:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,723,1249272000"; d="scan'208,217";a="162926221" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Nov 2009 08:30:54 -0500 Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.152]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Nov 2009 08:30:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA62D3.2B6A4CBA" Date: Wed, 11 Nov 2009 13:28:11 -0000 Message-ID: <4C607BEA097DF048BEA625B974A36618DC5797@306900ANEX2.global.avaya.com> In-Reply-To: <004d01ca62d1$6c10d5d0$0af01eac@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Quick Answer follow-up thread-index: AcpigUqMMCImhw3ARbi6TPXy7R8aagASspLQAADhRHAAALtHgA== References: <4C607BEA097DF048BEA625B974A36618DC575D@306900ANEX2.global.avaya.com> <004d01ca62d1$6c10d5d0$0af01eac@china.huawei.com> From: "Smyth, Colm (Colm)" To: "Deepanshu" , "Adam Roach" X-Mailman-Approved-At: Wed, 11 Nov 2009 14:34:34 -0800 Cc: simple@ietf.org Subject: Re: [Simple] Quick Answer follow-up X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 13:30:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA62D3.2B6A4CBA Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 QWdyZWVkLCBJIHRoaW5rIGl0IHdvdWxkIGJlIHZhbHVhYmxlIGlmIHlvdSBjb3VsZCBhZGFwdCB5 b3VyIHByb3Bvc2FsIHRvIFhDQVAsIHByZXNlcnZpbmcgdGhlIGJlbmVmaXQgb2YgY2VudHJhbCBh Y2Nlc3MgYW5kIG1hbmFnZW1lbnQgb2YgdGhlIFF1aWNrIEFuc3dlcnMgKGNhbm5lZCByZXNwb25z ZXMpLg0KIA0KQlRXLCBteSBwcmVmZXJyZWQgc2hvcnQgbmFtZSAoYW5kIGZpcnN0IG5hbWUpIGlz IENvbG0gOykNCiANCkFsbCB0aGUgYmVzdCwNCkNvbG0uDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCkZyb206IERlZXBhbnNodSBbbWFpbHRvOmRlZXBhbnNodUBodWF3ZWku Y29tXSANClNlbnQ6IDExIE5vdmVtYmVyIDIwMDkgMTM6MTcNClRvOiBTbXl0aCwgQ29sbSAoQ29s bSk7ICdBZGFtIFJvYWNoJw0KQ2M6IHNpbXBsZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtTaW1w bGVdIFF1aWNrIEFuc3dlciBmb2xsb3ctdXANCg0KDQoNClN5bXRoLA0KDQogDQoNClRoZSBiZW5l Zml0cyB5b3UgbWVudGlvbmVkIGZvciBjZW50cmFsIHN0b3JhZ2UgaXMgZXhhY3RseSB3aGF0IEkg aGFkIGluIG1pbmQgd2hpbGUgY29taW5nIHVwIHdpdGggdGhpcyBkcmFmdC4NCg0KV2hhdCBJIHNh aWQgKGluIG15IG1haWwgdG8gUmljaGFyZCBvbmx5LCBzb3JyeSBmb3Igbm90IHNlbmRpbmcgdG8g dGhlIGxpc3QpIGlzIGZ1cnRoZXIgZWNob2VkIGJ5IHlvdSBpbiB0ZXJtcyBvZiBiZW5lZml0IGZv ciBjZW50cmFsIHN0b3JhZ2UuIA0KDQpBcyBmb3IgWENBUCwgaWYgdGhhdCBpcyB0aGUgYmVzdCB3 YXkgdG8gZG8gaXQgdGhlbiwgc28gYmUgaXQuDQoNCiANCg0KUmVnYXJkcw0KDQpEZWVwYW5zaHUN Cg0KIA0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K DQpUbzogUmljaGFyZA0KDQo+IEl0J3MgZXZlbiBsZXNzIGNsZWFyIHRvIG1lIHRoYXQgaXQgbmVl ZHMgdG8gYmUgc29tZXRoaW5nIHRoYXQncyBkb25lIGluIHRoZSBuZXR3b3JrDQoNCkFzIEkgbWVu dGlvbmVkIHRoYXQgdG9kYXnigJlzIElNIHN5c3RlbXMgYWxsb3cgZGlmZmVyZW50IGNsaWVudCBk ZXZpY2UgdG8gbG9nLWluIElNIHN5c3RlbSBhdCBkaWZmZXJlbnQgcG9pbnQgb2YgdGltZS4NCg0K SeKAmW0gY3JlYXRpbmcgYSBRQSB0b2RheSB3aXRoIG15IFBEQSAoYXMgbXkgY2xpZW50IGRldmlj ZSkuIFRvbW9ycm93IHdoZW4gSeKAmWxsIGJlIGxvZ2dpbmctaW4gdXNpbmcgbXkgbW9iaWxlIHBo b25lIEkgd2FudCB0aGF0IFFBLCBjcmVhdGVkIHVzaW5nIFBEQSwgYXZhaWxhYmxlIGluIG15IG1v YmlsZSBwaG9uZS4gSG93IHRoYXQgY2FuIGJlIGRvbmUgd2l0aG91dCBzdG9yaW5nIHRoYXQgUUEg c29tZXdoZXJlIGluIHRoZSBuZXR3b3JrPw0KDQo+IHN1cmVseSBhIFVBIGNvdWxkIGJlIHByb3Zp c2lvbmVkIHdpdGggdGhlIHJpZ2h0IFFBIHRvIHNlbmQgYmFjaz8NCg0KWWVzLCBpdCBjYW4gYmUs IGlmIGRldmljZSBtYW51ZmFjdHVyZXIgcHJlLWNvbmZpZ3VyZWQgdGhlbSBpbnRvIHRoZSBkZXZp Y2UuIEJ1dCBoZXJlIEnigJltIHRhbGtpbmcgYWJvdXQgKnVzZXIqIGNyZWF0aW5nIHRoZW0gYW5k IHRoZW4gdXNpbmcgdGhlbS4NCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqDQoNCiANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K RnJvbTogU215dGgsIENvbG0gKENvbG0pIFttYWlsdG86c215dGhjQGF2YXlhLmNvbV0gDQpTZW50 OiAyMDA55bm0MTHmnIgxMeaXpSAyMDo1MA0KVG86IEFkYW0gUm9hY2g7IERlZXBhbnNodQ0KQ2M6 IHNpbXBsZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtTaW1wbGVdIFF1aWNrIEFuc3dlciBmb2xs b3ctdXANCg0KIA0KDQpMaWtlIFJpY2hhcmQsIEkgYmVsaWV2ZSB0aGUgUXVpY2sgQW5zd2VyIChR QSkgcmVxdWlyZW1lbnQgY2FuIGJlIG1ldCBlbnRpcmVseSB3aXRoaW4gdGhlIFVBIGltcGxlbWVu dGF0aW9uLCBwb3RlbnRpYWxseSB1c2luZyBsb2NhbCBzdG9yYWdlLg0KDQogDQoNClRoZXJlIGlz IHNvbWUgYmVuZWZpdCBpbiB0aGlzIHByb3Bvc2FsJ3MgY2VudHJhbCBzdG9yYWdlIG9mIHRoZSBR QSdzLCB3aGljaCBlbmFibGVzIG1vYmlsaXR5IG9mIHRoZSBlbmRwb2ludCwgb3IgcG90ZW50aWFs bHkgc2hhcmluZyB0aGUgUUEncyBhY3Jvc3MgYSB1c2VyJ3MgZW5kcG9pbnRzLiBIb3dldmVyIEkg YWdyZWUgd2l0aCBBZGFtIHRoYXQgWENBUCBzZWVtcyBhIG1vcmUgbmF0dXJhbCBtZWNoYW5pc20g Zm9yIHRoaXMga2luZCBvZiBkYXRhLCBtb3JlIHNvIHRoYW4gb3ZlcmxvYWRpbmcgdGhlIFNJUCBS RUdJU1RFUiBhbmQgSU5WSVRFIG1ldGhvZHMuDQoNCiANCg0KQlRXLCB0aGUgdGVybSAiY2FubmVk IHJlc3BvbnNlIiBpcyB1c2VkIGVsc2V3aGVyZToNCg0KLSBodHRwOi8vZW4ud2lraXBlZGlhLm9y Zy93aWtpL0Nhbm5lZF9yZXNwb25zZQ0KDQotIGh0dHA6Ly9nbWFpbGJsb2cuYmxvZ3Nwb3QuY29t LzIwMDgvMTAvbmV3LWluLWxhYnMtY2FubmVkLXJlc3BvbnNlcy5odG1sDQoNCiANCg0KQWxsIHRo ZSBiZXN0LA0KDQpDb2xtLg0KDQogDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNCkZyb206IHNpbXBsZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2ltcGxlLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZGFtIFJvYWNoDQpTZW50OiAxMSBOb3ZlbWJlciAyMDA5 IDAzOjQ0DQpUbzogRGVlcGFuc2h1DQpDYzogc2ltcGxlQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W1NpbXBsZV0gUXVpY2sgQW5zd2VyIGZvbGxvdy11cA0KDQoJRGVhciBBbGwsDQoNCglBcyBtZW50 aW9uZWQgaW4gdGhlIHNlc3Npb24sIEkgd291bGQgbGlrZSB0byBnZXQgeW91ciBvcGluaW9uIGJ5 IGVtYWlsLg0KDQoJQmFzaWNhbGx5IEkgd291bGQgbGlrZSB0byBrbm93IHRoZSBmb2xsb3dpbmcN Cg0KCTwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT4xLiAgICAgICA8IS0tW2VuZGlmXS0tPkRvIHlv dSB0aGluayB0aGF0IHRoZSBjb25jZXB0IG9mIFF1aWNrIEFuc3dlciAoYXMgSSBleHBsYWluZWQg d2hpbGUgcHJlc2VudGluZykgaXRzZWxmLCBpcyBmZWFzaWJsZS9uZWVkZWQgZm9yIGN1cnJlbnQg SU0gc3lzdGVtcy4gSW4gb3RoZXIgd29yZHMgaXMgaXQgYWR2YW50YWdlb3VzIHRvIGhhdmUgaXQg aW4gdG9kYXkgSU0gc2VydmljZT8NCg0KCTwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT4yLiAgICAg ICA8IS0tW2VuZGlmXS0tPklmIHlvdXIgYW5zd2VyIGlzIOKAnFllc+KAnSBvciBldmVuIOKAnE1h eSBiZeKAnS4gVGhlbiBkbyB5b3UgdGhpbmsgc29tZXRoaW5nIGlzIG5lZWRlZCB0byBiZSBkZWZp bmVkIChzdGFuZGFyZGl6ZWQpIGFib3V0IHRoYXQgaW4gSUVURj8gDQoNCgk8IS0tW2lmICFzdXBw b3J0TGlzdHNdLS0+My4gICAgICAgPCEtLVtlbmRpZl0tLT5JZiB5b3UgYW5zd2VyIGluIOKAnFll c+KAnSBvciBldmVuIOKAnE1heSBiZeKAnS4gVGhlbiBJIGtpbmRseSByZXF1ZXN0IHlvdSB0byBw bGVhc2UgbmFtZSBzb21lIG9mIHRob3NlIHRoaW5ncyAoaW5zdGVhZCBvZiB0aGUgc29sdXRpb24g ZGVmaW5lZCBpbiB0aGUgZHJhZnQpIHdoaWNoIHlvdSBleHBlY3QgdG8gYmUgdXNlZC9leHRlbmRl ZCBmb3IgdGhpcyBwdXJwb3NlLiBlLGcgWENBUC4gVGhpcyB3aWxsIGFzc2lzdCBtZSB0byBwcm92 aWRlIHNvbWUgZ2FwIGFuYWx5c2VzLCBpZiBhbnkuDQoNCg0KSSdtIG5vdCAxMDAlIGNvbnZpbmNl ZCB0aGF0IHdlIG5lZWQgdGhpcyBtZWNoYW5pc20sIGJ1dCBJJ20gd2lsbGluZyB0byBlbnRlcnRh aW4gcmVxdWlyZW1lbnRzIHJlbGF0aW5nIHRvIGl0Lg0KDQpJZiB0aGlzIG1lY2hhbmlzbSBpcyBw dXJzdWVkLCBpdCB3b3VsZCBzZWVtIHRvIG1ha2Ugc2Vuc2UgdG8gaGF2ZSBzb21ldGhpbmcgc3Rh bmRhcmRpemVkLg0KDQpJbiB0ZXJtcyBvZiBleGlzdGluZyBtZWNoYW5pc21zLCBJIHdvdWxkIHRo aW5rIHRoZSBtb3N0IHByb21pc2luZyBhcHByb2FjaGVzIHdvdWxkIGJlIGVpdGhlciBYQ0FQLCBv ciBiYXJlIEhUVFAgKFBVVCBhbmQgR0VUKS4NCg0KL2EgDQoNCg== ------_=_NextPart_001_01CA62D3.2B6A4CBA Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4 bWxuczp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIj48SEVBRD4NCjxNRVRBIGh0dHAtZXF1 aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8TUVU QSBjb250ZW50PSJNU0hUTUwgNi4wMC4yOTAwLjM2MDMiIG5hbWU9R0VORVJBVE9SPjwhLS1baWYg IW1zb10+DQo8U1RZTEU+dlw6KiB7DQoJQkVIQVZJT1I6IHVybCgjZGVmYXVsdCNWTUwpDQp9DQpv XDoqIHsNCglCRUhBVklPUjogdXJsKCNkZWZhdWx0I1ZNTCkNCn0NCndcOiogew0KCUJFSEFWSU9S OiB1cmwoI2RlZmF1bHQjVk1MKQ0KfQ0KLnNoYXBlIHsNCglCRUhBVklPUjogdXJsKCNkZWZhdWx0 I1ZNTCkNCn0NCjwvU1RZTEU+DQo8IVtlbmRpZl0tLT4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglm b250LWZhbWlseTog5a6L5L2TOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFRhaG9t YTsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBA5a6L5L2TOw0KfQ0KQGZvbnQtZmFj ZSB7DQoJZm9udC1mYW1pbHk6IENhbGlicmk7DQp9DQpAcGFnZSBTZWN0aW9uMSB7c2l6ZTogNTk1 LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDsgbGF5b3V0 LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRl b2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgQ09MT1I6IGJs YWNrOyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJR046IGp1c3RpZnkN Cn0NCkxJLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGg7IEZPTlQt U0laRTogMTAuNXB0OyBNQVJHSU46IDBjbSAwY20gMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFN SUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0KfQ0KRElWLk1zb05v cm1hbCB7DQoJVEVYVC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGg7IEZPTlQtU0laRTogMTAuNXB0 OyBNQVJHSU46IDBjbSAwY20gMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiAiVGltZXMg TmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0KfQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1 ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsNCglD T0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJ Q09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJs aW5lDQp9DQpQLk1zb0FjZXRhdGUgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBG T05ULVNJWkU6IDhwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgQ09MT1I6IGJsYWNrOyBGT05ULUZB TUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJR046IGp1c3RpZnkNCn0NCkxJLk1zb0Fj ZXRhdGUgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6IDhwdDsg TUFSR0lOOiAwY20gMGNtIDBwdDsgQ09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogIlRpbWVzIE5l dyBSb21hbiI7IFRFWFQtQUxJR046IGp1c3RpZnkNCn0NCkRJVi5Nc29BY2V0YXRlIHsNCglURVhU LUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiA4cHQ7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhU LUFMSUdOOiBqdXN0aWZ5DQp9DQpTUEFOLkVtYWlsU3R5bGUxOCB7DQoJQ09MT1I6IHdpbmRvd3Rl eHQ7IEZPTlQtRkFNSUxZOiBBcmlhbDsgbXNvLXN0eWxlLXR5cGU6IHBlcnNvbmFsDQp9DQpTUEFO LkVtYWlsU3R5bGUxOSB7DQoJQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbDsgbXNvLXN0 eWxlLXR5cGU6IHBlcnNvbmFsLXJlcGx5DQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rp b24xDQp9DQo8L1NUWUxFPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNyIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAg PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPjwvSEVBRD4NCjxCT0RZIGxhbmc9WkgtQ04gdkxpbms9cHVycGxlIGxpbms9 Ymx1ZSBiZ0NvbG9yPXdoaXRlPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9 MjE2MDgyNjEzLTExMTEyMDA5PjxGT05UIGZhY2U9Q2FsaWJyaSANCmNvbG9yPSMwMDAwZmY+QWdy ZWVkLCBJJm5ic3A7dGhpbmsgaXQgd291bGQgYmUgdmFsdWFibGUgaWYgeW91IGNvdWxkIGFkYXB0 IHlvdXIgDQpwcm9wb3NhbCB0byBYQ0FQLCBwcmVzZXJ2aW5nIHRoZSBiZW5lZml0IG9mIGNlbnRy YWwgYWNjZXNzIGFuZCBtYW5hZ2VtZW50IG9mIHRoZSANClF1aWNrIEFuc3dlcnMgKGNhbm5lZCBy ZXNwb25zZXMpLjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48 U1BBTiBjbGFzcz0yMTYwODI2MTMtMTExMTIwMDk+PEZPTlQgZmFjZT1DYWxpYnJpIA0KY29sb3I9 IzAwMDBmZj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxl ZnQ+PFNQQU4gY2xhc3M9MjE2MDgyNjEzLTExMTEyMDA5PjxGT05UIGZhY2U9Q2FsaWJyaSANCmNv bG9yPSMwMDAwZmY+QlRXLCBteSBwcmVmZXJyZWQgc2hvcnQgbmFtZSAoYW5kIGZpcnN0IG5hbWUp IGlzIENvbG0gDQo7KTwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Q2FsaWJy aSBjb2xvcj0jMDAwMGZmPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MjE2 MDgyNjEzLTExMTEyMDA5PjxGT05UIGZhY2U9Q2FsaWJyaSBjb2xvcj0jMDAwMGZmPkFsbCB0aGUg DQpiZXN0LDwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTIxNjA4MjYxMy0x MTExMjAwOT48Rk9OVCBmYWNlPUNhbGlicmkgDQpjb2xvcj0jMDAwMGZmPkNvbG0uPC9GT05UPjwv U1BBTj48L0RJVj48QlI+DQo8RElWIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVhZGVyIGxhbmc9ZW4t dXMgZGlyPWx0ciBhbGlnbj1sZWZ0Pg0KPEhSIHRhYkluZGV4PS0xPg0KPEZPTlQgZmFjZT1UYWhv bWEgc2l6ZT0yPjxCPkZyb206PC9CPiBEZWVwYW5zaHUgW21haWx0bzpkZWVwYW5zaHVAaHVhd2Vp LmNvbV0gDQo8QlI+PEI+U2VudDo8L0I+IDExIE5vdmVtYmVyIDIwMDkgMTM6MTc8QlI+PEI+VG86 PC9CPiBTbXl0aCwgQ29sbSAoQ29sbSk7ICdBZGFtIA0KUm9hY2gnPEJSPjxCPkNjOjwvQj4gc2lt cGxlQGlldGYub3JnPEJSPjxCPlN1YmplY3Q6PC9CPiBSRTogW1NpbXBsZV0gUXVpY2sgDQpBbnN3 ZXIgZm9sbG93LXVwPEJSPjwvRk9OVD48QlI+PC9ESVY+DQo8RElWPjwvRElWPg0KPERJViBjbGFz cz1TZWN0aW9uMSBzdHlsZT0iTEFZT1VULUdSSUQ6ICAxNS42cHQgbm9uZSI+DQo8UCBjbGFzcz1N c29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9MT48U1BBTiBsYW5nPUVO LVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogOXB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFy aWFsIj5TeW10aCw8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KPFAgY2xhc3M9TXNvTm9y bWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTE+PFNQQU4gbGFuZz1FTi1VUyAN CnN0eWxlPSJGT05ULVNJWkU6IDlwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+ PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0xPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHls ZT0iRk9OVC1TSVpFOiA5cHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPlRoZSBi ZW5lZml0cyB5b3UgDQptZW50aW9uZWQgZm9yIGNlbnRyYWwgc3RvcmFnZSBpcyBleGFjdGx5IHdo YXQgSSBoYWQgaW4gbWluZCB3aGlsZSBjb21pbmcgdXAgd2l0aCANCnRoaXMgZHJhZnQuPG86cD48 L286cD48L1NQQU4+PC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFy aWFsIGNvbG9yPW5hdnkgc2l6ZT0xPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpF OiA5cHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPldoYXQgSSBzYWlkIChpbiBt eSBtYWlsIA0KdG8gUmljaGFyZCBvbmx5LCBzb3JyeSBmb3Igbm90IHNlbmRpbmcgdG8gdGhlIGxp c3QpIGlzIGZ1cnRoZXIgZWNob2VkIGJ5IHlvdSBpbiANCnRlcm1zIG9mIGJlbmVmaXQgZm9yIGNl bnRyYWwgc3RvcmFnZS4gPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCjxQIGNsYXNzPU1z b05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0xPjxTUEFOIGxhbmc9RU4t VVMgDQpzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJp YWwiPkFzIGZvciBYQ0FQLCBpZiB0aGF0IGlzIA0KdGhlIGJlc3Qgd2F5IHRvIGRvIGl0IHRoZW4s IHNvIGJlIGl0LjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29Ob3Jt YWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9MT48U1BBTiBsYW5nPUVOLVVTIA0K c3R5bGU9IkZPTlQtU0laRTogOXB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTE+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxl PSJGT05ULVNJWkU6IDlwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+UmVnYXJk czxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9MT48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZP TlQtU0laRTogOXB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5EZWVwYW5zaHU8 bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZh Y2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTE+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05U LVNJWkU6IDlwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJzcDs8 L286cD48L1NQQU4+PC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFy aWFsIGNvbG9yPW5hdnkgc2l6ZT0xPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpF OiA5cHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPG86cD48L286cD48L1NQQU4+PC9GT05UPjwv UD4NCjxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0x PjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IENPTE9SOiBuYXZ5OyBG T05ULUZBTUlMWTogQXJpYWwiPlRvOiANClJpY2hhcmQ8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+ PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0IiBhbGlnbj1s ZWZ0PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj1uYXZ5IHNpemU9MT48U1BBTiBsYW5nPUVOLVVT IA0Kc3R5bGU9IkZPTlQtU0laRTogOXB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFs Ij4mZ3Q7PC9TUEFOPjwvRk9OVD48Rk9OVCANCmNvbG9yPWJsYWNrIHNpemU9Mz48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IENPTE9SOiB3aW5kb3d0ZXh0Ij4gDQpJdCdz IGV2ZW4gbGVzcyBjbGVhciB0byBtZSB0aGF0IGl0IG5lZWRzIHRvIGJlIHNvbWV0aGluZyB0aGF0 J3MgZG9uZSBpbiB0aGUgDQpuZXR3b3JrPC9TUEFOPjwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsIGNv bG9yPW5hdnkgc2l6ZT0xPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7 IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9O VD48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQiIGFsaWdu PWxlZnQ+PEZPTlQgZmFjZT1BcmlhbCANCmNvbG9yPW5hdnkgc2l6ZT0xPjxTUEFOIGxhbmc9RU4t VVMgDQpzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJp YWwiPkFzIEkgbWVudGlvbmVkIHRoYXQgDQp0b2RheeKAmXMgSU0gc3lzdGVtcyBhbGxvdyBkaWZm ZXJlbnQgY2xpZW50IGRldmljZSB0byBsb2ctaW4gSU0gc3lzdGVtIGF0IA0KZGlmZmVyZW50IHBv aW50IG9mIHRpbWUuPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPUFyaWFs IA0KY29sb3I9bmF2eSBzaXplPTE+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6 IDlwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+SeKAmW0gY3JlYXRpbmcgYSBR QSB0b2RheSANCndpdGggbXkgUERBIChhcyBteSBjbGllbnQgZGV2aWNlKS4gVG9tb3Jyb3cgd2hl biBJ4oCZbGwgYmUgbG9nZ2luZy1pbiB1c2luZyBteSANCm1vYmlsZSBwaG9uZSBJIHdhbnQgdGhh dCBRQSwgY3JlYXRlZCB1c2luZyBQREEsIGF2YWlsYWJsZSBpbiBteSBtb2JpbGUgcGhvbmUuIA0K SG93IHRoYXQgY2FuIGJlIGRvbmUgd2l0aG91dCBzdG9yaW5nIHRoYXQgUUEgc29tZXdoZXJlIGlu IHRoZSANCm5ldHdvcms/PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCjxQIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0iVEVYVC1BTElHTjogbGVmdCIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPUFy aWFsIA0KY29sb3I9bmF2eSBzaXplPTE+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJ WkU6IDlwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Jmd0OyA8L1NQQU4+PC9G T05UPjxGT05UIA0KY29sb3I9YmxhY2sgc2l6ZT0zPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0i Rk9OVC1TSVpFOiAxMnB0OyBDT0xPUjogd2luZG93dGV4dCI+c3VyZWx5IGEgVUEgY291bGQgYmUg cHJvdmlzaW9uZWQgd2l0aCANCnRoZSByaWdodCBRQSB0byBzZW5kIGJhY2s/PG86cD48L286cD48 L1NQQU4+PC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iVEVYVC1BTElHTjog bGVmdCIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9bmF2eSBzaXplPTE+PFNQ QU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDlwdDsgQ09MT1I6IG5hdnk7IEZPTlQt RkFNSUxZOiBBcmlhbCI+WWVzLCBpdCBjYW4gYmUsIGlmIA0KZGV2aWNlIG1hbnVmYWN0dXJlciBw cmUtY29uZmlndXJlZCB0aGVtIGludG8gdGhlIGRldmljZS4gQnV0IGhlcmUgSeKAmW0gdGFsa2lu ZyANCmFib3V0ICo8Qj48U1BBTiBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPnVzZXI8L1NQQU4+ PC9CPiogY3JlYXRpbmcgdGhlbSBhbmQgDQp0aGVuIHVzaW5nIHRoZW0uPG86cD48L286cD48L1NQ QU4+PC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9y PW5hdnkgc2l6ZT0xPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IENP TE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQo8UCBj bGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9MT48U1BBTiBs YW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogOXB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1J TFk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KPERJViBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9IlRFWFQtQUxJR046IGNlbnRlciIgYWxpZ249Y2VudGVyPjxGT05U IA0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj1ibGFjayBzaXplPTM+PFNQQU4gbGFuZz1F Ti1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IENPTE9SOiB3aW5kb3d0ZXh0Ij4NCjxIUiB0 YWJJbmRleD0tMSBhbGlnbj1jZW50ZXIgd2lkdGg9IjEwMCUiIFNJWkU9Mj4NCjwvU1BBTj48L0ZP TlQ+PC9ESVY+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9IlRFWFQtQUxJR046IGxlZnQiIGFs aWduPWxlZnQ+PEI+PEZPTlQgZmFjZT1UYWhvbWEgDQpjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4g bGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVdFSUdIVDogYm9sZDsgRk9OVC1TSVpFOiAxMHB0OyBD T0xPUjogd2luZG93dGV4dDsgRk9OVC1GQU1JTFk6IFRhaG9tYSI+RnJvbTo8L1NQQU4+PC9GT05U PjwvQj48Rk9OVCANCmZhY2U9VGFob21hIGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiBsYW5nPUVO LVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtRkFN SUxZOiBUYWhvbWEiPiBTbXl0aCwgQ29sbSANCihDb2xtKSBbbWFpbHRvOnNteXRoY0BhdmF5YS5j b21dIDxCUj48Qj48U1BBTiANCnN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+U2VudDo8L1NQQU4+ PC9CPiAyMDA5PC9TUEFOPjwvRk9OVD48Rk9OVCBmYWNlPeWui+S9kyANCmNvbG9yPWJsYWNrIHNp emU9Mj48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiB3aW5kb3d0ZXh0OyBG T05ULUZBTUlMWTog5a6L5L2TIj7lubQ8L1NQQU4+PC9GT05UPjxGT05UIA0KZmFjZT1UYWhvbWEg Y29sb3I9YmxhY2sgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBDT0xPUjogd2luZG93dGV4dDsgRk9OVC1GQU1JTFk6IFRhaG9tYSI+MTE8L1NQQU4+PC9G T05UPjxGT05UIA0KZmFjZT3lrovkvZMgY29sb3I9YmxhY2sgc2l6ZT0yPjxTUEFOIA0Kc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtRkFNSUxZOiDlrovkvZMi PuaciDwvU1BBTj48L0ZPTlQ+PEZPTlQgDQpmYWNlPVRhaG9tYSBjb2xvcj1ibGFjayBzaXplPTI+ PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiB3aW5kb3d0 ZXh0OyBGT05ULUZBTUlMWTogVGFob21hIj4xMTwvU1BBTj48L0ZPTlQ+PEZPTlQgDQpmYWNlPeWu i+S9kyBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBD T0xPUjogd2luZG93dGV4dDsgRk9OVC1GQU1JTFk6IOWui+S9kyI+5pelPC9TUEFOPjwvRk9OVD48 Rk9OVCANCmZhY2U9VGFob21hIGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0K c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtRkFNSUxZOiBU YWhvbWEiPiANCjIwOjUwPEJSPjxCPjxTUEFOIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+VG86 PC9TUEFOPjwvQj4gQWRhbSBSb2FjaDsgDQpEZWVwYW5zaHU8QlI+PEI+PFNQQU4gc3R5bGU9IkZP TlQtV0VJR0hUOiBib2xkIj5DYzo8L1NQQU4+PC9CPiANCnNpbXBsZUBpZXRmLm9yZzxCUj48Qj48 U1BBTiBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPlN1YmplY3Q6PC9TUEFOPjwvQj4gUkU6IA0K W1NpbXBsZV0gUXVpY2sgQW5zd2VyIGZvbGxvdy11cDwvU1BBTj48L0ZPTlQ+PEZPTlQgY29sb3I9 YmxhY2sgc2l6ZT0zPjxTUEFOIA0KbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQ7 IENPTE9SOiB3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KPFAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSJURVhULUFMSUdOOiBsZWZ0IiBhbGlnbj1sZWZ0PjxGT05UIA0K ZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4gbGFuZz1FTi1V UyANCnN0eWxlPSJGT05ULVNJWkU6IDEwLjVwdCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9G T05UPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i IGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiANCmxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTog MTAuNXB0Ij48IS0tW2lmIGd0ZSB2bWwgMV0+PHY6c2hhcGV0eXBlIGlkPSJfeDAwMDBfdDc0IiAN CiBjb29yZHNpemU9IjIxNjAwLDIxNjAwIiBvOnNwdD0iNzQiIHBhdGg9Im0xMDg2MCwyMTg3YzEw NDUxLDE3NDYsOTUyOSwxMDE4LDkwMTUsNzMwLDc4NjUsMTUyLDY2ODUsLDU0MTUsLDQxNzUsMTUy LDI5OTUsNTc1LDE5NjcsMTMwNSwxMTUwLDIxODcsNTc1LDMyMjIsMjQyLDQyMjAsLDU0MTAsMjQy LDY1NjAsNTc1LDc1OTdsMTA4NjAsMjE2MDAsMjA5OTUsNzU5N3Y0ODUsLTEwMzcsNjA1LC0yMTg3 LDQ4NSwtMzM3N2MyMTExNSwzMjIyLDIwNDIwLDIxODcsMTk2MzIsMTMwNSwxODU3NSw1NzUsMTc0 MjUsMTUyLDE2Mjc1LCwxNTAwNSwsMTM3MzUsMTUyLDEyNzA1LDczMHYtNTI5LDI4OCwtMTQ1MSwx MDE2LC0xODQ1LDE0NTd4ZSI+DQogPHY6c3Ryb2tlIGpvaW5zdHlsZT0ibWl0ZXIiIC8+DQogPHY6 cGF0aCBncmFkaWVudHNoYXBlb2s9InQiIG86Y29ubmVjdHR5cGU9ImN1c3RvbSIgbzpjb25uZWN0 bG9jcz0iMTA4NjAsMjE4NzsyOTI4LDEwODAwOzEwODYwLDIxNjAwOzE4NjcyLDEwODAwIiANCiAg bzpjb25uZWN0YW5nbGVzPSIyNzAsMTgwLDkwLDAiIHRleHRib3hyZWN0PSI1MDM3LDIyNzcsMTY1 NTcsMTM2NzciIC8+DQo8L3Y6c2hhcGV0eXBlPjx2OnNoYXBlIGlkPSJEdHNTaGFwZU5hbWUiIG86 c3BpZD0iX3gwMDAwX3MxMDI2IiB0eXBlPSIjX3gwMDAwX3Q3NCIgDQogYWx0PSJTTFJeR0BITV5O UURPMjhANjRCMjRFRDVFNTBANUM4ODA4OjdCJmx0Ozg6O0FAS1hSOTE0NDczMCEhQklIT0BdRTQ2 NDIwISEhOTQ0RTAwOTAxMTBHMkNANEI0QzRPbnNsYG0vZW51ISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhITEhMSIg DQogc3R5bGU9J3Bvc2l0aW9uOmFic29sdXRlO2xlZnQ6MDt0ZXh0LWFsaWduOmxlZnQ7bWFyZ2lu LWxlZnQ6MDttYXJnaW4tdG9wOjA7DQogd2lkdGg6LjA1cHQ7aGVpZ2h0Oi4wNXB0O3otaW5kZXg6 MTt2aXNpYmlsaXR5OmhpZGRlbic+DQogPHc6YW5jaG9ybG9jay8+DQo8L3Y6c2hhcGU+PCFbZW5k aWZdLS0+PC9TUEFOPjwvRk9OVD48Rk9OVCBmYWNlPUNhbGlicmkgY29sb3I9Ymx1ZT48U1BBTiAN Cmxhbmc9RU4tVVMgc3R5bGU9IkNPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQ2FsaWJyaSI+TGlr ZSBSaWNoYXJkLCBJIGJlbGlldmUgdGhlIA0KUXVpY2sgQW5zd2VyIChRQSkgcmVxdWlyZW1lbnQg Y2FuIGJlIG1ldCBlbnRpcmVseSB3aXRoaW4gdGhlIFVBIGltcGxlbWVudGF0aW9uLCANCnBvdGVu dGlhbGx5IHVzaW5nIGxvY2FsIHN0b3JhZ2UuPC9TUEFOPjwvRk9OVD48U1BBTiANCmxhbmc9RU4t VVM+PG86cD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9YmxhY2sgc2l6ZT0yPjxTUEFOIA0KbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48 L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1DYWxpYnJpIGNvbG9yPWJsdWUgc2l6 ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMC41cHQ7IENPTE9SOiBi bHVlOyBGT05ULUZBTUlMWTogQ2FsaWJyaSI+VGhlcmUgaXMgc29tZSANCmJlbmVmaXQgaW4gdGhp cyBwcm9wb3NhbCdzIGNlbnRyYWwgc3RvcmFnZSBvZiB0aGUgUUEncywgd2hpY2ggZW5hYmxlcyBt b2JpbGl0eSANCm9mIHRoZSBlbmRwb2ludCwgb3IgcG90ZW50aWFsbHkgc2hhcmluZyB0aGUgUUEn cyBhY3Jvc3MgYSB1c2VyJ3MgZW5kcG9pbnRzLiANCkhvd2V2ZXIgSSBhZ3JlZSB3aXRoIEFkYW0g dGhhdCBYQ0FQIHNlZW1zIGEgbW9yZSBuYXR1cmFsIG1lY2hhbmlzbSBmb3IgdGhpcyBraW5kIA0K b2YgZGF0YSwgbW9yZSBzbyB0aGFuIG92ZXJsb2FkaW5nIHRoZSBTSVAgUkVHSVNURVIgYW5kIElO VklURSANCm1ldGhvZHMuPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+ PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iIGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiANCmxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0la RTogMTAuNXB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KPFAgY2xhc3M9 TXNvTm9ybWFsPjxGT05UIGZhY2U9Q2FsaWJyaSBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiBsYW5n PUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTAuNXB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1J TFk6IENhbGlicmkiPkJUVywgdGhlIHRlcm0gDQoiY2FubmVkIHJlc3BvbnNlIiBpcyB1c2VkIGVs c2V3aGVyZTo8L1NQQU4+PC9GT05UPjxTUEFOIA0KbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvU1BB Tj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1DYWxpYnJpIGNvbG9yPWJsdWUg c2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMC41cHQ7IENPTE9S OiBibHVlOyBGT05ULUZBTUlMWTogQ2FsaWJyaSI+LSA8QSANCmhyZWY9Imh0dHA6Ly9lbi53aWtp cGVkaWEub3JnL3dpa2kvQ2FubmVkX3Jlc3BvbnNlIj5odHRwOi8vZW4ud2lraXBlZGlhLm9yZy93 aWtpL0Nhbm5lZF9yZXNwb25zZTwvQT48L1NQQU4+PC9GT05UPjxTUEFOIA0KbGFuZz1FTi1VUz48 bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1DYWxp YnJpIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpF OiAxMC41cHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQ2FsaWJyaSI+LSA8QSANCmhyZWY9 Imh0dHA6Ly9nbWFpbGJsb2cuYmxvZ3Nwb3QuY29tLzIwMDgvMTAvbmV3LWluLWxhYnMtY2FubmVk LXJlc3BvbnNlcy5odG1sIj5odHRwOi8vZ21haWxibG9nLmJsb2dzcG90LmNvbS8yMDA4LzEwL25l dy1pbi1sYWJzLWNhbm5lZC1yZXNwb25zZXMuaHRtbDwvQT48L1NQQU4+PC9GT05UPjxTUEFOIA0K bGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9y bWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9YmxhY2sgc2l6ZT0yPjxTUEFO IA0KbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMC41cHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05U IGZhY2U9Q2FsaWJyaSBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9 IkZPTlQtU0laRTogMTAuNXB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IENhbGlicmkiPkFs bCB0aGUgDQpiZXN0LDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwv U1BBTj48L1A+PC9ESVY+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9Q2Fs aWJyaSBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0la RTogMTAuNXB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IENhbGlicmkiPkNvbG0uPC9TUEFO PjwvRk9OVD48U1BBTiANCmxhbmc9RU4tVVM+PG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0K PFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9Ymxh Y2sgc2l6ZT0yPjxTUEFOIA0KbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMC41cHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQo8RElWIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0iVEVYVC1BTElHTjogY2VudGVyIiBhbGlnbj1jZW50ZXI+PEZPTlQgDQpmYWNlPSJUaW1l cyBOZXcgUm9tYW4iIGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9 IkZPTlQtU0laRTogMTAuNXB0Ij4NCjxIUiB0YWJJbmRleD0tMSBhbGlnbj1jZW50ZXIgd2lkdGg9 IjEwMCUiIFNJWkU9Mj4NCjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8UCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9Ik1BUkdJTi1CT1RUT006IDEycHQiPjxCPjxGT05UIGZhY2U9VGFob21hIGNvbG9yPWJs YWNrIA0Kc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7 IEZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFRhaG9tYSI+RnJvbTo8L1NQQU4+PC9GT05U PjwvQj48Rk9OVCANCmZhY2U9VGFob21hIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFRhaG9tYSI+IHNpbXBsZS1ib3VuY2VzQGll dGYub3JnIA0KW21haWx0bzpzaW1wbGUtYm91bmNlc0BpZXRmLm9yZ10gPEI+PFNQQU4gc3R5bGU9 IkZPTlQtV0VJR0hUOiBib2xkIj5PbiBCZWhhbGYgT2YgDQo8L1NQQU4+PC9CPkFkYW0gUm9hY2g8 QlI+PEI+PFNQQU4gc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5TZW50OjwvU1BBTj48L0I+IDEx IA0KTm92ZW1iZXIgMjAwOSAwMzo0NDxCUj48Qj48U1BBTiBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJv bGQiPlRvOjwvU1BBTj48L0I+IA0KRGVlcGFuc2h1PEJSPjxCPjxTUEFOIHN0eWxlPSJGT05ULVdF SUdIVDogYm9sZCI+Q2M6PC9TUEFOPjwvQj4gDQpzaW1wbGVAaWV0Zi5vcmc8QlI+PEI+PFNQQU4g c3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5TdWJqZWN0OjwvU1BBTj48L0I+IFJlOiANCltTaW1w bGVdIFF1aWNrIEFuc3dlciBmb2xsb3ctdXA8L1NQQU4+PC9GT05UPjxTUEFOIA0KbGFuZz1FTi1V Uz48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8QkxPQ0tRVU9URSBzdHlsZT0iTUFSR0lOLVRPUDog NXB0OyBNQVJHSU4tQk9UVE9NOiA1cHQiIA0KY2l0ZT1taWQ6MDAwYjAxY2E2MjdlJDNkYTdhYTAw JDgxMTE1ZDg1QGNoaW5hLmh1YXdlaS5jb20gdHlwZT0iY2l0ZSI+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQogPHUxOnNoYXBlZGVmYXVsdHMgdTI6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI3Ii8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8dTM6c2hhcGVs YXlvdXQgdTQ6ZXh0PSJlZGl0Ij4NCiAgPHUzOmlkbWFwIHU0OmV4dD0iZWRpdCIgZGF0YT0iMSIv Pg0KIDwvdTM6c2hhcGVsYXlvdXQ+DQo8L3htbD48IVtlbmRpZl0tLT4NCiAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9YmxhY2sgc2l6ZT0xPjxTUEFOIGxhbmc9RU4t VVMgDQogIHN0eWxlPSJGT05ULVNJWkU6IDlwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj48VTU6U0hB UEVUWVBFIGlkPV94MDAwMF90NzQgDQogIHBhdGg9Im0xMDg2MCwyMTg3YzEwNDUxLDE3NDYsOTUy OSwxMDE4LDkwMTUsNzMwLDc4NjUsMTUyLDY2ODUsLDU0MTUsLDQxNzUsMTUyLDI5OTUsNTc1LDE5 NjcsMTMwNSwxMTUwLDIxODcsNTc1LDMyMjIsMjQyLDQyMjAsLDU0MTAsMjQyLDY1NjAsNTc1LDc1 OTdsMTA4NjAsMjE2MDAsMjA5OTUsNzU5N3Y0ODUsLTEwMzcsNjA1LC0yMTg3LDQ4NSwtMzM3N2My MTExNSwzMjIyLDIwNDIwLDIxODcsMTk2MzIsMTMwNSwxODU3NSw1NzUsMTc0MjUsMTUyLDE2Mjc1 LCwxNTAwNSwsMTM3MzUsMTUyLDEyNzA1LDczMHYtNTI5LDI4OCwtMTQ1MSwxMDE2LC0xODQ1LDE0 NTd4ZSIgDQogIHU2OnNwdD0iNzQiIGNvb3Jkc2l6ZT0iMjE2MDAsMjE2MDAiPjxVNTpTVFJPS0Ug am9pbnN0eWxlPSJtaXRlciIgLz48VTU6UEFUSCANCiAgdGV4dGJveHJlY3Q9IjUwMzcsMjI3Nywx NjU1NywxMzY3NyIgdTY6Y29ubmVjdGFuZ2xlcz0iMjcwLDE4MCw5MCwwIiANCiAgdTY6Y29ubmVj dGxvY3M9IjEwODYwLDIxODc7MjkyOCwxMDgwMDsxMDg2MCwyMTYwMDsxODY3MiwxMDgwMCIgDQog IHU2OmNvbm5lY3R0eXBlPSJjdXN0b20iIGdyYWRpZW50c2hhcGVvaz0idCIgLz48L1U1OlNIQVBF VFlQRT48VTU6U0hBUEUgDQogIGlkPUR0c1NoYXBlTmFtZSANCiAgc3R5bGU9Ik1BUkdJTi1UT1A6 IDBweDsgWi1JTkRFWDogMTsgTEVGVDogMHB4OyBWSVNJQklMSVRZOiBoaWRkZW47IE1BUkdJTi1M RUZUOiAwcHg7IFdJRFRIOiAwLjA1cHQ7IFBPU0lUSU9OOiBhYnNvbHV0ZTsgSEVJR0hUOiAwLjA1 cHQ7IFRFWFQtQUxJR046IGxlZnQiIA0KICB0eXBlPSIjX3gwMDAwX3Q3NCIgDQogIGFsdD0iU0xS XkdASE1eTlFETzI4QDY0QjI0RUQ1RTUwQDVDODgwODo3Qjw4OjtBQEtYUjkxNDQ3MzAhIUJJSE9A XUU0NjQyMCEhITk0NEUwMDkwMTEwRzJDQDRCNEM0T25zbGBtL2VudSEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhJiMxMzsmIzEwOyEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISYjMTM7JiMxMDshISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhITEhMSIgDQogIHU2OnNwaWQ9Il94MDAwMF9zMTAyNiI+PFU3OkFO Q0hPUkxPQ0sgLz48L1U1OlNIQVBFPjxVNTpTSEFQRSBpZD1feDAwMDBfczEwMjYgDQogIHN0eWxl PSJNQVJHSU4tVE9QOiAwcHg7IFotSU5ERVg6IDI7IExFRlQ6IDBweDsgVklTSUJJTElUWTogaGlk ZGVuOyBNQVJHSU4tTEVGVDogMHB4OyBXSURUSDogMC4wNXB0OyBQT1NJVElPTjogYWJzb2x1dGU7 IEhFSUdIVDogMC4wNXB0OyBURVhULUFMSUdOOiBsZWZ0IiANCiAgdHlwZT0iI194MDAwMF90NzQi IA0KICBhbHQ9IlNMUl5HQEhNXk5RRE8yOEA2NEIyNEVENUU1MEA1Qzg4MDg6N0I8ODo7QUBLWFI5 MTQ0NzMwISFCSUhPQF1FNDY0MjAhISE5NDRFMDA5MDExMEcyQ0A0QjRDNE9uc2xgbS9lbnUhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhJiMxMzsmIzEwOyEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISYjMTM7JiMxMDshISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEh ISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISExITEiPjxVODpBTkNIT1JMT0NLIA0KICAv PjwvVTU6U0hBUEU+RGVhciBBbGwsPE86UD48L086UD48L1NQQU4+PC9GT05UPjxTUEFOIA0KICBs YW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U9QXJpYWwgY29sb3I9YmxhY2sgc2l6ZT0xPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0 eWxlPSJGT05ULVNJWkU6IDlwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj48TzpQPjwvTzpQPkFzIG1l bnRpb25lZCBpbiB0aGUgDQogIHNlc3Npb24sIEkgd291bGQgbGlrZSB0byBnZXQgeW91ciBvcGlu aW9uIGJ5IA0KICBlbWFpbC48TzpQPjwvTzpQPjwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1V Uz48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPWJsYWNrIHNpemU9MT48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9O VC1TSVpFOiA5cHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+QmFzaWNhbGx5IEkgd291bGQgbGlrZSB0 byBrbm93IHRoZSANCiAgZm9sbG93aW5nPE86UD48L086UD48L1NQQU4+PC9GT05UPjxTUEFOIGxh bmc9RU4tVVM+PG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9Ik1BUkdJTi1MRUZUOiAxOHB0OyBURVhULUlOREVOVDogLTE4cHQiPjxGT05UIA0KICBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIA0K ICBzdHlsZT0iRk9OVC1TSVpFOiAxMC41cHQiPjxPOlA+PC9POlA+Jmx0OyEtLVtpZiANCiAgIXN1 cHBvcnRMaXN0c10tLSZndDs8L1NQQU4+PC9GT05UPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0xPjxT UEFOIGxhbmc9RU4tVVMgDQogIHN0eWxlPSJGT05ULVNJWkU6IDlwdDsgRk9OVC1GQU1JTFk6IEFy aWFsIj4xLjwvU1BBTj48L0ZPTlQ+PEZPTlQgc2l6ZT0xPjxTUEFOIA0KICBzdHlsZT0iZm9udC1z aXplLWFkanVzdDogbm9uZTsgZm9udC1zdHJldGNoOiBub3JtYWw7IHgtc3lzdGVtLWZvbnQ6IG5v bmUiPjxTUEFOIA0KICBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDdwdCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+PC9TUEFOPjwvRk9OVD48U1BB TiBsYW5nPUVOLVVTPiZsdDshLS1bZW5kaWZdLS0mZ3Q7PC9TUEFOPjxGT05UIA0KICBmYWNlPUFy aWFsIHNpemU9MT48U1BBTiBsYW5nPUVOLVVTIA0KICBzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IEZP TlQtRkFNSUxZOiBBcmlhbCI+RG8geW91IHRoaW5rIHRoYXQgdGhlIGNvbmNlcHQgb2YgDQogIFF1 aWNrIEFuc3dlciAoYXMgSSBleHBsYWluZWQgd2hpbGUgcHJlc2VudGluZykgaXRzZWxmLCBpcyBm ZWFzaWJsZS9uZWVkZWQgZm9yIA0KICBjdXJyZW50IElNIHN5c3RlbXMuIEluIG90aGVyIHdvcmRz IGlzIGl0IGFkdmFudGFnZW91cyB0byBoYXZlIGl0IGluIHRvZGF5IElNIA0KICBzZXJ2aWNlPzxP OlA+PC9POlA+PC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9TUEFO PjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMThwdDsgVEVY VC1JTkRFTlQ6IC0xOHB0Ij48Rk9OVCANCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj1i bGFjayBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTogMTAuNXB0 Ij4mbHQ7IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0mZ3Q7PC9TUEFOPjwvRk9OVD48Rk9OVCANCiAg ZmFjZT1BcmlhbCBzaXplPTE+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9IkZPTlQtU0laRTog OXB0OyBGT05ULUZBTUlMWTogQXJpYWwiPjIuPC9TUEFOPjwvRk9OVD48Rk9OVCBzaXplPTE+PFNQ QU4gDQogIHN0eWxlPSJmb250LXNpemUtYWRqdXN0OiBub25lOyBmb250LXN0cmV0Y2g6IG5vcm1h bDsgeC1zeXN0ZW0tZm9udDogbm9uZSI+PFNQQU4gDQogIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogN3B0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIDwvU1BB Tj48L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+Jmx0OyEtLVtlbmRpZl0tLSZndDs8L1NQ QU4+PEZPTlQgDQogIGZhY2U9QXJpYWwgc2l6ZT0xPjxTUEFOIGxhbmc9RU4tVVMgDQogIHN0eWxl PSJGT05ULVNJWkU6IDlwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5JZiB5b3VyIGFuc3dlciBpcyDi gJxZZXPigJ0gb3IgZXZlbiANCiAg4oCcTWF5IGJl4oCdLiBUaGVuIGRvIHlvdSB0aGluayBzb21l dGhpbmcgaXMgbmVlZGVkIHRvIGJlIGRlZmluZWQgKHN0YW5kYXJkaXplZCkgDQogIGFib3V0IHRo YXQgaW4gSUVURj8gPE86UD48L086UD48L1NQQU4+PC9GT05UPjxTUEFOIA0KICBsYW5nPUVOLVVT PjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJH SU4tTEVGVDogMThwdDsgVEVYVC1JTkRFTlQ6IC0xOHB0Ij48Rk9OVCANCiAgZmFjZT0iVGltZXMg TmV3IFJvbWFuIiBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyANCiAgc3R5bGU9 IkZPTlQtU0laRTogMTAuNXB0Ij4mbHQ7IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0mZ3Q7PC9TUEFO PjwvRk9OVD48Rk9OVCANCiAgZmFjZT1BcmlhbCBzaXplPTE+PFNQQU4gbGFuZz1FTi1VUyANCiAg c3R5bGU9IkZPTlQtU0laRTogOXB0OyBGT05ULUZBTUlMWTogQXJpYWwiPjMuPC9TUEFOPjwvRk9O VD48Rk9OVCBzaXplPTE+PFNQQU4gDQogIHN0eWxlPSJmb250LXNpemUtYWRqdXN0OiBub25lOyBm b250LXN0cmV0Y2g6IG5vcm1hbDsgeC1zeXN0ZW0tZm9udDogbm9uZSI+PFNQQU4gDQogIGxhbmc9 RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogN3B0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgDQogIDwvU1BBTj48L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+Jmx0OyEt LVtlbmRpZl0tLSZndDs8L1NQQU4+PEZPTlQgDQogIGZhY2U9QXJpYWwgc2l6ZT0xPjxTUEFOIGxh bmc9RU4tVVMgDQogIHN0eWxlPSJGT05ULVNJWkU6IDlwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5J ZiB5b3UgYW5zd2VyIGluIOKAnFllc+KAnSBvciBldmVuIOKAnE1heSANCiAgYmXigJ0uIFRoZW4g SSBraW5kbHkgcmVxdWVzdCB5b3UgdG8gcGxlYXNlIG5hbWUgc29tZSBvZiB0aG9zZSB0aGluZ3Mg KGluc3RlYWQgb2YgDQogIHRoZSBzb2x1dGlvbiBkZWZpbmVkIGluIHRoZSBkcmFmdCkgd2hpY2gg eW91IGV4cGVjdCB0byBiZSB1c2VkL2V4dGVuZGVkIGZvciANCiAgdGhpcyBwdXJwb3NlLiBlLGcg WENBUC4gVGhpcyB3aWxsIGFzc2lzdCBtZSB0byBwcm92aWRlIHNvbWUgZ2FwIGFuYWx5c2VzLCBp ZiANCiAgYW55LjxPOlA+PC9POlA+PC9TUEFOPjwvRk9OVD48U1BBTiANCmxhbmc9RU4tVVM+PG86 cD48L286cD48L1NQQU4+PC9QPjwvQkxPQ0tRVU9URT4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0iVEVYVC1BTElHTjogbGVmdCIgYWxpZ249bGVmdD48Rk9OVCANCmZhY2U9IlRpbWVzIE5ldyBS b21hbiIgY29sb3I9YmxhY2sgc2l6ZT0zPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1T SVpFOiAxMnB0Ij48QlI+SSdtIG5vdCAxMDAlIGNvbnZpbmNlZCB0aGF0IHdlIG5lZWQgdGhpcyBt ZWNoYW5pc20sIA0KYnV0IEknbSB3aWxsaW5nIHRvIGVudGVydGFpbiByZXF1aXJlbWVudHMgcmVs YXRpbmcgdG8gaXQuPEJSPjxCUj5JZiB0aGlzIA0KbWVjaGFuaXNtIGlzIHB1cnN1ZWQsIGl0IHdv dWxkIHNlZW0gdG8gbWFrZSBzZW5zZSB0byBoYXZlIHNvbWV0aGluZyANCnN0YW5kYXJkaXplZC48 QlI+PEJSPkluIHRlcm1zIG9mIGV4aXN0aW5nIG1lY2hhbmlzbXMsIEkgd291bGQgdGhpbmsgdGhl IG1vc3QgDQpwcm9taXNpbmcgYXBwcm9hY2hlcyB3b3VsZCBiZSBlaXRoZXIgWENBUCwgb3IgYmFy ZSBIVFRQIChQVVQgYW5kIEdFVCkuPEJSPjxCUj4vYSANCjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9O VD48L1A+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01CA62D3.2B6A4CBA-- From deepanshu@huawei.com Wed Nov 11 06:48:51 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 717783A67E3 for ; Wed, 11 Nov 2009 06:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.662 X-Spam-Level: X-Spam-Status: No, score=-0.662 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dtZHCwV-PGU for ; Wed, 11 Nov 2009 06:48:49 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 909A73A67DA for ; Wed, 11 Nov 2009 06:48:44 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSY00EB695VIG@szxga01-in.huawei.com> for simple@ietf.org; Wed, 11 Nov 2009 22:49:08 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSY00GGH95VES@szxga01-in.huawei.com> for simple@ietf.org; Wed, 11 Nov 2009 22:49:07 +0800 (CST) Received: from jys8055621 (222-151-138-069.jp.fiberbit.net [222.151.138.69]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSY00I2Z95F5W@szxml01-in.huawei.com>; Wed, 11 Nov 2009 22:49:07 +0800 (CST) Date: Wed, 11 Nov 2009 22:48:58 +0800 From: Deepanshu In-reply-to: <4C607BEA097DF048BEA625B974A36618DC5797@306900ANEX2.global.avaya.com> To: "'Smyth, Colm (Colm)'" , 'Adam Roach' Message-id: <007001ca62de$1dfb4a30$0af01eac@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_YM32gRKrQ6SQ8icfoLqUAg)" Thread-index: AcpigUqMMCImhw3ARbi6TPXy7R8aagASspLQAADhRHAAALtHgAACwYAg X-Mailman-Approved-At: Wed, 11 Nov 2009 14:34:42 -0800 Cc: simple@ietf.org Subject: Re: [Simple] Quick Answer follow-up X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 14:48:51 -0000 This is a multi-part message in MIME format. --Boundary_(ID_YM32gRKrQ6SQ8icfoLqUAg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Sure, I=A1=AFll do that. Thanks for your suggestion Colm (I go it).=20 In case anyone have any other suggestion/comments/opinion please let me know. =20 Regards Deepanshu =20 =20 =20 _____ =20 From: Smyth, Colm (Colm) [mailto:smythc@avaya.com]=20 Sent: 2009=C4=EA11=D4=C211=C8=D5 21:28 To: Deepanshu; Adam Roach Cc: simple@ietf.org Subject: RE: [Simple] Quick Answer follow-up =20 Agreed, I think it would be valuable if you could adapt your proposal to XCAP, preserving the benefit of central access and management of the = Quick Answers (canned responses). =20 BTW, my preferred short name (and first name) is Colm ;) =20 All the best, Colm. =20 _____ =20 From: Deepanshu [mailto:deepanshu@huawei.com]=20 Sent: 11 November 2009 13:17 To: Smyth, Colm (Colm); 'Adam Roach' Cc: simple@ietf.org Subject: RE: [Simple] Quick Answer follow-up Symth, =20 The benefits you mentioned for central storage is exactly what I had in = mind while coming up with this draft. What I said (in my mail to Richard only, sorry for not sending to the = list) is further echoed by you in terms of benefit for central storage.=20 As for XCAP, if that is the best way to do it then, so be it. =20 Regards Deepanshu =20 *********************************************** To: Richard > It's even less clear to me that it needs to be something that's done = in the network As I mentioned that today=A1=AFs IM systems allow different client = device to log-in IM system at different point of time. I=A1=AFm creating a QA today with my PDA (as my client device). Tomorrow = when I=A1=AFll be logging-in using my mobile phone I want that QA, created = using PDA, available in my mobile phone. How that can be done without storing that = QA somewhere in the network? > surely a UA could be provisioned with the right QA to send back? Yes, it can be, if device manufacturer pre-configured them into the = device. But here I=A1=AFm talking about *user* creating them and then using = them. ************************************************ =20 _____ =20 From: Smyth, Colm (Colm) [mailto:smythc@avaya.com]=20 Sent: 2009=C4=EA11=D4=C211=C8=D5 20:50 To: Adam Roach; Deepanshu Cc: simple@ietf.org Subject: RE: [Simple] Quick Answer follow-up =20 Like Richard, I believe the Quick Answer (QA) requirement can be met entirely within the UA implementation, potentially using local storage. =20 There is some benefit in this proposal's central storage of the QA's, = which enables mobility of the endpoint, or potentially sharing the QA's across = a user's endpoints. However I agree with Adam that XCAP seems a more = natural mechanism for this kind of data, more so than overloading the SIP = REGISTER and INVITE methods. =20 BTW, the term "canned response" is used elsewhere: - http://en.wikipedia.org/wiki/Canned_response - = http://gmailblog.blogspot.com/2008/10/new-in-labs-canned-responses.html =20 All the best, Colm. =20 _____ =20 From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf = Of Adam Roach Sent: 11 November 2009 03:44 To: Deepanshu Cc: simple@ietf.org Subject: Re: [Simple] Quick Answer follow-up Dear All, As mentioned in the session, I would like to get your opinion by email. Basically I would like to know the following 1. Do you think that the concept of Quick Answer (as I explained while presenting) itself, is feasible/needed for current IM systems. In other words is it = advantageous to have it in today IM service? 2. If your answer is = =A1=B0Yes=A1=B1 or even =A1=B0May be=A1=B1. Then do you think something is needed to be = defined (standardized) about that in IETF?=20 3. If you answer in = =A1=B0Yes=A1=B1 or even =A1=B0May be=A1=B1. Then I kindly request you to please name some = of those things (instead of the solution defined in the draft) which you expect = to be used/extended for this purpose. e,g XCAP. This will assist me to provide some gap analyses, if any. I'm not 100% convinced that we need this mechanism, but I'm willing to entertain requirements relating to it. If this mechanism is pursued, it would seem to make sense to have = something standardized. In terms of existing mechanisms, I would think the most promising = approaches would be either XCAP, or bare HTTP (PUT and GET). /a=20 --Boundary_(ID_YM32gRKrQ6SQ8icfoLqUAg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Sure, I=A1=AFll = do that.

Thanks for your = suggestion Colm (I go it).

In case anyone = have any other suggestion/comments/opinion please let me = know.

 <= /span>

Regards=

Deepanshu

 <= /span>

 <= /span>

 <= /span>

From: Smyth, Colm (Colm) [mailto:smythc@avaya.com] =
Sent: = 2009=C4=EA11<= /font>=D4=C211<= /font>=C8=D5 = 21:28
To: Deepanshu; Adam = Roach
Cc: simple@ietf.org
Subject: RE: [Simple] = Quick Answer follow-up

 

Agreed, = I think it would be valuable if you could adapt your proposal to XCAP, = preserving the benefit of central access and management of the Quick Answers (canned responses).

&nbs= p;

BTW, my preferred short name (and first name) is Colm = ;)

&nbs= p;

All the best,

Colm.

 

From:= Deepanshu = [mailto:deepanshu@huawei.com]
Sent: 11 November 2009 = 13:17
To: Smyth, Colm (Colm); = 'Adam Roach'
Cc: simple@ietf.org
Subject: RE: [Simple] = Quick Answer follow-up

Symth,

 

The benefits you mentioned for central storage is exactly = what I had in mind while coming up with this = draft.

What I said (in my mail to Richard only, sorry for not = sending to the list) is further echoed by you in terms of benefit for central = storage.

As for XCAP, if that is the best way to do it then, so be = it.

 

Regards

Deepanshu

 

***********************************************

To: Richard

> It's even less = clear to me that it needs to be something that's done in the = network

As I mentioned that today=A1=AFs IM = systems allow different client device to log-in IM system at different point of = time.

I=A1=AFm creating a QA today with my PDA = (as my client device). Tomorrow when I=A1=AFll be logging-in using my mobile phone I = want that QA, created using PDA, available in my mobile phone. How that can be done = without storing that QA somewhere in the network?

> surely a UA = could be provisioned with the right QA to send back?

Yes, it can be, if device manufacturer pre-configured them into the device. But here I=A1=AFm talking about = *user* creating them and then using = them.

************************************************

 

From:= Smyth, Colm (Colm) [mailto:smythc@avaya.com]
Sent: = 2009=C4=EA11<= /font>=D4=C211<= /font>=C8=D5 = 20:50
To: Adam Roach; = Deepanshu
Cc: simple@ietf.org
Subject: RE: [Simple] = Quick Answer follow-up

=

 

Like Richard, I = believe the Quick Answer (QA) requirement can be met entirely within the UA = implementation, potentially using local storage.

 

There is some benefit in this proposal's central storage of = the QA's, which enables mobility of the endpoint, or potentially sharing the = QA's across a user's endpoints. However I agree with Adam that XCAP seems a = more natural mechanism for this kind of data, more so than overloading the = SIP REGISTER and INVITE methods.

 

BTW, the term "canned response" is used = elsewhere:

- http://en.wikipedia= .org/wiki/Canned_response

- http://gmailblog.blogspot.com/2008/10/new-in-labs-canned-response= s.html

 

All the best,

Colm.

 

From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Adam Roach
Sent: 11 November 2009 = 03:44
To: Deepanshu
Cc: simple@ietf.org
Subject: Re: [Simple] = Quick Answer follow-up

Dear All,

As mentioned in the session, I would like to get your opinion by = email.

Basically I would like to know the following

<!--[if = !supportLists]-->1.       <!--[endif]-->Do you think that the concept of Quick Answer (as I explained while presenting) itself, is feasible/needed for current IM systems. In other words is it advantageous to have it in today IM service?

<!--[if !supportLists]-->2.       = <!--[endif]-->If your answer is = =A1=B0Yes=A1=B1 or even =A1=B0May be=A1=B1. Then do you think something is needed to be defined = (standardized) about that in IETF?

<!--[if = !supportLists]-->3.       = <!--[endif]-->If you answer in = =A1=B0Yes=A1=B1 or even =A1=B0May be=A1=B1. Then I kindly request you to please name some of those things = (instead of the solution defined in the draft) which you expect to be used/extended = for this purpose. e,g XCAP. This will assist me to provide some gap = analyses, if any.


I'm not 100% convinced that we need this mechanism, but I'm willing to entertain requirements relating to it.

If this mechanism is pursued, it would seem to make sense to have = something standardized.

In terms of existing mechanisms, I would think the most promising = approaches would be either XCAP, or bare HTTP (PUT and GET).

/a

--Boundary_(ID_YM32gRKrQ6SQ8icfoLqUAg)-- From ibc@aliax.net Thu Nov 12 10:45:30 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4C9E3A6B03 for ; Thu, 12 Nov 2009 10:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPbzm7BdY+GY for ; Thu, 12 Nov 2009 10:45:30 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id C51C33A6821 for ; Thu, 12 Nov 2009 10:45:29 -0800 (PST) Received: by fxm7 with SMTP id 7so2583140fxm.29 for ; Thu, 12 Nov 2009 10:45:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.54.23 with SMTP id o23mr504529fag.72.1258051555408; Thu, 12 Nov 2009 10:45:55 -0800 (PST) Date: Thu, 12 Nov 2009 19:45:55 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: simple@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Simple] XCAP: Unique node selector but non unique path => HTTP 409 Conflict ? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 18:45:30 -0000 Hi, please consider the following pres-rules document in which there are two rules: - id =3D "pres_whitelilst" - id =3D "black_whitelist" allow block What should be the XCAP server response when receiving the following reques= t? GET /pres-rules/users/sip:myuser@domain.org/pres-rules/~~/cp:ruleset/cp:rul= e/cp:conditions/cp:identity/cp:one[@id=3D"sip:bob@example.org"] Note that the path is not unique when arriving to "cp:ruleset/cp:rule/" as there are two nodes so it's not unique. However, the final selector is unique as there is noly one node with id=3D"sip:bob@example.org". My XML parser allows it and finds the node. I think (but I'm not sure) that Xpath specifications allows it. However I don't know if XCAP protocol overrides it so the request should get a "409 Conflict". I do know that XCAP doesn't allow a Xpath selector getting more than one node, but it's not the case of the above request as I've explained. However the first portion of the Xpath "cp:ruleset/cp:rule/" is not unique (as there are two nodes). So, should the XCAP server reply 409? or should accept the request and reply 200 with the fetched node in the body? Thanks a lot. --=20 I=C3=B1aki Baz Castillo From ben@estacado.net Thu Nov 12 16:28:21 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 617AA28C14B for ; Thu, 12 Nov 2009 16:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmufHrras91A for ; Thu, 12 Nov 2009 16:28:20 -0800 (PST) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id A70013A685A for ; Thu, 12 Nov 2009 16:28:20 -0800 (PST) Received: from host-24-29.meeting.ietf.org (host-24-29.meeting.ietf.org [133.93.24.29]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id nAD0RITM070138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Nov 2009 18:27:30 -0600 (CST) (envelope-from ben@estacado.net) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Nov 2009 09:27:17 +0900 Message-Id: To: Simple WG Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [Simple] Draft Minutes for SIMPLE at IETF 76 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 00:28:21 -0000 All, Draft minutes from the IETF 76 SIMPLE meeting are available at the = following link. Please review and offer any corrections as soon as = possible. http://www.ietf.org/proceedings/09nov/minutes/simple.txt Thanks! Ben. From ibc@aliax.net Sat Nov 14 14:24:20 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FBC83A6826 for ; Sat, 14 Nov 2009 14:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hh73GvTbAl6f for ; Sat, 14 Nov 2009 14:24:19 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 8962A3A6832 for ; Sat, 14 Nov 2009 14:24:19 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1431511eyd.51 for ; Sat, 14 Nov 2009 14:24:47 -0800 (PST) Received: by 10.213.96.136 with SMTP id h8mr781154ebn.48.1258237487099; Sat, 14 Nov 2009 14:24:47 -0800 (PST) Received: from ibc-laptop.localnet ([212.230.46.89]) by mx.google.com with ESMTPS id 7sm2902284eyb.16.2009.11.14.14.24.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 14 Nov 2009 14:24:46 -0800 (PST) From: =?utf-8?q?I=C3=B1aki_Baz_Castillo?= To: simple@ietf.org Date: Sat, 14 Nov 2009 23:24:43 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.28-15-generic; KDE/4.3.2; x86_64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <200911142324.43550.ibc@aliax.net> Subject: Re: [Simple] XCAP: Unique node selector but non unique path => HTTP 409 Conflict ? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 22:24:20 -0000 El Jueves, 12 de Noviembre de 2009, I=C3=B1aki Baz Castillo escribi=C3=B3: > My XML parser allows it and finds the node. I think (but I'm not sure) > that Xpath specifications allows it. However I don't know if XCAP > protocol overrides it so the request should get a "409 Conflict". >=20 > I do know that XCAP doesn't allow a Xpath selector getting more than > one node, but it's not the case of the above request as I've > explained. However the first portion of the Xpath > "cp:ruleset/cp:rule/" is not unique (as there are two > nodes). >=20 > So, should the XCAP server reply 409? or should accept the request and > reply 200 with the fetched node in the body? >=20 > Thanks a lot. Hi, as nobody replies to questions about SIMPLE/XCAP in this maillist I jus= t=20 would like to know if this is not the appropriate place to ask such questio= ns. Perhaps this maillist is focused on comments about new drafts or specificat= ion=20 proposals. If so, could I know a good maillist in which I could ask about=20 SIMPLE/XCAP as implementor? Is sip-implementors the appropriate place? Thanks a lot. =20 =2D-=20 I=C3=B1aki Baz Castillo From hisham.khartabil@gmail.com Sun Nov 15 19:15:47 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 499333A6A65 for ; Sun, 15 Nov 2009 19:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tt2415Doijo for ; Sun, 15 Nov 2009 19:15:46 -0800 (PST) Received: from mail-iw0-f186.google.com (mail-iw0-f186.google.com [209.85.223.186]) by core3.amsl.com (Postfix) with ESMTP id 770A73A6A61 for ; Sun, 15 Nov 2009 19:15:46 -0800 (PST) Received: by iwn16 with SMTP id 16so4034691iwn.29 for ; Sun, 15 Nov 2009 19:15:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=YvEhp90LmCYoU/aNQcQ8p4s6m4m7D+J9XTAoU4+RhZI=; b=QWHC/p+O7LiQjga/+v9LNm/K7yBxMFMi/mdqDGVJeFaaG2yPvbrrVBPv8MgO/ck0qf 7bt5QDwSzIvSJ96RJE1B38tyquibf+NN7j2LQ0pumOwDlY0OV35ASzH4kLqau5objz7u tqMfLGZYGDvQ2weG3tTqyyq77aNFl7bixgPNg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=aG6sq/NmuOyQftKyc7tH3LckJZWd8KQccHbNJN563cVMTqVlTqEMLxlPjKx0W1Viqq mF5STOb+rRhe3q/iQUf1vrRjCnNwPSSFgEsWEJJ57wB4mmHKDNUz8GtZcvik24HjFqEq RcME+D6r5wgzg4fmjD2yLyqIYTULaDgnKu6/U= MIME-Version: 1.0 Received: by 10.231.29.149 with SMTP id q21mr2943807ibc.35.1258341343217; Sun, 15 Nov 2009 19:15:43 -0800 (PST) Date: Mon, 16 Nov 2009 14:15:43 +1100 Message-ID: <66cd252f0911151915m724a0d0drebd39240c2256b56@mail.gmail.com> From: Hisham Khartabil To: Simple WG Content-Type: multipart/alternative; boundary=00151774051cc4c9c20478746c56 Subject: [Simple] WGLC on draft-ietf-simple-chat-05.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 03:15:47 -0000 --00151774051cc4c9c20478746c56 Content-Type: text/plain; charset=ISO-8859-1 This is a Working Group Last Call on draft-ietf-simple-chat-05.txt. http://www.ietf.org/id/draft-ietf-simple-chat-05.txt The WGLC will conclude on 30th November 2009. Please send your comments, including NITS and "this is ready to go" type comments, to the authors and the working group. Thanks, Hisham --00151774051cc4c9c20478746c56 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is a Working Group Last Call on draft-ietf-simple-chat-05.txt.

= http://www= .ietf.org/id/draft-ietf-simple-chat-05.txt

The WGLC will conclud= e on 30th November 2009. Please send your comments, including NITS and &quo= t;this is ready to go" type comments, to the authors and the working g= roup.

Thanks,
Hisham
--00151774051cc4c9c20478746c56-- From ibc@aliax.net Mon Nov 16 02:09:11 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C834328C102 for ; Mon, 16 Nov 2009 02:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.115 X-Spam-Level: X-Spam-Status: No, score=0.115 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8XNSTTFrqR3 for ; Mon, 16 Nov 2009 02:09:11 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id DF29A28C0F6 for ; Mon, 16 Nov 2009 02:09:10 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so2045120fga.13 for ; Mon, 16 Nov 2009 02:09:06 -0800 (PST) Received: by 10.86.178.18 with SMTP id a18mr5681005fgf.55.1258366145900; Mon, 16 Nov 2009 02:09:05 -0800 (PST) Received: from ibc-laptop.localnet ([212.230.46.89]) by mx.google.com with ESMTPS id 3sm10643510fge.9.2009.11.16.02.09.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 02:09:04 -0800 (PST) From: =?utf-8?q?I=C3=B1aki_Baz_Castillo?= To: simple@ietf.org Date: Mon, 16 Nov 2009 11:09:02 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.28-16-generic; KDE/4.3.2; x86_64; ; ) References: <66cd252f0911151915m724a0d0drebd39240c2256b56@mail.gmail.com> In-Reply-To: <66cd252f0911151915m724a0d0drebd39240c2256b56@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <200911161109.02222.ibc@aliax.net> Cc: miguel.a.garcia@ericsson.com, geir.sandbakken@tandberg.com, aki.niemi@nokia.com Subject: Re: [Simple] WGLC on draft-ietf-simple-chat-05.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 10:09:11 -0000 El Lunes, 16 de Noviembre de 2009, Hisham Khartabil escribi=C3=B3: > This is a Working Group Last Call on draft-ietf-simple-chat-05.txt. >=20 > http://www.ietf.org/id/draft-ietf-simple-chat-05.txt >=20 > The WGLC will conclude on 30th November 2009. Please send your comments, > including NITS and "this is ready to go" type comments, to the authors and > the working group. Hi, I assume the following are typos: =2D lines 1379 and 1432: From: (note "sip:sip:"). =2D-=20 I=C3=B1aki Baz Castillo From Jari.Urpalainen@nokia.com Mon Nov 16 05:14:47 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 781C428C152 for ; Mon, 16 Nov 2009 05:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGzgObDMPMZz for ; Mon, 16 Nov 2009 05:14:46 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 4983E3A6AA4 for ; Mon, 16 Nov 2009 05:14:46 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAGDENvq009313; Mon, 16 Nov 2009 15:14:41 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 15:13:56 +0200 Received: from mgw-da02.ext.nokia.com ([147.243.128.26]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 15:13:55 +0200 Received: from [172.21.37.235] (esdhcp037235.research.nokia.com [172.21.37.235]) by mgw-da02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAGDDqnr021513; Mon, 16 Nov 2009 15:13:52 +0200 From: Jari Urpalainen To: ext =?ISO-8859-1?Q?I=F1aki?= Baz Castillo In-Reply-To: <200911142324.43550.ibc@aliax.net> References: <200911142324.43550.ibc@aliax.net> Content-Type: text/plain; charset="UTF-8" Date: Mon, 16 Nov 2009 15:13:52 +0200 Message-Id: <1258377232.15678.24.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Nov 2009 13:13:55.0949 (UTC) FILETIME=[A6AA79D0:01CA66BE] X-Nokia-AV: Clean Cc: "simple@ietf.org" Subject: Re: [Simple] XCAP: Unique node selector but non unique path => HTTP 409 Conflict ? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 13:14:47 -0000 On Sat, 2009-11-14 at 23:24 +0100, ext Iñaki Baz Castillo wrote: > El Jueves, 12 de Noviembre de 2009, Iñaki Baz Castillo escribió: > > My XML parser allows it and finds the node. I think (but I'm not sure) > > that Xpath specifications allows it. However I don't know if XCAP > > protocol overrides it so the request should get a "409 Conflict". > > > > I do know that XCAP doesn't allow a Xpath selector getting more than > > one node, but it's not the case of the above request as I've > > explained. However the first portion of the Xpath > > "cp:ruleset/cp:rule/" is not unique (as there are two > > nodes). > > > > So, should the XCAP server reply 409? or should accept the request and > > reply 200 with the fetched node in the body? > > > > Thanks a lot. > > > Hi, as nobody replies to questions about SIMPLE/XCAP in this maillist I just > would like to know if this is not the appropriate place to ask such questions. > > Perhaps this maillist is focused on comments about new drafts or specification > proposals. If so, could I know a good maillist in which I could ask about > SIMPLE/XCAP as implementor? Is sip-implementors the appropriate place? > > Thanks a lot. > Section 6.3: "Each step in a node selector MUST produce a single element to form the context for the next step. This is more restrictive than general XPath expressions, which allow a context to contain multiple nodes." So 409/error is the right answer. That being said, I would have preferred the more liberal XPath model, but it was argued that it could have performance implications. At least in my implementation though, it would be faster to use the XPath model (the difference is very small however). But I've no clue how many implementations actually obey this rule. br, jari From ibc@aliax.net Mon Nov 16 05:36:18 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B445428C153 for ; Mon, 16 Nov 2009 05:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpsOSjF+o+5b for ; Mon, 16 Nov 2009 05:36:17 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 75F8128C155 for ; Mon, 16 Nov 2009 05:36:17 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id e12so1038833fga.13 for ; Mon, 16 Nov 2009 05:36:13 -0800 (PST) Received: by 10.86.104.7 with SMTP id b7mr3978655fgc.34.1258378572940; Mon, 16 Nov 2009 05:36:12 -0800 (PST) Received: from ibc-laptop.localnet ([212.230.46.89]) by mx.google.com with ESMTPS id l19sm4727480fgb.16.2009.11.16.05.36.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 05:36:11 -0800 (PST) From: =?utf-8?q?I=C3=B1aki_Baz_Castillo?= To: simple@ietf.org Date: Mon, 16 Nov 2009 14:36:08 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.28-16-generic; KDE/4.3.2; x86_64; ; ) References: <200911142324.43550.ibc@aliax.net> <1258377232.15678.24.camel@localhost> In-Reply-To: <1258377232.15678.24.camel@localhost> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <200911161436.08334.ibc@aliax.net> Subject: Re: [Simple] XCAP: Unique node selector but non unique path => HTTP 409 Conflict ? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 13:36:18 -0000 El Lunes, 16 de Noviembre de 2009, Jari Urpalainen escribi=C3=B3: > On Sat, 2009-11-14 at 23:24 +0100, ext I=C3=B1aki Baz Castillo wrote: > > El Jueves, 12 de Noviembre de 2009, I=C3=B1aki Baz Castillo escribi=C3= =B3: > > > My XML parser allows it and finds the node. I think (but I'm not sure) > > > that Xpath specifications allows it. However I don't know if XCAP > > > protocol overrides it so the request should get a "409 Conflict". > > > > > > I do know that XCAP doesn't allow a Xpath selector getting more than > > > one node, but it's not the case of the above request as I've > > > explained. However the first portion of the Xpath > > > "cp:ruleset/cp:rule/" is not unique (as there are two > > > nodes). > > > > > > So, should the XCAP server reply 409? or should accept the request and > > > reply 200 with the fetched node in the body? > > > > > > Thanks a lot. > > > > Hi, as nobody replies to questions about SIMPLE/XCAP in this maillist I > > just would like to know if this is not the appropriate place to ask such > > questions. > > > > Perhaps this maillist is focused on comments about new drafts or > > specification proposals. If so, could I know a good maillist in which I > > could ask about SIMPLE/XCAP as implementor? Is sip-implementors the > > appropriate place? > > > > Thanks a lot. >=20 > Section 6.3: > "Each step in a node selector MUST produce a single element to form the > context for the next step. This is more restrictive than general XPath > expressions, which allow a context to contain multiple nodes." >=20 > So 409/error is the right answer. That being said, I would have > preferred the more liberal XPath model, but it was argued that it could > have performance implications. At least in my implementation though, it > would be faster to use the XPath model (the difference is very small > however). But I've no clue how many implementations actually obey this > rule. Thanks. However I also asked in sip-implementors and got a reply in which=20 returning 200 OK is the correct reply: =2D--------------------------------------------------------------- The response should be 200 OK with the queried node. During the selection process, you can have a result with a list of matching= =20 context. The uniqueness is only considered AFTER the whole criteria has bee= n=20 applied. As per RFC 4825 (Para 6.3), emphasis of mine: =20 "The selection operation operates as follows. Within the current document context, the children of that context are enumerated in document order. If the context is the root node of the document, its child element is the root element of the document. If the context is an element, its children are all of the children of that element (naturally). Next, those elements whose name is not a match for NameorAny are discarded. An element name is a match if NameorAny is the wildcard, or if it is not a wildcard, the element name matches NameorAny. Matching is discussed below. The result is an ordered list of elements. The elements in the list are further filtered by the predicates, which are the expressions in square brackets following NameorAny. Each predicate further prunes the elements from the current ordered list. These predicates are evaluated in order. If the content of the predicate is a position, the position-th element is selected (that is, treat "position" as a variable, and take the element whose position equals that variable), and all others are discarded. If there are fewer elements in the list than the value of position, the result is a no-match." =2E.. After the predicates have been applied, the result will be a no-match, one element, or multiple elements. If the result is multiple elements, the node selector is invalid. Each step in a node selector MUST produce a single element to form the context for the next step. This is more restrictive than general XPath expressions, which allow a context to contain multiple nodes. If the result is a no-match, the node selector is invalid. The node selector is only valid if a single element was selected. This element becomes the context for the evaluation of the next step in the node selector expression." =2D--------------------------------------------------------------- However I also read "Each step in a node selector MUST produce a single=20 element to form the context for the next step" which doesn't clarify me if = 200=20 is correct. Thanks. =2D-=20 I=C3=B1aki Baz Castillo From geir.sandbakken@tandberg.com Mon Nov 16 09:26:04 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D685028C1D9 for ; Mon, 16 Nov 2009 09:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1cD81s76shJ for ; Mon, 16 Nov 2009 09:26:04 -0800 (PST) Received: from mail169.messagelabs.com (mail169.messagelabs.com [85.158.138.179]) by core3.amsl.com (Postfix) with SMTP id 5A2AB28C1D0 for ; Mon, 16 Nov 2009 09:26:02 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: geir.sandbakken@tandberg.com X-Msg-Ref: server-11.tower-169.messagelabs.com!1258392359!20178390!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 11563 invoked from network); 16 Nov 2009 17:25:59 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-11.tower-169.messagelabs.com with SMTP; 16 Nov 2009 17:25:59 -0000 Received: from ultra.eu.tandberg.int ([10.47.1.15]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 18:25:59 +0100 Received: from [10.0.6.163] (rdsip2.eu.tandberg.int [10.0.6.163] (may be forged)) by ultra.eu.tandberg.int (8.13.1/8.13.1) with ESMTP id nAGHPwop006786; Mon, 16 Nov 2009 18:25:58 +0100 Message-ID: <4B018B25.7070700@tandberg.com> Date: Mon, 16 Nov 2009 18:25:57 +0100 From: Geir Arne Sandbakken User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <66cd252f0911151915m724a0d0drebd39240c2256b56@mail.gmail.com> <200911161109.02222.ibc@aliax.net> In-Reply-To: <200911161109.02222.ibc@aliax.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Nov 2009 17:25:59.0231 (UTC) FILETIME=[DCD82CF0:01CA66E1] Cc: miguel.a.garcia@ericsson.com, simple@ietf.org, aki.niemi@nokia.com Subject: Re: [Simple] WGLC on draft-ietf-simple-chat-05.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 17:26:04 -0000 Thank you! I will update the draft. Geir Arne Iñaki Baz Castillo wrote: > El Lunes, 16 de Noviembre de 2009, Hisham Khartabil escribió: > >> This is a Working Group Last Call on draft-ietf-simple-chat-05.txt. >> >> http://www.ietf.org/id/draft-ietf-simple-chat-05.txt >> >> The WGLC will conclude on 30th November 2009. Please send your comments, >> including NITS and "this is ready to go" type comments, to the authors and >> the working group. >> > > Hi, I assume the following are typos: > > - lines 1379 and 1432: > > From: > > (note "sip:sip:"). > > > > From dean.willis@softarmor.com Tue Nov 17 15:56:46 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BD173A6A35 for ; Tue, 17 Nov 2009 15:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAVTQsUjbP+9 for ; Tue, 17 Nov 2009 15:56:45 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 275EC3A694E for ; Tue, 17 Nov 2009 15:56:45 -0800 (PST) Received: from [192.168.2.105] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAHNuamQ003154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 17 Nov 2009 17:56:38 -0600 Message-Id: <19F1F9C9-6A3D-418E-A006-70ABD47F9BD2@softarmor.com> From: Dean Willis To: "Rauschenbach, Uwe (NSN - DE/Munich)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Nov 2009 17:56:31 -0600 References: <39E0CF0AE5F81649AA77FC1758A2BEF03D23B2200B@XMSCLUSTER-MBX.etsihq.org> X-Mailer: Apple Mail (2.936) Cc: adam@nostrum.com, jdrosen@cisco.com, Louise.Clarke@forapolis.com, simple@ietf.org Subject: Re: [Simple] Liaison statement from OMA to IETF SIMPLE on XML validation issues of IANA copies of XML schemas from RFC 4826 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 23:56:46 -0000 The IETF doesn't work much with attachments. LS do not go to mailing lists. Rather, they go to the IETF Liaison Tool. Theoretically, OMA's secretariat is supposed to use this tool for submission purposes, but we've never gotten the process worked out right so I've been doing it. Your LS was posted here on October 3, 2009: https://datatracker.ietf.org/liaison/592/ -- Dean WIllis IETF liaison manager to OMA, I think. On Oct 1, 2009, at 7:39 AM, Rauschenbach, Uwe (NSN - DE/Munich) wrote: > Dear IETF colleagues, > > the recently-sent LS below did not appear on the SIMPLE mailing > list. This is the second attempt to get it through. > > OMA kindly asks the SIMPLE working group to address the issue > reported in the enclosed LS. > Kind regards, > Uwe Rauschenbach > > -- > Dr. Uwe Rauschenbach > Senior Specialist > Nokia Siemens Networks GmbH & Co. KG > Research, Technology & Platforms > St.-Martin-Str. 53, D-80240 Munich, Germany > Tel.: +49 89 5159 29751 > Mobile: +49 173 3083573 > > > > > From: ext Louise Clarke [mailto:Louise.Clarke@forapolis.com] > Sent: Wednesday, September 23, 2009 9:52 AM > To: dean.willis@softarmor.com; adam@nostrum.com; simple@ietf.org > Cc: OMA-PLENARY@MAIL.OPENMOBILEALLIANCE.ORG; OMA-LIAISON@MAIL.OPENMOBILEALLIANCE.ORG > ; UNMEHOPA, Musa (Musa); Rauschenbach, Uwe (NSN - DE/Munich); kyungtak.lee@samsung.com > Subject: > > To: IETF > Cc: OMA-TP, OMA-Liaison, ARC Chair, MWG Chair > > Dear IETF, > > Please find attached a Liaison Statement from OMA Architecture and > Messaging Working Groups on XML validation issues for your > consideration > > Kind Regards > > Louise Clarke > Document Support Officer > Open Mobile Alliance > Louise.Clarke@forapolis.com > > Tel: +33(0) 492 944912 > Mob:+33(0) 607590853 > > A.zip> From dean.willis@softarmor.com Tue Nov 17 16:07:32 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21F553A69E3 for ; Tue, 17 Nov 2009 16:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6PfJlO29hCE for ; Tue, 17 Nov 2009 16:07:31 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 162513A67B3 for ; Tue, 17 Nov 2009 16:07:31 -0800 (PST) Received: from [192.168.2.105] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id nAI07QFE003266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 17 Nov 2009 18:07:28 -0600 Message-Id: <7DB339B0-0844-48A2-B51C-CC94AC321B7A@softarmor.com> From: Dean Willis To: "simple@ietf.org WG" In-Reply-To: <19F1F9C9-6A3D-418E-A006-70ABD47F9BD2@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Nov 2009 18:07:21 -0600 References: <39E0CF0AE5F81649AA77FC1758A2BEF03D23B2200B@XMSCLUSTER-MBX.etsihq.org> <19F1F9C9-6A3D-418E-A006-70ABD47F9BD2@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: Louise.Clarke@forapolis.com Subject: Re: [Simple] Liaison statement from OMA to IETF SIMPLE on XML validation issues of IANA copies of XML schemas from RFC 4826 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 00:07:32 -0000 SIMPLE list: I tripped over something and e-responded to this old LS submission. It's not a new one, and the resend here is my error. However, this is a good time for me to ask: Are we dealing with this LS, and have we responded? I have seen nothing on-list about it since I submitted the LS on October 3. -- Dean On Nov 17, 2009, at 5:56 PM, Dean Willis wrote: > The IETF doesn't work much with attachments. LS do not go to mailing > lists. Rather, they go to the IETF Liaison Tool. Theoretically, > OMA's secretariat is supposed to use this tool for submission > purposes, but we've never gotten the process worked out right so > I've been doing it. > > Your LS was posted here on October 3, 2009: > > https://datatracker.ietf.org/liaison/592/ > > -- > Dean WIllis > IETF liaison manager to OMA, I think. > > On Oct 1, 2009, at 7:39 AM, Rauschenbach, Uwe (NSN - DE/Munich) wrote: > >> Dear IETF colleagues, >> >> the recently-sent LS below did not appear on the SIMPLE mailing >> list. This is the second attempt to get it through. >> >> OMA kindly asks the SIMPLE working group to address the issue >> reported in the enclosed LS. >> Kind regards, >> Uwe Rauschenbach >> >> -- >> Dr. Uwe Rauschenbach >> Senior Specialist >> Nokia Siemens Networks GmbH & Co. KG >> Research, Technology & Platforms >> St.-Martin-Str. 53, D-80240 Munich, Germany >> Tel.: +49 89 5159 29751 >> Mobile: +49 173 3083573 >> >> >> >> >> From: ext Louise Clarke [mailto:Louise.Clarke@forapolis.com] >> Sent: Wednesday, September 23, 2009 9:52 AM >> To: dean.willis@softarmor.com; adam@nostrum.com; simple@ietf.org >> Cc: OMA-PLENARY@MAIL.OPENMOBILEALLIANCE.ORG; OMA-LIAISON@MAIL.OPENMOBILEALLIANCE.ORG >> ; UNMEHOPA, Musa (Musa); Rauschenbach, Uwe (NSN - DE/Munich); kyungtak.lee@samsung.com >> Subject: >> >> To: IETF >> Cc: OMA-TP, OMA-Liaison, ARC Chair, MWG Chair >> >> Dear IETF, >> >> Please find attached a Liaison Statement from OMA Architecture and >> Messaging Working Groups on XML validation issues for your >> consideration >> >> Kind Regards >> >> Louise Clarke >> Document Support Officer >> Open Mobile Alliance >> Louise.Clarke@forapolis.com >> >> Tel: +33(0) 492 944912 >> Mob:+33(0) 607590853 >> >> > A.zip> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From ben@nostrum.com Tue Nov 17 16:40:28 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14CB93A6898 for ; Tue, 17 Nov 2009 16:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZOqHu4+jjnA for ; Tue, 17 Nov 2009 16:40:27 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 010103A67B3 for ; Tue, 17 Nov 2009 16:40:26 -0800 (PST) Received: from [10.0.1.8] (adsl-68-94-17-55.dsl.rcsntx.swbell.net [68.94.17.55]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nAI0eLve049391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Nov 2009 18:40:21 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <7DB339B0-0844-48A2-B51C-CC94AC321B7A@softarmor.com> Date: Tue, 17 Nov 2009 18:40:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3F127336-6656-4A7E-8C2D-07A3AE10EB7D@nostrum.com> References: <39E0CF0AE5F81649AA77FC1758A2BEF03D23B2200B@XMSCLUSTER-MBX.etsihq.org> <19F1F9C9-6A3D-418E-A006-70ABD47F9BD2@softarmor.com> <7DB339B0-0844-48A2-B51C-CC94AC321B7A@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1077) Received-SPF: pass (nostrum.com: 68.94.17.55 is authenticated by a trusted mechanism) Cc: Louise.Clarke@forapolis.com, "simple@ietf.org WG" Subject: Re: [Simple] Liaison statement from OMA to IETF SIMPLE on XML validation issues of IANA copies of XML schemas from RFC 4826 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 00:40:28 -0000 On Nov 17, 2009, at 6:07 PM, Dean Willis wrote: > However, this is a good time for me to ask: Are we dealing with this = LS, and have we responded? I have seen nothing on-list about it since I = submitted the LS on October 3. We've had a little bit of discussion on it. I will send a summary to the = list shortly.= From root@core3.amsl.com Wed Nov 18 01:30:01 2009 Return-Path: X-Original-To: simple@ietf.org Delivered-To: simple@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5B7813A692B; Wed, 18 Nov 2009 01:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091118093001.5B7813A692B@core3.amsl.com> Date: Wed, 18 Nov 2009 01:30:01 -0800 (PST) Cc: simple@ietf.org Subject: [Simple] I-D Action:draft-ietf-simple-msrp-acm-02.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 09:30:01 -0000 --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 Alternative Connection Model for the Message Session Relay Protocol (MSRP) Author(s) : C. Holmberg, S. Blau Filename : draft-ietf-simple-msrp-acm-02.txt Pages : 8 Date : 2009-11-18 This document defines an alternative connection model for MSRP UAs, which uses COMEDIA in order to create the MSRP transport connection. The model allows MSRP UAs which are located behind NATs to indicate that they want to initiate the establishment of the TCP connection towards the remote MSRP UA, in order for MSRP messages to traverse the NAT. The document also defines how an MSRP UA which is located behind a NAT keeps the NAT binding alive. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 22, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-acm-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-simple-msrp-acm-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-18012605.I-D@ietf.org> --NextPart-- From christer.holmberg@ericsson.com Wed Nov 18 01:30:17 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B4F728C190 for ; Wed, 18 Nov 2009 01:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L950kuXFaLkh for ; Wed, 18 Nov 2009 01:30:16 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A3E5928C191 for ; Wed, 18 Nov 2009 01:30:15 -0800 (PST) X-AuditID: c1b4fb3e-b7b90ae000005e1e-7d-4b03bea477f6 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 9E.02.24094.4AEB30B4; Wed, 18 Nov 2009 10:30:12 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 10:30:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6831.B74744D9" Date: Wed, 18 Nov 2009 10:30:06 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MSRP ACM: Two drafts thread-index: AcpoMbbbDg5NKmUESFSFO1+Z4cItgg== From: "Christer Holmberg" To: "Simple WG" X-OriginalArrivalTime: 18 Nov 2009 09:30:08.0387 (UTC) FILETIME=[B80A9D30:01CA6831] X-Brightmail-Tracker: AAAAAA== Subject: [Simple] MSRP ACM: Two drafts X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 09:30:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6831.B74744D9 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, Based on the discussions in Hiroshima, I have put together a separate draft for the RFC4975 session matching update. In addition, I've removed the c/m routing stuff from the ACM draft, so most of the stuff left is related to COMEDIA. =20 I have submitted both drafts, and they can also be found at: http://users.piuha.net/cholmber/drafts/draft-ietf-simple-msrp-acm-02.txt http://users.piuha.net/cholmber/drafts/draft-holmberg-simple-msrp-sessma tch-00.txt=20 Regards, Christer ------_=_NextPart_001_01CA6831.B74744D9 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable MSRP ACM: Two drafts

Hi,

Based on the discussions in = Hiroshima, I have put together a separate draft for the RFC4975 session = matching update.

In addition, I've removed the c/m = routing stuff from the ACM draft, so most of the stuff left is related = to COMEDIA.
 
I have submitted both drafts, = and they can also be found at:

http://users.piuha.net/cholmber/drafts/draft-ietf-simple-msrp-acm-02= .txt

http://users.piuha.net/cholmber/drafts/draft-holmberg-simple-msrp-se= ssmatch-00.txt =

Regards,

Christer

------_=_NextPart_001_01CA6831.B74744D9-- From ben@nostrum.com Wed Nov 18 13:59:33 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1B593A67D6 for ; Wed, 18 Nov 2009 13:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twHM03xvohND for ; Wed, 18 Nov 2009 13:59:33 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id AC4743A6782 for ; Wed, 18 Nov 2009 13:59:32 -0800 (PST) Received: from rocinante.test.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nAILxNqq036804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Nov 2009 15:59:23 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: Date: Wed, 18 Nov 2009 15:59:23 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <81621E94-1FF4-4584-9C55-30945836C7DF@nostrum.com> References: To: Simple WG X-Mailer: Apple Mail (2.1077) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Louise.Clarke@forapolis.com, Dean Willis Subject: Re: [Simple] Liaison Statement from the Open Mobile Alliance X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 21:59:34 -0000 We've had a small amount of on-list discussion. =46rom the emails so far = I gather that there are no objections to correcting the schema as = published by IANA to match those from RFC 4826. However, there have been = some objections to adding the SchemaLocation parameters as requested in = the liaison statement. Everyone--please take a look at the liaison statement and offer your = opinions. Even "me too" comments would be helpful at this point. It's = been almost two months since OMA sent the liaison statement, and we need = to respond to it ASAP. Thanks! Ben. On Oct 2, 2009, at 1:12 PM, Ben Campbell wrote: > (as SIMPLE co-chair) >=20 > OMA sent a liaison statement to the SIMPLE working group. The = statement's overview reads as follows: >=20 > "This Liaison Statement reports XML validation problems in the XML = schemas that were introduced in RFC 4826 and asks for correction." >=20 > Please read the LS, and send your opinions to the SIMPLE list. A PDF = is available at = https://datatracker.ietf.org/documents/LIAISON/file707.pdf >=20 > Thanks! >=20 > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From hisham.khartabil@gmail.com Wed Nov 18 17:14:48 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C1DE3A6ACD for ; Wed, 18 Nov 2009 17:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lEHoQV0Gqya for ; Wed, 18 Nov 2009 17:14:47 -0800 (PST) Received: from mail-px0-f186.google.com (mail-px0-f186.google.com [209.85.216.186]) by core3.amsl.com (Postfix) with ESMTP id 91E363A6B0F for ; Wed, 18 Nov 2009 17:14:42 -0800 (PST) Received: by pxi16 with SMTP id 16so1156006pxi.29 for ; Wed, 18 Nov 2009 17:14:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=+ift2pT8WQdnEXNlZGhMnQU/cSAwVCMnCGafveLNGMA=; b=E2A8NEo0q5eztom17ms2AFy4WQiUjXiBS2pEGNY9c9b2wJWBXsprwzwb6BOEsHJflQ 5JKI8ym9KUk0MnAa9o3Sfp6gDKpCfuFl1OS8aCCcphYgUcsXaZxBl30BESln19/gojHH QXyCRh3Eatimb2v2YuSVWBbywfevY1hvdv4n4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oXuz9uFvbRiaT5562NYn0uWnFMcyCUCubT8gqWYey3RyvJWBa+r+lxn0OJGmo2fas4 2mpiOX5H4xT64hSWpPuBR03wmLBAmpK6lw8nIZ7lBQpOlfSkdrt9GQW33XtqkIqumi++ /c+vPlSxCQufu6IhHyz12kb+TaOvS39Nd73d8= MIME-Version: 1.0 Received: by 10.142.61.23 with SMTP id j23mr1300568wfa.323.1258593277503; Wed, 18 Nov 2009 17:14:37 -0800 (PST) In-Reply-To: <81621E94-1FF4-4584-9C55-30945836C7DF@nostrum.com> References: <81621E94-1FF4-4584-9C55-30945836C7DF@nostrum.com> Date: Thu, 19 Nov 2009 12:14:37 +1100 Message-ID: <66cd252f0911181714p756a42e9y8ed4b0c96f032b42@mail.gmail.com> From: Hisham Khartabil To: Ben Campbell Content-Type: multipart/alternative; boundary=001636e1f73d38ea7d0478af15a9 Cc: Louise.Clarke@forapolis.com, Simple WG , Dean Willis Subject: Re: [Simple] Liaison Statement from the Open Mobile Alliance X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 01:14:48 -0000 --001636e1f73d38ea7d0478af15a9 Content-Type: text/plain; charset=ISO-8859-1 No issues in correcting the IANA pages, but we can't make modifications or extensions to a schema published in an RFC unless the extension is documented and published. Thanks, Hisham 2009/11/19 Ben Campbell > > We've had a small amount of on-list discussion. From the emails so far I > gather that there are no objections to correcting the schema as published by > IANA to match those from RFC 4826. However, there have been some objections > to adding the SchemaLocation parameters as requested in the liaison > statement. > > Everyone--please take a look at the liaison statement and offer your > opinions. Even "me too" comments would be helpful at this point. It's been > almost two months since OMA sent the liaison statement, and we need to > respond to it ASAP. > > Thanks! > > Ben. > > > > > On Oct 2, 2009, at 1:12 PM, Ben Campbell wrote: > > > (as SIMPLE co-chair) > > > > OMA sent a liaison statement to the SIMPLE working group. The statement's > overview reads as follows: > > > > "This Liaison Statement reports XML validation problems in the XML > schemas that were introduced in RFC 4826 and asks for correction." > > > > Please read the LS, and send your opinions to the SIMPLE list. A PDF is > available at https://datatracker.ietf.org/documents/LIAISON/file707.pdf > > > > Thanks! > > > > Ben. > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > --001636e1f73d38ea7d0478af15a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <as individual>

No issues in correcting the IANA pages, but we= can't make modifications or extensions to a schema published in an RFC= unless the extension is documented and published.

Thanks,
Hisham=

2009/11/19 Ben Campbell &l= t;ben@nostrum.com>
<chair>
We've had a small amount of on-list discussion. From the emails so far = I gather that there are no objections to correcting the schema as published= by IANA to match those from RFC 4826. However, there have been some object= ions to adding the SchemaLocation parameters as requested in the liaison st= atement.

Everyone--please take a look at the liaison statement and offer your opinio= ns. Even "me too" comments would be helpful at this point. It'= ;s been almost two months since OMA sent the liaison statement, and we need= to respond to it ASAP.

Thanks!

Ben.

</chair>


On Oct 2, 2009, at 1:12 PM, Ben Campbell wrote:

> (as SIMPLE co-chair)
>
> OMA sent a liaison statement to the SIMPLE working group. The statemen= t's overview reads as follows:
>
> "This Liaison Statement reports XML validation problems in the XM= L schemas that were introduced in RFC 4826 and asks for correction." >
> Please read the LS, and send your opinions to the SIMPLE list. A PDF = =A0is available at https://datatracker.ietf.org/documents/LIA= ISON/file707.pdf
>
> Thanks!
>
> Ben.
> ________________________= _______________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple

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

--001636e1f73d38ea7d0478af15a9-- From ben@nostrum.com Wed Nov 18 17:31:34 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE7803A6867 for ; Wed, 18 Nov 2009 17:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZDGYTr55cxR for ; Wed, 18 Nov 2009 17:31:33 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 4B7D43A67B3 for ; Wed, 18 Nov 2009 17:31:32 -0800 (PST) Received: from [10.0.1.8] (adsl-68-94-17-55.dsl.rcsntx.swbell.net [68.94.17.55]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nAJ1VQJ1078986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Nov 2009 19:31:26 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-2--1033276910 From: Ben Campbell In-Reply-To: <66cd252f0911181714p756a42e9y8ed4b0c96f032b42@mail.gmail.com> Date: Wed, 18 Nov 2009 19:31:20 -0600 Message-Id: References: <81621E94-1FF4-4584-9C55-30945836C7DF@nostrum.com> <66cd252f0911181714p756a42e9y8ed4b0c96f032b42@mail.gmail.com> To: Hisham Khartabil X-Mailer: Apple Mail (2.1077) Received-SPF: pass (nostrum.com: 68.94.17.55 is authenticated by a trusted mechanism) Cc: Louise.Clarke@forapolis.com, Simple WG , Dean Willis Subject: Re: [Simple] Liaison Statement from the Open Mobile Alliance X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 01:31:34 -0000 --Apple-Mail-2--1033276910 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii And the thing they are asking for would generally _not_ make sense to = put in an RFC, unless we are willing to ensure the URL to the schema = lives forever. On Nov 18, 2009, at 7:14 PM, Hisham Khartabil wrote: > >=20 > No issues in correcting the IANA pages, but we can't make = modifications or extensions to a schema published in an RFC unless the = extension is documented and published. >=20 > Thanks, > Hisham >=20 > 2009/11/19 Ben Campbell > > We've had a small amount of on-list discussion. =46rom the emails so = far I gather that there are no objections to correcting the schema as = published by IANA to match those from RFC 4826. However, there have been = some objections to adding the SchemaLocation parameters as requested in = the liaison statement. >=20 > Everyone--please take a look at the liaison statement and offer your = opinions. Even "me too" comments would be helpful at this point. It's = been almost two months since OMA sent the liaison statement, and we need = to respond to it ASAP. >=20 > Thanks! >=20 > Ben. >=20 > >=20 >=20 > On Oct 2, 2009, at 1:12 PM, Ben Campbell wrote: >=20 > > (as SIMPLE co-chair) > > > > OMA sent a liaison statement to the SIMPLE working group. The = statement's overview reads as follows: > > > > "This Liaison Statement reports XML validation problems in the XML = schemas that were introduced in RFC 4826 and asks for correction." > > > > Please read the LS, and send your opinions to the SIMPLE list. A PDF = is available at = https://datatracker.ietf.org/documents/LIAISON/file707.pdf > > > > Thanks! > > > > Ben. > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 --Apple-Mail-2--1033276910 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
<individual>

And the thing they are asking for would generally _not_ make sense to put in an RFC, unless we are willing to ensure the URL to the schema lives forever.

On Nov 18, 2009, at 7:14 PM, Hisham Khartabil wrote:

<as individual>

No issues in correcting the IANA pages, but we can't make modifications or extensions to a schema published in an RFC unless the extension is documented and published.

Thanks,
Hisham

2009/11/19 Ben Campbell <ben@nostrum.com>
<chair>
We've had a small amount of on-list discussion. From the emails so far I gather that there are no objections to correcting the schema as published by IANA to match those from RFC 4826. However, there have been some objections to adding the SchemaLocation parameters as requested in the liaison statement.

Everyone--please take a look at the liaison statement and offer your opinions. Even "me too" comments would be helpful at this point. It's been almost two months since OMA sent the liaison statement, and we need to respond to it ASAP.

Thanks!

Ben.

</chair>


On Oct 2, 2009, at 1:12 PM, Ben Campbell wrote:

> (as SIMPLE co-chair)
>
> OMA sent a liaison statement to the SIMPLE working group. The statement's overview reads as follows:
>
> "This Liaison Statement reports XML validation problems in the XML schemas that were introduced in RFC 4826 and asks for correction."
>
> Please read the LS, and send your opinions to the SIMPLE list. A PDF  is available at https://datatracker.ietf.org/documents/LIAISON/file707.pdf
>
> Thanks!
>
> Ben.
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple

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


--Apple-Mail-2--1033276910-- From ibc@aliax.net Thu Nov 19 02:03:07 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F2AB3A6A78 for ; Thu, 19 Nov 2009 02:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNvtAKmXR0rz for ; Thu, 19 Nov 2009 02:03:05 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 9A3463A694C for ; Thu, 19 Nov 2009 02:03:05 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so477281eya.51 for ; Thu, 19 Nov 2009 02:02:56 -0800 (PST) Received: by 10.213.23.75 with SMTP id q11mr1222003ebb.74.1258624976815; Thu, 19 Nov 2009 02:02:56 -0800 (PST) Received: from ibc-laptop.localnet ([212.230.46.89]) by mx.google.com with ESMTPS id 7sm99599eyb.18.2009.11.19.02.02.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 02:02:55 -0800 (PST) From: =?utf-8?q?I=C3=B1aki_Baz_Castillo?= To: simple@ietf.org Date: Thu, 19 Nov 2009 11:02:52 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.28-16-generic; KDE/4.3.2; x86_64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <200911191102.52794.ibc@aliax.net> Subject: [Simple] XCAP: Issues with document/application default namespace X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:03:07 -0000 Hi, let imagine this XML document stored in XCAP server: =2D---test.xml------------------------ =2D----------------------------------- Which would be the correct XCAP query to get the node?: 1) /test/users/sip:a@d.org/test.xml/~~/foo 2) /test/users/sip:a@d.org/test.xml/~~/foo?xmlns(xmlns=3Durn:default-namespace) 3) /test/users/sip:a@d.org/test.xml/~~/a:foo?xmlns(a=3Durn:default-namespace) I'm sure that case 3) is valid and works. About case 1) I'm not sure if it should work. Case 2) seems incorrect to me. However I don't know how the client can indicate which is the default namespace used in the query (IMHO it cannot=20 according to XCAP specs so it must use namespaces with prefix). AFAIK XCAP specifies that when no prefix is used in the query Xpath the aui= d=20 default namespace must be used (let's suppose "urn:default-namespace"), but= =20 what about if the XML document declares a different default namespace=20 (different than the XCAP application default namespace)? XCAP seems to "extend" this specs by allowing a Xpath query with no=20 namespaces matching a XML document node in which the default document=20 namespaces matches the XCAP app default namespace (ugly however). According to XML namespaces and Xpath specs, cases 1) and 2) shouldn't work= =20 since the node has a namespace "urn:default-namespace" and it's not=20 specified in the Xpath query. This is, in Xpath specs if the document decla= res=20 a namespace then it must be included in the Xpath query even if it's the=20 default namespace (so "xmlns=3D'xxxxxxxxxx'" should appear in the Xpath que= ry).=20 Since XCAP query doesn't allow indicating a default namespace the client=20 should use namespace prefix for the default namespace (so case 3 is valid). What I mean is that XCAP violates Xpath and XML namespaces spects. Opinions? Other question 100% related to this issue: https://lists.cs.columbia.edu/pipermail/sip-implementors/2008- April/018952.html Thanks for any help. Regards. =2D-=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Thu Nov 19 04:28:17 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5B423A68C7 for ; Thu, 19 Nov 2009 04:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbATR4eNoeGN for ; Thu, 19 Nov 2009 04:28:16 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 0AC123A6918 for ; Thu, 19 Nov 2009 04:28:15 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so514150eya.51 for ; Thu, 19 Nov 2009 04:28:09 -0800 (PST) Received: by 10.213.23.151 with SMTP id r23mr2964394ebb.63.1258633688803; Thu, 19 Nov 2009 04:28:08 -0800 (PST) Received: from ibc-laptop.localnet ([212.230.46.89]) by mx.google.com with ESMTPS id 10sm124571eyd.5.2009.11.19.04.28.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 04:28:07 -0800 (PST) From: =?utf-8?q?I=C3=B1aki_Baz_Castillo?= To: simple@ietf.org Date: Thu, 19 Nov 2009 13:28:04 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.28-16-generic; KDE/4.3.2; x86_64; ; ) References: <200911191102.52794.ibc@aliax.net> In-Reply-To: <200911191102.52794.ibc@aliax.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <200911191328.04675.ibc@aliax.net> Subject: Re: [Simple] XCAP: Issues with document/application default namespace X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 12:28:17 -0000 El Jueves, 19 de Noviembre de 2009, I=C3=B1aki Baz Castillo escribi=C3=B3: > Hi, let imagine this XML document stored in XCAP server: >=20 > ----test.xml------------------------ > > > > ------------------------------------ >=20 > Which would be the correct XCAP query to get the node?: >=20 > 1) > /test/users/sip:a@d.org/test.xml/~~/foo >=20 > 2) > /test/users/sip:a@d.org/test.xml/~~/foo?xmlns(xmlns=3Durn:default-namespa= ce) >=20 > 3) > /test/users/sip:a@d.org/test.xml/~~/a:foo?xmlns(a=3Durn:default-namespace) >=20 >=20 > I'm sure that case 3) is valid and works. >=20 > About case 1) I'm not sure if it should work. >=20 > Case 2) seems incorrect to me. However I don't know how the client can > indicate which is the default namespace used in the query (IMHO it cannot > according to XCAP specs so it must use namespaces with prefix). > AFAIK XCAP specifies that when no prefix is used in the query Xpath the > auid default namespace must be used (let's suppose > "urn:default-namespace"), but what about if the XML document declares a > different default namespace (different than the XCAP application default > namespace)? >=20 > XCAP seems to "extend" this specs by allowing a Xpath query with no > namespaces matching a XML document node in which the default document > namespaces matches the XCAP app default namespace (ugly however). >=20 > According to XML namespaces and Xpath specs, cases 1) and 2) shouldn't wo= rk > since the node has a namespace "urn:default-namespace" and it's not > specified in the Xpath query. This is, in Xpath specs if the document > declares a namespace then it must be included in the Xpath query even if > it's the default namespace (so "xmlns=3D'xxxxxxxxxx'" should appear in t= he > Xpath query). Since XCAP query doesn't allow indicating a default > namespace the client should use namespace prefix for the default namespa= ce > (so case 3 is valid). >=20 > What I mean is that XCAP violates Xpath and XML namespaces spects. > Opinions? >=20 > Other question 100% related to this issue: >=20 > https://lists.cs.columbia.edu/pipermail/sip-implementors/2008- > April/018952.html After readin 5-6 times RFC 4825 section 5.2 "Default Document Namespace" I= =20 think I got the response. Please correct me if I'm wrong: =2D Each XCAP auid has a "default auid document namespace" (AKA "default=20 document namespace"). =2D This is just valid for the XCAP Xpath query and refers to the default u= sed=20 in evaluation of XCAP URIs, so if the Xpath contains nodes with no prefix (= so=20 no namespace association) then the server must assume that those nodes belo= ng=20 to the "default auid document namespace". =2D The XML document itself can contain a "default namespace" in root node = or=20 childs (this means: . This namespace can match th= e=20 "default auid document namespace" or *not*. =2D If the XML document or node contains a default namespace then the XCAP = Xpath=20 query *MUST* contain a namespace definition matching it. So, XML/Xpath specs are not violated by XCAP :) To explain it with examples: Example 1: ********** Assume default auid document namespace =3D "urn:default-namespace": =2D---test1.xml------------------------ =2D----------------------------------- =20 Client XCAP Xpath queries: 1) /test/users/sip:a@d.org/test1.xml/~~/foo Not valid since the XML document contains a default namespace in node "foo"= =20 but the query doesn't declare it. =20 2) /test/users/sip:a@d.org/test1.xml/~~/a:foo?xmlns(a=3Durn:default-namespace) Valid since the Xpath query declares a namespace with prefix "a" matching t= he=20 namespace used in the server for same node, and the query uses it in the no= de=20 selector ("a:foo"). Example 2: ********** Assume default auid document namespace =3D "urn:default-namespace": =2D---test2.xml------------------------ =2D----------------------------------- =20 Client XCAP Xpath queries: 1) /test/users/sip:a@d.org/test2.xml/~~/foo Valid since the XML document doesn't declare a namespace for "foo" node so = the=20 Xpath query has no namespaces. 2) /test/users/sip:a@d.org/test2.xml/~~/a:foo?xmlns(a=3Durn:default-namespace) Invalid since the XML document doesn't declare namespace for node "foo" but= =20 the XCAP Xpath query declares it. Example 3: ********** Assume default auid document namespace =3D "urn:default-namespace": =2D---test1.xml------------------------ =2D----------------------------------- =20 Client XCAP Xpath queries: 1) /test/users/sip:a@d.org/test1.xml/~~/foo Not valid since the XML document contains a default namespace in node "foo"= =20 ("org.lalala") but the query doesn't declare it. =20 2) /test/users/sip:a@d.org/test1.xml/~~/a:foo?xmlns(a=3Dorg.lalala) Valid since the Xpath query declares a namespace with prefix "a" matching t= he=20 namespace used in the server for same node, and the query uses it in the no= de=20 selector ("a:foo"). Unfortunatelly I don't understand yet the real purpose of the "default auid= =20 document namespace" :( =2D-=20 I=C3=B1aki Baz Castillo From Jari.Urpalainen@nokia.com Thu Nov 19 05:40:25 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E24D53A681F for ; Thu, 19 Nov 2009 05:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-94J7xoYdKs for ; Thu, 19 Nov 2009 05:40:24 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id F3CD43A69DB for ; Thu, 19 Nov 2009 05:40:23 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAJDduhU023107; Thu, 19 Nov 2009 15:40:18 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 15:40:14 +0200 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 15:40:03 +0200 Received: from [172.21.37.235] (esdhcp037235.research.nokia.com [172.21.37.235]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAJDe25N015954; Thu, 19 Nov 2009 15:40:02 +0200 From: Jari Urpalainen To: ext =?ISO-8859-1?Q?I=F1aki?= Baz Castillo In-Reply-To: <200911191328.04675.ibc@aliax.net> References: <200911191102.52794.ibc@aliax.net> <200911191328.04675.ibc@aliax.net> Content-Type: text/plain; charset="UTF-8" Date: Thu, 19 Nov 2009 15:40:02 +0200 Message-Id: <1258638002.10221.235.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Nov 2009 13:40:03.0477 (UTC) FILETIME=[CC398450:01CA691D] X-Nokia-AV: Clean Cc: "simple@ietf.org" Subject: Re: [Simple] XCAP: Issues with document/application default namespace X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 13:40:26 -0000 On Thu, 2009-11-19 at 13:28 +0100, ext Iñaki Baz Castillo wrote: > El Jueves, 19 de Noviembre de 2009, Iñaki Baz Castillo escribió: > > Hi, let imagine this XML document stored in XCAP server: > > > > ----test.xml------------------------ > > > > > > > > ------------------------------------ > > > > Which would be the correct XCAP query to get the node?: > > > > 1) > > /test/users/sip:a@d.org/test.xml/~~/foo > > > > 2) > > /test/users/sip:a@d.org/test.xml/~~/foo?xmlns(xmlns=urn:default-namespace) > > > > 3) > > /test/users/sip:a@d.org/test.xml/~~/a:foo?xmlns(a=urn:default-namespace) > > > > > > I'm sure that case 3) is valid and works. > > > > About case 1) I'm not sure if it should work. > > > > Case 2) seems incorrect to me. However I don't know how the client can > > indicate which is the default namespace used in the query (IMHO it cannot > > according to XCAP specs so it must use namespaces with prefix). > > AFAIK XCAP specifies that when no prefix is used in the query Xpath the > > auid default namespace must be used (let's suppose > > "urn:default-namespace"), but what about if the XML document declares a > > different default namespace (different than the XCAP application default > > namespace)? > > > > XCAP seems to "extend" this specs by allowing a Xpath query with no > > namespaces matching a XML document node in which the default document > > namespaces matches the XCAP app default namespace (ugly however). > > > > According to XML namespaces and Xpath specs, cases 1) and 2) shouldn't work > > since the node has a namespace "urn:default-namespace" and it's not > > specified in the Xpath query. This is, in Xpath specs if the document > > declares a namespace then it must be included in the Xpath query even if > > it's the default namespace (so "xmlns='xxxxxxxxxx'" should appear in the > > Xpath query). Since XCAP query doesn't allow indicating a default > > namespace the client should use namespace prefix for the default namespace > > (so case 3 is valid). > > > > What I mean is that XCAP violates Xpath and XML namespaces spects. > > Opinions? > > > > Other question 100% related to this issue: > > > > https://lists.cs.columbia.edu/pipermail/sip-implementors/2008- > > April/018952.html > > > After readin 5-6 times RFC 4825 section 5.2 "Default Document Namespace" I > think I got the response. Please correct me if I'm wrong: > > > - Each XCAP auid has a "default auid document namespace" (AKA "default > document namespace"). > > - This is just valid for the XCAP Xpath query and refers to the default used > in evaluation of XCAP URIs, so if the Xpath contains nodes with no prefix (so > no namespace association) then the server must assume that those nodes belong > to the "default auid document namespace". > > - The XML document itself can contain a "default namespace" in root node or > childs (this means: . This namespace can match the > "default auid document namespace" or *not*. > > - If the XML document or node contains a default namespace then the XCAP Xpath > query *MUST* contain a namespace definition matching it. > not exactly since if prefix is "empty" default document namespace must be applied. > So, XML/Xpath specs are not violated by XCAP :) > I wouldn't call it a violation, but there's definitely different interpretations between XPath 1 / XPath 2 / XCAP / Patch-Ops selections. > > To explain it with examples: > > > > Example 1: > ********** > > Assume default auid document namespace = "urn:default-namespace": > ----test1.xml------------------------ > > > > ------------------------------------ > > Client XCAP Xpath queries: > > 1) > /test/users/sip:a@d.org/test1.xml/~~/foo > > Not valid since the XML document contains a default namespace in node "foo" > but the query doesn't declare it. > as default document namespace URI for this AU is indeed "urn:default-namespace" a match occurs. This _is_ the use-case for default document namespace, i.e. to avoid the query parameter. > > 2) > /test/users/sip:a@d.org/test1.xml/~~/a:foo?xmlns(a=urn:default-namespace) > > Valid since the Xpath query declares a namespace with prefix "a" matching the > namespace used in the server for same node, and the query uses it in the node > selector ("a:foo"). > right. > > > Example 2: > ********** > > Assume default auid document namespace = "urn:default-namespace": > ----test2.xml------------------------ > > > > ------------------------------------ > > Client XCAP Xpath queries: > > 1) > /test/users/sip:a@d.org/test2.xml/~~/foo > > Valid since the XML document doesn't declare a namespace for "foo" node so the > Xpath query has no namespaces. > not valid since the spec says that without prefixes you apply default document namespace to elements. In practice, this is not a big deal since at least all existing AUs use some namespace and don't define unqualified elements. > > 2) > /test/users/sip:a@d.org/test2.xml/~~/a:foo?xmlns(a=urn:default-namespace) > > Invalid since the XML document doesn't declare namespace for node "foo" but > the XCAP Xpath query declares it. > right. > > > Example 3: > ********** > > Assume default auid document namespace = "urn:default-namespace": > ----test1.xml------------------------ > > > > ------------------------------------ > > Client XCAP Xpath queries: > > 1) > /test/users/sip:a@d.org/test1.xml/~~/foo > > Not valid since the XML document contains a default namespace in node "foo" > ("org.lalala") but the query doesn't declare it. > so implementation looks for a element with namespace "urn:default-namespace" and match isn't found. > > 2) > /test/users/sip:a@d.org/test1.xml/~~/a:foo?xmlns(a=org.lalala) > > Valid since the Xpath query declares a namespace with prefix "a" matching the > namespace used in the server for same node, and the query uses it in the node > selector ("a:foo"). > right. > > > > Unfortunatelly I don't understand yet the real purpose of the "default auid > document namespace" :( As said, it was defined to avoid those long URIs. If the model were according to XPath 1.0 spec, you'd always need query parameters with requests (with qualified element conventions). So there's indeed a deficiency with selections if default document namespace is defined for an AU, i.e. you can't select unqualified elements then, but this is a minor issue. Note also that XPath 2 selects also qualified elements (default namespace) with a selection like "foo", so XPath 2 is closer to XCAP interpretation, but it's not the same. If you still insist on having more XPath like selection logic look section 4.2.1 and 4.2.2 of rfc5261 ;-) br, Jari From ibc@aliax.net Thu Nov 19 05:54:51 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44F7C3A6B39 for ; Thu, 19 Nov 2009 05:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIFZREdGmk+m for ; Thu, 19 Nov 2009 05:54:50 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 81AD53A693B for ; Thu, 19 Nov 2009 05:54:49 -0800 (PST) Received: by bwz23 with SMTP id 23so2476493bwz.29 for ; Thu, 19 Nov 2009 05:54:44 -0800 (PST) Received: by 10.216.86.201 with SMTP id w51mr9935wee.8.1258638883969; Thu, 19 Nov 2009 05:54:43 -0800 (PST) Received: from ibc-laptop.localnet ([212.230.46.89]) by mx.google.com with ESMTPS id 28sm127684eye.7.2009.11.19.05.54.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 05:54:42 -0800 (PST) From: =?utf-8?q?I=C3=B1aki_Baz_Castillo?= To: simple@ietf.org Date: Thu, 19 Nov 2009 14:54:39 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.28-16-generic; KDE/4.3.2; x86_64; ; ) References: <200911191102.52794.ibc@aliax.net> <200911191328.04675.ibc@aliax.net> <1258638002.10221.235.camel@localhost> In-Reply-To: <1258638002.10221.235.camel@localhost> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <200911191454.39799.ibc@aliax.net> Subject: Re: [Simple] XCAP: Issues with document/application default namespace X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 13:54:51 -0000 El Jueves, 19 de Noviembre de 2009, Jari Urpalainen escribi=C3=B3: > On Thu, 2009-11-19 at 13:28 +0100, ext I=C3=B1aki Baz Castillo wrote: > > El Jueves, 19 de Noviembre de 2009, I=C3=B1aki Baz Castillo escribi=C3= =B3: > > > Hi, let imagine this XML document stored in XCAP server: > > > > > > ----test.xml------------------------ > > > > > > > > > > > > ------------------------------------ > > > > > > Which would be the correct XCAP query to get the node?: > > > > > > 1) > > > /test/users/sip:a@d.org/test.xml/~~/foo > > > > > > 2) > > > /test/users/sip:a@d.org/test.xml/~~/foo?xmlns(xmlns=3Durn:default-nam= espa > > >ce) > > > > > > 3) > > > /test/users/sip:a@d.org/test.xml/~~/a:foo?xmlns(a=3Durn:default-names= pace > > >) > > > > > > > > > I'm sure that case 3) is valid and works. > > > > > > About case 1) I'm not sure if it should work. > > > > > > Case 2) seems incorrect to me. However I don't know how the client can > > > indicate which is the default namespace used in the query (IMHO it > > > cannot according to XCAP specs so it must use namespaces with prefix). > > > AFAIK XCAP specifies that when no prefix is used in the query Xpath t= he > > > auid default namespace must be used (let's suppose > > > "urn:default-namespace"), but what about if the XML document declares > > > a different default namespace (different than the XCAP application > > > default namespace)? > > > > > > XCAP seems to "extend" this specs by allowing a Xpath query with no > > > namespaces matching a XML document node in which the default document > > > namespaces matches the XCAP app default namespace (ugly however). > > > > > > According to XML namespaces and Xpath specs, cases 1) and 2) shouldn't > > > work since the node has a namespace "urn:default-namespace" and > > > it's not specified in the Xpath query. This is, in Xpath specs if the > > > document declares a namespace then it must be included in the Xpath > > > query even if it's the default namespace (so "xmlns=3D'xxxxxxxxxx'" > > > should appear in the Xpath query). Since XCAP query doesn't allow > > > indicating a default namespace the client should use namespace prefix > > > for the default namespace (so case 3 is valid). > > > > > > What I mean is that XCAP violates Xpath and XML namespaces spects. > > > Opinions? > > > > > > Other question 100% related to this issue: > > > > > > https://lists.cs.columbia.edu/pipermail/sip-implementors/2008- > > > April/018952.html > > > > After readin 5-6 times RFC 4825 section 5.2 "Default Document Namespace" > > I think I got the response. Please correct me if I'm wrong: > > > > > > - Each XCAP auid has a "default auid document namespace" (AKA "default > > document namespace"). > > > > - This is just valid for the XCAP Xpath query and refers to the default > > used in evaluation of XCAP URIs, so if the Xpath contains nodes with no > > prefix (so no namespace association) then the server must assume that > > those nodes belong to the "default auid document namespace". > > > > - The XML document itself can contain a "default namespace" in root node > > or childs (this means: . This namespace can m= atch > > the "default auid document namespace" or *not*. > > > > - If the XML document or node contains a default namespace then the XCAP > > Xpath query *MUST* contain a namespace definition matching it. >=20 > not exactly since if prefix is "empty" default document namespace must > be applied. >=20 > > So, XML/Xpath specs are not violated by XCAP :) >=20 > I wouldn't call it a violation, but there's definitely different > interpretations between XPath 1 / XPath 2 / XCAP / Patch-Ops > selections. >=20 > > To explain it with examples: > > > > > > > > Example 1: > > ********** > > > > Assume default auid document namespace =3D "urn:default-namespace": > > ----test1.xml------------------------ > > > > > > > > ------------------------------------ > > > > Client XCAP Xpath queries: > > > > 1) > > /test/users/sip:a@d.org/test1.xml/~~/foo > > > > Not valid since the XML document contains a default namespace in node > > "foo" but the query doesn't declare it. >=20 > as default document namespace URI for this AU is indeed > "urn:default-namespace" a match occurs. This _is_ the use-case for > default document namespace, i.e. to avoid the query parameter. >=20 > > 2) > > /test/users/sip:a@d.org/test1.xml/~~/a:foo?xmlns(a=3Durn:default-namesp= ace) > > > > Valid since the Xpath query declares a namespace with prefix "a" matchi= ng > > the namespace used in the server for same node, and the query uses it in > > the node selector ("a:foo"). >=20 > right. >=20 > > Example 2: > > ********** > > > > Assume default auid document namespace =3D "urn:default-namespace": > > ----test2.xml------------------------ > > > > > > > > ------------------------------------ > > > > Client XCAP Xpath queries: > > > > 1) > > /test/users/sip:a@d.org/test2.xml/~~/foo > > > > Valid since the XML document doesn't declare a namespace for "foo" node > > so the Xpath query has no namespaces. >=20 > not valid since the spec says that without prefixes you apply default > document namespace to elements. In practice, this is not a big deal > since at least all existing AUs use some namespace and don't define > unqualified elements. >=20 > > 2) > > /test/users/sip:a@d.org/test2.xml/~~/a:foo?xmlns(a=3Durn:default-namesp= ace) > > > > Invalid since the XML document doesn't declare namespace for node "foo" > > but the XCAP Xpath query declares it. >=20 > right. >=20 > > Example 3: > > ********** > > > > Assume default auid document namespace =3D "urn:default-namespace": > > ----test1.xml------------------------ > > > > > > > > ------------------------------------ > > > > Client XCAP Xpath queries: > > > > 1) > > /test/users/sip:a@d.org/test1.xml/~~/foo > > > > Not valid since the XML document contains a default namespace in node > > "foo" ("org.lalala") but the query doesn't declare it. >=20 > so implementation looks for a element with namespace > "urn:default-namespace" and match isn't found. >=20 > > 2) > > /test/users/sip:a@d.org/test1.xml/~~/a:foo?xmlns(a=3Dorg.lalala) > > > > Valid since the Xpath query declares a namespace with prefix "a" matchi= ng > > the namespace used in the server for same node, and the query uses it in > > the node selector ("a:foo"). >=20 > right. >=20 > > Unfortunatelly I don't understand yet the real purpose of the "default > > auid document namespace" :( >=20 > As said, it was defined to avoid those long URIs. If the model were > according to XPath 1.0 spec, you'd always need query parameters with > requests (with qualified element conventions). So there's indeed a > deficiency with selections if default document namespace is defined for > an AU, i.e. you can't select unqualified elements then, but this is a > minor issue. >=20 > Note also that XPath 2 selects also qualified elements (default > namespace) with a selection like "foo", so XPath 2 is closer to XCAP > interpretation, but it's not the same. If you still insist on having > more XPath like selection logic look section 4.2.1 and 4.2.2 of > rfc5261 ;-) Really thanks for your great response. Please let me some time to study it = :) =2D-=20 I=C3=B1aki Baz Castillo From alan@sipstation.com Thu Nov 19 07:13:40 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B220D3A68E0 for ; Thu, 19 Nov 2009 07:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awOEZUuz4kRV for ; Thu, 19 Nov 2009 07:13:38 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 7B8DC3A681E for ; Thu, 19 Nov 2009 07:13:38 -0800 (PST) Received: from 24-107-148-54.dhcp.stls.mo.charter.com ([24.107.148.54] helo=aidan-DS.sipserver.homeip.net) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1NB8hT-0006On-Ml for simple@ietf.org; Thu, 19 Nov 2009 15:13:36 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.148.54 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+Epo0FYM1Vve8788XT8hZEWYSqCXzkH5c= Message-ID: <4B05609C.4070400@sipstation.com> Date: Thu, 19 Nov 2009 09:13:32 -0600 From: Alan Johnston User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Simple] WGLC review and comments on draft-ietf-simple-intradomain-federation-04 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 15:13:40 -0000 I believe this is a useful document for implementors and is ready to progress. I have noted a few minor comments below that should be considered by the authors but should not be considered blocking. A suggestion for closing the one open issue listed in the document is contained below. Thanks, Alan - - - - - Title and Abstract: Currently, neither the title or abstract of the document mention SIP by name. While many of the concepts and models described in the document are not SIP-specific, all the realization discussions are very SIP specific. I would suggest adding a mention of SIP to at least the Abstract if not the title as well. Section 1. Introduction: This section mentions "pager mode" which is also mentioned later. I have always used "page mode" in my writing but perhaps "pager mode" is also commonly in usage? Figure 1 Caption: Again, perhaps SIP should be in the caption of this figure as it does show SIP specific mechanisms such as SUBSCRIBE and NOTIFY. Figure 2 Caption: As this figure relates to SIP Session Mode IM, perhaps the caption should indicate this. Section 2 Intra-Domain Bridging vs. Clustering This section uses the word "federated" without defining it. The word is used in a few places elsewhere. Perhaps a definition could be included or a reference. Also, in this section, the differences between bridging and clustering are described. If the intent is to rule a detailed discussion of clustering out of scope for this document, it might be worth saying this. Figure 4: I'm OK with leaving off the URI schemes of the users - presumably they are either sip: or sips: - for clarity. However, it might be worth stating up front that all users are actually fully URIs. Section 6.1 Applicability: Including the definition of AoR would be helpful. Section 6.2.1: The discussion of the protocol used in this section doesn't mention the possible use of SIP with redirection, although this is discussed in Figure 7. Section 6.2.4 Peer-to-Peer: Replace "gorup" with "group" Section 7.1.4 Peer-to-Peer: Define "P2P" the first time it is used. Section 7.1.5 Forking: Delete space in "test-and- set" and "on- behalf-of" Section 8.1.2.2 Distributed Provisioning: Second to last paragraph should begin with "If" instead of "if" Figures 13 and 14: These figures should be kept on a single page if possible. Section 8.1.4: Replace "ALice" with "Alice" Section 8.2.1 Routing: This section has an Open Issue in the last paragraph about mixing peer and exclusive bridging for different users. To channel, Rohan, I'd say, "If it hurts, don't do it." Section 9. More About Policy: Is there a reason why this section talks about servers A and B instead of 1 and 2 in the rest of the document? Section 11. Security Considerations: While this section is OK, the security folks might appreciate a little repetition by adding a paragraph saying that "Normal SIP mechanisms for securing presence and instant messaging should be used including..." Section 13. References: As RFC 3261 is referenced, a reference to RFC 3265 and RFC 3903 might not be a bad idea. From ibc@aliax.net Thu Nov 19 07:20:46 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D887B3A6904 for ; Thu, 19 Nov 2009 07:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HsnVeLeht1z for ; Thu, 19 Nov 2009 07:20:46 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 030D43A6A25 for ; Thu, 19 Nov 2009 07:20:45 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so557052eya.51 for ; Thu, 19 Nov 2009 07:20:39 -0800 (PST) Received: by 10.213.2.81 with SMTP id 17mr102482ebi.45.1258644038955; Thu, 19 Nov 2009 07:20:38 -0800 (PST) Received: from ibc-laptop.localnet ([212.230.46.89]) by mx.google.com with ESMTPS id 5sm146207eyf.2.2009.11.19.07.20.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Nov 2009 07:20:37 -0800 (PST) From: =?utf-8?q?I=C3=B1aki_Baz_Castillo?= To: simple@ietf.org Date: Thu, 19 Nov 2009 16:20:34 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.28-16-generic; KDE/4.3.2; x86_64; ; ) References: <200911191102.52794.ibc@aliax.net> <1258638002.10221.235.camel@localhost> <200911191454.39799.ibc@aliax.net> In-Reply-To: <200911191454.39799.ibc@aliax.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <200911191620.35065.ibc@aliax.net> Subject: Re: [Simple] XCAP: Issues with document/application default namespace X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 15:20:47 -0000 El Jueves, 19 de Noviembre de 2009, I=C3=B1aki Baz Castillo escribi=C3=B3: > > As said, it was defined to avoid those long URIs. If the model were > > according to XPath 1.0 spec, you'd always need query parameters with > > requests (with qualified element conventions). So there's indeed a > > deficiency with selections if default document namespace is defined for > > an AU, i.e. you can't select unqualified elements then, but this is a > > minor issue. > > > > Note also that XPath 2 selects also qualified elements (default > > namespace) with a selection like "foo", so XPath 2 is closer to XCAP > > interpretation, but it's not the same. If you still insist on having > > more XPath like selection logic look section 4.2.1 and 4.2.2 of > > rfc5261 ;-) >=20 > Really thanks for your great response. Please let me some time to study it > :) Ok, 100% understood. However this is the reply I didn't desire as it requir= es=20 a modification in the XML parser I'm using... :-D Really thanks a lot. =2D-=20 I=C3=B1aki Baz Castillo From ben@estacado.net Fri Nov 20 13:07:47 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36B493A6841 for ; Fri, 20 Nov 2009 13:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9x6qJZwfqduE for ; Fri, 20 Nov 2009 13:07:46 -0800 (PST) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 122543A67BD for ; Fri, 20 Nov 2009 13:07:45 -0800 (PST) Received: from [172.16.3.213] (rocinante.test.estacado.net [172.16.3.213] (may be forged)) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id nAKL6KOv018104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Nov 2009 15:06:21 -0600 (CST) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-7--876377686 From: Ben Campbell In-Reply-To: Date: Fri, 20 Nov 2009 15:06:20 -0600 Message-Id: <3CD66A98-8562-4E49-B1CA-AED5C20D67E4@estacado.net> References: <81621E94-1FF4-4584-9C55-30945836C7DF@nostrum.com> <66cd252f0911181714p756a42e9y8ed4b0c96f032b42@mail.gmail.com> To: Louise.Clarke@forapolis.com, Simple WG , Dean Willis X-Mailer: Apple Mail (2.1077) Subject: Re: [Simple] Liaison Statement from the Open Mobile Alliance X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 21:07:47 -0000 --Apple-Mail-7--876377686 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Digging a little deeper, I have a question about the schemaLocation = request in the liaison statement: The statement proposes adding a schemaLocation attribute to the = element that imports the resource-list schema into the RLS-Services = schema. But on inspection, there is no element whatsoever in = the rls-services schema. However, the element does contain a = namespace declaration that references resource-list. Was the liaison = statement intended to request we add schemaLocation to the namespace = declaration? Or am I missing something? On Nov 18, 2009, at 7:31 PM, Ben Campbell wrote: > >=20 > And the thing they are asking for would generally _not_ make sense to = put in an RFC, unless we are willing to ensure the URL to the schema = lives forever. >=20 > On Nov 18, 2009, at 7:14 PM, Hisham Khartabil wrote: >=20 >> >>=20 >> No issues in correcting the IANA pages, but we can't make = modifications or extensions to a schema published in an RFC unless the = extension is documented and published. >>=20 >> Thanks, >> Hisham >>=20 >> 2009/11/19 Ben Campbell >> >> We've had a small amount of on-list discussion. =46rom the emails so = far I gather that there are no objections to correcting the schema as = published by IANA to match those from RFC 4826. However, there have been = some objections to adding the SchemaLocation parameters as requested in = the liaison statement. >>=20 >> Everyone--please take a look at the liaison statement and offer your = opinions. Even "me too" comments would be helpful at this point. It's = been almost two months since OMA sent the liaison statement, and we need = to respond to it ASAP. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >> >>=20 >>=20 >> On Oct 2, 2009, at 1:12 PM, Ben Campbell wrote: >>=20 >> > (as SIMPLE co-chair) >> > >> > OMA sent a liaison statement to the SIMPLE working group. The = statement's overview reads as follows: >> > >> > "This Liaison Statement reports XML validation problems in the XML = schemas that were introduced in RFC 4826 and asks for correction." >> > >> > Please read the LS, and send your opinions to the SIMPLE list. A = PDF is available at = https://datatracker.ietf.org/documents/LIAISON/file707.pdf >> > >> > Thanks! >> > >> > Ben. >> > _______________________________________________ >> > Simple mailing list >> > Simple@ietf.org >> > https://www.ietf.org/mailman/listinfo/simple >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail-7--876377686 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
<as = individual>

No issues in correcting the IANA pages, but we = can't make modifications or extensions to a schema published in an RFC = unless the extension is documented and = published.

Thanks,
Hisham

2009/11/19 Ben Campbell <ben@nostrum.com>
<chair>
We've had a small amount of on-list discussion. =46rom the emails so far = I gather that there are no objections to correcting the schema as = published by IANA to match those from RFC 4826. However, there have been = some objections to adding the SchemaLocation parameters as requested in = the liaison statement.

Everyone--please take a look at the liaison statement and offer your = opinions. Even "me too" comments would be helpful at this point. It's = been almost two months since OMA sent the liaison statement, and we need = to respond to it ASAP.

Thanks!

Ben.

</chair>


On Oct 2, 2009, at 1:12 PM, Ben Campbell wrote:

> (as SIMPLE co-chair)
>
> OMA sent a liaison statement to the SIMPLE working group. The = statement's overview reads as follows:
>
> "This Liaison Statement reports XML validation problems in the XML = schemas that were introduced in RFC 4826 and asks for correction."
>
> Please read the LS, and send your opinions to the SIMPLE list. A = PDF  is available at https://datatracker.ietf.org/documents/LIAISON/file707.p= df
>
> Thanks!
>
> Ben.
> = _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple

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

=

_____________________________________________= __
Simple mailing list
Simple@ietf.org
https://www.ietf.or= g/mailman/listinfo/simple

= --Apple-Mail-7--876377686-- From b_mccolgan@hotmail.com Fri Nov 20 13:37:28 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFCE03A6948 for ; Fri, 20 Nov 2009 13:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wf9DF1ZxuAXC for ; Fri, 20 Nov 2009 13:37:28 -0800 (PST) Received: from snt0-omc4-s2.snt0.hotmail.com (snt0-omc4-s2.snt0.hotmail.com [65.55.90.205]) by core3.amsl.com (Postfix) with ESMTP id 14CFA3A6828 for ; Fri, 20 Nov 2009 13:37:28 -0800 (PST) Received: from SNT114-W51 ([65.55.90.200]) by snt0-omc4-s2.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 13:37:25 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_096ef174-60ef-4247-a1ba-185fd21621df_" X-Originating-IP: [208.65.73.202] From: Brian McColgan To: Date: Fri, 20 Nov 2009 16:37:25 -0500 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 20 Nov 2009 21:37:25.0480 (UTC) FILETIME=[A69A1680:01CA6A29] Subject: Re: [Simple] Liaison Statement from the Open Mobile Alliance X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 21:37:28 -0000 --_096ef174-60ef-4247-a1ba-185fd21621df_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ben Campbel wrote: =20 > And the thing they are asking for would generally _not_ make sense to put= in an RFC=2C... =20 What about simply adding the schemaLocation as an 'informative comment'? A= t least folks (i.e. implementors making use of these XML Schema's) would be= able to locate a 'presumably correct' soft-copy of the XSD corresponding t= o the RFC. =20 =20 Or perhaps the RFC template could be ammended to include the IANA schema lo= cation?=20 =20 >...unless we are willing to ensure the URL to the schema lives forever. =20 Ben=2C do you know something (regarding IANA) that we don't? 8^) =20 _________________________________________________________________ Ready. Set. Get a great deal on Windows 7. See fantastic deals on Windows 7= now http://go.microsoft.com/?linkid=3D9691818= --_096ef174-60ef-4247-a1ba-185fd21621df_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ben Campbel wrote:
 =3B
>=3B And the thing they are asking for would generally _not_ = make sense to put in an RFC=2C...
 =3B
<=3Bas individual>=3B
What about simply adding the schemaLocation as an 'informative comment'?&nb= sp=3B At least folks (i.e. implementors making use of these XML Schema's) w= ould be able to locate a 'presumably correct' soft-copy of the XSD correspo= nding to the RFC. =3B
 =3B
Or perhaps the RFC template could be ammended to include the IANA schema lo= cation? =3B
 =3B
>=3B...unless we are willing to ensure the = URL to the schema lives forever.
 =3B
Ben=2C do you know something (regarding IANA) that we don't? =3B 8^)
Get a great deal on Windows 7 and see how it works= the way you want. See the Windows 7 offers now. = --_096ef174-60ef-4247-a1ba-185fd21621df_-- From ben@nostrum.com Fri Nov 20 14:08:08 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 922D028C17E for ; Fri, 20 Nov 2009 14:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzJLSVoiVEv0 for ; Fri, 20 Nov 2009 14:08:07 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 0DB4328C17D for ; Fri, 20 Nov 2009 14:08:06 -0800 (PST) Received: from dn3-213.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id nAKM817c095438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Nov 2009 16:08:01 -0600 (CST) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-8--872676474 From: Ben Campbell In-Reply-To: Date: Fri, 20 Nov 2009 16:08:01 -0600 Message-Id: <565773E0-CF92-4957-B8A0-503B7ECE64C3@nostrum.com> References: To: Brian McColgan X-Mailer: Apple Mail (2.1077) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: simple@ietf.org Subject: Re: [Simple] Liaison Statement from the Open Mobile Alliance X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 22:08:08 -0000 --Apple-Mail-8--872676474 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 20, 2009, at 3:37 PM, Brian McColgan wrote: > Ben Campbel wrote: > =20 > > And the thing they are asking for would generally _not_ make sense = to put in an RFC,... > =20 > > What about simply adding the schemaLocation as an 'informative = comment'? At least folks (i.e. implementors making use of these XML = Schema's) would be able to locate a 'presumably correct' soft-copy of = the XSD corresponding to the RFC. =20 If I understand the liaison statement correctly, they need = schemaLocation in a formally correct location, so that automated = validation tools can find and include the referenced schema. That is, = this is for automata, not people. So I'm not sure adding it as just a = comment helps. (Note that I am _not_ sure I understand the liaison = statement correctly on this point--please see my other email on the = subject.) > =20 > Or perhaps the RFC template could be ammended to include the IANA = schema location?=20 > =20 > >...unless we are willing to ensure the URL to the schema lives = forever. > =20 > Ben, do you know something (regarding IANA) that we don't? 8^) >=20 I am not aware of some impending doom, if that's what you mean. :-) = It's probably really up to IANA whether this sort of thing makes sense. = I can see they might want the ability to reorganize such things from = time to time, but they may consider that no different than other IANA = registered information that gets written into RFC-stone.=20 > Get a great deal on Windows 7 and see how it works the way you want. = See the Windows 7 offers = now._______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail-8--872676474 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Nov 20, 2009, at 3:37 PM, Brian = McColgan wrote:

Ben Campbel = wrote:
 
> And the thing they are asking = for would generally _not_ make sense to put in an = RFC,...
 
<as individual>
What about simply = adding the schemaLocation as an 'informative comment'?  At least = folks (i.e. implementors making use of these XML Schema's) would be able = to locate a 'presumably correct' soft-copy of the XSD corresponding to = the RFC.  

If I understand the liaison statement correctly, = they need schemaLocation in a formally correct location, so that = automated validation tools can find and include the referenced schema. = That is, this is for automata, not people. So I'm not sure adding it as = just a comment helps. (Note that I am _not_ sure I understand the = liaison statement correctly on this point--please see my other email on = the subject.)


 
Or perhaps = the RFC template could be ammended to include the IANA schema = location? 
 
>...unless we are willing to ensure the URL to the schema = lives forever.
 
Ben, do you know something (regarding = IANA) that we don't?  = 8^)


 I am not = aware of some impending doom, if that's what you mean. :-) It's probably = really up to IANA whether this sort of thing makes sense. I can see they = might want the ability to reorganize such things from time to time, but = they may consider that no different than other IANA registered = information that gets written into = RFC-stone. 



Get a great deal = on Windows 7 and see how it works the way you want. See = the Windows 7 offers = now._______________________________________________
Simple = mailing list
Simple@ietf.org
https://www.ietf.org= /mailman/listinfo/simple

= --Apple-Mail-8--872676474-- From AVSHALOM@il.ibm.com Mon Nov 23 11:44:36 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25F3B3A6AC0 for ; Mon, 23 Nov 2009 11:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.42 X-Spam-Level: X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijE9rVt8lEhq for ; Mon, 23 Nov 2009 11:44:34 -0800 (PST) Received: from mtagate7.de.ibm.com (mtagate7.de.ibm.com [195.212.17.167]) by core3.amsl.com (Postfix) with ESMTP id 4B2B33A6AB1 for ; Mon, 23 Nov 2009 11:44:34 -0800 (PST) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate7.de.ibm.com (8.13.1/8.13.1) with ESMTP id nANJiS06027197 for ; Mon, 23 Nov 2009 19:44:28 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nANJiSwZ741392 for ; Mon, 23 Nov 2009 20:44:28 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id nANJiSMl005885 for ; Mon, 23 Nov 2009 20:44:28 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id nANJiSIH005880 for ; Mon, 23 Nov 2009 20:44:28 +0100 To: simple@ietf.org MIME-Version: 1.0 X-KeepSent: 48F7C2C3:F1DC64DE-C2257677:006BBFE5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 HF58 February 06, 2009 From: Avshalom Houri Message-ID: Date: Mon, 23 Nov 2009 21:44:27 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5|December 05, 2008) at 23/11/2009 21:44:28, Serialize complete at 23/11/2009 21:44:28 Content-Type: multipart/alternative; boundary="=_alternative 006C2797C2257677_=" Subject: [Simple] Suggested next actions with draft-ietf-simple-interdomain-scaling-analysis X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 19:44:36 -0000 This is a multipart message in MIME format. --=_alternative 006C2797C2257677_= Content-Type: text/plain; charset="US-ASCII" This did not get much attention when it was sent before the IETF. We really need some input from actual deployments of SIMPLE regarding the following in order to be able to address the IESG comment in a new revision of this draft: - Message sizes. - Different refresh (re-subscribe) rates used and when they are used. - Presence document data sizes - Geolocation presence document data sizes. - Size of data per subscription that the presence server needs to allocate - Any other data that we can get from the field. Any other comments are also welcome. Thanks --Avshalom __________________ The IESG had substantial comments on the draft: https://datatracker.ietf.org/idtracker/draft-ietf-simple-interdomain-scaling-analysis/comment/102863/ The following is a plan for revising the draft to address these comments. The plan is based on discussions with Ben, Cullen and Robert. One very important thing that will help us a lot in this work is getting real data from actual deployments of SIMPLE regarding the following: - Message sizes. - Different refresh (re-subscribe) rates used and when they are used. - Presence document data sizes - Geolocation presence document data sizes. - Size of data per subscription that the presence server needs to allocate - Any other data that we can get from the field. **** Any numbers here will be greatly appreciated and will help a lot in creating the new revision of the document **** Note that the above numbers are more SIP specific and we need to get them from actual SIP deployments. They are different from the general constants of buddy list size, rate of state changes per day etc. which are more usage numbers. General Changes: ---------------- * Remove subjective language as much as possible * The document should not be written as a protocol comparison document but as a document that provides input that will help deployment considerations for SIMPLE and directions for optimizations. * Clarify the assumptions behind the chosen input values. * Discuss elasticity of inputs and which inputs have more effect. * Make it clear that we are talking only about inter-domain traffic. * The document will have to go through the working group last call again. Changes in Phase I ------------------- * Separate the scenarios into enterprise and consumer related scenarios. Number as the time that a user will be logged in which is reasonable to be 8 in an enterprise will be different for a consumer network. The rate of status changes will be different also. * Since we can not mention explicit numbers from actual deployments, we should say e.g. "hypothetical consumer service"... * Add per active (logged in) user calculations * Section 2.2: The 2000/4000 difference in login/logouts is probably a typo mistake that needs to be clarified. It does NOT affect the calculations. * Add a section describing changes with different constants. Provide several points on the possible reasonable values. * Add geolocation information as part of the model. * Provide different calculations for the refresh time. The 3600 seconds from the RFC is not the number that is usually used. Provide both extremes. * Message sizes: Need to do sanity check of messages. Talk to people that may have these numbers. * Section 2.10 - Change to 48 changes per day from 24. It was done in order to show that the optimized protocol can be better even with doubling the number notifications. This is probably confusing and need to be fixed. * Sizes for state calculations. Need to revisit the numbers that are used. Get actual numbers from the same sources that we will get message sizes. * Talk about the limits that are imposed by privacy constraints on the way that SIMPLE works and possible optimizations. * Provide numbers for when SIGCOMP compression is used. Phase II -------- * Revisit Processing Complexities, Current Optimizations, Summary and Conclusions sections after doing the changes in the main part of the document. Thanks --Avshalom --=_alternative 006C2797C2257677_= Content-Type: text/html; charset="US-ASCII" This did not get much attention when it was sent before the IETF.

We really need some input from actual deployments of SIMPLE regarding the
following in order to be able to address the IESG comment in a new
revision of this draft:

- Message sizes.
- Different refresh (re-subscribe) rates used and when they are used.
- Presence document data sizes
- Geolocation presence document data sizes.
- Size of data per subscription that the presence server needs to
  allocate

- Any other data that we can get from the field.
Any other comments are also welcome.

Thanks
--Avshalom
__________________

The IESG had substantial comments on the draft:
https://datatracker.ietf.org/idtracker/draft-ietf-simple-interdomain-scaling-analysis/comment/102863/

The following is a plan for revising the draft to address these comments.
The plan is based on discussions with Ben, Cullen and Robert.

One very important thing that will help us a lot in this work is getting
real data from actual deployments of SIMPLE regarding the following:

- Message sizes.
- Different refresh (re-subscribe) rates used and when they are used.
- Presence document data sizes
- Geolocation presence document data sizes.
- Size of data per subscription that the presence server needs to
  allocate

- Any other data that we can get from the field.
**** Any numbers here will be greatly appreciated and will help a lot
in creating the new revision of the document ****

Note that the above numbers are more SIP specific and we need to get  
them from actual SIP deployments. They are different from the  
general constants of buddy list size, rate of state changes per day etc.
which are more usage numbers.

General Changes:
----------------
* Remove subjective language as much as possible

* The document should not be written as a protocol comparison document
but as a document that provides input that will help deployment  
considerations for SIMPLE and directions for optimizations.
* Clarify the assumptions behind the chosen input values.
* Discuss elasticity of inputs and which inputs have more effect.

* Make it clear that we are talking only about inter-domain  
traffic.
* The document will have to go through the working group last call  
again.

Changes in Phase I
-------------------
* Separate the scenarios into enterprise and consumer related  
scenarios. Number as the time that a user will be logged in which is
reasonable to be 8 in an enterprise will be different for a consumer
network. The rate of status changes will be different also.
* Since we can not mention explicit numbers from actual deployments,  
we should say e.g. "hypothetical consumer service"...

* Add per active (logged in) user calculations
* Section 2.2: The 2000/4000 difference in login/logouts is probably  
a typo mistake that needs to be clarified. It does NOT affect the  
calculations.
* Add a section describing changes with different constants. Provide  
several points on the possible reasonable values.
* Add geolocation information as part of the model.

* Provide different calculations for the refresh time. The 3600  
seconds from the RFC is not the number that is usually used.
Provide both extremes.

* Message sizes: Need to do sanity check of messages. Talk to people  
that may have these numbers.

* Section 2.10 - Change to 48 changes per day from 24. It was done  
in order to show that the optimized protocol can be better even with
doubling the number notifications. This is probably confusing and need to
be fixed.
* Sizes for state calculations. Need to revisit the numbers that are  
used. Get actual numbers from the same sources that we will get message
sizes.
* Talk about the limits that are imposed by privacy constraints on  
the way that SIMPLE works and possible optimizations.
* Provide numbers for when SIGCOMP compression is used.
Phase II
--------
* Revisit Processing Complexities, Current Optimizations, Summary and
Conclusions sections after doing the changes in the main part of the  
document.
Thanks
--Avshalom

 --=_alternative 006C2797C2257677_=-- From ben@estacado.net Mon Nov 23 13:16:24 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1026D28C1A5 for ; Mon, 23 Nov 2009 13:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9z1X+5AHu5M3 for ; Mon, 23 Nov 2009 13:16:22 -0800 (PST) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id B00A828C1A2 for ; Mon, 23 Nov 2009 13:16:22 -0800 (PST) Received: from rocinante.test.estacado.net (rocinante.test.estacado.net [172.16.3.213] (may be forged)) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id nANLExlJ043213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Nov 2009 15:14:59 -0600 (CST) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-10--616658636 From: Ben Campbell In-Reply-To: Date: Mon, 23 Nov 2009 15:14:59 -0600 Message-Id: <4A9E47DB-D91D-42AF-887F-9F416E7DEE33@estacado.net> References: To: Christer Holmberg X-Mailer: Apple Mail (2.1077) Cc: Simple WG Subject: Re: [Simple] MSRP ACM: Two drafts X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 21:16:24 -0000 --Apple-Mail-10--616658636 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On a quick review, I think the sessmatch draft reasonably captures the = discussions I have heard so far on the subject. I may have further = feedback on a more detailed review, but I don't expect to find anything = major. On the acm draft, I do have one question. We had some discussions in the = past about how the certificate fingerprint requirement in comedia-tls = might be problematic. Can you remind me of the resolution to that = discussion, if any? On Nov 18, 2009, at 3:30 AM, Christer Holmberg wrote: >=20 > Hi, >=20 > Based on the discussions in Hiroshima, I have put together a separate = draft for the RFC4975 session matching update. >=20 > In addition, I've removed the c/m routing stuff from the ACM draft, so = most of the stuff left is related to COMEDIA.=20 > =20 > I have submitted both drafts, and they can also be found at: >=20 > = http://users.piuha.net/cholmber/drafts/draft-ietf-simple-msrp-acm-02.txt >=20 > = http://users.piuha.net/cholmber/drafts/draft-holmberg-simple-msrp-sessmatc= h-00.txt >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail-10--616658636 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On a quick review, I think the sessmatch draft reasonably captures the discussions I have heard so far on the subject. I may have further feedback on a more detailed review, but I don't expect to find anything major.

On the acm draft, I do have one question. We had some discussions in the past about how the certificate fingerprint requirement in comedia-tls might be problematic. Can you remind me of the resolution to that discussion, if any?


On Nov 18, 2009, at 3:30 AM, Christer Holmberg wrote:


Hi,

Based on the discussions in Hiroshima, I have put together a separate draft for the RFC4975 session matching update.

In addition, I've removed the c/m routing stuff from the ACM draft, so most of the stuff left is related to COMEDIA.
 
I have submitted both drafts, and they can also be found at:

http://users.piuha.net/cholmber/drafts/draft-ietf-simple-msrp-acm-02.txt

http://users.piuha.net/cholmber/drafts/draft-holmberg-simple-msrp-sessmatch-00.txt

Regards,

Christer

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

--Apple-Mail-10--616658636-- From ibc@aliax.net Tue Nov 24 03:43:49 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1386228C10A for ; Tue, 24 Nov 2009 03:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.168 X-Spam-Level: X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_20=-0.74, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6yp7IIHJI6q for ; Tue, 24 Nov 2009 03:43:48 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id C0ADA28C108 for ; Tue, 24 Nov 2009 03:43:47 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so422529eyf.51 for ; Tue, 24 Nov 2009 03:43:36 -0800 (PST) Received: by 10.213.2.82 with SMTP id 18mr4979245ebi.44.1259063016451; Tue, 24 Nov 2009 03:43:36 -0800 (PST) Received: from ibc-laptop.localnet ([212.230.46.89]) by mx.google.com with ESMTPS id 28sm2395726eyg.44.2009.11.24.03.43.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Nov 2009 03:43:35 -0800 (PST) From: =?utf-8?q?I=C3=B1aki_Baz_Castillo?= To: simple@ietf.org Date: Tue, 24 Nov 2009 12:43:32 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.28-16-generic; KDE/4.3.2; x86_64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <200911241243.32881.ibc@aliax.net> Subject: [Simple] XCAP: Hex-encoding doubt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 11:43:49 -0000 Hi, I'm trying to understand how exactly a XCAP client must encode the requ= est=20 URI according to RFC 4825 and RFC 3986. =46or example, in RFC 4825 (XCAP) section 7.7 there is a PUT example: PUT /rls-services/users/sip:bill@example.com/index/~~/rls-services/ service%5b@uri=3D%22sip:good-friends@example.com%22%5d HTTP/1.1 I would like to understand why "@" and ":" are not hex-escaped. As you can= =20 read below (RFC 3986): gen-delims =3D ":" / "/" / "?" / "#" / "[" / "]" / "@" So if "[" and "]" are clearly hex-escaped in the example PUT URI why "@" an= d=20 ":" are not hex-escaped? Also, I would like to know how a client should escape the following URI (no= te=20 the SIP URI param ";myparam=3Dabc"): /rls-services/users/sip:bill@example.com/index/~~/rls-services/ service[@uri=3D"sip:good-friends@example.com;myparam=3Dabc"] Should the ";" be encoded? Thanks a lot. =2D----------------------------------------------------------- http://tools.ietf.org/html/rfc3986#section-2.2 2.2. Reserved Characters URIs include components and subcomponents that are delimited by characters in the "reserved" set. These characters are called "reserved" because they may (or may not) be defined as delimiters by the generic syntax, by each scheme-specific syntax, or by the implementation-specific syntax of a URI's dereferencing algorithm. If data for a URI component would conflict with a reserved character's purpose as a delimiter, then the conflicting data must be percent-encoded before the URI is formed. reserved =3D gen-delims / sub-delims gen-delims =3D ":" / "/" / "?" / "#" / "[" / "]" / "@" sub-delims =3D "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=3D" The purpose of reserved characters is to provide a set of delimiting characters that are distinguishable from other data within a URI. URIs that differ in the replacement of a reserved character with its corresponding percent-encoded octet are not equivalent. Percent- encoding a reserved character, or decoding a percent-encoded octet that corresponds to a reserved character, will change how the URI is interpreted by most applications. http://tools.ietf.org/html/rfc3986#section-2.3 2.3. Unreserved Characters =20 Characters that are allowed in a URI but do not have a reserved purpose are called unreserved. These include uppercase and lowercase letters, decimal digits, hyphen, period, underscore, and tilde. unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~" URIs that differ in the replacement of an unreserved character with its corresponding percent-encoded US-ASCII octet are equivalent: they identify the same resource. However, URI comparison implementations do not always perform normalization prior to comparison (see Section 6). For consistency, percent-encoded octets in the ranges of ALPHA (%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), period (%2E), underscore (%5F), or tilde (%7E) should not be created by URI producers and, when found in a URI, should be decoded to their corresponding unreserved characters by URI normalizers. =2D----------------------------------------------------------- =2D-=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Nov 24 05:05:33 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C0B23A690A for ; Tue, 24 Nov 2009 05:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rK10HijGC1v7 for ; Tue, 24 Nov 2009 05:05:32 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id 200BD28C11D for ; Tue, 24 Nov 2009 05:05:30 -0800 (PST) Received: by ewy7 with SMTP id 7so17244ewy.28 for ; Tue, 24 Nov 2009 05:05:20 -0800 (PST) Received: by 10.213.1.7 with SMTP id 7mr4994479ebd.27.1259067918812; Tue, 24 Nov 2009 05:05:18 -0800 (PST) Received: from ibc-laptop.localnet ([212.230.46.89]) by mx.google.com with ESMTPS id 10sm2489747eyz.15.2009.11.24.05.05.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Nov 2009 05:05:18 -0800 (PST) From: =?utf-8?q?I=C3=B1aki_Baz_Castillo?= To: simple@ietf.org Date: Tue, 24 Nov 2009 14:05:13 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.28-16-generic; KDE/4.3.2; x86_64; ; ) References: <200911241243.32881.ibc@aliax.net> In-Reply-To: <200911241243.32881.ibc@aliax.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <200911241405.14018.ibc@aliax.net> Subject: Re: [Simple] XCAP: Hex-encoding doubt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 13:05:33 -0000 El Martes, 24 de Noviembre de 2009, I=C3=B1aki Baz Castillo escribi=C3=B3: > Also, I would like to know how a client should escape the following URI > (note the SIP URI param ";myparam=3Dabc"): >=20 > /rls-services/users/sip:bill@example.com/index/~~/rls-services/ > service[@uri=3D"sip:good-friends@example.com;myparam=3Dabc"] >=20 > Should the ";" be encoded? I think ";" should be encoded. At least, I'm testing with a HTTP server and= it=20 cuts from path everything after ";". =2D-=20 I=C3=B1aki Baz Castillo From emmartins@gmail.com Tue Nov 24 06:11:23 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B7463A681B for ; Tue, 24 Nov 2009 06:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xvq8vZfFiqN2 for ; Tue, 24 Nov 2009 06:11:21 -0800 (PST) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by core3.amsl.com (Postfix) with ESMTP id 7CBB63A67F2 for ; Tue, 24 Nov 2009 06:11:20 -0800 (PST) Received: by qyk29 with SMTP id 29so3146703qyk.32 for ; Tue, 24 Nov 2009 06:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=iZv0vk8BMTI40eTRXMZmz2VZBttTBAR1UGRifWYWPbs=; b=NGZjgBSJkenG48pUrfy5zaDcqXPWV+uVQtWYUGuxMDbCPRnaKGQfYdFGT2InNmolaz W/3YDr7oU7/LoIfbKuKFeu4Gdn5jZEEtXJeZ0SC0r63RFgPYRYE0np2r5XwEOOIedwhX WodRIGthvo9G1lM8uwFsT95A0y6EkI2vcWl0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JfPPaDoA7c+Vq31AlGAn05Re7sAnXiz33wdbIZuAPBUVM3LGTkcNRl/1t/5xxF9AN2 MkU3XiGz0PjwZTlwcv+psfHEUMtp9LvUXXaY2yRh9dGrQuCurNlSBxEYtpHAyMCKgr7u XfK6ntPYwyWRRMmQiTZ7er/suLZNEixKls8fA= MIME-Version: 1.0 Received: by 10.229.1.200 with SMTP id 8mr847507qcg.64.1259071872528; Tue, 24 Nov 2009 06:11:12 -0800 (PST) In-Reply-To: <200911241405.14018.ibc@aliax.net> References: <200911241243.32881.ibc@aliax.net> <200911241405.14018.ibc@aliax.net> Date: Tue, 24 Nov 2009 14:11:12 +0000 Message-ID: From: Eduardo Martins To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001485394218b5732f04791e8334 Cc: simple@ietf.org Subject: Re: [Simple] XCAP: Hex-encoding doubt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 14:11:23 -0000 --001485394218b5732f04791e8334 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Look at RFC 3896 Appendix A, the ":" , "@" and any sub-delims are permitted in path segments. -- Eduardo http://emmartins.blogspot.com On Tue, Nov 24, 2009 at 1:05 PM, I=F1aki Baz Castillo wrote= : > El Martes, 24 de Noviembre de 2009, I=F1aki Baz Castillo escribi=F3: > > > Also, I would like to know how a client should escape the following URI > > (note the SIP URI param ";myparam=3Dabc"): > > > > /rls-services/users/sip:bill@example.com/index/~~/rls-services/ > > service[@uri=3D"sip:good-friends@example.com > ;myparam=3Dabc"] > > > > Should the ";" be encoded? > > > I think ";" should be encoded. At least, I'm testing with a HTTP server a= nd > it > cuts from path everything after ";". > > > -- > I=F1aki Baz Castillo > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > --001485394218b5732f04791e8334 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Look at RFC 3896 Appendix A, the ":" , "@" and any sub-= delims are permitted in path segments.

-- Eduardo

http://emmartins.blogspot.com=

On Tue, Nov 24, 2009 at 1:05 PM, I=F1aki= Baz Castillo <ibc@al= iax.net> wrote:
El Martes, 24 de = Noviembre de 2009, I=F1aki Baz Castillo escribi=F3:

> Also, I would like to know how a client should escape the following UR= I
> =A0(note the SIP URI param ";myparam=3Dabc"):
>
> =A0 =A0/rls-services/users/sip:bill@example.com/index/~~/rls= -services/
> =A0 =A0service[@uri=3D"sip:good-friends@example.com;myparam=3Dabc"]
>
> Should the ";" be encoded?


I think ";" should be encoded. At least, I'm testing wi= th a HTTP server and it
cuts from path everything after ";".


--
I=F1aki Baz Castillo <ibc@aliax.net= >
_______________________________________________
Simple mailing list
Simple@ietf.org
= https://www.ietf.org/mailman/listinfo/simple

--001485394218b5732f04791e8334-- From ibc@aliax.net Tue Nov 24 06:17:43 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239803A6870 for ; Tue, 24 Nov 2009 06:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0t7G2jE6D6Fj for ; Tue, 24 Nov 2009 06:17:42 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 2F5B43A6858 for ; Tue, 24 Nov 2009 06:17:42 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so455386eyf.51 for ; Tue, 24 Nov 2009 06:17:33 -0800 (PST) Received: by 10.213.24.15 with SMTP id t15mr6327053ebb.42.1259072253166; Tue, 24 Nov 2009 06:17:33 -0800 (PST) Received: from ibc-laptop.localnet ([212.230.46.89]) by mx.google.com with ESMTPS id 23sm2558687eya.35.2009.11.24.06.17.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Nov 2009 06:17:31 -0800 (PST) From: =?utf-8?q?I=C3=B1aki_Baz_Castillo?= To: simple@ietf.org Date: Tue, 24 Nov 2009 15:17:28 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.28-16-generic; KDE/4.3.2; x86_64; ; ) References: <200911241243.32881.ibc@aliax.net> <200911241405.14018.ibc@aliax.net> In-Reply-To: <200911241405.14018.ibc@aliax.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <200911241517.28508.ibc@aliax.net> Subject: Re: [Simple] XCAP: Hex-encoding doubt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 14:17:43 -0000 El Martes, 24 de Noviembre de 2009, I=C3=B1aki Baz Castillo escribi=C3=B3: > El Martes, 24 de Noviembre de 2009, I=C3=B1aki Baz Castillo escribi=C3=B3: > > Also, I would like to know how a client should escape the following URI > > (note the SIP URI param ";myparam=3Dabc"): > > > > /rls-services/users/sip:bill@example.com/index/~~/rls-services/ > > service[@uri=3D"sip:good-friends@example.com;myparam=3Dabc"] > > > > Should the ";" be encoded? >=20 > I think ";" should be encoded. At least, I'm testing with a HTTP server a= nd > it cuts from path everything after ";". A new related question would be: Is it allowed to use " rather than " ?: (after hex-unescaping): cp:ruleset/cp:rule[@id=3D"pres_whitelist"]/cp:conditions/cp:identity/cp:o= ne[@id=3D"sip:alice@example.org"] rather than: cp:ruleset/cp:rule[@id=3D"pres_whitelist"]/cp:conditions/cp:identity/cp:o= ne[@id=3D"sip:alice@example.org"] I've read about it but not sure if it's 100% "standard" and allowed. Thanks. =2D-=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Nov 24 06:50:45 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF5543A6A86 for ; Tue, 24 Nov 2009 06:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hju5S6dkw4eo for ; Tue, 24 Nov 2009 06:50:44 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id 860463A6A85 for ; Tue, 24 Nov 2009 06:50:43 -0800 (PST) Received: by ewy7 with SMTP id 7so33018ewy.28 for ; Tue, 24 Nov 2009 06:50:33 -0800 (PST) Received: by 10.213.1.7 with SMTP id 7mr5123927ebd.27.1259074199724; Tue, 24 Nov 2009 06:49:59 -0800 (PST) Received: from ibc-laptop.localnet ([212.230.46.89]) by mx.google.com with ESMTPS id 23sm2594411eya.27.2009.11.24.06.49.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Nov 2009 06:49:58 -0800 (PST) From: =?utf-8?q?I=C3=B1aki_Baz_Castillo?= To: simple@ietf.org Date: Tue, 24 Nov 2009 15:49:55 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.28-16-generic; KDE/4.3.2; x86_64; ; ) References: <200911241243.32881.ibc@aliax.net> <200911241405.14018.ibc@aliax.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <200911241549.55366.ibc@aliax.net> Subject: Re: [Simple] XCAP: Hex-encoding doubt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 14:50:45 -0000 El Martes, 24 de Noviembre de 2009, Eduardo Martins escribi=C3=B3: > Look at RFC 3896 Appendix A, the ":" , "@" and any sub-delims are permitt= ed > in path segments. You are right: pchar =3D unreserved / pct-encoded / sub-delims / ":" / "@" Thanks a lot. =2D-=20 I=C3=B1aki Baz Castillo From Jari.Urpalainen@nokia.com Wed Nov 25 01:24:48 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8892A3A6867 for ; Wed, 25 Nov 2009 01:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M20Fs6On-oO5 for ; Wed, 25 Nov 2009 01:24:47 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 8A59A3A6807 for ; Wed, 25 Nov 2009 01:24:46 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAP9OB06015646; Wed, 25 Nov 2009 11:24:38 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 11:24:32 +0200 Received: from mgw-da01.ext.nokia.com ([147.243.128.24]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 11:24:30 +0200 Received: from [172.21.37.235] (esdhcp037235.research.nokia.com [172.21.37.235]) by mgw-da01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nAP9ORXb016243; Wed, 25 Nov 2009 11:24:28 +0200 From: Jari Urpalainen To: ext =?ISO-8859-1?Q?I=F1aki?= Baz Castillo In-Reply-To: <200911241517.28508.ibc@aliax.net> References: <200911241243.32881.ibc@aliax.net> <200911241405.14018.ibc@aliax.net> <200911241517.28508.ibc@aliax.net> Content-Type: text/plain; charset="UTF-8" Date: Wed, 25 Nov 2009 11:24:27 +0200 Message-Id: <1259141067.20723.17.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 25 Nov 2009 09:24:30.0995 (UTC) FILETIME=[17D4EE30:01CA6DB1] X-Nokia-AV: Clean Cc: "simple@ietf.org" Subject: Re: [Simple] XCAP: Hex-encoding doubt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 09:24:48 -0000 On Tue, 2009-11-24 at 15:17 +0100, ext Iñaki Baz Castillo wrote: > > A new related question would be: > > Is it allowed to use " rather than " ?: > > (after hex-unescaping): > > cp:ruleset/cp:rule[@id="pres_whitelist"]/cp:conditions/cp:identity/cp:one[@id="sip:alice@example.org"] > rather than: > cp:ruleset/cp:rule[@id="pres_whitelist"]/cp:conditions/cp:identity/cp:one[@id="sip:alice@example.org"] > > > I've read about it but not sure if it's 100% "standard" and allowed. > > Thanks. > > > No, from xml 1.0: [10] AttValue ::= '"' ([^<&"] | Reference)* '"' | "'" ([^<&'] | Reference)* "'" So my hint is to use the apostrophe "'" character instead (sub-delim in rfc3986), no need to percent-escape (though i wouldn't be surprised if there were buggy implementations). br, Jari From ibc@aliax.net Wed Nov 25 01:49:53 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B0B03A691F for ; Wed, 25 Nov 2009 01:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjFxVmZO1isT for ; Wed, 25 Nov 2009 01:49:52 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 6AC153A6880 for ; Wed, 25 Nov 2009 01:49:52 -0800 (PST) Received: by fxm5 with SMTP id 5so6745598fxm.28 for ; Wed, 25 Nov 2009 01:49:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.144.85 with SMTP id y21mr1160135fau.1.1259142584376; Wed, 25 Nov 2009 01:49:44 -0800 (PST) In-Reply-To: <1259141067.20723.17.camel@localhost> References: <200911241243.32881.ibc@aliax.net> <200911241405.14018.ibc@aliax.net> <200911241517.28508.ibc@aliax.net> <1259141067.20723.17.camel@localhost> Date: Wed, 25 Nov 2009 10:49:44 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Jari Urpalainen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] XCAP: Hex-encoding doubt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 09:49:53 -0000 2009/11/25 Jari Urpalainen : > On Tue, 2009-11-24 at 15:17 +0100, ext I=C3=B1aki Baz Castillo wrote: >> Is it allowed to use " rather than " ?: >> >> (after hex-unescaping): >> >> =C2=A0 cp:ruleset/cp:rule[@id=3D"pres_whitelist"]/cp:conditions/cp:ident= ity/cp:one[@id=3D"sip:alice@example.org"] >> rather than: >> =C2=A0 cp:ruleset/cp:rule[@id=3D"pres_whitelist"]/cp:conditions/cp:ident= ity/cp:one[@id=3D"sip:alice@example.org"] >> >> >> I've read about it but not sure if it's 100% "standard" and allowed. >> >> Thanks. >> >> >> > No, from xml 1.0: > > [10] =C2=A0 AttValue =C2=A0 ::=3D =C2=A0 '"' ([^<&"] | Reference)* '"' | = =C2=A0"'" ([^<&'] | > Reference)* "'" > > So my hint is to use the apostrophe "'" character instead (sub-delim in > rfc3986), no need to percent-escape (though i wouldn't be surprised if > there were buggy implementations). Thanks a lot. --=20 I=C3=B1aki Baz Castillo From uwe.rauschenbach@nsn.com Wed Nov 25 09:32:34 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720173A6AB6 for ; Wed, 25 Nov 2009 09:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtK6AiJDj0Zo for ; Wed, 25 Nov 2009 09:32:33 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 938CA3A67F4 for ; Wed, 25 Nov 2009 09:32:31 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nAPHVQK4007682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Nov 2009 18:31:26 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nAPHVKRm030953; Wed, 25 Nov 2009 18:31:25 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 18:31:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6DF5.1BFE6DE8" Date: Wed, 25 Nov 2009 18:31:58 +0100 Message-ID: In-Reply-To: <3CD66A98-8562-4E49-B1CA-AED5C20D67E4@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Liaison Statement from the Open Mobile Alliance Thread-Index: AcpqJYWsLKnghL13SfGMi4QW+8/YDgC8puww References: <81621E94-1FF4-4584-9C55-30945836C7DF@nostrum.com><66cd252f0911181714p756a42e9y8ed4b0c96f032b42@mail.gmail.com> <3CD66A98-8562-4E49-B1CA-AED5C20D67E4@estacado.net> From: "Rauschenbach, Uwe (NSN - DE/Munich)" To: "ext Ben Campbell" , , "Simple WG" , "Dean Willis" X-OriginalArrivalTime: 25 Nov 2009 17:31:24.0440 (UTC) FILETIME=[1C66E180:01CA6DF5] Subject: Re: [Simple] Liaison Statement from the Open Mobile Alliance X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 17:32:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6DF5.1BFE6DE8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ben, =20 thanks for moving this forward. As the author of the LS, let me provide some clarification. =20 The LS states: =20 Validation problems in urn:ietf:params:xml:ns:rls-services Schema as available from [3] This XML schema imports the resource-lists schema, however does not provide a schema location for it. Due to this, the rls-services schema does not validate because the validator can not fetch the referenced schema. It is therefore suggested to add a schemaLocation attribute to the declaration of the rls-services XML schema instance in the IANA repository. [3] http://www.iana.org/assignments/xml-registry/schema/rls-services.xsd =20 I have cross-checked and indeed neither the schema in IANA repository nor the one in the RFC contains an statement. So, the text in the LS is not 100% correct but its spirit is that OMA requests to make sure that validators that use this schema will be informed about the additional schema needed for validation and its location. Note that a similar declaration (including a schemaLocation attribute) is contained in the XML schema for resource-lists (it imports the standard XML namespace). =20 Based on the schema for rls-services in RFC4826, the LS should have stated: The rls-services XML schema references the resource-lists schema namespace, however neither imports the schema nor provides a schema location for it. Due to this, the rls-services schema does not validate because the validator can not fetch the referenced schema. It is therefore suggested to add the missing declaration (including a schemaLocation attribute) to the rls-services XML schema instance in the IANA repository. Sorry about the confusion caused, and good catch. Kind regards, Uwe=20 =20 ________________________________ From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of ext Ben Campbell Sent: Friday, November 20, 2009 10:06 PM To: Louise.Clarke@forapolis.com; Simple WG; Dean Willis Subject: Re: [Simple] Liaison Statement from the Open Mobile Alliance =09 =09 Digging a little deeper, I have a question about the schemaLocation request in the liaison statement:=20 The statement proposes adding a schemaLocation attribute to the element that imports the resource-list schema into the RLS-Services schema. But on inspection, there is no element whatsoever in the rls-services schema. However, the element does contain a namespace declaration that references resource-list. Was the liaison statement intended to request we add schemaLocation to the namespace declaration? =09 =09 Or am I missing something? On Nov 18, 2009, at 7:31 PM, Ben Campbell wrote: And the thing they are asking for would generally _not_ make sense to put in an RFC, unless we are willing to ensure the URL to the schema lives forever. On Nov 18, 2009, at 7:14 PM, Hisham Khartabil wrote: =09 No issues in correcting the IANA pages, but we can't make modifications or extensions to a schema published in an RFC unless the extension is documented and published. =09 Thanks, Hisham =09 =09 2009/11/19 Ben Campbell =09 We've had a small amount of on-list discussion. From the emails so far I gather that there are no objections to correcting the schema as published by IANA to match those from RFC 4826. However, there have been some objections to adding the SchemaLocation parameters as requested in the liaison statement. =09 Everyone--please take a look at the liaison statement and offer your opinions. Even "me too" comments would be helpful at this point. It's been almost two months since OMA sent the liaison statement, and we need to respond to it ASAP. =09 Thanks! =09 Ben. =09 =09 On Oct 2, 2009, at 1:12 PM, Ben Campbell wrote: =09 > (as SIMPLE co-chair) > > OMA sent a liaison statement to the SIMPLE working group. The statement's overview reads as follows: > > "This Liaison Statement reports XML validation problems in the XML schemas that were introduced in RFC 4826 and asks for correction." > > Please read the LS, and send your opinions to the SIMPLE list. A PDF is available at https://datatracker.ietf.org/documents/LIAISON/file707.pdf > > Thanks! > > Ben. =09 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple =09 =09 _______________________________________________ Simple mailing list Simple@ietf.org =09 https://www.ietf.org/mailman/listinfo/simple =09 _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple =09 ------_=_NextPart_001_01CA6DF5.1BFE6DE8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Ben,
 
thanks=20 for moving this forward. As the author of the LS, let me provide some=20 clarification.
 
The LS=20 states:
 
Validation problems in=20 urn:ietf:params:xml:ns:rls-services Schema as available from=20 [3]

This XML schema imports the resource-lists schema, however does = not=20 provide a schema location for it. Due to this, the rls-services schema = does not=20 validate because the validator can not fetch the referenced schema. It = is=20 therefore suggested to add a schemaLocation attribute to the = <import>=20 declaration of the rls-services XML schema instance in the IANA=20 repository.
[3] http://www.iana.org/assignments/xml-registry/schema/rls-s= ervices.xsd

I have cross-checked and indeed neither the = schema in=20 IANA repository nor the one in the RFC contains an <import> = statement. So,=20 the text in the LS is not 100% correct but = its spirit=20 is that OMA requests to make sure that validators that use this schema = will be=20 informed about the additional schema needed for validation and its = location.=20 Note that a similar <import> declaration (including a = schemaLocation=20 attribute) is contained in the XML schema for resource-lists (it imports = the=20 standard XML namespace).  

Based on the schema for rls-services in = RFC4826, the LS=20 should have stated:

The rls-services XML=20 schema references the resource-lists schema = namespace, however neither = imports the=20 schema nor provides a schema = location for it.=20 Due to this, the rls-services schema does not validate because the = validator can=20 not fetch the referenced schema. It is therefore suggested to = add the missing = <import> declaration (including a schemaLocation attribute) to the = rls-services=20 XML schema instance in the IANA=20 repository.

Sorry about the confusion caused, and good=20 catch.

Kind regards,
Uwe=20

 

From: simple-bounces@ietf.org=20 [mailto:simple-bounces@ietf.org] On Behalf Of ext Ben=20 Campbell
Sent: Friday, November 20, 2009 10:06 = PM
To:=20 Louise.Clarke@forapolis.com; Simple WG; Dean Willis
Subject: = Re:=20 [Simple] Liaison Statement from the Open Mobile = Alliance

Digging a little deeper, I have a question about the = schemaLocation=20 request in the liaison statement:=20

The statement proposes adding a schemaLocation attribute to the=20 <import> element that imports the resource-list schema into the=20 RLS-Services  schema. But on inspection, there is no = <import>=20 element whatsoever in the rls-services schema. However, the = <schema>=20 element does contain a namespace declaration that references = resource-list.=20 Was the liaison statement intended to request we add schemaLocation to = the=20 namespace declaration?

Or am I missing something?

On Nov 18, 2009, at 7:31 PM, Ben Campbell wrote:
<individual>

And the thing they are asking for would generally _not_ make = sense to=20 put in an RFC, unless we are willing to ensure the URL to the schema = lives=20 forever.

On Nov 18, 2009, at 7:14 PM, Hisham Khartabil wrote:
<as individual>

No issues in=20 correcting the IANA pages, but we can't make modifications or = extensions=20 to a schema published in an RFC unless the extension is documented = and=20 published.

Thanks,
Hisham

2009/11/19 Ben Campbell <ben@nostrum.com>
<chair>
We've=20 had a small amount of on-list discussion. From the emails so far = I=20 gather that there are no objections to correcting the schema as=20 published by IANA to match those from RFC 4826. However, there = have been=20 some objections to adding the SchemaLocation parameters as = requested in=20 the liaison statement.

Everyone--please take a look at = the=20 liaison statement and offer your opinions. Even "me too" = comments would=20 be helpful at this point. It's been almost two months since OMA = sent the=20 liaison statement, and we need to respond to it=20 ASAP.

Thanks!

Ben.

</chair>


On Oct 2, 2009, at 1:12 PM, Ben Campbell = wrote:

> (as SIMPLE co-chair)
>
> OMA sent = a=20 liaison statement to the SIMPLE working group. The statement's = overview=20 reads as follows:
>
> "This Liaison Statement = reports XML=20 validation problems in the XML schemas that were introduced in = RFC 4826=20 and asks for correction."
>
> Please read the LS, = and send=20 your opinions to the SIMPLE list. A PDF  is available at https://datatracker.ietf.org/documents/LIAISON/file707.pd= f
>
>=20 Thanks!
>
> Ben.
>=20 _______________________________________________
> Simple = mailing=20 list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple

_= ______________________________________________
Simple=20 mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple


______________= _________________________________
Simple=20 mailing list
Simple@ietf.org
https://www.ietf.o= rg/mailman/listinfo/simple

<= /BODY> ------_=_NextPart_001_01CA6DF5.1BFE6DE8-- From ben@estacado.net Wed Nov 25 13:02:25 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFAD23A6B51 for ; Wed, 25 Nov 2009 13:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vomEbV6eN1rc for ; Wed, 25 Nov 2009 13:02:24 -0800 (PST) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 04CED3A6B45 for ; Wed, 25 Nov 2009 13:02:23 -0800 (PST) Received: from rocinante.test.estacado.net (rocinante.test.estacado.net [172.16.3.213] (may be forged)) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id nAPL0xpr003499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Nov 2009 15:00:59 -0600 (CST) (envelope-from ben@estacado.net) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Nov 2009 15:00:59 -0600 Message-Id: <4B18E7BE-C392-4B0B-BB57-C568B5B52D93@estacado.net> To: Simple WG Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [Simple] MSRP-ACM Draft Split X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 21:02:25 -0000 We discussed at the Hiroshima SIMPLE meeting that Christer would split = the MSRP-ACM draft into two parts. The first part would contain the = COMEDIA usage and related text, and the second would include the = normative update to RFC 4975 to remove the domain part of an MSRP URI = from the session matching comparison. This update was originally = intended to be part of the MSRP-ACM draft, but the sense of the room was = that we should separate the normative update from the optional behavior = in MSRP-ACM. Based on this discussion, Christer submitted = draft-holmberg-simple-msrp-sessmatch-00, which contains the session = matching update. The draft is available at: http://tools.ietf.org/html/draft-holmberg-simple-msrp-sessmatch-00 Does anyone object to the adoption of that draft as a SIMPLE workgroup = item, as part of the "additional connection models for MSRP" milestone? = If you have objections, please raise them on the list ASAP. Please = remember that accepting this as a work group document does not mean we = have agreed to every detail of the draft--just that we believe that this = draft is a good start towards the milestone. Thanks! Ben. From Martin.Thomson@andrew.com Wed Nov 25 16:14:15 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D00293A6843 for ; Wed, 25 Nov 2009 16:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJw2De3QD8Ix for ; Wed, 25 Nov 2009 16:14:14 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id DEE063A6891 for ; Wed, 25 Nov 2009 16:14:13 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:63550 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S82228AbZKZAOH (ORCPT ); Wed, 25 Nov 2009 18:14:07 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 25 Nov 2009 18:14:07 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Thu, 26 Nov 2009 08:14:04 +0800 From: "Thomson, Martin" To: "Rauschenbach, Uwe (NSN - DE/Munich)" , ext Ben Campbell , "Louise.Clarke@forapolis.com" , Simple WG , Dean Willis Date: Thu, 26 Nov 2009 08:14:45 +0800 Thread-Topic: [Simple] Liaison Statement from the Open Mobile Alliance Thread-Index: AcpqJYWsLKnghL13SfGMi4QW+8/YDgC8puwwAEUcrnA= Message-ID: <8B0A9FCBB9832F43971E38010638454F01D648F169@SISPE7MB1.commscope.com> References: <81621E94-1FF4-4584-9C55-30945836C7DF@nostrum.com><66cd252f0911181714p756a42e9y8ed4b0c96f032b42@mail.gmail.com> <3CD66A98-8562-4E49-B1CA-AED5C20D67E4@estacado.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8B0A9FCBB9832F43971E38010638454F01D648F169SISPE7MB1comm_" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [Simple] Liaison Statement from the Open Mobile Alliance X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 00:14:15 -0000 --_000_8B0A9FCBB9832F43971E38010638454F01D648F169SISPE7MB1comm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VXdlLA0KDQpDYW4gSSBzdWdnZXN0IHRoYXQgeW91IHN1Ym1pdCBlcnJhdGEgb24gNDgyNj8gIFRo YXQgaXMgdGhlIHVzdWFsIG1ldGhvZCB3ZSB1c2UgdG8gcmVzb2x2ZSBhY3R1YWwgZXJyb3JzLg0K DQpUbyBkYXRlLCB0aGUgcG9saWN5IGhhcyBiZWVuIHRvIE5PVCB1c2Ugc2NoZW1hTG9jYXRpb24g aW4gUkZDcy4gIFdl4oCZdmUgaGFkIGEgbG90IG9mIGRpc2N1c3Npb24gb24gdGhlIG1lcml0cyAo YW5kIGRpc2FkdmFudGFnZXMpIG9mIHB1dHRpbmcgc2NoZW1hTG9jYXRpb24gYXR0cmlidXRlcyBp biBmaWxlcy4gIE91ciBkaXNjdXNzaW9ucyBjb25jZW50cmF0ZWQgb24gdGhhdCBhc3BlY3QuICBJ ZiB0aGVyZSBpcyBhIGNhc2UgZm9yIGRvaW5nIHNvLCB0aGVuIElBTkEgbmVlZCB0byBiZSB0aGUg b25lcyB0aGF0IGFjY2VwdCB0aGUgcmVzcG9uc2liaWxpdHkgZm9yIG1haW50YWluaW5nIHNjaGVt YSBVUkxzLCBzaW5jZSBSRkNzIHdpbGwgbm90Lg0KDQotLU1hcnRpbg0KDQpGcm9tOiBzaW1wbGUt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNpbXBsZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgUmF1c2NoZW5iYWNoLCBVd2UgKE5TTiAtIERFL011bmljaCkNClNlbnQ6IFRodXJzZGF5 LCAyNiBOb3ZlbWJlciAyMDA5IDQ6MzIgQU0NClRvOiBleHQgQmVuIENhbXBiZWxsOyBMb3Vpc2Uu Q2xhcmtlQGZvcmFwb2xpcy5jb207IFNpbXBsZSBXRzsgRGVhbiBXaWxsaXMNClN1YmplY3Q6IFJl OiBbU2ltcGxlXSBMaWFpc29uIFN0YXRlbWVudCBmcm9tIHRoZSBPcGVuIE1vYmlsZSBBbGxpYW5j ZQ0KDQpIaSBCZW4sDQoNCnRoYW5rcyBmb3IgbW92aW5nIHRoaXMgZm9yd2FyZC4gQXMgdGhlIGF1 dGhvciBvZiB0aGUgTFMsIGxldCBtZSBwcm92aWRlIHNvbWUgY2xhcmlmaWNhdGlvbi4NCg0KVGhl IExTIHN0YXRlczoNCg0KVmFsaWRhdGlvbiBwcm9ibGVtcyBpbiB1cm46aWV0ZjpwYXJhbXM6eG1s Om5zOnJscy1zZXJ2aWNlcyBTY2hlbWEgYXMgYXZhaWxhYmxlIGZyb20gWzNdDQoNClRoaXMgWE1M IHNjaGVtYSBpbXBvcnRzIHRoZSByZXNvdXJjZS1saXN0cyBzY2hlbWEsIGhvd2V2ZXIgZG9lcyBu b3QgcHJvdmlkZSBhIHNjaGVtYSBsb2NhdGlvbiBmb3IgaXQuIER1ZSB0byB0aGlzLCB0aGUgcmxz LXNlcnZpY2VzIHNjaGVtYSBkb2VzIG5vdCB2YWxpZGF0ZSBiZWNhdXNlIHRoZSB2YWxpZGF0b3Ig Y2FuIG5vdCBmZXRjaCB0aGUgcmVmZXJlbmNlZCBzY2hlbWEuIEl0IGlzIHRoZXJlZm9yZSBzdWdn ZXN0ZWQgdG8gYWRkIGEgc2NoZW1hTG9jYXRpb24gYXR0cmlidXRlIHRvIHRoZSA8aW1wb3J0PiBk ZWNsYXJhdGlvbiBvZiB0aGUgcmxzLXNlcnZpY2VzIFhNTCBzY2hlbWEgaW5zdGFuY2UgaW4gdGhl IElBTkEgcmVwb3NpdG9yeS4NClszXSBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3ht bC1yZWdpc3RyeS9zY2hlbWEvcmxzLXNlcnZpY2VzLnhzZA0KDQpJIGhhdmUgY3Jvc3MtY2hlY2tl ZCBhbmQgaW5kZWVkIG5laXRoZXIgdGhlIHNjaGVtYSBpbiBJQU5BIHJlcG9zaXRvcnkgbm9yIHRo ZSBvbmUgaW4gdGhlIFJGQyBjb250YWlucyBhbiA8aW1wb3J0PiBzdGF0ZW1lbnQuIFNvLCB0aGUg dGV4dCBpbiB0aGUgTFMgaXMgbm90IDEwMCUgY29ycmVjdCBidXQgaXRzIHNwaXJpdCBpcyB0aGF0 IE9NQSByZXF1ZXN0cyB0byBtYWtlIHN1cmUgdGhhdCB2YWxpZGF0b3JzIHRoYXQgdXNlIHRoaXMg c2NoZW1hIHdpbGwgYmUgaW5mb3JtZWQgYWJvdXQgdGhlIGFkZGl0aW9uYWwgc2NoZW1hIG5lZWRl ZCBmb3IgdmFsaWRhdGlvbiBhbmQgaXRzIGxvY2F0aW9uLiBOb3RlIHRoYXQgYSBzaW1pbGFyIDxp bXBvcnQ+IGRlY2xhcmF0aW9uIChpbmNsdWRpbmcgYSBzY2hlbWFMb2NhdGlvbiBhdHRyaWJ1dGUp IGlzIGNvbnRhaW5lZCBpbiB0aGUgWE1MIHNjaGVtYSBmb3IgcmVzb3VyY2UtbGlzdHMgKGl0IGlt cG9ydHMgdGhlIHN0YW5kYXJkIFhNTCBuYW1lc3BhY2UpLg0KDQpCYXNlZCBvbiB0aGUgc2NoZW1h IGZvciBybHMtc2VydmljZXMgaW4gUkZDNDgyNiwgdGhlIExTIHNob3VsZCBoYXZlIHN0YXRlZDoN ClRoZSBybHMtc2VydmljZXMgWE1MIHNjaGVtYSByZWZlcmVuY2VzIHRoZSByZXNvdXJjZS1saXN0 cyBzY2hlbWEgbmFtZXNwYWNlLCBob3dldmVyIG5laXRoZXIgaW1wb3J0cyB0aGUgc2NoZW1hIG5v ciBwcm92aWRlcyBhIHNjaGVtYSBsb2NhdGlvbiBmb3IgaXQuIER1ZSB0byB0aGlzLCB0aGUgcmxz LXNlcnZpY2VzIHNjaGVtYSBkb2VzIG5vdCB2YWxpZGF0ZSBiZWNhdXNlIHRoZSB2YWxpZGF0b3Ig Y2FuIG5vdCBmZXRjaCB0aGUgcmVmZXJlbmNlZCBzY2hlbWEuIEl0IGlzIHRoZXJlZm9yZSBzdWdn ZXN0ZWQgdG8gYWRkIHRoZSBtaXNzaW5nIDxpbXBvcnQ+IGRlY2xhcmF0aW9uIChpbmNsdWRpbmcg YSBzY2hlbWFMb2NhdGlvbiBhdHRyaWJ1dGUpIHRvIHRoZSBybHMtc2VydmljZXMgWE1MIHNjaGVt YSBpbnN0YW5jZSBpbiB0aGUgSUFOQSByZXBvc2l0b3J5Lg0KDQpTb3JyeSBhYm91dCB0aGUgY29u ZnVzaW9uIGNhdXNlZCwgYW5kIGdvb2QgY2F0Y2guDQoNCktpbmQgcmVnYXJkcywNClV3ZQ0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBzaW1wbGUtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOnNpbXBsZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0 IEJlbiBDYW1wYmVsbA0KU2VudDogRnJpZGF5LCBOb3ZlbWJlciAyMCwgMjAwOSAxMDowNiBQTQ0K VG86IExvdWlzZS5DbGFya2VAZm9yYXBvbGlzLmNvbTsgU2ltcGxlIFdHOyBEZWFuIFdpbGxpcw0K U3ViamVjdDogUmU6IFtTaW1wbGVdIExpYWlzb24gU3RhdGVtZW50IGZyb20gdGhlIE9wZW4gTW9i aWxlIEFsbGlhbmNlDQpEaWdnaW5nIGEgbGl0dGxlIGRlZXBlciwgSSBoYXZlIGEgcXVlc3Rpb24g YWJvdXQgdGhlIHNjaGVtYUxvY2F0aW9uIHJlcXVlc3QgaW4gdGhlIGxpYWlzb24gc3RhdGVtZW50 Og0KDQpUaGUgc3RhdGVtZW50IHByb3Bvc2VzIGFkZGluZyBhIHNjaGVtYUxvY2F0aW9uIGF0dHJp YnV0ZSB0byB0aGUgPGltcG9ydD4gZWxlbWVudCB0aGF0IGltcG9ydHMgdGhlIHJlc291cmNlLWxp c3Qgc2NoZW1hIGludG8gdGhlIFJMUy1TZXJ2aWNlcyAgc2NoZW1hLiBCdXQgb24gaW5zcGVjdGlv biwgdGhlcmUgaXMgbm8gPGltcG9ydD4gZWxlbWVudCB3aGF0c29ldmVyIGluIHRoZSBybHMtc2Vy dmljZXMgc2NoZW1hLiBIb3dldmVyLCB0aGUgPHNjaGVtYT4gZWxlbWVudCBkb2VzIGNvbnRhaW4g YSBuYW1lc3BhY2UgZGVjbGFyYXRpb24gdGhhdCByZWZlcmVuY2VzIHJlc291cmNlLWxpc3QuIFdh cyB0aGUgbGlhaXNvbiBzdGF0ZW1lbnQgaW50ZW5kZWQgdG8gcmVxdWVzdCB3ZSBhZGQgc2NoZW1h TG9jYXRpb24gdG8gdGhlIG5hbWVzcGFjZSBkZWNsYXJhdGlvbj8NCg0KT3IgYW0gSSBtaXNzaW5n IHNvbWV0aGluZz8NCg0KT24gTm92IDE4LCAyMDA5LCBhdCA3OjMxIFBNLCBCZW4gQ2FtcGJlbGwg d3JvdGU6DQoNCg0KPGluZGl2aWR1YWw+DQoNCkFuZCB0aGUgdGhpbmcgdGhleSBhcmUgYXNraW5n IGZvciB3b3VsZCBnZW5lcmFsbHkgX25vdF8gbWFrZSBzZW5zZSB0byBwdXQgaW4gYW4gUkZDLCB1 bmxlc3Mgd2UgYXJlIHdpbGxpbmcgdG8gZW5zdXJlIHRoZSBVUkwgdG8gdGhlIHNjaGVtYSBsaXZl cyBmb3JldmVyLg0KDQpPbiBOb3YgMTgsIDIwMDksIGF0IDc6MTQgUE0sIEhpc2hhbSBLaGFydGFi aWwgd3JvdGU6DQoNCg0KPGFzIGluZGl2aWR1YWw+DQoNCk5vIGlzc3VlcyBpbiBjb3JyZWN0aW5n IHRoZSBJQU5BIHBhZ2VzLCBidXQgd2UgY2FuJ3QgbWFrZSBtb2RpZmljYXRpb25zIG9yIGV4dGVu c2lvbnMgdG8gYSBzY2hlbWEgcHVibGlzaGVkIGluIGFuIFJGQyB1bmxlc3MgdGhlIGV4dGVuc2lv biBpcyBkb2N1bWVudGVkIGFuZCBwdWJsaXNoZWQuDQoNClRoYW5rcywNCkhpc2hhbQ0KMjAwOS8x MS8xOSBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbTxtYWlsdG86YmVuQG5vc3RydW0uY29t Pj4NCjxjaGFpcj4NCldlJ3ZlIGhhZCBhIHNtYWxsIGFtb3VudCBvZiBvbi1saXN0IGRpc2N1c3Np b24uIEZyb20gdGhlIGVtYWlscyBzbyBmYXIgSSBnYXRoZXIgdGhhdCB0aGVyZSBhcmUgbm8gb2Jq ZWN0aW9ucyB0byBjb3JyZWN0aW5nIHRoZSBzY2hlbWEgYXMgcHVibGlzaGVkIGJ5IElBTkEgdG8g bWF0Y2ggdGhvc2UgZnJvbSBSRkMgNDgyNi4gSG93ZXZlciwgdGhlcmUgaGF2ZSBiZWVuIHNvbWUg b2JqZWN0aW9ucyB0byBhZGRpbmcgdGhlIFNjaGVtYUxvY2F0aW9uIHBhcmFtZXRlcnMgYXMgcmVx dWVzdGVkIGluIHRoZSBsaWFpc29uIHN0YXRlbWVudC4NCg0KRXZlcnlvbmUtLXBsZWFzZSB0YWtl IGEgbG9vayBhdCB0aGUgbGlhaXNvbiBzdGF0ZW1lbnQgYW5kIG9mZmVyIHlvdXIgb3BpbmlvbnMu IEV2ZW4gIm1lIHRvbyIgY29tbWVudHMgd291bGQgYmUgaGVscGZ1bCBhdCB0aGlzIHBvaW50LiBJ dCdzIGJlZW4gYWxtb3N0IHR3byBtb250aHMgc2luY2UgT01BIHNlbnQgdGhlIGxpYWlzb24gc3Rh dGVtZW50LCBhbmQgd2UgbmVlZCB0byByZXNwb25kIHRvIGl0IEFTQVAuDQoNClRoYW5rcyENCg0K QmVuLg0KDQo8L2NoYWlyPg0KDQoNCk9uIE9jdCAyLCAyMDA5LCBhdCAxOjEyIFBNLCBCZW4gQ2Ft cGJlbGwgd3JvdGU6DQoNCj4gKGFzIFNJTVBMRSBjby1jaGFpcikNCj4NCj4gT01BIHNlbnQgYSBs aWFpc29uIHN0YXRlbWVudCB0byB0aGUgU0lNUExFIHdvcmtpbmcgZ3JvdXAuIFRoZSBzdGF0ZW1l bnQncyBvdmVydmlldyByZWFkcyBhcyBmb2xsb3dzOg0KPg0KPiAiVGhpcyBMaWFpc29uIFN0YXRl bWVudCByZXBvcnRzIFhNTCB2YWxpZGF0aW9uIHByb2JsZW1zIGluIHRoZSBYTUwgc2NoZW1hcyB0 aGF0IHdlcmUgaW50cm9kdWNlZCBpbiBSRkMgNDgyNiBhbmQgYXNrcyBmb3IgY29ycmVjdGlvbi4i DQo+DQo+IFBsZWFzZSByZWFkIHRoZSBMUywgYW5kIHNlbmQgeW91ciBvcGluaW9ucyB0byB0aGUg U0lNUExFIGxpc3QuIEEgUERGICBpcyBhdmFpbGFibGUgYXQgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2N1bWVudHMvTElBSVNPTi9maWxlNzA3LnBkZg0KPg0KPiBUaGFua3MhDQo+DQo+ IEJlbi4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gU2ltcGxlIG1haWxpbmcgbGlzdA0KPiBTaW1wbGVAaWV0Zi5vcmc8bWFpbHRvOlNpbXBsZUBp ZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaW1wbGUN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNpbXBs ZSBtYWlsaW5nIGxpc3QNClNpbXBsZUBpZXRmLm9yZzxtYWlsdG86U2ltcGxlQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaW1wbGUNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU2ltcGxlIG1haWxpbmcg bGlzdA0KU2ltcGxlQGlldGYub3JnPG1haWx0bzpTaW1wbGVAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpbXBsZQ0KDQo= --_000_8B0A9FCBB9832F43971E38010638454F01D648F169SISPE7MB1comm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9VVRGLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDov L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KDQo8bWV0YSBuYW1lPUdlbmVy YXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0t W2lmICFtc29dPg0KPHN0eWxlPg0Kdlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0K b1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNk ZWZhdWx0I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0 eWxlPg0KPCFbZW5kaWZdLS0+DQo8c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAq Lw0KIEBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjAgMTEg NSAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2EtQm9sZDsNCglwYW5vc2Ut MTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBtbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowbW07DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MG1tOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMyNDQwNjE7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5TZWN0 aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4NCjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K IDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFu Zz1FTi1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlIHN0eWxlPSdXT1JELVdSQVA6IGJyZWFrLXdv cmQ7DQp3ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTt3ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hp dGUtc3BhY2UnPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCmNvbG9yOiMyNDQwNjEnPlV3ZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMyNDQw NjEnPkNhbiBJIHN1Z2dlc3QgdGhhdCB5b3Ugc3VibWl0IGVycmF0YSBvbiA0ODI2P8KgIFRoYXQg aXMgdGhlIHVzdWFsDQptZXRob2Qgd2UgdXNlIHRvIHJlc29sdmUgYWN0dWFsIGVycm9ycy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6 IzI0NDA2MSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCmNvbG9yOiMyNDQwNjEnPlRvIGRhdGUsIHRoZSBwb2xpY3kgaGFzIGJlZW4g dG8gTk9UIHVzZSBzY2hlbWFMb2NhdGlvbiBpbiBSRkNzLsKgDQpXZeKAmXZlIGhhZCBhIGxvdCBv ZiBkaXNjdXNzaW9uIG9uIHRoZSBtZXJpdHMgKGFuZCBkaXNhZHZhbnRhZ2VzKSBvZiBwdXR0aW5n DQpzY2hlbWFMb2NhdGlvbiBhdHRyaWJ1dGVzIGluIGZpbGVzLsKgIE91ciBkaXNjdXNzaW9ucyBj b25jZW50cmF0ZWQgb24gdGhhdA0KYXNwZWN0LsKgIElmIHRoZXJlIGlzIGEgY2FzZSBmb3IgZG9p bmcgc28sIHRoZW4gSUFOQSBuZWVkIHRvIGJlIHRoZSBvbmVzIHRoYXQNCmFjY2VwdCB0aGUgcmVz cG9uc2liaWxpdHkgZm9yIG1haW50YWluaW5nIHNjaGVtYSBVUkxzLCBzaW5jZSBSRkNzIHdpbGwg bm90LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQpjb2xvcjojMjQ0MDYxJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+LS1NYXJ0aW48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MG1tIDBtbSAwbW0gNC4wcHQnPg0K DQo8ZGl2Pg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwbW0gMG1tIDBtbSc+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 Og0KIlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+IHNpbXBsZS1ib3VuY2VzQGlldGYub3JnDQpbbWFpbHRvOnNpbXBsZS1ib3VuY2VzQGll dGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPlJhdXNjaGVuYmFjaCwgVXdlIChOU04gLQ0KREUv TXVuaWNoKTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgMjYgTm92ZW1iZXIgMjAwOSA0OjMy IEFNPGJyPg0KPGI+VG86PC9iPiBleHQgQmVuIENhbXBiZWxsOyBMb3Vpc2UuQ2xhcmtlQGZvcmFw b2xpcy5jb207IFNpbXBsZSBXRzsgRGVhbg0KV2lsbGlzPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbU2ltcGxlXSBMaWFpc29uIFN0YXRlbWVudCBmcm9tIHRoZSBPcGVuIE1vYmlsZSBBbGxpYW5j ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjsNCmNvbG9yOmJsdWUnPkhpIEJlbiw8L3NwYW4+PG86cD48L286cD48L3A+DQoN CjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48 L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQpjb2xv cjpibHVlJz50aGFua3MgZm9yIG1vdmluZyB0aGlzIGZvcndhcmQuIEFzIHRoZSBhdXRob3Igb2Yg dGhlIExTLCBsZXQgbWUNCnByb3ZpZGUgc29tZSBjbGFyaWZpY2F0aW9uLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIjsNCmNvbG9yOmJsdWUnPlRoZSBMUyBzdGF0ZXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K DQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EtQm9sZCIsInNlcmlm Iic+VmFsaWRhdGlvbg0KcHJvYmxlbXMgaW4gdXJuOmlldGY6cGFyYW1zOnhtbDpuczpybHMtc2Vy dmljZXMgU2NoZW1hIGFzIGF2YWlsYWJsZSBmcm9tIFszXTxicj4NCjxicj4NCjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNh bnMtc2VyaWYiJz5UaGlzDQpYTUwgc2NoZW1hIGltcG9ydHMgdGhlIHJlc291cmNlLWxpc3RzIHNj aGVtYSwgaG93ZXZlciBkb2VzIG5vdCBwcm92aWRlIGEgc2NoZW1hDQpsb2NhdGlvbiBmb3IgaXQu IER1ZSB0byB0aGlzLCB0aGUgcmxzLXNlcnZpY2VzIHNjaGVtYSBkb2VzIG5vdCB2YWxpZGF0ZSBi ZWNhdXNlDQp0aGUgdmFsaWRhdG9yIGNhbiBub3QgZmV0Y2ggdGhlIHJlZmVyZW5jZWQgc2NoZW1h LiBJdCBpcyB0aGVyZWZvcmUgc3VnZ2VzdGVkIHRvDQphZGQgYSBzY2hlbWFMb2NhdGlvbiBhdHRy aWJ1dGUgdG8gdGhlICZsdDtpbXBvcnQmZ3Q7IGRlY2xhcmF0aW9uIG9mIHRoZQ0KcmxzLXNlcnZp Y2VzIFhNTCBzY2hlbWEgaW5zdGFuY2UgaW4gdGhlIElBTkEgcmVwb3NpdG9yeS48YnI+DQpbM10g PHNwYW4gc3R5bGU9J2NvbG9yOiMzMzAwRkYnPjxhDQpocmVmPSJodHRwOi8vd3d3LmlhbmEub3Jn L2Fzc2lnbm1lbnRzL3htbC1yZWdpc3RyeS9zY2hlbWEvcmxzLXNlcnZpY2VzLnhzZCI+PHNwYW4N CnN0eWxlPSdjb2xvcjpibGFjayc+aHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy94bWwt cmVnaXN0cnkvc2NoZW1hL3Jscy1zZXJ2aWNlcy54c2Q8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8cD48c3BhbiBsYW5nPURFIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KY29sb3I6Ymx1 ZSc+SSBoYXZlIGNyb3NzLWNoZWNrZWQgYW5kIGluZGVlZCBuZWl0aGVyIHRoZSBzY2hlbWEgaW4g SUFOQQ0KcmVwb3NpdG9yeSBub3IgdGhlIG9uZSBpbiB0aGUgUkZDIGNvbnRhaW5zIGFuICZsdDtp bXBvcnQmZ3Q7IHN0YXRlbWVudC4gU28sIHRoZQ0KdGV4dCBpbiB0aGUgTFMgaXMgbm90IDEwMCUg Y29ycmVjdCBidXQgaXRzIHNwaXJpdCBpcyB0aGF0IE9NQSByZXF1ZXN0cyB0byBtYWtlDQpzdXJl IHRoYXQgdmFsaWRhdG9ycyB0aGF0IHVzZSB0aGlzIHNjaGVtYSB3aWxsIGJlIGluZm9ybWVkIGFi b3V0IHRoZSBhZGRpdGlvbmFsDQpzY2hlbWEgbmVlZGVkIGZvciB2YWxpZGF0aW9uIGFuZCBpdHMg bG9jYXRpb24uIE5vdGUgdGhhdCBhIHNpbWlsYXINCiZsdDtpbXBvcnQmZ3Q7IGRlY2xhcmF0aW9u IChpbmNsdWRpbmcgYSBzY2hlbWFMb2NhdGlvbiBhdHRyaWJ1dGUpIGlzIGNvbnRhaW5lZA0KaW4g dGhlIFhNTCBzY2hlbWEgZm9yIHJlc291cmNlLWxpc3RzIChpdCBpbXBvcnRzIHRoZSBzdGFuZGFy ZCBYTUwgbmFtZXNwYWNlKS4NCiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHA+PHNw YW4gbGFuZz1ERSBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjsNCmNvbG9yOmJsdWUnPkJhc2VkIG9uIHRoZSBzY2hlbWEgZm9yIHJscy1zZXJ2 aWNlcyBpbiBSRkM0ODI2LCB0aGUgTFMgPHN0cm9uZz48c3Bhbg0Kc3R5bGU9J2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5zaG91bGQgPC9zcGFuPjwvc3Ryb25nPmhhdmUgc3RhdGVk Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9REUgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkhlbHZldGlj YSIsInNhbnMtc2VyaWYiJz5UaGUNCjxzcGFuIHN0eWxlPSdjb2xvcjpyZWQnPnJscy1zZXJ2aWNl czwvc3Bhbj4mbmJzcDtYTUwgc2NoZW1hIDxzcGFuDQpzdHlsZT0nY29sb3I6cmVkJz5yZWZlcmVu Y2VzPC9zcGFuPiB0aGUgcmVzb3VyY2UtbGlzdHMgc2NoZW1hIDxzcGFuDQpzdHlsZT0nY29sb3I6 cmVkJz5uYW1lc3BhY2U8L3NwYW4+LCBob3dldmVyIDxzcGFuIHN0eWxlPSdjb2xvcjpyZWQnPm5l aXRoZXINCmltcG9ydHMgdGhlIHNjaGVtYSBub3I8L3NwYW4+IHByb3ZpZGU8c3BhbiBzdHlsZT0n Y29sb3I6cmVkJz5zIDwvc3Bhbj5hIHNjaGVtYQ0KbG9jYXRpb24gZm9yIGl0LiBEdWUgdG8gdGhp cywgdGhlIHJscy1zZXJ2aWNlcyBzY2hlbWEgZG9lcyBub3QgdmFsaWRhdGUgYmVjYXVzZQ0KdGhl IHZhbGlkYXRvciBjYW4gbm90IGZldGNoIHRoZSByZWZlcmVuY2VkIHNjaGVtYS4gSXQgaXMgdGhl cmVmb3JlIHN1Z2dlc3RlZCB0bw0KYWRkJm5ic3A7PHNwYW4gc3R5bGU9J2NvbG9yOnJlZCc+dGhl IG1pc3Npbmc8L3NwYW4+DQombHQ7aW1wb3J0Jmd0OyZuYnNwO2RlY2xhcmF0aW9uJm5ic3A7PHNw YW4gc3R5bGU9J2NvbG9yOnJlZCc+KGluY2x1ZGluZyBhDQpzY2hlbWFMb2NhdGlvbiBhdHRyaWJ1 dGUpIHRvPC9zcGFuPiB0aGUgcmxzLXNlcnZpY2VzIFhNTCBzY2hlbWEgaW5zdGFuY2UgaW4gdGhl DQpJQU5BIHJlcG9zaXRvcnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPHA+ PHNwYW4gbGFuZz1ERSBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjsNCmNvbG9yOmJsdWUnPlNvcnJ5IGFib3V0IHRoZSBjb25mdXNpb24gY2F1 c2VkLCBhbmQgZ29vZCBjYXRjaC48L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxwPjxzcGFuIGxh bmc9REUgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7DQpjb2xvcjpibHVlJz5LaW5kIHJlZ2FyZHMsPGJyPg0KVXdlIDwvc3Bhbj48c3BhbiBs YW5nPURFPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGJsb2NrcXVvdGUgc3R5bGU9 J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowbW0gMG1t IDBtbSA0LjBwdDsNCm1hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowbW07bWFyZ2luLWJvdHRvbTo1LjBwdCc+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0 eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNwYW4gbGFuZz1ERT4NCg0KPGhyIHNpemU9MiB3aWR0 aD0iMTAwJSIgYWxpZ249Y2VudGVyPg0KDQo8L3NwYW4+PC9kaXY+DQoNCjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxiPjxzcGFuIGxhbmc9REUNCnN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJv bTo8L3NwYW4+PC9iPjxzcGFuDQpsYW5nPURFIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+DQpzaW1wbGUtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOnNpbXBsZS1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPmV4dA0K QmVuIENhbXBiZWxsPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTm92ZW1iZXIgMjAsIDIwMDkg MTA6MDYgUE08YnI+DQo8Yj5Ubzo8L2I+IExvdWlzZS5DbGFya2VAZm9yYXBvbGlzLmNvbTsgU2lt cGxlIFdHOyBEZWFuIFdpbGxpczxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1NpbXBsZV0gTGlh aXNvbiBTdGF0ZW1lbnQgZnJvbSB0aGUgT3BlbiBNb2JpbGUgQWxsaWFuY2U8L3NwYW4+PHNwYW4N Cmxhbmc9REU+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+RGln Z2luZyBhIGxpdHRsZSBkZWVwZXIsIEkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0IHRoZQ0Kc2NoZW1h TG9jYXRpb24gcmVxdWVzdCBpbiB0aGUgbGlhaXNvbiBzdGF0ZW1lbnQ6IDxvOnA+PC9vOnA+PC9w Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoN CjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+VGhlIHN0YXRlbWVudCBwcm9w b3NlcyBhZGRpbmcgYSBzY2hlbWFMb2NhdGlvbiBhdHRyaWJ1dGUgdG8NCnRoZSAmbHQ7aW1wb3J0 Jmd0OyBlbGVtZW50IHRoYXQgaW1wb3J0cyB0aGUgcmVzb3VyY2UtbGlzdCBzY2hlbWEgaW50byB0 aGUNClJMUy1TZXJ2aWNlcyAmbmJzcDtzY2hlbWEuIEJ1dCBvbiBpbnNwZWN0aW9uLCB0aGVyZSBp cyBubyAmbHQ7aW1wb3J0Jmd0Ow0KZWxlbWVudCB3aGF0c29ldmVyIGluIHRoZSBybHMtc2Vydmlj ZXMgc2NoZW1hLiBIb3dldmVyLCB0aGUgJmx0O3NjaGVtYSZndDsgZWxlbWVudA0KZG9lcyBjb250 YWluIGEgbmFtZXNwYWNlIGRlY2xhcmF0aW9uIHRoYXQgcmVmZXJlbmNlcyByZXNvdXJjZS1saXN0 LiBXYXMgdGhlDQpsaWFpc29uIHN0YXRlbWVudCBpbnRlbmRlZCB0byByZXF1ZXN0IHdlIGFkZCBz Y2hlbWFMb2NhdGlvbiB0byB0aGUgbmFtZXNwYWNlDQpkZWNsYXJhdGlvbj88bzpwPjwvbzpwPjwv cD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5PciBhbSBJ IG1pc3Npbmcgc29tZXRoaW5nPzxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8ZGl2Pg0KDQo8ZGl2 Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+T24gTm92IDE4LCAyMDA5LCBhdCA3OjMxIFBNLCBCZW4g Q2FtcGJlbGwgd3JvdGU6PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD4mbHQ7aW5kaXZpZHVhbCZndDs8bzpwPjwvbzpwPjwvcD4NCg0KPC9k aXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4N Cg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5BbmQgdGhlIHRoaW5nIHRo ZXkgYXJlIGFza2luZyBmb3Igd291bGQgZ2VuZXJhbGx5IF9ub3RfIG1ha2UNCnNlbnNlIHRvIHB1 dCBpbiBhbiBSRkMsIHVubGVzcyB3ZSBhcmUgd2lsbGluZyB0byBlbnN1cmUgdGhlIFVSTCB0byB0 aGUgc2NoZW1hDQpsaXZlcyBmb3JldmVyLjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rpdj4N Cg0KPGRpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPk9uIE5vdiAxOCwgMjAwOSwg YXQgNzoxNCBQTSwgSGlzaGFtIEtoYXJ0YWJpbCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCg0KPC9k aXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+Jmx0O2FzIGlu ZGl2aWR1YWwmZ3Q7PGJyPg0KPGJyPg0KTm8gaXNzdWVzIGluIGNvcnJlY3RpbmcgdGhlIElBTkEg cGFnZXMsIGJ1dCB3ZSBjYW4ndCBtYWtlIG1vZGlmaWNhdGlvbnMgb3INCmV4dGVuc2lvbnMgdG8g YSBzY2hlbWEgcHVibGlzaGVkIGluIGFuIFJGQyB1bmxlc3MgdGhlIGV4dGVuc2lvbiBpcyBkb2N1 bWVudGVkDQphbmQgcHVibGlzaGVkLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpIaXNoYW08bzpw PjwvbzpwPjwvcD4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjIwMDkvMTEvMTkgQmVu IENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmVuQG5vc3RydW0uY29tIj5iZW5Abm9zdHJ1 bS5jb208L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jmx0O2No YWlyJmd0Ozxicj4NCldlJ3ZlIGhhZCBhIHNtYWxsIGFtb3VudCBvZiBvbi1saXN0IGRpc2N1c3Np b24uIEZyb20gdGhlIGVtYWlscyBzbyBmYXIgSSBnYXRoZXINCnRoYXQgdGhlcmUgYXJlIG5vIG9i amVjdGlvbnMgdG8gY29ycmVjdGluZyB0aGUgc2NoZW1hIGFzIHB1Ymxpc2hlZCBieSBJQU5BIHRv DQptYXRjaCB0aG9zZSBmcm9tIFJGQyA0ODI2LiBIb3dldmVyLCB0aGVyZSBoYXZlIGJlZW4gc29t ZSBvYmplY3Rpb25zIHRvIGFkZGluZw0KdGhlIFNjaGVtYUxvY2F0aW9uIHBhcmFtZXRlcnMgYXMg cmVxdWVzdGVkIGluIHRoZSBsaWFpc29uIHN0YXRlbWVudC48YnI+DQo8YnI+DQpFdmVyeW9uZS0t cGxlYXNlIHRha2UgYSBsb29rIGF0IHRoZSBsaWFpc29uIHN0YXRlbWVudCBhbmQgb2ZmZXIgeW91 ciBvcGluaW9ucy4NCkV2ZW4gJnF1b3Q7bWUgdG9vJnF1b3Q7IGNvbW1lbnRzIHdvdWxkIGJlIGhl bHBmdWwgYXQgdGhpcyBwb2ludC4gSXQncyBiZWVuDQphbG1vc3QgdHdvIG1vbnRocyBzaW5jZSBP TUEgc2VudCB0aGUgbGlhaXNvbiBzdGF0ZW1lbnQsIGFuZCB3ZSBuZWVkIHRvIHJlc3BvbmQNCnRv IGl0IEFTQVAuPGJyPg0KPGJyPg0KVGhhbmtzITxicj4NCjxicj4NCkJlbi48YnI+DQo8YnI+DQom bHQ7L2NoYWlyJmd0OzxvOnA+PC9vOnA+PC9wPg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PGJyPg0KPGJyPg0KT24gT2N0IDIsIDIwMDksIGF0IDE6MTIgUE0sIEJlbiBD YW1wYmVsbCB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IChhcyBTSU1QTEUgY28tY2hhaXIpPGJyPg0K Jmd0Ozxicj4NCiZndDsgT01BIHNlbnQgYSBsaWFpc29uIHN0YXRlbWVudCB0byB0aGUgU0lNUExF IHdvcmtpbmcgZ3JvdXAuIFRoZSBzdGF0ZW1lbnQncw0Kb3ZlcnZpZXcgcmVhZHMgYXMgZm9sbG93 czo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmcXVvdDtUaGlzIExpYWlzb24gU3RhdGVtZW50IHJlcG9y dHMgWE1MIHZhbGlkYXRpb24gcHJvYmxlbXMgaW4gdGhlIFhNTA0Kc2NoZW1hcyB0aGF0IHdlcmUg aW50cm9kdWNlZCBpbiBSRkMgNDgyNiBhbmQgYXNrcyBmb3IgY29ycmVjdGlvbi4mcXVvdDs8YnI+ DQomZ3Q7PGJyPg0KJmd0OyBQbGVhc2UgcmVhZCB0aGUgTFMsIGFuZCBzZW5kIHlvdXIgb3Bpbmlv bnMgdG8gdGhlIFNJTVBMRSBsaXN0LiBBIFBERg0KJm5ic3A7aXMgYXZhaWxhYmxlIGF0IDxhDQpo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvY3VtZW50cy9MSUFJU09OL2ZpbGU3 MDcucGRmIg0KdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j dW1lbnRzL0xJQUlTT04vZmlsZTcwNy5wZGY8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtz ITxicj4NCiZndDs8YnI+DQomZ3Q7IEJlbi48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwv ZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgU2ltcGxl IG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOlNpbXBsZUBpZXRmLm9yZyI+ U2ltcGxlQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zaW1wbGUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpbXBsZTwvYT48YnI+DQo8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClNpbXBsZSBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86U2ltcGxlQGlldGYub3JnIj5TaW1wbGVAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaW1wbGUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NpbXBsZTwvYT48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8 L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KU2ltcGxlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpTaW1wbGVAaWV0Zi5vcmciPlNpbXBsZUBpZXRmLm9yZzwvYT48YnI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpbXBsZTxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0K PC9ibG9ja3F1b3RlPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K --_000_8B0A9FCBB9832F43971E38010638454F01D648F169SISPE7MB1comm_-- From ben@estacado.net Wed Nov 25 18:37:06 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 747BB3A6959 for ; Wed, 25 Nov 2009 18:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsGejzY6rNr2 for ; Wed, 25 Nov 2009 18:37:05 -0800 (PST) Received: from estacado.net (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) by core3.amsl.com (Postfix) with ESMTP id 960ED3A6948 for ; Wed, 25 Nov 2009 18:37:04 -0800 (PST) Received: from [10.0.1.8] (adsl-68-94-26-178.dsl.rcsntx.swbell.net [68.94.26.178]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id nAQ2ZEPn065653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Nov 2009 20:35:26 -0600 (CST) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-1--424649154 From: Ben Campbell In-Reply-To: <8B0A9FCBB9832F43971E38010638454F01D648F169@SISPE7MB1.commscope.com> Date: Wed, 25 Nov 2009 20:35:08 -0600 Message-Id: <1B748CBF-3F36-4D98-ABA4-6B54BB0785E8@estacado.net> References: <81621E94-1FF4-4584-9C55-30945836C7DF@nostrum.com><66cd252f0911181714p756a42e9y8ed4b0c96f032b42@mail.gmail.com> <3CD66A98-8562-4E49-B1CA-AED5C20D67E4@estacado.net> <8B0A9FCBB9832F43971E38010638454F01D648F169@SISPE7MB1.commscope.com> To: "Thomson, Martin" X-Mailer: Apple Mail (2.1077) Cc: "Louise.Clarke@forapolis.com" , Simple WG , Dean Willis Subject: Re: [Simple] Liaison Statement from the Open Mobile Alliance X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 02:37:06 -0000 --Apple-Mail-1--424649154 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Unless I misunderstand, the statement is not asking for an update to the = RFC--it's asking for an update to the IANA published version. It's an = IETF policy question whether that would actually require an RFC update = or errata. On Nov 25, 2009, at 6:14 PM, Thomson, Martin wrote: > Uwe, > =20 > Can I suggest that you submit errata on 4826? That is the usual = method we use to resolve actual errors. > =20 > To date, the policy has been to NOT use schemaLocation in RFCs. We=92ve= had a lot of discussion on the merits (and disadvantages) of putting = schemaLocation attributes in files. Our discussions concentrated on = that aspect. If there is a case for doing so, then IANA need to be the = ones that accept the responsibility for maintaining schema URLs, since = RFCs will not. > =20 > --Martin > =20 > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On = Behalf Of Rauschenbach, Uwe (NSN - DE/Munich) > Sent: Thursday, 26 November 2009 4:32 AM > To: ext Ben Campbell; Louise.Clarke@forapolis.com; Simple WG; Dean = Willis > Subject: Re: [Simple] Liaison Statement from the Open Mobile Alliance > =20 > Hi Ben, > =20 > thanks for moving this forward. As the author of the LS, let me = provide some clarification. > =20 > The LS states: > =20 > Validation problems in urn:ietf:params:xml:ns:rls-services Schema as = available from [3] >=20 > This XML schema imports the resource-lists schema, however does not = provide a schema location for it. Due to this, the rls-services schema = does not validate because the validator can not fetch the referenced = schema. It is therefore suggested to add a schemaLocation attribute to = the declaration of the rls-services XML schema instance in the = IANA repository. > [3] = http://www.iana.org/assignments/xml-registry/schema/rls-services.xsd > I have cross-checked and indeed neither the schema in IANA repository = nor the one in the RFC contains an statement. So, the text in = the LS is not 100% correct but its spirit is that OMA requests to make = sure that validators that use this schema will be informed about the = additional schema needed for validation and its location. Note that a = similar declaration (including a schemaLocation attribute) is = contained in the XML schema for resource-lists (it imports the standard = XML namespace). =20 >=20 > Based on the schema for rls-services in RFC4826, the LS should have = stated: >=20 > The rls-services XML schema references the resource-lists schema = namespace, however neither imports the schema nor provides a schema = location for it. Due to this, the rls-services schema does not validate = because the validator can not fetch the referenced schema. It is = therefore suggested to add the missing declaration (including a = schemaLocation attribute) to the rls-services XML schema instance in the = IANA repository. > Sorry about the confusion caused, and good catch. >=20 > Kind regards, > Uwe >=20 > =20 > =20 > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On = Behalf Of ext Ben Campbell > Sent: Friday, November 20, 2009 10:06 PM > To: Louise.Clarke@forapolis.com; Simple WG; Dean Willis > Subject: Re: [Simple] Liaison Statement from the Open Mobile Alliance >=20 > Digging a little deeper, I have a question about the schemaLocation = request in the liaison statement: > =20 > The statement proposes adding a schemaLocation attribute to the = element that imports the resource-list schema into the = RLS-Services schema. But on inspection, there is no element = whatsoever in the rls-services schema. However, the element = does contain a namespace declaration that references resource-list. Was = the liaison statement intended to request we add schemaLocation to the = namespace declaration? > =20 > Or am I missing something? > =20 > On Nov 18, 2009, at 7:31 PM, Ben Campbell wrote: >=20 >=20 > > =20 > And the thing they are asking for would generally _not_ make sense to = put in an RFC, unless we are willing to ensure the URL to the schema = lives forever. > =20 > On Nov 18, 2009, at 7:14 PM, Hisham Khartabil wrote: >=20 >=20 > >=20 > No issues in correcting the IANA pages, but we can't make = modifications or extensions to a schema published in an RFC unless the = extension is documented and published. >=20 > Thanks, > Hisham >=20 > 2009/11/19 Ben Campbell > > We've had a small amount of on-list discussion. =46rom the emails so = far I gather that there are no objections to correcting the schema as = published by IANA to match those from RFC 4826. However, there have been = some objections to adding the SchemaLocation parameters as requested in = the liaison statement. >=20 > Everyone--please take a look at the liaison statement and offer your = opinions. Even "me too" comments would be helpful at this point. It's = been almost two months since OMA sent the liaison statement, and we need = to respond to it ASAP. >=20 > Thanks! >=20 > Ben. >=20 > >=20 >=20 > On Oct 2, 2009, at 1:12 PM, Ben Campbell wrote: >=20 > > (as SIMPLE co-chair) > > > > OMA sent a liaison statement to the SIMPLE working group. The = statement's overview reads as follows: > > > > "This Liaison Statement reports XML validation problems in the XML = schemas that were introduced in RFC 4826 and asks for correction." > > > > Please read the LS, and send your opinions to the SIMPLE list. A PDF = is available = athttps://datatracker.ietf.org/documents/LIAISON/file707.pdf > > > > Thanks! > > > > Ben. > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > =20 > =20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > =20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail-1--424649154 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Unless I misunderstand, the statement is not = asking for an update to the RFC--it's asking for an update to the IANA = published version. It's an IETF policy question whether that would = actually require an RFC update or errata.

On Nov 25, = 2009, at 6:14 PM, Thomson, Martin wrote:

 
Can I suggest that you submit = errata on 4826?  That is the usual method we use to resolve actual = errors.
 
To date, the policy has been to = NOT use schemaLocation in RFCs.  We=92ve had a lot of discussion on = the merits (and disadvantages) of putting schemaLocation attributes in = files.  Our discussions concentrated on that aspect.  If there = is a case for doing so, then IANA need to be the ones that accept the = responsibility for maintaining schema URLs, since RFCs will = not.
 
 
From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.o= rg] On Behalf = Of Rauschenbach, = Uwe (NSN - DE/Munich)
Sent: Thursday, 26 November 2009 = 4:32 AM
To: ext Ben Campbell; Louise.Clarke@forapolis.com; Simple = WG; Dean Willis
Subject: Re: [Simple] Liaison = Statement from the Open Mobile = Alliance
 
 
This XML schema imports the = resource-lists schema, however does not provide a schema location for = it. Due to this, the rls-services schema does not validate because the = validator can not fetch the referenced schema. It is therefore suggested = to add a schemaLocation attribute to the <import> declaration of = the rls-services XML schema instance in the IANA repository.
[3] I have cross-checked and indeed neither the = schema in IANA repository nor the one in the RFC contains an = <import> statement. So, the text in the LS is not 100% correct but = its spirit is that OMA requests to make sure that validators that use = this schema will be informed about the additional schema needed for = validation and its location. Note that a similar <import> = declaration (including a schemaLocation attribute) is contained in the = XML schema for resource-lists (it imports the standard XML namespace). =  

Based on the schema for rls-services in RFC4826, the = LS should have = stated:

The   the = resource-lists schema   provides a = schema location for it. Due to this, the rls-services schema does not = validate because the validator can not fetch the referenced schema. It = is therefore suggested to add the = missing <import> declarati= on (including a schemaLocation = attribute) to the= rls-services XML schema instance in the IANA = repository.

Sorry about the confusion caused, and good = catch.

Kind regards,
Uwe

 

From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.o= rg] On Behalf = Of ext Ben = Campbell
Sent: Friday, November 20, 2009 = 10:06 PM
To: Louise.Clarke@forapolis.com; Simple = WG; Dean Willis
Subject: Re: [Simple] Liaison = Statement from the Open Mobile Alliance

Digging a little = deeper, I have a question about the schemaLocation request in the = liaison statement:
The statement = proposes adding a schemaLocation attribute to the <import> element = that imports the resource-list schema into the RLS-Services =  schema. But on inspection, there is no <import> element = whatsoever in the rls-services schema. However, the <schema> = element does contain a namespace declaration that references = resource-list. Was the liaison statement intended to request we add = schemaLocation to the namespace = declaration?
Or am I missing = something?
On Nov 18, 2009, at = 7:31 PM, Ben Campbell wrote:


 
And the thing they = are asking for would generally _not_ make sense to put in an RFC, unless = we are willing to ensure the URL to the schema lives = forever.
On Nov 18, 2009, at = 7:14 PM, Hisham Khartabil wrote:


<as individual>

No issues in correcting the IANA = pages, but we can't make modifications or extensions to a schema = published in an RFC unless the extension is documented and = published.

Thanks,
Hisham

__________________= _____________________________
Simple mailing list
Simple@ietf.org
); Wed, 25 Nov 2009 21:14:13 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 25 Nov 2009 21:14:12 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 26 Nov 2009 11:14:10 +0800 From: "Thomson, Martin" To: Ben Campbell Date: Thu, 26 Nov 2009 11:14:50 +0800 Thread-Topic: [Simple] Liaison Statement from the Open Mobile Alliance Thread-Index: AcpuQSbWOHiZ7vi1TAOUt8jM6gj5UwABSOWA Message-ID: <8B0A9FCBB9832F43971E38010638454F01D648F1FD@SISPE7MB1.commscope.com> References: <81621E94-1FF4-4584-9C55-30945836C7DF@nostrum.com><66cd252f0911181714p756a42e9y8ed4b0c96f032b42@mail.gmail.com> <3CD66A98-8562-4E49-B1CA-AED5C20D67E4@estacado.net> <8B0A9FCBB9832F43971E38010638454F01D648F169@SISPE7MB1.commscope.com> <1B748CBF-3F36-4D98-ABA4-6B54BB0785E8@estacado.net> In-Reply-To: <1B748CBF-3F36-4D98-ABA4-6B54BB0785E8@estacado.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8B0A9FCBB9832F43971E38010638454F01D648F1FDSISPE7MB1comm_" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "Louise.Clarke@forapolis.com" , Simple WG , Dean Willis Subject: Re: [Simple] Liaison Statement from the Open Mobile Alliance X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 03:14:20 -0000 --_000_8B0A9FCBB9832F43971E38010638454F01D648F1FDSISPE7MB1comm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGF0IGFuIGVycmF0YSBuZWVkcyB0byBiZSByYWlzZWQgdG8gcmVzb2x2ZSB0aGUg aW1wb3J0IGlzc3VlOyBJ4oCZbSBoYXBweSB0byByYWlzZSB0aGlzIG15c2VsZi4NCg0KSXQgd291 bGQgYmUgcG9zc2libGUgdG8gcHV0IHNjaGVtYUxvY2F0aW9uIGluIFJGQ3MsIGJ1dCB0aGF04oCZ cyBhbiBJRVRGIHBvbGljeSBpc3N1ZSB0aGF0IHdl4oCZZCBoYXZlIHRvIGRpc2N1c3Mgd2l0aCB0 aGUgWE1MIGV4cGVydHMgYW5kIHByb2JhYmx5IHdpdGggSUFOQSwgc2luY2UgdGhleSB3b3VsZCBo YXZlIHRvIG1haW50YWluIHRoZSBkb2N1bWVudHMgdGhhdCB0aGUgbGlua3MgcmVmZXIgdG8uICBU byBkYXRlLCB0aGUgcG9saWN5IGhhcyBiZWVuIHRvIGF2b2lkIHRoaXMsIGJ1dCB0aGF0IGRvZXNu 4oCZdCBtZWFuIHRoYXQgdGhlIHBvbGljeSBjYW7igJl0IGJlIGNoYW5nZWQuDQoNCi0tTWFydGlu DQoNCkZyb206IEJlbiBDYW1wYmVsbCBbbWFpbHRvOmJlbkBlc3RhY2Fkby5uZXRdDQpTZW50OiBU aHVyc2RheSwgMjYgTm92ZW1iZXIgMjAwOSAxOjM1IFBNDQpUbzogVGhvbXNvbiwgTWFydGluDQpD YzogUmF1c2NoZW5iYWNoLCBVd2UgKE5TTiAtIERFL011bmljaCk7IExvdWlzZS5DbGFya2VAZm9y YXBvbGlzLmNvbTsgU2ltcGxlIFdHOyBEZWFuIFdpbGxpcw0KU3ViamVjdDogUmU6IFtTaW1wbGVd IExpYWlzb24gU3RhdGVtZW50IGZyb20gdGhlIE9wZW4gTW9iaWxlIEFsbGlhbmNlDQoNClVubGVz cyBJIG1pc3VuZGVyc3RhbmQsIHRoZSBzdGF0ZW1lbnQgaXMgbm90IGFza2luZyBmb3IgYW4gdXBk YXRlIHRvIHRoZSBSRkMtLWl0J3MgYXNraW5nIGZvciBhbiB1cGRhdGUgdG8gdGhlIElBTkEgcHVi bGlzaGVkIHZlcnNpb24uIEl0J3MgYW4gSUVURiBwb2xpY3kgcXVlc3Rpb24gd2hldGhlciB0aGF0 IHdvdWxkIGFjdHVhbGx5IHJlcXVpcmUgYW4gUkZDIHVwZGF0ZSBvciBlcnJhdGEuDQoNCk9uIE5v diAyNSwgMjAwOSwgYXQgNjoxNCBQTSwgVGhvbXNvbiwgTWFydGluIHdyb3RlOg0KDQoNClV3ZSwN Cg0KQ2FuIEkgc3VnZ2VzdCB0aGF0IHlvdSBzdWJtaXQgZXJyYXRhIG9uIDQ4MjY/ICBUaGF0IGlz IHRoZSB1c3VhbCBtZXRob2Qgd2UgdXNlIHRvIHJlc29sdmUgYWN0dWFsIGVycm9ycy4NCg0KVG8g ZGF0ZSwgdGhlIHBvbGljeSBoYXMgYmVlbiB0byBOT1QgdXNlIHNjaGVtYUxvY2F0aW9uIGluIFJG Q3MuICBXZeKAmXZlIGhhZCBhIGxvdCBvZiBkaXNjdXNzaW9uIG9uIHRoZSBtZXJpdHMgKGFuZCBk aXNhZHZhbnRhZ2VzKSBvZiBwdXR0aW5nIHNjaGVtYUxvY2F0aW9uIGF0dHJpYnV0ZXMgaW4gZmls ZXMuICBPdXIgZGlzY3Vzc2lvbnMgY29uY2VudHJhdGVkIG9uIHRoYXQgYXNwZWN0LiAgSWYgdGhl cmUgaXMgYSBjYXNlIGZvciBkb2luZyBzbywgdGhlbiBJQU5BIG5lZWQgdG8gYmUgdGhlIG9uZXMg dGhhdCBhY2NlcHQgdGhlIHJlc3BvbnNpYmlsaXR5IGZvciBtYWludGFpbmluZyBzY2hlbWEgVVJM cywgc2luY2UgUkZDcyB3aWxsIG5vdC4NCg0KLS1NYXJ0aW4NCg0KRnJvbTogc2ltcGxlLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOnNpbXBsZS1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnNpbXBs ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmF1c2NoZW5iYWNoLCBVd2UgKE5TTiAt IERFL011bmljaCkNClNlbnQ6IFRodXJzZGF5LCAyNiBOb3ZlbWJlciAyMDA5IDQ6MzIgQU0NClRv OiBleHQgQmVuIENhbXBiZWxsOyBMb3Vpc2UuQ2xhcmtlQGZvcmFwb2xpcy5jb208bWFpbHRvOkxv dWlzZS5DbGFya2VAZm9yYXBvbGlzLmNvbT47IFNpbXBsZSBXRzsgRGVhbiBXaWxsaXMNClN1Ympl Y3Q6IFJlOiBbU2ltcGxlXSBMaWFpc29uIFN0YXRlbWVudCBmcm9tIHRoZSBPcGVuIE1vYmlsZSBB bGxpYW5jZQ0KDQpIaSBCZW4sDQoNCnRoYW5rcyBmb3IgbW92aW5nIHRoaXMgZm9yd2FyZC4gQXMg dGhlIGF1dGhvciBvZiB0aGUgTFMsIGxldCBtZSBwcm92aWRlIHNvbWUgY2xhcmlmaWNhdGlvbi4N Cg0KVGhlIExTIHN0YXRlczoNCg0KVmFsaWRhdGlvbiBwcm9ibGVtcyBpbiB1cm46aWV0ZjpwYXJh bXM6eG1sOm5zOnJscy1zZXJ2aWNlcyBTY2hlbWEgYXMgYXZhaWxhYmxlIGZyb20gWzNdDQoNClRo aXMgWE1MIHNjaGVtYSBpbXBvcnRzIHRoZSByZXNvdXJjZS1saXN0cyBzY2hlbWEsIGhvd2V2ZXIg ZG9lcyBub3QgcHJvdmlkZSBhIHNjaGVtYSBsb2NhdGlvbiBmb3IgaXQuIER1ZSB0byB0aGlzLCB0 aGUgcmxzLXNlcnZpY2VzIHNjaGVtYSBkb2VzIG5vdCB2YWxpZGF0ZSBiZWNhdXNlIHRoZSB2YWxp ZGF0b3IgY2FuIG5vdCBmZXRjaCB0aGUgcmVmZXJlbmNlZCBzY2hlbWEuIEl0IGlzIHRoZXJlZm9y ZSBzdWdnZXN0ZWQgdG8gYWRkIGEgc2NoZW1hTG9jYXRpb24gYXR0cmlidXRlIHRvIHRoZSA8aW1w b3J0PiBkZWNsYXJhdGlvbiBvZiB0aGUgcmxzLXNlcnZpY2VzIFhNTCBzY2hlbWEgaW5zdGFuY2Ug aW4gdGhlIElBTkEgcmVwb3NpdG9yeS4NClszXSBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1l bnRzL3htbC1yZWdpc3RyeS9zY2hlbWEvcmxzLXNlcnZpY2VzLnhzZA0KDQpJIGhhdmUgY3Jvc3Mt Y2hlY2tlZCBhbmQgaW5kZWVkIG5laXRoZXIgdGhlIHNjaGVtYSBpbiBJQU5BIHJlcG9zaXRvcnkg bm9yIHRoZSBvbmUgaW4gdGhlIFJGQyBjb250YWlucyBhbiA8aW1wb3J0PiBzdGF0ZW1lbnQuIFNv LCB0aGUgdGV4dCBpbiB0aGUgTFMgaXMgbm90IDEwMCUgY29ycmVjdCBidXQgaXRzIHNwaXJpdCBp cyB0aGF0IE9NQSByZXF1ZXN0cyB0byBtYWtlIHN1cmUgdGhhdCB2YWxpZGF0b3JzIHRoYXQgdXNl IHRoaXMgc2NoZW1hIHdpbGwgYmUgaW5mb3JtZWQgYWJvdXQgdGhlIGFkZGl0aW9uYWwgc2NoZW1h IG5lZWRlZCBmb3IgdmFsaWRhdGlvbiBhbmQgaXRzIGxvY2F0aW9uLiBOb3RlIHRoYXQgYSBzaW1p bGFyIDxpbXBvcnQ+IGRlY2xhcmF0aW9uIChpbmNsdWRpbmcgYSBzY2hlbWFMb2NhdGlvbiBhdHRy aWJ1dGUpIGlzIGNvbnRhaW5lZCBpbiB0aGUgWE1MIHNjaGVtYSBmb3IgcmVzb3VyY2UtbGlzdHMg KGl0IGltcG9ydHMgdGhlIHN0YW5kYXJkIFhNTCBuYW1lc3BhY2UpLg0KDQpCYXNlZCBvbiB0aGUg c2NoZW1hIGZvciBybHMtc2VydmljZXMgaW4gUkZDNDgyNiwgdGhlIExTIHNob3VsZCBoYXZlIHN0 YXRlZDoNClRoZSBybHMtc2VydmljZXMgWE1MIHNjaGVtYSByZWZlcmVuY2VzIHRoZSByZXNvdXJj ZS1saXN0cyBzY2hlbWEgbmFtZXNwYWNlLCBob3dldmVyIG5laXRoZXIgaW1wb3J0cyB0aGUgc2No ZW1hIG5vciBwcm92aWRlcyBhIHNjaGVtYSBsb2NhdGlvbiBmb3IgaXQuIER1ZSB0byB0aGlzLCB0 aGUgcmxzLXNlcnZpY2VzIHNjaGVtYSBkb2VzIG5vdCB2YWxpZGF0ZSBiZWNhdXNlIHRoZSB2YWxp ZGF0b3IgY2FuIG5vdCBmZXRjaCB0aGUgcmVmZXJlbmNlZCBzY2hlbWEuIEl0IGlzIHRoZXJlZm9y ZSBzdWdnZXN0ZWQgdG8gYWRkIHRoZSBtaXNzaW5nIDxpbXBvcnQ+IGRlY2xhcmF0aW9uIChpbmNs dWRpbmcgYSBzY2hlbWFMb2NhdGlvbiBhdHRyaWJ1dGUpIHRvIHRoZSBybHMtc2VydmljZXMgWE1M IHNjaGVtYSBpbnN0YW5jZSBpbiB0aGUgSUFOQSByZXBvc2l0b3J5Lg0KDQpTb3JyeSBhYm91dCB0 aGUgY29uZnVzaW9uIGNhdXNlZCwgYW5kIGdvb2QgY2F0Y2guDQoNCktpbmQgcmVnYXJkcywNClV3 ZQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBzaW1wbGUtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ltcGxlLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86c2lt cGxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgQmVuIENhbXBiZWxsDQpTZW50 OiBGcmlkYXksIE5vdmVtYmVyIDIwLCAyMDA5IDEwOjA2IFBNDQpUbzogTG91aXNlLkNsYXJrZUBm b3JhcG9saXMuY29tPG1haWx0bzpMb3Vpc2UuQ2xhcmtlQGZvcmFwb2xpcy5jb20+OyBTaW1wbGUg V0c7IERlYW4gV2lsbGlzDQpTdWJqZWN0OiBSZTogW1NpbXBsZV0gTGlhaXNvbiBTdGF0ZW1lbnQg ZnJvbSB0aGUgT3BlbiBNb2JpbGUgQWxsaWFuY2UNCkRpZ2dpbmcgYSBsaXR0bGUgZGVlcGVyLCBJ IGhhdmUgYSBxdWVzdGlvbiBhYm91dCB0aGUgc2NoZW1hTG9jYXRpb24gcmVxdWVzdCBpbiB0aGUg bGlhaXNvbiBzdGF0ZW1lbnQ6DQoNClRoZSBzdGF0ZW1lbnQgcHJvcG9zZXMgYWRkaW5nIGEgc2No ZW1hTG9jYXRpb24gYXR0cmlidXRlIHRvIHRoZSA8aW1wb3J0PiBlbGVtZW50IHRoYXQgaW1wb3J0 cyB0aGUgcmVzb3VyY2UtbGlzdCBzY2hlbWEgaW50byB0aGUgUkxTLVNlcnZpY2VzICBzY2hlbWEu IEJ1dCBvbiBpbnNwZWN0aW9uLCB0aGVyZSBpcyBubyA8aW1wb3J0PiBlbGVtZW50IHdoYXRzb2V2 ZXIgaW4gdGhlIHJscy1zZXJ2aWNlcyBzY2hlbWEuIEhvd2V2ZXIsIHRoZSA8c2NoZW1hPiBlbGVt ZW50IGRvZXMgY29udGFpbiBhIG5hbWVzcGFjZSBkZWNsYXJhdGlvbiB0aGF0IHJlZmVyZW5jZXMg cmVzb3VyY2UtbGlzdC4gV2FzIHRoZSBsaWFpc29uIHN0YXRlbWVudCBpbnRlbmRlZCB0byByZXF1 ZXN0IHdlIGFkZCBzY2hlbWFMb2NhdGlvbiB0byB0aGUgbmFtZXNwYWNlIGRlY2xhcmF0aW9uPw0K DQpPciBhbSBJIG1pc3Npbmcgc29tZXRoaW5nPw0KDQpPbiBOb3YgMTgsIDIwMDksIGF0IDc6MzEg UE0sIEJlbiBDYW1wYmVsbCB3cm90ZToNCg0KDQoNCjxpbmRpdmlkdWFsPg0KDQpBbmQgdGhlIHRo aW5nIHRoZXkgYXJlIGFza2luZyBmb3Igd291bGQgZ2VuZXJhbGx5IF9ub3RfIG1ha2Ugc2Vuc2Ug dG8gcHV0IGluIGFuIFJGQywgdW5sZXNzIHdlIGFyZSB3aWxsaW5nIHRvIGVuc3VyZSB0aGUgVVJM IHRvIHRoZSBzY2hlbWEgbGl2ZXMgZm9yZXZlci4NCg0KT24gTm92IDE4LCAyMDA5LCBhdCA3OjE0 IFBNLCBIaXNoYW0gS2hhcnRhYmlsIHdyb3RlOg0KDQoNCg0KPGFzIGluZGl2aWR1YWw+DQoNCk5v IGlzc3VlcyBpbiBjb3JyZWN0aW5nIHRoZSBJQU5BIHBhZ2VzLCBidXQgd2UgY2FuJ3QgbWFrZSBt b2RpZmljYXRpb25zIG9yIGV4dGVuc2lvbnMgdG8gYSBzY2hlbWEgcHVibGlzaGVkIGluIGFuIFJG QyB1bmxlc3MgdGhlIGV4dGVuc2lvbiBpcyBkb2N1bWVudGVkIGFuZCBwdWJsaXNoZWQuDQoNClRo YW5rcywNCkhpc2hhbQ0KMjAwOS8xMS8xOSBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbTxt YWlsdG86YmVuQG5vc3RydW0uY29tPj4NCjxjaGFpcj4NCldlJ3ZlIGhhZCBhIHNtYWxsIGFtb3Vu dCBvZiBvbi1saXN0IGRpc2N1c3Npb24uIEZyb20gdGhlIGVtYWlscyBzbyBmYXIgSSBnYXRoZXIg dGhhdCB0aGVyZSBhcmUgbm8gb2JqZWN0aW9ucyB0byBjb3JyZWN0aW5nIHRoZSBzY2hlbWEgYXMg cHVibGlzaGVkIGJ5IElBTkEgdG8gbWF0Y2ggdGhvc2UgZnJvbSBSRkMgNDgyNi4gSG93ZXZlciwg dGhlcmUgaGF2ZSBiZWVuIHNvbWUgb2JqZWN0aW9ucyB0byBhZGRpbmcgdGhlIFNjaGVtYUxvY2F0 aW9uIHBhcmFtZXRlcnMgYXMgcmVxdWVzdGVkIGluIHRoZSBsaWFpc29uIHN0YXRlbWVudC4NCg0K RXZlcnlvbmUtLXBsZWFzZSB0YWtlIGEgbG9vayBhdCB0aGUgbGlhaXNvbiBzdGF0ZW1lbnQgYW5k IG9mZmVyIHlvdXIgb3BpbmlvbnMuIEV2ZW4gIm1lIHRvbyIgY29tbWVudHMgd291bGQgYmUgaGVs cGZ1bCBhdCB0aGlzIHBvaW50LiBJdCdzIGJlZW4gYWxtb3N0IHR3byBtb250aHMgc2luY2UgT01B IHNlbnQgdGhlIGxpYWlzb24gc3RhdGVtZW50LCBhbmQgd2UgbmVlZCB0byByZXNwb25kIHRvIGl0 IEFTQVAuDQoNClRoYW5rcyENCg0KQmVuLg0KDQo8L2NoYWlyPg0KDQoNCk9uIE9jdCAyLCAyMDA5 LCBhdCAxOjEyIFBNLCBCZW4gQ2FtcGJlbGwgd3JvdGU6DQoNCj4gKGFzIFNJTVBMRSBjby1jaGFp cikNCj4NCj4gT01BIHNlbnQgYSBsaWFpc29uIHN0YXRlbWVudCB0byB0aGUgU0lNUExFIHdvcmtp bmcgZ3JvdXAuIFRoZSBzdGF0ZW1lbnQncyBvdmVydmlldyByZWFkcyBhcyBmb2xsb3dzOg0KPg0K PiAiVGhpcyBMaWFpc29uIFN0YXRlbWVudCByZXBvcnRzIFhNTCB2YWxpZGF0aW9uIHByb2JsZW1z IGluIHRoZSBYTUwgc2NoZW1hcyB0aGF0IHdlcmUgaW50cm9kdWNlZCBpbiBSRkMgNDgyNiBhbmQg YXNrcyBmb3IgY29ycmVjdGlvbi4iDQo+DQo+IFBsZWFzZSByZWFkIHRoZSBMUywgYW5kIHNlbmQg eW91ciBvcGluaW9ucyB0byB0aGUgU0lNUExFIGxpc3QuIEEgUERGICBpcyBhdmFpbGFibGUgYXRo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvY3VtZW50cy9MSUFJU09OL2ZpbGU3MDcucGRm DQo+DQo+IFRoYW5rcyENCj4NCj4gQmVuLg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBTaW1wbGUgbWFpbGluZyBsaXN0DQo+IFNpbXBsZUBpZXRm Lm9yZzxtYWlsdG86U2ltcGxlQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpbXBsZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KU2ltcGxlIG1haWxpbmcgbGlzdA0KU2ltcGxlQGlldGYub3JnPG1haWx0 bzpTaW1wbGVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NpbXBsZQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpTaW1wbGUgbWFpbGluZyBsaXN0DQpTaW1wbGVAaWV0Zi5vcmc8bWFpbHRvOlNpbXBsZUBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ltcGxlDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTaW1wbGUg bWFpbGluZyBsaXN0DQpTaW1wbGVAaWV0Zi5vcmc8bWFpbHRvOlNpbXBsZUBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ltcGxlDQoNCg== --_000_8B0A9FCBB9832F43971E38010638454F01D648F1FDSISPE7MB1comm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9VVRGLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDov L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KDQo8bWV0YSBuYW1lPUdlbmVy YXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8YmFz ZSBocmVmPSJ4LW1zZzovLzI3LyI+DQo8IS0tW2lmICFtc29dPg0KPHN0eWxlPg0Kdlw6KiB7YmVo YXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZN TCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlv cjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPg0KPCFbZW5kaWZdLS0+DQo8c3R5bGU+DQo8 IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjAgMTEgNSAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpIZWx2ZXRpY2EtQm9sZDsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCiAvKiBT dHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBtbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowbW07DQoJbXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MG1tOw0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLmFwcGxl LXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLmFw cGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3Bh Y2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMjQ0MDYxO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpT ZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tQVUgbGluaz1i bHVlIHZsaW5rPXB1cnBsZSBzdHlsZT0nd29yZC13cmFwOiBicmVhay13b3JkOw0KLXdlYmtpdC1u YnNwLW1vZGU6IHNwYWNlOy13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2UnPg0K DQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNv bG9yOiMyNDQwNjEnPkkgdGhpbmsgdGhhdCBhbiBlcnJhdGEgbmVlZHMgdG8gYmUgcmFpc2VkIHRv IHJlc29sdmUgdGhlIGltcG9ydA0KaXNzdWU7IEnigJltIGhhcHB5IHRvIHJhaXNlIHRoaXMgbXlz ZWxmLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQpjb2xvcjojMjQ0MDYxJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+SXQgd291bGQgYmUgcG9zc2libGUg dG8gcHV0IHNjaGVtYUxvY2F0aW9uIGluIFJGQ3MsIGJ1dCB0aGF04oCZcw0KYW4gSUVURiBwb2xp Y3kgaXNzdWUgdGhhdCB3ZeKAmWQgaGF2ZSB0byBkaXNjdXNzIHdpdGggdGhlIFhNTCBleHBlcnRz IGFuZA0KcHJvYmFibHkgd2l0aCBJQU5BLCBzaW5jZSB0aGV5IHdvdWxkIGhhdmUgdG8gbWFpbnRh aW4gdGhlIGRvY3VtZW50cyB0aGF0IHRoZQ0KbGlua3MgcmVmZXIgdG8uwqAgVG8gZGF0ZSwgdGhl IHBvbGljeSBoYXMgYmVlbiB0byBhdm9pZCB0aGlzLCBidXQgdGhhdCBkb2VzbuKAmXQNCm1lYW4g dGhhdCB0aGUgcG9saWN5IGNhbuKAmXQgYmUgY2hhbmdlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9y OiMyNDQwNjEnPi0tTWFydGluPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMyNDQwNjEnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBtbSAwbW0gMG1tIDQuMHB0Jz4NCg0KPGRpdj4NCg0KPGRpdiBzdHlsZT0nYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMG1t IDBtbSAwbW0nPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToNCiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 DQpmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBCZW4gQ2FtcGJlbGwgW21haWx0 bzpiZW5AZXN0YWNhZG8ubmV0XSA8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIDI2IE5vdmVt YmVyIDIwMDkgMTozNSBQTTxicj4NCjxiPlRvOjwvYj4gVGhvbXNvbiwgTWFydGluPGJyPg0KPGI+ Q2M6PC9iPiBSYXVzY2hlbmJhY2gsIFV3ZSAoTlNOIC0gREUvTXVuaWNoKTsgTG91aXNlLkNsYXJr ZUBmb3JhcG9saXMuY29tOw0KU2ltcGxlIFdHOyBEZWFuIFdpbGxpczxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW1NpbXBsZV0gTGlhaXNvbiBTdGF0ZW1lbnQgZnJvbSB0aGUgT3BlbiBNb2JpbGUg QWxsaWFuY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+VW5sZXNzIEkgbWlzdW5kZXJzdGFuZCwgdGhlIHN0YXRlbWVudCBpcyBub3Qg YXNraW5nIGZvciBhbg0KdXBkYXRlIHRvIHRoZSBSRkMtLWl0J3MgYXNraW5nIGZvciBhbiB1cGRh dGUgdG8gdGhlIElBTkEgcHVibGlzaGVkIHZlcnNpb24uDQpJdCdzIGFuIElFVEYgcG9saWN5IHF1 ZXN0aW9uIHdoZXRoZXIgdGhhdCB3b3VsZCBhY3R1YWxseSByZXF1aXJlIGFuIFJGQyB1cGRhdGUN Cm9yIGVycmF0YS48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPk9uIE5vdiAyNSwgMjAwOSwgYXQgNjoxNCBQTSwgVGhvbXNvbiwgTWFydGluIHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wPg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMyNDQwNjEnPlV3ZSw8L3NwYW4+PG86cD48L286 cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN CmNvbG9yOiMyNDQwNjEnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoN CjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+Q2Fu IEkgc3VnZ2VzdCB0aGF0IHlvdSBzdWJtaXQgZXJyYXRhIG9uIDQ4MjY/Jm5ic3A7IFRoYXQgaXMg dGhlDQp1c3VhbCBtZXRob2Qgd2UgdXNlIHRvIHJlc29sdmUgYWN0dWFsIGVycm9ycy48L3NwYW4+ PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCmNvbG9yOiMyNDQwNjEnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0K PC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0 NDA2MSc+VG8gZGF0ZSwgdGhlIHBvbGljeSBoYXMgYmVlbiB0byBOT1QgdXNlIHNjaGVtYUxvY2F0 aW9uIGluDQpSRkNzLiZuYnNwOyBXZeKAmXZlIGhhZCBhIGxvdCBvZiBkaXNjdXNzaW9uIG9uIHRo ZSBtZXJpdHMgKGFuZCBkaXNhZHZhbnRhZ2VzKSBvZg0KcHV0dGluZyBzY2hlbWFMb2NhdGlvbiBh dHRyaWJ1dGVzIGluIGZpbGVzLiZuYnNwOyBPdXIgZGlzY3Vzc2lvbnMgY29uY2VudHJhdGVkDQpv biB0aGF0IGFzcGVjdC4mbmJzcDsgSWYgdGhlcmUgaXMgYSBjYXNlIGZvciBkb2luZyBzbywgdGhl biBJQU5BIG5lZWQgdG8gYmUgdGhlDQpvbmVzIHRoYXQgYWNjZXB0IHRoZSByZXNwb25zaWJpbGl0 eSBmb3IgbWFpbnRhaW5pbmcgc2NoZW1hIFVSTHMsIHNpbmNlIFJGQ3MNCndpbGwgbm90Ljwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K DQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjoj MjQ0MDYxJz4tLU1hcnRpbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBtbSAwbW0gMG1tIDQuMHB0Ow0K Ym9yZGVyLXdpZHRoOmluaXRpYWw7Ym9yZGVyLWNvbG9yOmluaXRpYWwnPg0KDQo8ZGl2Pg0KDQo8 ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwbW0gMG1tIDBtbTsNCmJvcmRlci13aWR0aDppbml0aWFsO2JvcmRlci1jb2xv cjppbml0aWFsJz4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6DQoiVGFob21hIiwic2Fu cy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3Bh Y2U+PHNwYW4NCmxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuDQpsYW5nPUVO LVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIic+PGENCmhyZWY9Im1haWx0bzpzaW1wbGUtYm91bmNlc0BpZXRmLm9yZyI+c2ltcGxlLWJv dW5jZXNAaWV0Zi5vcmc8L2E+PHNwYW4NCmNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJz cDs8L3NwYW4+W21haWx0bzpzaW1wbGUtYm91bmNlc0BpZXRmLm9yZ108c3Bhbg0KY2xhc3M9YXBw bGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48Yj5PbiBCZWhhbGYgT2Y8c3Bhbg0KY2xh c3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48L2I+UmF1c2NoZW5iYWNoLCBV d2UgKE5TTiAtDQpERS9NdW5pY2gpPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9YXBwbGUt Y29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj5UaHVyc2RheSwgMjYNCk5vdmVtYmVyIDIwMDkg NDozMiBBTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+ Jm5ic3A7PC9zcGFuPmV4dCBCZW4gQ2FtcGJlbGw7PHNwYW4NCmNsYXNzPWFwcGxlLWNvbnZlcnRl ZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGENCmhyZWY9Im1haWx0bzpMb3Vpc2UuQ2xhcmtlQGZvcmFw b2xpcy5jb20iPkxvdWlzZS5DbGFya2VAZm9yYXBvbGlzLmNvbTwvYT47DQpTaW1wbGUgV0c7IERl YW4gV2lsbGlzPGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVk LXNwYWNlPiZuYnNwOzwvc3Bhbj5SZTogW1NpbXBsZV0NCkxpYWlzb24gU3RhdGVtZW50IGZyb20g dGhlIE9wZW4gTW9iaWxlIEFsbGlhbmNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4N Cg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7 PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7DQpjb2xvcjpibHVlJz5IaSBCZW4sPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0K DQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQpjb2xvcjpibHVlJz50aGFua3Mg Zm9yIG1vdmluZyB0aGlzIGZvcndhcmQuIEFzIHRoZSBhdXRob3Igb2YgdGhlIExTLCBsZXQgbWUN CnByb3ZpZGUgc29tZSBjbGFyaWZpY2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPC9k aXY+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5i c3A7PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPGRpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KY29sb3I6Ymx1ZSc+VGhlIExTIHN0YXRlczo8 L3NwYW4+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPGRp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4N Cg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiSGVsdmV0aWNhLUJvbGQiLCJz ZXJpZiInPlZhbGlkYXRpb24NCnByb2JsZW1zIGluIHVybjppZXRmOnBhcmFtczp4bWw6bnM6cmxz LXNlcnZpY2VzIFNjaGVtYSBhcyBhdmFpbGFibGUgZnJvbSBbM108YnI+DQo8YnI+DQo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2Ei LCJzYW5zLXNlcmlmIic+VGhpcw0KWE1MIHNjaGVtYSBpbXBvcnRzIHRoZSByZXNvdXJjZS1saXN0 cyBzY2hlbWEsIGhvd2V2ZXIgZG9lcyBub3QgcHJvdmlkZSBhIHNjaGVtYQ0KbG9jYXRpb24gZm9y IGl0LiBEdWUgdG8gdGhpcywgdGhlIHJscy1zZXJ2aWNlcyBzY2hlbWEgZG9lcyBub3QgdmFsaWRh dGUgYmVjYXVzZQ0KdGhlIHZhbGlkYXRvciBjYW4gbm90IGZldGNoIHRoZSByZWZlcmVuY2VkIHNj aGVtYS4gSXQgaXMgdGhlcmVmb3JlIHN1Z2dlc3RlZCB0bw0KYWRkIGEgc2NoZW1hTG9jYXRpb24g YXR0cmlidXRlIHRvIHRoZSAmbHQ7aW1wb3J0Jmd0OyBkZWNsYXJhdGlvbiBvZiB0aGUgcmxzLXNl cnZpY2VzDQpYTUwgc2NoZW1hIGluc3RhbmNlIGluIHRoZSBJQU5BIHJlcG9zaXRvcnkuPGJyPg0K WzNdPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0nY29sb3I6IzMzMDBGRic+PGENCmhyZWY9Imh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdu bWVudHMveG1sLXJlZ2lzdHJ5L3NjaGVtYS9ybHMtc2VydmljZXMueHNkIj48c3Bhbg0Kc3R5bGU9 J2NvbG9yOmJsYWNrJz5odHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3htbC1yZWdpc3Ry eS9zY2hlbWEvcmxzLXNlcnZpY2VzLnhzZDwvc3Bhbj48L2E+PC9zcGFuPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8cD48c3BhbiBsYW5nPURFIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KY29sb3I6 Ymx1ZSc+SSBoYXZlIGNyb3NzLWNoZWNrZWQgYW5kIGluZGVlZCBuZWl0aGVyIHRoZSBzY2hlbWEg aW4gSUFOQQ0KcmVwb3NpdG9yeSBub3IgdGhlIG9uZSBpbiB0aGUgUkZDIGNvbnRhaW5zIGFuICZs dDtpbXBvcnQmZ3Q7IHN0YXRlbWVudC4gU28sIHRoZQ0KdGV4dCBpbiB0aGUgTFMgaXMgbm90IDEw MCUgY29ycmVjdCBidXQgaXRzIHNwaXJpdCBpcyB0aGF0IE9NQSByZXF1ZXN0cyB0byBtYWtlDQpz dXJlIHRoYXQgdmFsaWRhdG9ycyB0aGF0IHVzZSB0aGlzIHNjaGVtYSB3aWxsIGJlIGluZm9ybWVk IGFib3V0IHRoZSBhZGRpdGlvbmFsDQpzY2hlbWEgbmVlZGVkIGZvciB2YWxpZGF0aW9uIGFuZCBp dHMgbG9jYXRpb24uIE5vdGUgdGhhdCBhIHNpbWlsYXINCiZsdDtpbXBvcnQmZ3Q7IGRlY2xhcmF0 aW9uIChpbmNsdWRpbmcgYSBzY2hlbWFMb2NhdGlvbiBhdHRyaWJ1dGUpIGlzIGNvbnRhaW5lZA0K aW4gdGhlIFhNTCBzY2hlbWEgZm9yIHJlc291cmNlLWxpc3RzIChpdCBpbXBvcnRzIHRoZSBzdGFu ZGFyZCBYTUwgbmFtZXNwYWNlKS4gJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cD48 c3BhbiBsYW5nPURFIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiOw0KY29sb3I6Ymx1ZSc+QmFzZWQgb24gdGhlIHNjaGVtYSBmb3IgcmxzLXNl cnZpY2VzIGluIFJGQzQ4MjYsIHRoZSBMUzxzcGFuDQpjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3Bh Y2U+Jm5ic3A7PC9zcGFuPjxzdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiJz5zaG91bGQ8L3NwYW4+PC9zdHJvbmc+PHNwYW4NCmNsYXNzPWFwcGxlLWNv bnZlcnRlZC1zcGFjZT48Yj4mbmJzcDs8L2I+PC9zcGFuPmhhdmUgc3RhdGVkOjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IGxhbmc9REUgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIs InNhbnMtc2VyaWYiJz5UaGU8c3Bhbg0KY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6cmVkJz5ybHMtc2VydmljZXM8L3NwYW4+Jm5ic3A7 WE1MDQpzY2hlbWE8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSdjb2xvcjpyZWQnPnJlZmVyZW5jZXM8L3NwYW4+PHNwYW4NCmNsYXNzPWFw cGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+dGhlIHJlc291cmNlLWxpc3RzIHNjaGVt YTxzcGFuDQpjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSdjb2xvcjpyZWQnPm5hbWVzcGFjZTwvc3Bhbj4sDQpob3dldmVyPHNwYW4gY2xhc3M9YXBw bGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6cmVkJz5u ZWl0aGVyDQppbXBvcnRzIHRoZSBzY2hlbWEgbm9yPC9zcGFuPjxzcGFuIGNsYXNzPWFwcGxlLWNv bnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+cHJvdmlkZTxzcGFuDQpzdHlsZT0nY29sb3I6cmVk Jz5zPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48L3NwYW4+ YQ0Kc2NoZW1hIGxvY2F0aW9uIGZvciBpdC4gRHVlIHRvIHRoaXMsIHRoZSBybHMtc2VydmljZXMg c2NoZW1hIGRvZXMgbm90IHZhbGlkYXRlDQpiZWNhdXNlIHRoZSB2YWxpZGF0b3IgY2FuIG5vdCBm ZXRjaCB0aGUgcmVmZXJlbmNlZCBzY2hlbWEuIEl0IGlzIHRoZXJlZm9yZQ0Kc3VnZ2VzdGVkIHRv IGFkZCZuYnNwOzxzcGFuIHN0eWxlPSdjb2xvcjpyZWQnPnRoZSBtaXNzaW5nPC9zcGFuPjxzcGFu DQpjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPiZsdDtpbXBvcnQmZ3Q7 Jm5ic3A7ZGVjbGFyYXRpb24mbmJzcDs8c3Bhbg0Kc3R5bGU9J2NvbG9yOnJlZCc+KGluY2x1ZGlu ZyBhIHNjaGVtYUxvY2F0aW9uIGF0dHJpYnV0ZSkgdG88L3NwYW4+PHNwYW4NCmNsYXNzPWFwcGxl LWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+dGhlIHJscy1zZXJ2aWNlcyBYTUwgc2NoZW1h IGluc3RhbmNlDQppbiB0aGUgSUFOQSByZXBvc2l0b3J5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N Cg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8cD48c3BhbiBsYW5nPURFIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KY29sb3I6Ymx1ZSc+U29y cnkgYWJvdXQgdGhlIGNvbmZ1c2lvbiBjYXVzZWQsIGFuZCBnb29kIGNhdGNoLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCg0KPHA+PHNwYW4gbGFuZz1ERSBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOmJsdWUnPktpbmQgcmVnYXJk cyw8YnI+DQpVd2U8L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2 Pg0KDQo8YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBtbSAwbW0gMG1tIDQuMHB0Ow0KbWFyZ2luLWxlZnQ6My43NXB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBtbTttYXJnaW4tYm90dG9tOjUuMHB0Ow0KYm9y ZGVyLXdpZHRoOmluaXRpYWw7Ym9yZGVyLWNvbG9yOmluaXRpYWwnPg0KDQo8ZGl2Pg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2IGNs YXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48c3Bh biBsYW5nPURFPg0KDQo8aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXI+DQoNCjwv c3Bhbj48L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEy LjBwdCc+PGI+PHNwYW4gbGFuZz1ERQ0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4NCmNsYXNzPWFw cGxlLWNvbnZlcnRlZC1zcGFjZT48c3BhbiBsYW5nPURFIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5Og0KIlRhaG9tYSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PC9zcGFu PjxzcGFuIGxhbmc9REUgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiInPjxhIGhyZWY9Im1haWx0bzpzaW1wbGUtYm91bmNlc0BpZXRmLm9y ZyI+c2ltcGxlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PHNwYW4NCmNsYXNzPWFwcGxlLWNvbnZlcnRl ZC1zcGFjZT4mbmJzcDs8L3NwYW4+W21haWx0bzpzaW1wbGUtYm91bmNlc0BpZXRmLm9yZ108c3Bh bg0KY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48Yj5PbiBCZWhhbGYg T2Y8c3Bhbg0KY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48L2I+ZXh0 IEJlbiBDYW1wYmVsbDxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRl ZC1zcGFjZT4mbmJzcDs8L3NwYW4+RnJpZGF5LCBOb3ZlbWJlciAyMCwNCjIwMDkgMTA6MDYgUE08 YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwv c3Bhbj48YQ0KaHJlZj0ibWFpbHRvOkxvdWlzZS5DbGFya2VAZm9yYXBvbGlzLmNvbSI+TG91aXNl LkNsYXJrZUBmb3JhcG9saXMuY29tPC9hPjsNClNpbXBsZSBXRzsgRGVhbiBXaWxsaXM8YnI+DQo8 Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9z cGFuPlJlOiBbU2ltcGxlXQ0KTGlhaXNvbiBTdGF0ZW1lbnQgZnJvbSB0aGUgT3BlbiBNb2JpbGUg QWxsaWFuY2U8L3NwYW4+PG86cD48L286cD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD5EaWdnaW5nIGEgbGl0dGxlIGRlZXBlciwgSSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgdGhl DQpzY2hlbWFMb2NhdGlvbiByZXF1ZXN0IGluIHRoZSBsaWFpc29uIHN0YXRlbWVudDo8bzpwPjwv bzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8 ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+VGhlIHN0YXRlbWVudCBwcm9wb3NlcyBhZGRpbmcg YSBzY2hlbWFMb2NhdGlvbiBhdHRyaWJ1dGUgdG8NCnRoZSAmbHQ7aW1wb3J0Jmd0OyBlbGVtZW50 IHRoYXQgaW1wb3J0cyB0aGUgcmVzb3VyY2UtbGlzdCBzY2hlbWEgaW50byB0aGUNClJMUy1TZXJ2 aWNlcyAmbmJzcDtzY2hlbWEuIEJ1dCBvbiBpbnNwZWN0aW9uLCB0aGVyZSBpcyBubyAmbHQ7aW1w b3J0Jmd0Ow0KZWxlbWVudCB3aGF0c29ldmVyIGluIHRoZSBybHMtc2VydmljZXMgc2NoZW1hLiBI b3dldmVyLCB0aGUgJmx0O3NjaGVtYSZndDsNCmVsZW1lbnQgZG9lcyBjb250YWluIGEgbmFtZXNw YWNlIGRlY2xhcmF0aW9uIHRoYXQgcmVmZXJlbmNlcyByZXNvdXJjZS1saXN0LiBXYXMNCnRoZSBs aWFpc29uIHN0YXRlbWVudCBpbnRlbmRlZCB0byByZXF1ZXN0IHdlIGFkZCBzY2hlbWFMb2NhdGlv biB0byB0aGUNCm5hbWVzcGFjZSBkZWNsYXJhdGlvbj88bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+ DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7 PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPGRpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPk9yIGFtIEkgbWlzc2luZyBzb21ldGhpbmc/PG86cD48L286cD48 L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPGRpdj4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPk9uIE5vdiAxOCwgMjAwOSwgYXQgNzozMSBQ TSwgQmVuIENhbXBiZWxsIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+ DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD4mbHQ7aW5kaXZpZHVhbCZndDs8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoN CjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86 cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPkFuZCB0aGUgdGhpbmcgdGhleSBhcmUgYXNraW5nIGZvciB3b3VsZCBn ZW5lcmFsbHkgX25vdF8gbWFrZQ0Kc2Vuc2UgdG8gcHV0IGluIGFuIFJGQywgdW5sZXNzIHdlIGFy ZSB3aWxsaW5nIHRvIGVuc3VyZSB0aGUgVVJMIHRvIHRoZSBzY2hlbWENCmxpdmVzIGZvcmV2ZXIu PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPGRpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPC9k aXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5PbiBO b3YgMTgsIDIwMDksIGF0IDc6MTQgUE0sIEhpc2hhbSBLaGFydGFiaWwgd3JvdGU6PG86cD48L286 cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+Jmx0O2FzIGluZGl2aWR1YWwm Z3Q7PGJyPg0KPGJyPg0KTm8gaXNzdWVzIGluIGNvcnJlY3RpbmcgdGhlIElBTkEgcGFnZXMsIGJ1 dCB3ZSBjYW4ndCBtYWtlIG1vZGlmaWNhdGlvbnMgb3INCmV4dGVuc2lvbnMgdG8gYSBzY2hlbWEg cHVibGlzaGVkIGluIGFuIFJGQyB1bmxlc3MgdGhlIGV4dGVuc2lvbiBpcyBkb2N1bWVudGVkDQph bmQgcHVibGlzaGVkLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpIaXNoYW08bzpwPjwvbzpwPjwv cD4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjIwMDkvMTEvMTkgQmVu IENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmVuQG5vc3RydW0uY29tIj5iZW5Abm9zdHJ1 bS5jb208L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPiZsdDtjaGFpciZndDs8YnI+DQpXZSd2ZSBoYWQgYSBzbWFsbCBhbW91bnQg b2Ygb24tbGlzdCBkaXNjdXNzaW9uLiBGcm9tIHRoZSBlbWFpbHMgc28gZmFyIEkgZ2F0aGVyDQp0 aGF0IHRoZXJlIGFyZSBubyBvYmplY3Rpb25zIHRvIGNvcnJlY3RpbmcgdGhlIHNjaGVtYSBhcyBw dWJsaXNoZWQgYnkgSUFOQSB0bw0KbWF0Y2ggdGhvc2UgZnJvbSBSRkMgNDgyNi4gSG93ZXZlciwg dGhlcmUgaGF2ZSBiZWVuIHNvbWUgb2JqZWN0aW9ucyB0byBhZGRpbmcNCnRoZSBTY2hlbWFMb2Nh dGlvbiBwYXJhbWV0ZXJzIGFzIHJlcXVlc3RlZCBpbiB0aGUgbGlhaXNvbiBzdGF0ZW1lbnQuPGJy Pg0KPGJyPg0KRXZlcnlvbmUtLXBsZWFzZSB0YWtlIGEgbG9vayBhdCB0aGUgbGlhaXNvbiBzdGF0 ZW1lbnQgYW5kIG9mZmVyIHlvdXIgb3BpbmlvbnMuDQpFdmVuICZxdW90O21lIHRvbyZxdW90OyBj b21tZW50cyB3b3VsZCBiZSBoZWxwZnVsIGF0IHRoaXMgcG9pbnQuIEl0J3MgYmVlbg0KYWxtb3N0 IHR3byBtb250aHMgc2luY2UgT01BIHNlbnQgdGhlIGxpYWlzb24gc3RhdGVtZW50LCBhbmQgd2Ug bmVlZCB0byByZXNwb25kDQp0byBpdCBBU0FQLjxicj4NCjxicj4NClRoYW5rcyE8YnI+DQo8YnI+ DQpCZW4uPGJyPg0KPGJyPg0KJmx0Oy9jaGFpciZndDs8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+ DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48YnI+DQo8 YnI+DQpPbiBPY3QgMiwgMjAwOSwgYXQgMToxMiBQTSwgQmVuIENhbXBiZWxsIHdyb3RlOjxicj4N Cjxicj4NCiZndDsgKGFzIFNJTVBMRSBjby1jaGFpcik8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPTUEg c2VudCBhIGxpYWlzb24gc3RhdGVtZW50IHRvIHRoZSBTSU1QTEUgd29ya2luZyBncm91cC4gVGhl IHN0YXRlbWVudCdzDQpvdmVydmlldyByZWFkcyBhcyBmb2xsb3dzOjxicj4NCiZndDs8YnI+DQom Z3Q7ICZxdW90O1RoaXMgTGlhaXNvbiBTdGF0ZW1lbnQgcmVwb3J0cyBYTUwgdmFsaWRhdGlvbiBw cm9ibGVtcyBpbiB0aGUgWE1MDQpzY2hlbWFzIHRoYXQgd2VyZSBpbnRyb2R1Y2VkIGluIFJGQyA0 ODI2IGFuZCBhc2tzIGZvciBjb3JyZWN0aW9uLiZxdW90Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFBs ZWFzZSByZWFkIHRoZSBMUywgYW5kIHNlbmQgeW91ciBvcGluaW9ucyB0byB0aGUgU0lNUExFIGxp c3QuIEEgUERGDQombmJzcDtpcyBhdmFpbGFibGUgYXQ8YQ0KaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2N1bWVudHMvTElBSVNPTi9maWxlNzA3LnBkZiINCnRhcmdldD0iX2Js YW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvY3VtZW50cy9MSUFJU09OL2ZpbGU3 MDcucGRmPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5rcyE8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBCZW4uPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxk aXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBTaW1wbGUg bWFpbGluZyBsaXN0PGJyPg0KJmd0OzxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4m bmJzcDs8L3NwYW4+PGENCmhyZWY9Im1haWx0bzpTaW1wbGVAaWV0Zi5vcmciPlNpbXBsZUBpZXRm Lm9yZzwvYT48YnI+DQomZ3Q7PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNw Ozwvc3Bhbj48YQ0KaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z aW1wbGUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpbXBsZTwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NClNpbXBsZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86U2ltcGxlQGlldGYub3JnIj5TaW1wbGVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaW1wbGUiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpbXBsZTwvYT48bzpw PjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxk aXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+ DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286 cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KU2lt cGxlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpTaW1wbGVAaWV0Zi5vcmciPlNp bXBsZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpbXBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaW1wbGU8L2E+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGRpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0K PC9kaXY+DQoNCjwvYmxvY2txdW90ZT4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IkhlbHZl dGljYSIsInNhbnMtc2VyaWYiJz5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NClNpbXBsZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 U2ltcGxlQGlldGYub3JnIj5TaW1wbGVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaW1wbGUiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ltcGxlPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PC9kaXY+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQo= --_000_8B0A9FCBB9832F43971E38010638454F01D648F1FDSISPE7MB1comm_-- From christer.holmberg@ericsson.com Fri Nov 27 03:55:31 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE9D63A69AE for ; Fri, 27 Nov 2009 03:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltfH0qaIo5SW for ; Fri, 27 Nov 2009 03:55:31 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E2D763A697B for ; Fri, 27 Nov 2009 03:55:30 -0800 (PST) X-AuditID: c1b4fb3c-b7b08ae000000935-b6-4b0fbe2c7890 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 3B.08.02357.C2EBF0B4; Fri, 27 Nov 2009 12:55:24 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 12:55:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Nov 2009 12:55:23 +0100 Message-ID: In-Reply-To: <4B05609C.4070400@sipstation.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] WGLC review and comments ondraft-ietf-simple-intradomain-federation-04 Thread-Index: AcppKudF7HXGcjg5TEGABnTpaCps+wGKGBuA References: <4B05609C.4070400@sipstation.com> From: "Christer Holmberg" To: X-OriginalArrivalTime: 27 Nov 2009 11:55:23.0944 (UTC) FILETIME=[80A2D280:01CA6F58] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] WGLC review and comments ondraft-ietf-simple-intradomain-federation-04 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 11:55:32 -0000 =20 Hi, First, my main issue is related to the assumptions about the databases, and claimed advantages of federation over clustering. The draft claims that clustering often requires database replication, and that it is tightly bound with the internal implementation of the product. However, in figure 5 (Partitioned) a database is used. And, in a big domain this database could very well be replicated, which means you have exactly the same issue as for clusters.=20 And, if all the servers communicate with the database anyway, what is the advantage of each server being able to handle only a subset of the users? The same goes for figure 6 (Partitioned) where the routing proxy/proxies would communicate with the database(s). The same goes for figure 7 (Subdomain). If the subdomains are big, the database may be replicated. The same goes for Section 7 (exclusive), and it alwo puts additional requirement on the database. So, should the document contain some assumptions which are made regarding the database(s) used? Second, I am a little confused about section 6.2.4. What is stated may be true, but isn't the reason we are working on things in IETF to solve identified problems and needs? So, shouldn't 6.2.4 instead simply describe how this is done with a peer-to-peer technique. "Today" depends on when someone reads the draft, and what is stated for "today" may not be true tomorrow :) Regards, Christer From ibc@aliax.net Mon Nov 30 08:04:23 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36F2E3A6939 for ; Mon, 30 Nov 2009 08:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.256 X-Spam-Level: X-Spam-Status: No, score=-1.256 tagged_above=-999 required=5 tests=[AWL=-0.816, BAYES_20=-0.74, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Luv06lNwHZ3z for ; Mon, 30 Nov 2009 08:04:22 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 357D73A692F for ; Mon, 30 Nov 2009 08:04:21 -0800 (PST) Received: by ewy6 with SMTP id 6so3060106ewy.29 for ; Mon, 30 Nov 2009 08:04:12 -0800 (PST) Received: by 10.213.102.138 with SMTP id g10mr1813035ebo.19.1259597051480; Mon, 30 Nov 2009 08:04:11 -0800 (PST) Received: from ibc-laptop.localnet ([212.230.46.89]) by mx.google.com with ESMTPS id 23sm6830606eya.11.2009.11.30.08.04.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Nov 2009 08:04:10 -0800 (PST) From: =?utf-8?q?I=C3=B1aki_Baz_Castillo?= To: simple@ietf.org Date: Mon, 30 Nov 2009 17:04:07 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.28-16-generic; KDE/4.3.2; x86_64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <200911301704.07884.ibc@aliax.net> Subject: [Simple] [XCAP] XUI SIP or TEL URI with uri parameters? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 16:04:23 -0000 Hi, does it make sense a XCAP XUI URI with parameters? i.e: GET /pres-rules/users/sip:ibc@domain.org;param=3Daaa/index GET /pres-rules/users/tel:+12345678;param=3Dbbbb/index I wonder the same for the value of the X-XCAP/3GPP-Asserted-Identity header= =2E=20 Theorically the aggregation proxy requires authentication for the HTTP requ= est=20 and after cheking it, the "username" field in the request's credentials is= =20 copied verbatim (including the doble quitation) into the X-XCAP/3GPP-Assert= ed- Identity header. So the question would be: does it make sense a HTTP Digest credentials with= a=20 "username" field containing a SIP/TEL URI with parameters? PS: I hope the reply to both questions is "no" :) Thanks. =2D-=20 I=C3=B1aki Baz Castillo From pkyzivat@cisco.com Mon Nov 30 08:08:25 2009 Return-Path: X-Original-To: simple@core3.amsl.com Delivered-To: simple@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BB183A6912 for ; Mon, 30 Nov 2009 08:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAkIFfQX5wis for ; Mon, 30 Nov 2009 08:08:24 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 36DF53A67A8 for ; Mon, 30 Nov 2009 08:08:24 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAFAEd8E0tAZnwM/2dsb2JhbACZKKhqiHuNdoIvC4F3BI1Q X-IronPort-AV: E=Sophos;i="4.47,314,1257120000"; d="scan'208";a="70975706" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 30 Nov 2009 16:08:16 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAUG8Gm4005804; Mon, 30 Nov 2009 16:08:16 GMT Received: from xfe-rtp-212.amer.cisco.com ([64.102.31.100]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 11:08:16 -0500 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Nov 2009 11:08:16 -0500 Message-ID: <4B13EDF5.5050306@cisco.com> Date: Mon, 30 Nov 2009 11:08:21 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Hisham Khartabil References: <66cd252f0911151915m724a0d0drebd39240c2256b56@mail.gmail.com> <66cd252f0911250255p1da871c3i388708b7017c5ba@mail.gmail.com> In-Reply-To: <66cd252f0911250255p1da871c3i388708b7017c5ba@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Nov 2009 16:08:16.0432 (UTC) FILETIME=[53620300:01CA71D7] Cc: Simple WG Subject: Re: [Simple] Fwd: WGLC on draft-ietf-simple-chat-05.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 16:08:25 -0000 Hisham Khartabil wrote: > Hi Paul, > > Do you think you can give the chat draft a quick wglc review? > > Thanks, > Hisham Hisham, I had missed this. Here is a *quick* review of the document. I do find a few things missing. ISSUES/CONCERNS: Section 5.2: If a participant wants to remain anonymous to the rest of the participants in the conference, the participant's UA can register or acquire by other means a temporary GRUU with the conference focus. The procedure SHOULD follow the recommendation of draft-ietf-sip-gruu [I-D.ietf-sip-gruu]. The temporary GRUU can be used in the From and To header in the 'Message/CPIM' wrapper concealing the participant's SIP AOR from the other participants in the conference. Does this mean REGISTER with the focus server to obtain a gruu? That presumes it will permit such a thing. Because this is somewhat unusual behavior, I think it needs some explanation of what is envisioned. (For instance it seems likely that the client would be registering its *AOR* as a *contact* with the chat room.) Also, this should probably be shown in the call flows. Section 6.1: Do we expect that the sender will always use the same URI used when establishing the dialog with the chat room? Or might it be using something else that must be independently verified by the MSRP switch? (I see later in the examples that they do sometimes differ.) If it can differ, then I assume the switch only allows certain values to be used. So something needs to be said about how this usage is to be verified. If it is the URI used when establishing the dialog, and its an anonymous gruu, then hopefully something will be said about how that is verified as being acceptable if the chat room restricts admission. I gather the expectation is that if its an anonymous gruu, then it isn't just *any* anonymous gruu, but only one that was issued by a registrar associated with the chat room, and the mapping to the actual identity is known. (This is also hinted at in 9.6. But not called out explicitly.) Section 6.3: participants URI associated with a participant. If the URI in the To header can not be resolved (e.g. cased by a mistyped URI or that the recipient has abandoned he chat room), the response error code is 427. The new 427 status code indicates a failure to resolve the recipient URI in the To header field. If the recipient doesn't Why is a new error code required? ISTM that the sip 404 code is appropriate here, and could be borrowed into MSRP rather than inventing a new code. Section 7.1: There is good detail of how to request and be granted use of a nickname. But there is no normative language about how to use the nickname once it has been received, either by the sender or the recipient. This goes back to my earlier question about the relationship between the From in MSRP and the URI used to connect to the focus. I later see in the examples, that the nickname is being combined with the domain name of the focus to create a sip uri (with some escaping being done to make it legal). If that is the intent, then it needs better explanation. On the receiving side, I suppose it is intended that the user part of the URI be rendered as the sender, rather than the full URI. But how would the recipient know to do that? It can't do so with all URIs, so how does it know this one is special? This seems to require more technical work to be fully sorted out. NITS: Section 6.1: An MSRP endpoint that receives a SEND request from the MSRP switch containing a Message/CPIM wrapper SHOULD first inspect the To header field of the Message/CPIM body. If the To header field is set to the chat room URI, it should render it is a regular message that has been s/it should render it is a/it should render it as a/ Section 6.3: participants URI associated with a participant. If the URI in the To header can not be resolved (e.g. cased by a mistyped URI or that the s/cased/caused/ Section 9.2: MSRP d93kswow NICKNAME To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp Use-Nickname: "Alice the great" -------d93kswow$ Figure 7: MSRP NICKNAME request with an initial nickname proposal F2: The MSRP switch analyzes the existing allocation of nicknames and detects that the nickname "Alice is great" is already provided to another participant by the conference. The MSRP switch answers with a 423 response. The nicknames used in the request and response are different.