From iptel-admin@lists.bell-labs.com Fri Sep 1 03:30:33 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06267 for ; Fri, 1 Sep 2000 03:30:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EF1BD44356; Fri, 1 Sep 2000 02:30:22 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 120CB4434C for ; Fri, 1 Sep 2000 02:30:20 -0400 (EDT) Received: from dynamicsoft.com (1Cust105.tnt1.freehold.nj.da.uu.net [63.17.113.105]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA05167; Fri, 1 Sep 2000 03:31:51 -0400 (EDT) Message-ID: <39AF5AC2.1016B520@dynamicsoft.com> Date: Fri, 01 Sep 2000 03:29:06 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Undery Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] supporting CPL versions References: <39A4F1A6.87F7A386@indigosw.com> <39A4F5B4.BD3E3EE2@ubiquity.net> <39A5275C.3AADBE1F@dynamicsoft.com> <39A535F1.48928278@ubiquity.net> <39A5FC2D.F49020AB@dynamicsoft.com> <39A6379C.DCC21EA3@ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit I want to come to closure ASAP on this time-switch issue. James Undery wrote: > > Jonathan Rosenberg wrote: > > > James Undery wrote: > > > > > > > I understand the desire to be compatible with iCal, but I fear that no > > > > one will implement this thing completely, and even fewer folks will > > > > implement it correctly. Is there any way to simplify and retain some > > > > level of interoperability with ical? What if we keep the time and > > > > duration formats, and allow for repition, but eliminate the "by*" > > > > parameters which is most of the nightmare of this thing? > > > > > > > > > > >From a quick first glance this would appear to be a good solution, however, I am > > > less convinced about simplifying recurrence this way, principally because I like > > > the idea of specifying the last concepts like "the last friday of the month". I > > > also understand that compatibility with iCalendar may be nice from a philosophical > > > viewpoint, but, as a CPL implementor it is too complex for my needs and I would > > > prefer to return to something closer to the syntax of draft 01 for time nodes. > > > > I agree, although I'll note that this syntax does not, AFAIK, allow you > > to say things like "the last Friday of every month". > > >From what I can recall there was a suggestion in the "implementation notes" about using > negative numbers in a similar way to the "by*" parameters in version 02. > > > > > We could always add support for iCal style time switches in the next > > revision of CPL, which could then support both. > > This would be nice as I'd like first CPL RFC to be a simple as it need be and then > problems with backward compatibility in future versions would be minimised. (When CPL is > in use and we have a better idea of how it is to be used in practise.) So, is there consensus around this? We keep the time-switch from the older drafts, and then think about defining the iCal one for the next CPL rev once we understand its usage better? Any objections? -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Sep 1 04:22:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06755 for ; Fri, 1 Sep 2000 04:22:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 368A244339; Fri, 1 Sep 2000 03:22:44 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 9C92C44336 for ; Fri, 1 Sep 2000 03:22:38 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA09760; Fri, 1 Sep 2000 09:20:49 +0100 (BST) Message-ID: <39AF66E3.AED1763@ubiquity.net> Date: Fri, 01 Sep 2000 09:20:51 +0100 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: IPTEL Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] CPL log nodes Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, This isn't really a bug, but may I suggest some text be added to 8.2 to the effect of "name SHOULD be a legal filename without any path specification", the reason for this is to prevent the modification of any files outside of the script owners file space. e.g. Could be very bad for security. Also it is questionable how useful log is to anyone outside of administrators and developers of CPL (non UA) servers as the users will require an account on the server and access to the log files, doesn't mail provide a more useful "logging" mechanism for users. Log would appear to be useful for UAs only as is. James Undery _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From mailman-owner@lists.bell-labs.com Fri Sep 1 06:30:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07703 for ; Fri, 1 Sep 2000 06:30:55 -0400 (EDT) From: mailman-owner@lists.bell-labs.com Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B633D44E4C for ; Fri, 1 Sep 2000 05:08:14 -0400 (EDT) Subject: lists.bell-labs.com mailing list memberships reminder To: iptel-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.1 Precedence: bulk List-Id: External Test Mailing List Message-Id: <20000901090814.B633D44E4C@lists.bell-labs.com> Date: Fri, 1 Sep 2000 05:08:14 -0400 (EDT) This is a reminder, sent out once a month, about your lists.bell-labs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, iptel-request@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for iptel-archive@lists.ietf.org: List Password // URL ---- -------- iptel@lists.bell-labs.com Gfcn http://lists.bell-labs.com/mailman/options/iptel/iptel-archive@lists.ietf.org From iptel-admin@lists.bell-labs.com Fri Sep 1 09:40:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11623 for ; Fri, 1 Sep 2000 09:40:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8B6ED44338; Fri, 1 Sep 2000 08:39:57 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id AFCD944336 for ; Fri, 1 Sep 2000 08:26:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Fri Sep 1 09:25:11 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 69C4A44347; Fri, 1 Sep 2000 09:12:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by lists.bell-labs.com (Postfix) with ESMTP id 411A844341 for ; Fri, 1 Sep 2000 09:12:01 -0400 (EDT) Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA29553; Fri, 1 Sep 2000 09:11:57 -0400 (EDT) Message-ID: <39AFAB1E.D73D303D@cs.columbia.edu> Date: Fri, 01 Sep 2000 09:11:58 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: Jonathan Rosenberg Cc: James Undery , iptel@lists.bell-labs.com Subject: Re: [IPTEL] supporting CPL versions References: <39A4F1A6.87F7A386@indigosw.com> <39A4F5B4.BD3E3EE2@ubiquity.net> <39A5275C.3AADBE1F@dynamicsoft.com> <39A535F1.48928278@ubiquity.net> <39A5FC2D.F49020AB@dynamicsoft.com> <39A6379C.DCC21EA3@ubiquity.net> <39AF5AC2.1016B520@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit > > So, is there consensus around this? We keep the time-switch from the > older drafts, and then think about defining the iCal one for the next > CPL rev once we understand its usage better? Any objections? > I'm *very* uncomfortable with this. At the very least, we need to define how CPL can be reasonably extended in the future. Also, if we go that route, I would suggest going for real simplicity, i.e., fixed time range only, as a proper subset of the iCal specification. That will make for a much cleaner transition strategy rather than mixing two models. That way, we have an overall implementation that's simpler. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Sep 1 09:43:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11708 for ; Fri, 1 Sep 2000 09:43:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A245044342; Fri, 1 Sep 2000 08:40:15 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 937B744336 for ; Fri, 1 Sep 2000 08:32:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Sep 1 09:30:06 EDT 2000 Received: by lists.bell-labs.com (Postfix) id DFCC844370; Fri, 1 Sep 2000 09:16:55 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by lists.bell-labs.com (Postfix) with ESMTP id B1A3244341 for ; Fri, 1 Sep 2000 09:16:55 -0400 (EDT) Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA29670; Fri, 1 Sep 2000 09:16:54 -0400 (EDT) Message-ID: <39AFAC48.C3399D1A@cs.columbia.edu> Date: Fri, 01 Sep 2000 09:16:56 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: James Undery Cc: IPTEL Subject: Re: [IPTEL] CPL log nodes References: <39AF66E3.AED1763@ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit I would even argue that absolute file name references are bad in the context. This should be a *logical* name, which the system should translate in whatever way it sees fit. I believe this feature is useful only under two circumstances: - the ability to retrieve the log file and/or - the ability to check whether a new call matches an existing call in one of the logs That way, for example, one can easily build a service such as "only allow this person to call me if I have called the person before". This type of abstraction is fully within the scope of CPL and easy to express as a switch. One could imagine that a CPL-implementing server makes the log file available as a web page, say, so maybe we just need to recommend or mention the access issue. Having such a service is very useful if all you have is an Ethernet phone. It won't be able to store long call lists. James Undery wrote: > > Hi, > This isn't really a bug, but may I suggest some text be added to 8.2 > to the effect of "name SHOULD be a legal filename without any path > specification", the reason for this is to prevent the modification of > any files outside of the script owners file space. e.g. > > > > Could be very bad for security. Also it is questionable how useful log > is to anyone outside of administrators and developers of CPL (non UA) > servers as the users will require an account on the server and access to > the log files, doesn't mail provide a more useful "logging" mechanism > for users. Log would appear to be useful for UAs only as is. > > James Undery > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Sep 1 10:39:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12904 for ; Fri, 1 Sep 2000 10:39:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1E05C44342; Fri, 1 Sep 2000 09:38:51 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29]) by lists.bell-labs.com (Postfix) with ESMTP id CE9BF44336 for ; Fri, 1 Sep 2000 09:38:47 -0400 (EDT) Received: from orit ([38.150.216.6]) by hvmta01-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20000901143846.BCSA17786.hvmta01-stg@orit>; Fri, 1 Sep 2000 10:38:46 -0400 Message-ID: <006001c01424$9f0ecf60$6dd8a8c0@orit.us.radvision.com> Reply-To: "Orit Levin" From: "Orit Levin" To: "Lennox, Jonathan" , "Jonathan Rosenberg" Cc: "IPTEL WG" Date: Fri, 1 Sep 2000 10:55:07 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_005C_01C01403.1790D900" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: [IPTEL] [CPL] The Liaison Statement from ITU-T SG16 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_005C_01C01403.1790D900 Content-Type: multipart/alternative; boundary="----=_NextPart_001_005D_01C01403.1790D900" ------=_NextPart_001_005D_01C01403.1790D900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello! As the result of the last SG16 meeting and on behalf of SG16, I am = attaching the "The Liaison Statement" on CPL for your review and = response. Best Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit@radvision.com ------=_NextPart_001_005D_01C01403.1790D900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello!
As the result of the last SG16 meeting and on behalf = of SG16,=20 I am attaching the "The Liaison Statement" on CPL for your review = and=20 response.
Best Regards,
Orit Levin
RADVision Inc.
575 Corporate Drive = Suite=20 420
Mahwah, NJ 07430
Tel: 1 201 529 4300  (230)
Fax: 1 201 = 529=20 3516
www.radvision.com
orit@radvision.com
------=_NextPart_001_005D_01C01403.1790D900-- ------=_NextPart_000_005C_01C01403.1790D900 Content-Type: application/x-zip-compressed; name="TD-44d.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="TD-44d.zip" Content-Transfer-Encoding: base64 UEsDBAoABgAGAL1LGikOJVM5EzMAAADWAAAKABIAVEQtNDRkLmRvYwUnDgBaUElUV0RCTk1TV0QB AKIDJQYlFgcGBwUHBtcJBwNXCTcGBwYJFwZ3CQcKBwkWFwYnFgcJFyYJJgcJFyoHGhcFJgQXBgUJ BwUGFQYHJQYnBgcKCSonCwcqCRoMCQwLDAoLCgcGGwwJGwoHChsHCwcLBwoLChs6CwoGCgkrKgwK GwoLCgcaCwoNBxoJGzoHCwkKCxoLCgkKCwoHCwoHCxobCQtKCwoJBxkNBwkaCwkHGhcJKBECAyQV BDYHJicFFwkKGQhZGAkICQsJCwkLDQkLCQoLChsNGwodChgEDxEDJAUUBWYHBgcGhwb39wfRg6xu 1IATrFUChMuonP/8I4Ri+h9NJq4GnwpjUe//dpNlhFCEIhQkdxs8xYdCYNofCoGpSmAET9D95H96 9v+ZOkEva/n/X+Tjlv+//u8Ke1fY58XmxewMcnq2xi8x+n+NkavBjlzp/2GX76Qa+b+N8aTFwH+B ZUgr7AjlvsPc4Bpa/EzZ/xs4fK2yNqvDrJbgRMmyDkPkdfjUXsu5w+fymSje93+68/9RPL6kx1cr 838Nhx8v47M6DCf7H+IOT3Kxy7iuoe3//+Lwoel3Wh0Gxu8S9PwfmVU8WYb/g8jja+J+TaL1C8zc E8FSBmfE/07BBovDaNf7Ah9YpT3HOCzGy3gOHTQ+P+E24TDK94LGcYTHqND2+475Aksvi6rlMPhg 8RztUAH89D3iQS6nDx2jcL6h/wse/EZ+gQHEe+GZaPQ0MlFvgp5Q1Y95dQyV2KNbHT6F28cnH+Bf YAox2J3hFX3d9+buXLW1tay3nbv5drV+PfPdumO37Ngm9ljenfPV8k13D79AWLBg576nO8NwyL0s vf0Z+l7h/Pv9vm+1nG/MfuLVft2DGbO9tKOvXMfLmDFjxonX3NzcXO7VGivwRlpStizmE2+sSJEi Nff7cGbI1tM92D/Qk3s6nONjY+EtXPiVTOX8u071K/H2Pf0ZerNn0/nChcLr/N2D3Zk0Pnt/xozZ Brp7Xv/Ay96X6Q33jmTt3qdJIzCxzzQ4Mtjj8z3dI93ZtG7f3Z97ejBbd9Y32NedLdN76bM82fa7 /UhfX29/OEYy5Z4eSbm87443X73d/IVznH2/3l1rq2/fLcvFa7vv+Xad8pUUjxwrXJQ2LptL7LP2 91p+dtt6yzt5y3aJ+st70bpaL+7X1fwKU/3AKtnd1nUvzbahn71/oNvse3K/6YzL8Te829yvJ8Vy t54QiHg+HkxyGs6ee7pY4Zev0NjLb9CFihQp9JKMFRnb96zWLYs3cM+TrpYpFhPTWXdJck/vCxYs UuT1rlrm98vzehy+feL1tGw5vlCBIkUmprO17baiX/sNhVxftt5MgwPhQrQvCGoUdK/v+TiUudy7 1mIZUXOfFc9vX21M/IHMr0i+fGN5J16GnpH9fvpwAO79fj/StZgvee25X3f7dvE6V+v5ctvVgmzc sV10tiwW9+K1rhaLbRd/t2j5q1RI1tv1m7ffYvtOMle5ofFCY4Uegf21LlfJth1wv7zbdt6N5Nba LcvlvZ4D7kXr3blNJazl+L7Bft+9bKa0YdtaWzfNShvjXdf9SGfnSkAcaF3J+y3rjnu5kBFD+Qk8 s01mvtVym3K73m0Ed8rVbrN4SXcLt2vbpbiJdsedarveOuet47feCA/TqZarNp+tk1BeNzA5+26z eT3blLLPcX3L1XzVudqMv8H569ytXxfb33cbrRn7PT7eTtdl0xvpGySfoYo2nhzhbgiXEw/5V0l9 D+k6tqlS3WTuVu0lYzb9Fqdvftu21o34+/x2Pr7vhmvynvC/LckvzFdA0R275gmlBKPdVDSRvZPb LuLadbfvkm3NH9FnenXXnnuZ7MbXD9wMr/Sbe7GY4No0+rW+rfNerqVv3i6kngOkthajc+vV/Fn4 LW5NL0b3OxJ7M3akhn+37pZgK6OVfk5A79b5Asjy7VKgW1vpbrsW8TSdXDQv5ncbgllmdZkLunip tvemYzH+Mq6Wt7l6OUH562b1hV/JzxdNb7e8GZ1LyW21ut+dZKfvLaSvdWX9GnpVr2ewr+jy3uzm YA8suGPV2WJkI39l0bD2znuBvZMutdVL+pmIrXXueF0I3O6Xate23Wx3y5d0O2+303LuIl9Qi4bx F9TicK4LRBunXmkzNLCNSw9jYv/FFs3s697INIkS23XnpmWh7nL3Ntu2LSjf/lZVc+sS/KlE6dJY xqsOMMfaalJDfP0WcNW5s5NjmezfcZTI0WUqO56eNo5WVqOVJ8efsLa7OIgwYcfrXe06FMxN+xw7 j1ut2YzsSLbjMnc0gbrasdEen/IW34SCNLKZak214tACqFuZF3gCp3aWe7/PiiogNM0LRWV+UQ3n bL6e8JKNNVF6d2wBWW93m6Z3L5erpZOPoUQHLV9oRHa271rnTjq1CHU3rJHj+z2XVTWmnDdLvZUw m1ZVe5u0/qXa3EkUeQZ2pN4qIHnX7avV6BcLdq0Elg/cSV+8VPcOUqUj3oao7iLdy1VHSyfWKvcq PPUxCATxkhza8di432str8nJJ2bWeU/YF55hTk8kjRCWjosu8VRMeuxbW+ZaRtXemR2Ca5exlh2y bk8ujzeyXt9JXn8To2ipRWtL12a7aCfk8cG1vr3NeXNy782andoXqPWKl5MOT72sFBFmkxxZ1GT3 pmn8jTwi/nMtfimXq5ZWNZEpriUXLZ3t3tdxw3JVQ+TzbRu7cYecawlJvuU9e55N+clxSHwtjTiQ I1zfjtUIeeKZL7DEO5RtYsKL1Qae5aa3Wa1SFG1p9XclHrbHl6/kCu34W0COIvJJ2qWCuLfwwqOx XeMh+RjvMhbUJZgW8cxty6KGrh6dcts58bq2qAbSzElsF8g81XbO4pg29leQW+jf3lS2vJnt+mZq Jdak1Hkq7H4QVMEu76K7JTrjlLdIvMedgxXTa7vNEsaZsbEEAs1A2Uru4KEs+RayErnQYz7X08+T 3rfqsK5Stspa3eFwJSBTnyEbkspJNbYgiXfda3d/7qiZJ/PlK7kdv8cZOShfjpZQS0hQvaILC24l KNP3bg1+rn/vcPTxvKvJk84QH0xvylF4DrpJjorcYTJIFpaKXrLtnZSPr05yOTsqw52YdKnFJl3Z Ht8zWkElZXZV/nys+LnKSEXAfjxHTm20muT9lCuOrU+xSDJkQPyQzv3idSe1/lWrqlZUEumpxtAj M1nuR7qYoLKCMt9LCiE2P2n7zceok1QHoN8m8/uk7aI+tc2ONTGbU1A46dqXSaJYDY9UhkogDxgu hfQnyniIcf/eDyrSJfEGbge6cbj52D3MplRSm4qzcGz/WznGYArlQKl+mvSV5o5o8lbqyNOB/m4S PRCF8pMmnGIICiKhfFdg071JxUQVieRbd4VItl2YaU3eslKmatfFSB+Ez/YZXUWp/SM9A+OF8SnJ hbWoIzkGsu7DsVtuVy5EMxuFWlEFttDS87ULZyeV/gp34twsSAZrJro9ydWGKeiEiKVy0E7ZwiyE KApAMh1/2eQoBQxbAvTYWIHxIm8Emv5iRMqlRAyGX99uOW8eaCGiGfTaVl3bzZ1hMGN4WCzv5uC/ kKFlOFKJxJKOVmNyDo6Cz7ZrJxbqorzplPB3t72SLr28WxWXJHtOYAI1FmZxRY47teQdJcb5WI7n k+hR8zvbm/bZDakIYEW0KzCD0tikqwlhKSgZcTLFhDaHS2iBGUGvRhPVSAoeQlkUULPx1y9KI5e7 pRbxAK4sUhdGpKqohS5HopOYgErqtKBo07fhoahJsRT05roqMFo7cJvgtqEP91t0lQirzc2/pGJL wmekaI6qZWf7arWw2IjvtbRcVwhUuntrKaMWz4eviKTPt+amBTIZyWpiXtGI1Z6/Md+kFAgHukpo haEah1Kasb01JfAOEe94g6kc8JlIKsEkNWnkvLmV1I1vv0EJpT1HgpPLrQrm8gw+AeYaok0vgwe9 eYuZ/d4025LKVSs4X2zuVHMAFyRMGN6mIsX64ApAaWuJJKUJNlxIb0FFSZ/fWpO4mi9wtY1ZHNu5 C8mgZKp98TB9xG/RYobK0fWmuQlrt9szZ0wgugTElxyC3HIQCUOrrjRJaJXGX3Y40LFN6LjYhS3X isQpiJhBHpYBUJ8vYFgcQBFIXOD0eFg9Z20mPNJbEBZ4b1GIY3lYQQezoUYac5EOCT5CQBc7SoKA vPEnyQgPX4KT2po0BTaBz1Ied9MEr0uuFKPMizwdsZBM4cFcYjkhGFJfuXPDa940QxALBIffqtjC i7Lm1wbdcphPmFkBRL7a4u5AW5uAiIkS+0wrIC0zUZLd0ipiHM9ibaIn5SJ0I1p00a0GBkGZRDH2 zV0raJfW6CS7i92ys92avjFbwbBQXasWOjJVdrHxSWxMkvIslbRkqpYlF4lXrba43Jqt+DzzceQc z1u0bOaIxETnrnVnLfBU2w2GGf4FKKZBD3FOwCc5KeFWbLgUBWnPLOmKjEou3CkIy1TFOf5cWwoi mpZQKsADx5Q3BSFJp47HYXPvPmg212MqyxYX041s4kMe0Kb42oaEt+gmYbZEY+8RYeS8mabidZKv reSTTXZohKfyQikFq7YbGtNiFDFTqxvhmnp9HK453JZHdjUDcRmciQGPL17I6AdESEMLMl4WEJKX WGRntSl3/NTUGyCuWXDZdm3FJFmZyeK2nm+RKA0kObjmIxsp0lK2u2ChBDkCm3owlm2ZYyDYlC2p jDKQq5wegqV4heimCg6HQHBKvZVFovdOuXXhcnoK7qXK5iGXwrWSNCmmMWl5kZAKWAQFjlER+Nwh KHQ+AXLje0rDm/Yjz0hMnWMJRKVn3IaOzJERDHrmvj/T2sp0pLrA4XJ1Gt89I82VBZG0fYunduJK o1bmxMCOSmmGXnaseWBuuxnCYjDeAaRM5CQEubfaIgcmsUHkxLvHEd6bzwV6ee8Wvsw0dZ447ZIJ EL5DwlA4Dld1ZWh2Ct3R4ygENqlBEK+xgWCnp7AJypOyJIxlSy9KYYzxTYIOa4EQ4N1zxBVaJPH4 t8yhqVX+lnqQyrcu5i0dorbdGoYpdkgwu3ImxFR1GJQklbCSOu4PnT/uF18l9ckZh7d0ghBIdJLA M2QSiuJJb1u9g3q4aMGC++npPlqUar++kSzZXq2CNaWvkPIX72fA+2VyI94OopHhcGwd8uC6c3zi eUE8VqTwKzCWp6AXxBO+hM1Hl4bII21IyJCw2++xQejDF5j2f4Fp/xeY9n+Baf8XmPZ/gWn/F5hG zf4/bvBFDD6fwec1+GGDz2rwQwbfY/DdBr8x+DaDD5vBh4TBh5jBB6HBB6bBJz65vMEHIAZf4/h/ dYPPa/B5DD63wWc0+AGDbzf4rcG3Gfza4JMbfEgafKAYfJin/49j8Ilq/R8Wgw9egw+YBh/sBh/M Bh/T4KMbfKWa/1c0+NAbfOAbfOgMPpLB91d3aoMPVTXTrvp/q8EHUoMPfoMPXoOvUOX/ggYfylAF kMD8ofqhixa6aEEcLXRBGmRBGuCC1OKDPlowRQvdD9KA8oMz4P7A/MErsAyEEnOBdX8Ou5hXJHMI /wwz13P+mYQ1CswkzJ652u/P/H84Db595q+Hpmd/bZQRsyb3GxTJHFaZ+a9+mUmIuh5nrioL2z8M Fb+2DU3PHHzf4WYR7jcQWrQNsdnrwq1qEzOu87PbT9rkSkDzg8d+f8rhoebh+eZWZvG2ctDgQ9zX yjgGH2wGH5TWVgaGwR+M7ekMPgA1+LCYWxl6gw+twfc72lMafChd6gssQ4UxC3SMWWBhDBk4GLMA hTG46BhDAg4WY4igwZgFE8aQwY4x+/83DKFfuMx1Mn7lY40y132M07+mrvYboIyZ+ZfU1QJaZa2f gtkoe+qfqx9Zlr/h/2ewO/+68SOGonasJN/o/p+MX/1YN35gh1Jk4XvwYtdiYF/s144VVP8fi/36 8YO0aqmO4/VfVdbA/f9U7Gvt4C59+bX8LZVwVoXd4FMY/MZbESuDb3VX0lwV0eAjGHylw//hnnF9 6y4/5dEGHxwGH+wGn6fB/7kNPhZ5B4/Bzyf/bzH44DP46Xr/xzX4EK5r1QYfFAZX5/8gN/gw1vb9 iAIXKZLAItACTeAjRdaxGmrPDuzQBW6ACqIgCUOQBWUYYwSEmMEQzMEW3MEX5kAU/H6Wf4HF6RiG CKEIxekYpAprKEIRihqXyz9djwGU4g/Xmbx/+jplcX/ycv2nD7IbXuR+8hiikUIRiplhj7t6fMNj tUDxWKp+iASK5wWHwg52hR22iAoXEgo7gGrvwFHY81AoXIvCDmyFd55dhXLACmSbC3qtHXhC31Bo 8p8vy385X//hEkL/fD01nEU4lZcy5/eyVCAylrPAxJgFSIxZEGDMQi8zJMZgAzTT4JpoB/QLjMh+ /dliJGIUKx8UQwHrKjTiSjgIRoMFHMTlP38Q+ZnyOMTl1dXLXH/39V8C4ebPBPHxX5tCUbsUJHt3 idYQoH89bxEQAUkkFowYU5lgwZitMGZfYEzW/xuW+lNZh/Us05lXlxvkLzDy+ouCDfgXGE1nrxs/ +sXO5mmAu4AOrKcB1cCPj8tysC0YszGMWRGMIb/A0rou1mHPSCPPUOsXGJBGNy4eAIo7cGfFgRV3 UCIajKcEJ6IBerJii9AafIcjxc0Gf1boWYMPPIMPXIOPASUPaoMPox/FEfVmJgorMzapzJAYU4Yv MOASGpyDAUFCg1IIaH8FgkKg6faUvQUi9AafsNL/CQw+2Ay+0eEqOrzBN6jwf3WDD/Tn+QYfxeBD Y/CRDT5f+f9zGnwGgw+Hwac3+EBg8HENPjSBHjVaEAboABNggzzABUMwBnNwBszgiR28AXBYQjhB iIUtceKkiefzsJEG4F9gyNMl4d9fT5dECn+56jOqbMVwJYWfuYTIP1aE+C+xwy9xp2OoFBlXdqbS kAy1MxVvaEDxnwI5qx0Gq1WGrmEIhQ+dPIv/MQvLHy4+dM0itQ5J7Si2kwEx0GwnSW1TIHc6Bq8n lQOewk7oQXcChZ3ab+8UdmAqTpYNZMVJONNUWbkdhM4TEYUm5a1B7lcwodVi8CFk8EFt8EFl8Ga2 UBl8Nh97VoPPZPAZDX7A4PsNvtvOSgp1xB9oP7SBEdoAFtrAgLEA/AWm/V9gIYt/Ahl8r3Xwm9U4 MTwygQ9+fnjIX99VAeNNBTYp0+AwxsoysV9gynENkZ/9LM/HnJCGJVARq1z5gFQ7eX7jRlRAf4GR Jgwws5CDN+CCmnHjgZDXjgcV8A0++Byk9DEQWLgQJAaCaYhgxRiSaWxwYMyCi2lIjCG+wKCvCf+f TfhLdTQAth0TeeN+uMYsfw2CshcFnb8F8gQ9eH8Lql74fsMi11J911/J4Cs0Rg/va4wa8uUb45zK GXzZEIhzKmPwpRuFB6AvMO3/AlOOgG3ww4iDjh7GwGoOZTAGed2wJPAWD1fAmGLhh6I7s2oZk2Gl J10Q4d+xSLHcrUd7VuuWxfqej3eu2n4oQhHsAVIh0F9g2v8Fpv1fYNr/Bab9X2Da/wWm/V9g2v8F pv1fYNr/Bab9X2Da/wWm/V9gQNT5IfgbYhEcMn9SE41P/D8amlBcHO4f/8Bf/eVv+7u/8XhceP/2 GWnkp6WRn579ff86enX5Ppmf/kP/lvqOv/3rn/K/X1jlqyNgVubKDua8v3asKL9WrFx/tNT/tX+B mYTZM1f64Rqq9PszX344DV78L6J7QHSYMdF9EV2vomOuni36+VGvGuh86J8995DnMIU899lzvXiO ufwGX3KWSQRlycskOUxByT0ruZ4lx5x9/QIsYX4uX4w1L5fmMAVUvpbQNyw1Szlmdtaka/xRG7ve jeoNk19vH/X+pDfmdPg87hrI9n8QHOR8gvsg+EfBMccZwvjwnxHcw4LD5BXcM4J/EBxzmDIoB+eZ 7V7xMisOk0dxTyv+jOKYGWtL1hGJ5/ojo6EORcAxdddw6fun0vwWO/3c8vssfmnwKRV26283+ay+ +rXOf4GJ4j+HSIfa4UUqh9B3/Gar7/b8JFb74mk//5zFr0ZfTi9b3eFnd91zvVa9/0+/3j+XuVq9 VQt3hP7yV+n09Hs1f/HT/LIaH/5f1+nqdETB/H2MerNVzsE9W/AYdIdLaOpELR10QatnZC3oPkM3 LObpLP/6x67pLOedlstSCuLnMudTmetRdIUWjxX9so9R/7POv4+7gIRRPBftM1c86FL/CJOSYqn1 s+xqX1vX3mi88NXWKuExUb7wYIoI7xzXIkZ//D2u3yy7C8u6a9n6/ZlnwX4WbGFp1q6LqfHJ61cm 2cZozT8Zf/TIkO5jmIrHLH85yM0nrHfXVVNoVsBw96sBaU6iKfjaNnRwg9Qu5728dgl9A/PeibxM pTFX327mW9XeYfNlzWRlzvwRyflDKvk2mokk8ot0IL7GvhqppozHGjvb/2qScthPwpT//yElmRNc Q0ra2G2mbgvfr2piE4nId6mlEoyKxXPad3KXzmn0DV1Cu2tR/VeR/UBC0oFE9hvCju31yWG69lr8 jJS7xY274CWTtX6/spk3GT/Kx7KCJvSklcOWNP1gvQbttaTpiDFF60r69oLHL7WD7hoGqWEKSe2K Uu986Zzy5adT2VnN/ZRWv5TVMvyyGujaH9ARFjBHmEx+DfV13M9aduZnUJePDrmNdiC+1rlMmGWv MWUVrB+4IM2voNYn1JMXtNHWGiNnWMNfXm3JV93aeezSrWY84v9rTWvh9ekJn5UkSNJBG7rmuBh6 06pje835lr2ysrOwGjpQXTpWCqimZMcax8oI/FnIslqxKl39JRgrU/lL16WklntEjHerjJVbGeeX X1rIysKXpZB1A6kR2omLnPl/V6GRy+W7CtXXGiEYu4ip/w9Z7Rz8l5B1dGuuTmOerF5NXDoRVTkg Q8p2GVK6xraTlkqU/CU8lFY5140fukCWsoBl9d2xL1l998asF/Icz4W/zeQrmbA/GVlhOqwQjxw2 5ztMF0Vms/4s7lrF5CP3MWb+pdAhgFa8agQVNo2uq+qHDevrqFFin8KnUslLi5/bOlHQ1y7FVhxK 934DF3mu5GKjpab3Mer+U5Vz/0zYp7dTwdAArozpSlDhEqXPv+xT07LPMHe6742edVE9ywKBERvI TKI71BdreuIcUtZUxVluz8WE1Z2jIVjqUsOE+ovmiBxqvk+5UncyMPdLUa9DrtV+eNnj1Fy13CFQ puFepsIzk1DYhaTUy7nb2zrbT64v31lTExV12joCpab+ucpZkLrvJqzBhg6HNlPP4TAxHpT8VN4M e9f/5Y3akppPxg/u2brxQy5QqFlEcM/qaFzEarmziFV3lqrryrlxV9cOnmPd+CETSq1EUAsbDeTZ 4DmKjvtydOzcK5VHjLpDn++FwP8ffmXumqIUcGb6Oao3VzUd109z6OfTD6eiyP8vraP33EEwUzd+ mUB1iqm6g+4QBDN+Jtehrax2WVmfDKm4Dl0L6NCBVtbuz4zSBs+6FFc6dhVXTetRLKU0jZj1Si3L km9gSFt9juLH7JnByHIcm8qf309wTuW4O2QEyyhMSX+yZZS4yigWUL6M4vz2Kmd16hXIRC3mUQou Eyi4nWcCfNXla14zjTKhRqiOGXPl63nM1j3iR/mAiNqOUvN4WNcz+6PZH83mxaVZnWOfixu5zSaf g9qfTMf9dm6Fb3fl67nd4htajfXxHAi02A+PDZ9V/NP5Lms7fRDM1J7KvA+muqVqNFXRq/8drDKR oFmSolqDVlR71pptI6Nl/EhWcSLAQ9IfVuFC19Fx2GEJvjQhUkU6y2pKbFEv5HVnla7GjlC8YD0H 3lnx6hk4VsmQaTycqP9zUn5woUjtvn4jWrV0RXtQrSvagwrVq8SxiiyFzpf74damqE5HnlCYVDgM iDGVrvmcCGfUpDZPztrKZmT6/kldDfF/FVPawm3JBsnHYDLZUjn2VZunOUx7Z+V3CmmPfCnlyDL5 ++vz0FNgbIgkT33UN/uCgsRSit5BX3EraiFKmB1jnfI15wfmcXGujs1m0nL3qG1dnhCmo7JbUhyC J8Lz48hna1ADcoyuOWYHdKyVdS0S5D9PIphK3vZzGdItQBO+EZa2Mna0dLp3NrP/0nNUWbWczYyv NHX8NkEO6fB1VgRbLScHFAWLVC0ts6B1UBnydD0bgqfvQ4oY0tZySFC032T5n8Xv6mpwbWo0lxxP JQw55SdaXLORS4LZYZk9qEa3OyWynvQTudaO1UdhriWExemt2hIVIK6xZ22JOotr+X8dzz+VAdZq t4bVbYvxO7j9QYW7j/CsIqWe3JYOFHqS923smm/JW8HKoJ3NLOey3RtP2jLyWuv8cAmSkAdmU8xz bee5Nc3TM+I5p7FqtuucU87actTcgobN9A9lnMllcH1NXGlAqmGYdSTWhSI+12BV+WfkNIcxYm0W MrgU9X6Ph7OEUpmQymngKedZk14aG/9fU9heuVQiPq9K/HyX8MZP/scN3lud29nEzmsG82cwZ8oV mlCEela5nEy+tur+jPXZnJzBe8/CJhlMk6SE52B2pSxoL3L8ZqTZXnpLO5wSRYU0hL1dDSmlJ7mw IsuKzQUcVV3NGJAy/wgVy0MTijonrzSHMs2VZah3Fb32ZxzGiP4MYu3PuIHhTxv+NFgOv7vqVO4U fgHtbj3hIcndq2alz42cxnwmsisb9zhh+n9DksJ5ynEq4jNXsFWTeFKj9ePnIW5n9rEa0Pki5I2L 5YsgW6Y3IPfUz+BATQiFye21zO21u78Os0kr7mcRS0a92iCJanRjPXy7NYfdHnC0/1/B/EXpPPgD xXARRcjVk57/mDHD5ZiIkf1eOZ3hX7ySk/YMdZ8wDjPkLKxhCjkWhvQapj80oYh98lozqRvPaBNt 6FrPTEpjTAU71zDZbHBdQQV+AUpY17g+PdcwxQ130J6KG+6sX4etaY2SBg4Pw2nMwMrsBu6QlpPk NwpZSZPV6aLF3d41vcMfVTDXwdWcgsmcgkmdq+woFwxWLyi/5dFdi0J+O7WsJd01VtUi3UTpNy/o t3f+k35j/cfL+c0L+O0uv7X2lN/o2lN+o/L6J/OKulQXq6kmrImFRsG23CDqklfDVi63EuOyKHKj h+R273FIbqlnKqUjDD4r03G8/mtphV1KYYdPYesH79KPF9bPqfTTfBf90BpU+Q1f+i1DVk3+fyVD zhKJF+HzszWQ/NGqNBT2GzPstxMch/2WklVFhDOdo/j3VE0dKZ6OxGRS3MF/zKS4zODwJRw5e5Pw +lrcJ+O3enYIREQd3WoabC7NHfuYS3OZ3iSH3SRIvTEWaZgs4uGyyCksQonSGOY8uFV5sKO2So+j mstuXeONrkGiwW/j0AXFlR4LCi7FVXUFyBecaL+6WFgnqYF3HFNbugtNmrC34jnMV/GLeZYP5vLl 0yELSJf2Yu+ITwTdoW78cAdg9dA07CT5yJzqUg+yJg+ODihrt3pwsIHP6DbhiH2Mg5D8GviMvjdH 1jl4c0hjck2uyvD/Wb8snKqLHeSw3WqKS9RWZm1FQljASxsC2VCpGwrjkHrkPsjprn5aLhRIQZak JNr4XpMSdi/CXoKqxAq/del2j7bBSx1WzNVhQZLC196DajU0R+cpfqCJfqvrtvZabCNdsy9FqGG/ KyZroNq6VFnU0qJNMWpRArdnJXNysDYkujw46I4a9i7RV8QqscdOCrcnjYjtAs1sOSU/JDgUt7PO pIQjLUjU6+P3kjMOYBHUiVQB3ofgP9izmzIAs1mJlaxlRy3KaYW+sLE3wQd3WFXC0622W2uynk9P xo8OJy8CJ6W1k5qQGqaDGKNZTVJ3yOTjD0mzPalNBDuqSK6HUVV3FqPOqEC9L5i2KfVGxP01UV37 IzCYAS4mDAcX1bQrKEL/QsLSfbB0oWcPv4w+8IS0GzjlNoG/9fFsC8pmfoi7UnNvEmQlGZAOQlqV UTBmJEITRBv8ENPPkuMTv8KorHlmwiqrIwsZrfufiJ1Yo9aL6QXS/xP/aX0drWVWbyyptUioNbrU LzEa+5efKSVg3Cfjvn2JbAJVl9vy//w/fE5feEZIqK6Iw3oR6O1Nbgv8bl+rzGTnleDv6c/kFTPu 87Le6uFYCIjF//IWmdnrPcUyK/xBmYiwQNYqP0TFpCYRk5iYMWPGnHQwViJh47+iid81ow0lTFzX Mi4twoSIwuf9pbQ7uVqu4zXCO/j5DxW/aqCfIXXsn3CmpLbxkJy4odSNek5hYs1JfI7iTjBHWAmw drK+mOIcboc//RD6hct8UbqlUEnGnq1U9/+4Ff+/aliLcMoqsVVWYqpHxb1QhCIUoWBZfoHx8BuM 1oPKr/j+F+RmHrf892L/f0WTZUrcL29Iddx6/wd5nf/DaPQNKjitNYi+msGjIf+lqKtsuqxgtwxj bae1OsdbUBSKUJibDtrMLTxPL6nCN1RV7zxofrYkp5BRXkv8/16YKcFWg+3zGHxGg/eu2q87FIEo LLXT1QpFzfh7n6/1LVLHql1+HopAlCgUoRDldDIzL0T10ndSQPRO0NpOyAS+2wFaygktZMxpxOwb kS8ox72wK8p5BXZ+YcolTIMGH+IGP6zQwcvj/t/DZlogtI3GZjOaKIX0hQ0+YBp8mAw+kaQfFoMP XoMPmAYf7AYfLAYf0+CjG3wrvx9IDb4CaRc0+BaDD6vBB6fBB2SDD/jkfhyDDzO7H/AMPhq9H3gG H5XfD1yDj0zt57X/gF/RID3Y+wYDPuuwFLiLYfapYDb49A76kDP4QCBrD7gGH3pae4Ay+BoOXdng Yzr0lEGvDD5sFsFUMRgx67D0XkMRCk9bQ2feS1munwiQkwmKHrXX55YiPqnG7hA0Xnh8tzfjjL7y tE7sWwygrI2pK7f3F2tWfD12yZSNV7qI7nY3F7W2F3S3J5Xe7dLf4qnsKqQsYMb1fiH+LkHnl/+0 euaVKcdpfXaLwyd3NI8pf2HlT6souFN1bzWYTmsQYNrQahB0aYNA7YTn9Uz4Xsq5zGSL4rU6Vy68 RIdXwsr08n4OLfWQ0PdavMgJXK9R9yu+Q7rwiCgisPOKd58K2wJBGwdd1Dga8MyFVct3IT5ltebD U1taPijPeljt0+t8Wh/70kr0VgtNpvXkW22RVowuU3iLbtXZtmtRZ76Lan63Ne+0pvpCcl1I5NUZ WlSiW3SNXbUWVUKXKax+zMfIZ2T8jIycO8PLDuewXa7Ryk7X6Ge4fwQs6kIh8JNKbP0C8+svOBWm S+k/PRuKSYFR/4fYwOTparPdRoZE+PoONuO9eQLEtM144AwHasOSUaosvUdefxib09WfdBsqdom4 9U3Hg69ilUm38UWVU91J32CkSM8URHVNx4OxXMCoYzMeHEkCpM2QIZK3Wg2b8dCWbqvqFF5ol6iK zXh7npHKpuMVUgeA5avlD3sw+AYP6gwBO3ym43VmA0ZJm/FgSBru4t7jKasG9OIhGPQNg83LwFNk DqLipuOBni5SMdPx4K80VsT0DEg7C1F/Uqb4IE78tM4H1yGYC5uOB7hLYI2ZjodkyObPN9MR4gHZ ZnjNltDlcRuP1RH63DbjmTLnDfnNcdhmmDgVquR0Cg/KmWAabQri2AHWzOEhHVI/m/d4MFcskznG 2DpEbYbHCN8us6vGI4UrYGWyCA8khUJoQJl4IwudL5T97auQDUg2w/OG5CKcTuElkuTo9R6PFPLV u23Gwx6el950vC1/gE9vER6OUgXSuf2MzfBoITaULndASJzbxeGhmAkI6bzHg+ClDzmb8ap1i4eM zfj1ECmkbcbD89u7KgVGAJ62CB5oWdo73Mbz9GS6bcYjDATJNmeg9uW0GZ45TfGVteNB0hlYyU3H w14zrEub8XjFg3thOj6aLLjmbuNBWKo5qdt4hO1LbDPeWGwmJO0lZIgF1BBzG/8Cg3yVwvjqNC5N 8mT8xmvd+H0Raoqh1Xg9XqXm17PX0KPmmMeM6LVHL0ekG7cwmS1PZsM4YajZjn45nsyW4+bCbvOD 2/DUiujHCWS3nfp8PLhNjGvxt5ucthsRxe7r2a1Rzsdpu9Hj1vz9Jqb8RiYSRDpRoPjtRLPHKb8R 41q8DWd7w2HrnerGjxLJcNc7HfeGQ42b83YcO+k4Ko7jp3Zc45yOk46DPK7H3XJMXcvRReggjh5K y13keKxrOfhxC86eVx3IsV9gT3nudj9zmP2Mtl+P/Zmvmthf/6okIq8odFOaTzfUGUMjyHZRIxG8 9hgrvMZVHDT2ACY2/Cw2AvmFogN007f/SZ0KiFs68ekGqTIWbFSCVj7T/RTdT9GtayxDy/6sL5f6 f18u3f32fLqCpam/3wgsTf2xNMQo9phGjpv5WJpbs6iPT6h2nzi0LswRtNkAg1LUX42U+tMN9Kf7 /x3JwNszgGcUIdBWdDJaw0FOWQycjioQQpkRU9hPNxQTAXioKAyNzUbDq9loosDMzz/zcxb/2TPX +iiSoObqg5GQ9IZeEIn0DF2BYYmyYA8QWRWeGi6sGQNMHsMDI0Si2G4m5HxmHotcIeyz0oHlcWHx GB04HksSmPxmHovhsPqsFLD5zDwWTT5LTsR8xnLB7TE8gHst+WDzmbGA5TEjA81jRgWex4wMKo8Z HWweMwLQPGb8iHnMaEHzmFHB5zEjgM9jxgyfx4wZLo8ZO3geMzLwPGakEHnMCMHymDEA5zGjgclj RgeWx4wSNo8ZL0QeMxLoPGZEIHnMGKDymJHC5DHjgMljxgWWx4wXIo8ZC1geMz6QPGYUoHnMWIDz HUsCt8eMDCKPGRFsHjNuiDxmLDB5zBjB85h5iqJgCEXhADUVTD4zOtA8ZoQQecwYIfOY0YPlMaOA yWMWfBWr4MJiOWDymBWcCtPFY8YInMeMBSyP2aLKyc9iuYDymAXOcKA29JiRQeYx44TIY8avDoXA IgAbyt/PrsaAASKCllsMhbDcRb3S84FUuzCr7cKofFUWsP9XRvkptd3riFYETD6a7yLz7QJ8w7Tz zb2IlG9EKAS+L6yEF/PsFojkRExuEUfuU/+VMB0gpZ1Fcd9xLnoDPBQC0yi0qgdL2+GAdA5Xx2EZ pMFX+OBwTQ7Lmv8q7q7hs6zusAwin5eIAoRb07FfYBoTitFzouuP5sDd4DpCKPTfxYvmwpUOi0s9 rmXcip/STG431Dfw+Cw1QkDDv4Dif5o9Xc6zIZybd7TDsvtvf9u//4LSPODwSR2+l0Tf9nd/7fMF HP/yT6fr5Xo4XlTxeT3KiUQI1/Obzb5L7jcaX6iU/p46zl4ul8tFf8iRv/T/ndnurGP2zGyCCxcF rEX2n8Wo3WIlf3oAeQnNgO0vbPwzxgOz+i02+f5Lj2FtF/9nyxEC11AcPIf4Asue36m3W/9cc7k0 +LXie1y4C2i5D+fpy+V0mdVySIXw9PVUA5dDx7pD7vtE+n8tByF7uRBQlVjX8Yya/wxe7RYS+1bK qWzuGf7ecOAy2P32J5PbphZjZNjIEwmc5vABzR2eo6e222hPjUzv9+ufUst3WL2pKmeJ80iisFb7 P7onf2K+f9WgGApY5Q0+sLpyZz0b4/x/kdn/A7+6RTmoZs2ItqUXqD72CoVUTk7VRr0MGjCDf4Ep u7BX71f9qhRJUNSnwb9GLr2BCvRKKsNFGRqKUMjSRc4/KCaewV761tDfpmorsTYTtbap00g/d3hX lYHY3EN0h8IvFY0T+4z2u7mEdBqB+bDHd3q+imqt809f3+euLmqQnLQX3tjsB0v8UuJbjPfGf7f/ hoK/E9rCl0LoJZV+gWn/F5gGRWDgPtvw4jIsg1DUEA24oQ5lf3u94AzEM79Y+AJa6PXJCg6YR2SI EDB4uQuzwZPLoho8k/APDIO34IcJFyOneg4Pye05PCxpBR3eX6dLT4SstCIUOby9kK7Q3OFxeUlR T8dyWBxeirQmhyflF9fhazt8rKv/GsDRP/wOz8tosDvD6743d+eqra1lve3czber9euZ79Ydu2XH NrHH8u6cr5Zp0gj88Kqzpe1ez99IX/aijisBz45vcd6XZXOvX9bl3bLu2Gw7240mXd7ijGtgtWzb EYl7nGUN7zb360mx3K3/xuScqhDYW5xdZdx2LleLVar5S79adry840X+CorMseIFMcNZ7FqBtDeo agX91WIHwiCrG7l+TIs1RmCHN1QWf3ZIOpwPN4cz4sbPo/5fYNr/Bab9X2Da/wWm/V9g2v8Fpv1f YNr/Bab9X2Da/wWm/V9gmuJPgIvcJUiCIkjijleuFy8A8id4IpQBfdjkTyajwwZAeF43AmlBWLvB WxHUanUGHxaD90OryeDd8Itr8KiwxTJ4J1rBYfDGtAKqwbvQCkgGjw9b0Bi8AX5B+W3X6tYE6FoG n6mlE46g7ruzfb3arFJu74U9od0wOrstHc4NI4crXHPGfP//HYYMP0Y7liU+DWhQjyzlKgKvezvf 3B+NQPz/Kzn8rPuyJMuy96OtIWuXDJPH0uCscEvTNzicJkuGwWHhuMgeyjQ4EK4eIecjDj9g8CFp APbIz/cLmviFxTHOZ47xyM/j8SMSX1jgh2Xe5PJLvM4VEfj8Bp9H4/O67IJuX+SHhFJ2vdScSf/L +Es7bIPF/w6rvK2CwSvZOpSRNkMXo37oS6HVYvJOcDrujSa9Vm5wzBeY9n+Baf8XmPZ/gWn/F5j2 f4Fp/xeY9n+Baf8XmPZ/gWn/F5iGipOkRpQacRaEyRGnS9zB4GcMftrg3YnyoaVNlAlB9Q3emCA3 gkwJqmPwdgRpE1fT4P0IMiaomsFXNfgqBl/Z4CsZPAXBIDRrE/cMPkIoQhGKcg5f1uDLGHxpgy9l 8OEz+JI+y+IOX8zgJwy+qMGPG3x4Db6IwRc2eG+CChl8QYMvYPD5DT6fwec1+DwGn9vgw2PwuQw+ 5A0+p8H7EjRq8KKE5TD47Abvi1c2g89q8FkMfsjgBw0+s8GHy+AzGXxGg5el1W/wfQYfToM3I6jH 4LsN3qvC4fDpDT6dwYecwVsSFDIGn9ZnGVIOn8bgJWntDL7L4DsNvsNnGdHgU1osDRahEJhW9OrT XjkQ/OR77fDL3yz/X2AwNf7parkwNB2nLbE1Js+aVWGn/gUi1495jRM9UHtC5fBbkk/ktxwW8OcK 7i8wgDb8l6tnzGxgyiNcPYu1sJp9J2DfaOD9BQa0vp64oZj/QJQw+IFwWKzp9f2lvH3Y4TtdcG9z aAfbFxhsFf/2Urmp/AfqC3yJUYf1JKdXvzYF3942qP+pTHKbjPXWC8dfYMiS/g5oBoSr57+QD+UR 4Hn9303IfyBC2n/iKq/2x65VVN31w843MF9gVsf/xXVe/PwdCOmF+noL+HNPuYVqQzhQX+BqCLa/ g+AuCoeFzQzjfCXVCIXAtD8UAtOOq779DMza4ux4KD9WGbedy9VilWr+0q+WHU8YSZgwnbHH5Ege U7TFjfssxvP+yHnClJxPA/8Fpv1fYNBQSwECFAAKAAYABgC9SxopDiVTORMzAAAA1gAACgASAAAA AAAAAAAApIEAAAAAVEQtNDRkLmRvYwUnDgBaUElUV0RCTk1TV0QBAFBLBQYAAAAAAQABAEoAAABN MwAAAAA= ------=_NextPart_000_005C_01C01403.1790D900-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Sep 1 22:28:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25446 for ; Fri, 1 Sep 2000 22:28:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B242B44338; Fri, 1 Sep 2000 21:27:58 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3BB0744336 for ; Fri, 1 Sep 2000 21:27:55 -0400 (EDT) Received: from dynamicsoft.com (1Cust214.tnt4.freehold.nj.da.uu.net [63.36.112.214]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA11142; Fri, 1 Sep 2000 22:25:52 -0400 (EDT) Message-ID: <39B0648B.F4D99D53@dynamicsoft.com> Date: Fri, 01 Sep 2000 22:23:07 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: James Undery , IPTEL Subject: Re: [IPTEL] CPL log nodes References: <39AF66E3.AED1763@ubiquity.net> <39AFAC48.C3399D1A@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > I would even argue that absolute file name references are bad in the > context. This should be a *logical* name, which the system should > translate in whatever way it sees fit. I agree completely. In fact, I don't even think its really a requirement that the log be a physically separate file; it could just be content labeled in some way within a larger CPL-wide log. > > I believe this feature is useful only under two circumstances: > > - the ability to retrieve the log file and/or > > - the ability to check whether a new call matches an existing call in > one of the logs > > That way, for example, one can easily build a service such as "only > allow this person to call me if I have called the person before". This > type of abstraction is fully within the scope of CPL and easy to express > as a switch. I'd rather keep things simple and stick to what we have in CPL now; this can wait till the next rev or an extension or something. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Sep 1 22:47:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26598 for ; Fri, 1 Sep 2000 22:47:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 49FF344370; Fri, 1 Sep 2000 21:46:56 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4449144360 for ; Fri, 1 Sep 2000 21:46:53 -0400 (EDT) Received: from dynamicsoft.com (1Cust214.tnt4.freehold.nj.da.uu.net [63.36.112.214]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA11171; Fri, 1 Sep 2000 22:48:34 -0400 (EDT) Message-ID: <39B069DC.6B063419@dynamicsoft.com> Date: Fri, 01 Sep 2000 22:45:48 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Orit Levin Cc: "Lennox, Jonathan" , IPTEL WG References: <006001c01424$9f0ecf60$6dd8a8c0@orit.us.radvision.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] Re: [CPL] The Liaison Statement from ITU-T SG16 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit For the benefit of this list, enclosed is the text of this liaison statement in ASCII form. Comments? ITU - Telecommunication Standardization Sector TD -44c STUDY GROUP 16 Portland, 25 August, 2000 QUESTIONS: Q.22/11 (for action) SOURCE: Q13/16 TITLE: COMMENTS ON CPL DRAFT LIAISON STATEMENT TO: IETF IPTEL WG on CPL APPROVAL: Agreed to at Q.13/16 Rapporteurs meeting (Portland, 21-25 August 2000) FOR: ACTION required response by 1st November 2000 CONTACTS: Mr. Dale Skran, Rapporteur for Q.13/16 Tel: +1 732 625 3003 x202 Sonus Networks, 4400 Route 9 South, Suite 3500, Freehold, NJ 07728, USA Email: dskran@Sonusnet.com Abstract: This contribution discusses possible use of CPL in the context of H.323 and provides remarks for the current CPL specification. 1 Trying to apply CPL to H.323 According to our understanding, one of the original CPL goals was to make the definition independent from the specific underlying Call Signaling Protocol. It can be seemed as an "abstract" API definition for a specific Application, allowing for different protocols to actually implement it. The CPL, as it is defined today, can be used to describe the behavior of an H.323 Server. Nevertheless, the main concern is that the CPL specification is not structured in a way allowing a separation of the "abstract" concepts from their mapping into a specific system or into specific protocol fields. Moreover, many of the CPL "abstracts" are defined by providing examples or pointers to SIP-related IETF documents. This forces the writer of the CPL script to become familiar with the details and considerations behind the SIP design. This situation led for the inclusion of a limiting H.323 interpretation into the body of the CPL definition. In some cases, this interpretation is inconsistent with the SIP interpretation of the CPL. 2 The Proposed "Roadmap" Based on the "advanced" CPL standardization stage within the IETF, the following is proposed for the consideration: For the current CPL version, it is proposed to correct the "editorial" errors, described in the following chapter, within the CPL document. H.323 community will define a more flexible interpretation of H.323 behavior being expressed by the CPL. New "features" may be introduced by expanding the CPL definitions. (This "extension" practice, in some cases, is allowed by the CPL specification.) The output of this work will be included into H.323 "Annex O" and will be published as an Informational RFC. CPL nodes differ in their "abstraction level". A certain group of the CPL nodes (such as dealing with the time conditions) is naturally not dependent on the Call Signaling Protocol. Another group, such as "address-resolution" look-ups, is dependent on the System definition. In addition, the CPL "address-processing" and "string-processing" nodes define a "lower-level" logic, binding the CPL definitions with the certain fields of the Call Signaling messages. Therefore, for the next CPL version, It is proposed to re-arrange the CPL Specification by grouping the nodes, based on their "abstraction level". - For the "low level" nodes, it is proposed to split between their "abstract description" and the actual mapping into a specific Signaling protocol - For the benefit of the CPL user (i.e. the CPL script writer), it is also proposed to define the meaning of each "node" and provide its "design considerations" from the application point of view, without referencing to the SIP details. 3 Specific H.323 Comments 3.1 Thedefinition of "incoming" and "outgoing" From the [CPL]: "Two top-level action names are defined: incoming, the action performed when a call arrives whose destination is the owner of the script; and outgoing, the action performed when a call arrives whose originator is the owner of the script." In H.323, there is no explicit concept of the "intermediate Call Signaling Server" and the CPL "destination" field will NOT usually hold the address of the Call Signaling Server itself. Therefore, it is proposed to revise the quoted above definition. 3.2 Mapping of ASN.1 structures into ABNF Various H.323 ASN.1 definitions should be mapped to ABNF in order to be used within text based languages and protocols. Examples include H.225.0 AliasAddress definitions for PartyNumber and mobileUIM; and the TransportAddress definition. It is proposed to introduce such definitions in H.323 "Annex O" and reference them (or reproduce them till the "Annex O" is decided). 3.3 CPL "Address Switch" Current CPL definition has a concept of two, applicable to H.323, "address" field definitions: "origin" and "original-destination". On the contrary, H.323 defines many address fields that may be of interest of the CPL user. Moreover, more then one alias may exist in a single H.323 message. Mandating of choosing one single alias out of a number of possibilities is limiting for H.323 systems. The current CPL version allows for an expression like that: "If one of the alias fields of different types matches, the specified for it, condition, then ...". Unfortunately, this option is left out of the CPL Specification. Based on the remarks above, it is proposed that the current CPL specification will state that the "Address switch mapping for H.323" Chapter is "an illustration only" for how the CPL fields can be mapped into the H.323 fields. The third CPL "address" definition is called "destination". It reflects the SIP concept of intermediate Call Signaling Server. Therefore, the current mapping of H.225.0 redirectingNumberIE into the CPL "destination" concept is inconsistent with the SIP interpretation of the same field. For example, in case of the "incoming call", the H.225.0 destCallSignalAddress field fits the concept of CPL "destination" more closely. (This redirectingNumberIE element is, by mistake, called a "redirectedNumber" by the CPL) 3.4 Location Lookup The "Lookup" CPL node is a Call Signaling-independent concept. It fits both the H.323 and the SIP architectures. Nevertheless, bounding of the "location lookup" itself with the further operations to be applied to its results (such as capabilities filtering), seems to be a limiting design consideration. It is proposed to define these two actions (i.e. the lookup and the filtering on the output) as two separate CPL nodes. 3.4.1 "Caller Preferences and Callee Capabilities" As a part of CPL "Location Lookup" Switch, a filtering capability on "caller preferences" is defined. These CPL parameters are based solely on the "caller preferences" specified by one of the SIP extensions ["Caller Preferences and Callee Capabilities"]. The "Generic Framework", lately introduced into H.323, has essentially the same concept. Although, the following difference exists: CPL is limited to the scope of a Call. The "Generic Framework" of H.323 addresses both the Registration and the Call Establishment stages. H.323 Community will work to apply the "Generic Framework" to the CPL work. 3.5 "Location" A significant problem is that CPL generates outbound call signaling based on a Location element which currently can only be a URL. Some significant data that should be used in the outgoing signaling, e.g, redirection reason, are not available in current H.323 URL and may not naturally fit into such URLs. It would be desirable to have a more flexible way to set such parameters, but this may require more study than can be accomplished for the current version of CPL. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun Sep 3 01:24:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23472 for ; Sun, 3 Sep 2000 01:24:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CCC3344390; Sun, 3 Sep 2000 00:24:13 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 97EF244336 for ; Sun, 3 Sep 2000 00:24:10 -0400 (EDT) Received: from dynamicsoft.com (1Cust182.tnt5.freehold.nj.da.uu.net [63.36.113.182]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA12069; Sun, 3 Sep 2000 01:25:55 -0400 (EDT) Message-ID: <39B1E044.BF12899D@dynamicsoft.com> Date: Sun, 03 Sep 2000 01:23:16 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: James Undery , iptel@lists.bell-labs.com Subject: Re: [IPTEL] supporting CPL versions References: <39A4F1A6.87F7A386@indigosw.com> <39A4F5B4.BD3E3EE2@ubiquity.net> <39A5275C.3AADBE1F@dynamicsoft.com> <39A535F1.48928278@ubiquity.net> <39A5FC2D.F49020AB@dynamicsoft.com> <39A6379C.DCC21EA3@ubiquity.net> <39AF5AC2.1016B520@dynamicsoft.com> <39AFAB1E.D73D303D@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > > > > So, is there consensus around this? We keep the time-switch from the > > older drafts, and then think about defining the iCal one for the next > > CPL rev once we understand its usage better? Any objections? > > > > I'm *very* uncomfortable with this. At the very least, we need to define > how CPL can be reasonably extended in the future. Also, if we go that > route, I would suggest going for real simplicity, i.e., fixed time range > only, as a proper subset of the iCal specification. That will make for a > much cleaner transition strategy rather than mixing two models. That > way, we have an overall implementation that's simpler. I have no problem using a subset of iCal; namely the start and stop times, duration, and repitition stuff. The complexity is all in the byX attributes. I wouldn't be so concerned about doing these if someone could show me some pseudocode about how these might be implemented in a reasonable way. If the pseudocode for this is many pages, then I definitely need to question whether its worth it... Regarding extensibility: Ignoreing unknown attributes and tags (but parsing the content of unknown tags) seems a reasonable thing for extensibility, but has the unfortunate side effect of eliminating the possibility of DTD validation. Is there any way to build extensibility in without ruling out validation of a script against the DTD in the baseline CPL specification? -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun Sep 3 09:08:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08774 for ; Sun, 3 Sep 2000 09:08:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D962F44387; Sun, 3 Sep 2000 08:08:10 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157]) by lists.bell-labs.com (Postfix) with ESMTP id 81E8C4436F for ; Sun, 3 Sep 2000 08:08:07 -0400 (EDT) Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id JAA28275; Sun, 3 Sep 2000 09:07:20 -0400 (EDT) Message-ID: <39B24D1B.2D64DA2A@cs.columbia.edu> Date: Sun, 03 Sep 2000 09:07:39 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: James Undery , iptel@lists.bell-labs.com Subject: Re: [IPTEL] supporting CPL versions References: <39A4F1A6.87F7A386@indigosw.com> <39A4F5B4.BD3E3EE2@ubiquity.net> <39A5275C.3AADBE1F@dynamicsoft.com> <39A535F1.48928278@ubiquity.net> <39A5FC2D.F49020AB@dynamicsoft.com> <39A6379C.DCC21EA3@ubiquity.net> <39AF5AC2.1016B520@dynamicsoft.com> <39AFAB1E.D73D303D@cs.columbia.edu> <39B1E044.BF12899D@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit > I have no problem using a subset of iCal; namely the start and stop > times, duration, and repitition stuff. The complexity is all in the byX > attributes. I wouldn't be so concerned about doing these if someone > could show me some pseudocode about how these might be implemented in a > reasonable way. If the pseudocode for this is many pages, then I > definitely need to question whether its worth it... I think a subset makes sense for now. > Regarding extensibility: > > Ignoreing unknown attributes and tags (but parsing the content of > unknown tags) seems a reasonable thing for extensibility, but has the > unfortunate side effect of eliminating the possibility of DTD > validation. Is there any way to build extensibility in without ruling > out validation of a script against the DTD in the baseline CPL > specification? I don't like just ignoring attributes. That's why I suggested that, in addition, CPL itself has the ability to switch on extensions, so that one can implement default behavior if a particular feature is not supported. Outside of making extensions just parameter values, it will be hard to anticipate DTDs. I'm also not sure it matters. If the creator can generate new features, it presumably can validate them. If the server doesn't understand the feature, it doesn't much matter whether it is syntactically correct. The only borderline case is that a new feature is really just a mis-spelling of an old one. Having the switch around the feature would tell the server whether it should go checking, but unfortunately, I suspect that no XML checker would be smart enough for that. Namespaces? _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun Sep 3 14:40:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11247 for ; Sun, 3 Sep 2000 14:40:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 617C144351; Sun, 3 Sep 2000 13:40:30 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lists.bell-labs.com (Postfix) with ESMTP id E835A44348 for ; Sun, 3 Sep 2000 13:40:26 -0400 (EDT) Received: from fokus.gmd.de (shaky [193.175.132.94]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id UAA28968; Sun, 3 Sep 2000 20:40:18 +0200 (MET DST) Message-ID: <39B29B1E.D3290525@fokus.gmd.de> Date: Sun, 03 Sep 2000 20:40:30 +0200 From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: Jonathan Rosenberg , James Undery , iptel@lists.bell-labs.com Subject: Re: [IPTEL] supporting CPL versions References: <39A4F1A6.87F7A386@indigosw.com> <39A4F5B4.BD3E3EE2@ubiquity.net> <39A5275C.3AADBE1F@dynamicsoft.com> <39A535F1.48928278@ubiquity.net> <39A5FC2D.F49020AB@dynamicsoft.com> <39A6379C.DCC21EA3@ubiquity.net> <39AF5AC2.1016B520@dynamicsoft.com> <39AFAB1E.D73D303D@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > At the very least, we need to define > how CPL can be reasonably extended in the future. I second this. Extensibility is needed since both signaling and signaling processing are likely to evolve further. CPL's extensibility concept is not documented right now. (There is only a recommendation in Section 12.1 of RFC2824 to inform users of unknown features included in scripts.) In particular, we need to document how CPL interpreters deal with unknown elements (UE) in CPL scripts. Two possible (RFC-2824-conformant) strategies I see are: 1) conservative '- on installation: reject scripts that include unknown elements (UE)' 2) liberal '- on installation: accept scripts with UEs, issue warnings; - in run-time: if UEs encountered, skip them and pass control to UE handlers embedded in the CPL scripts' My preference is 2. Jiri _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Sep 4 00:50:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17121 for ; Mon, 4 Sep 2000 00:50:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E5F3A44398; Sun, 3 Sep 2000 23:50:18 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 12B6D44348 for ; Sun, 3 Sep 2000 23:50:16 -0400 (EDT) Received: from dynamicsoft.com (1Cust19.tnt1.freehold.nj.da.uu.net [63.17.113.19]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA00878; Mon, 4 Sep 2000 00:50:15 -0400 (EDT) Message-ID: <39B3296F.1D28EC17@dynamicsoft.com> Date: Mon, 04 Sep 2000 00:47:43 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: James Undery , iptel@lists.bell-labs.com Subject: Re: [IPTEL] supporting CPL versions References: <39A4F1A6.87F7A386@indigosw.com> <39A4F5B4.BD3E3EE2@ubiquity.net> <39A5275C.3AADBE1F@dynamicsoft.com> <39A535F1.48928278@ubiquity.net> <39A5FC2D.F49020AB@dynamicsoft.com> <39A6379C.DCC21EA3@ubiquity.net> <39AF5AC2.1016B520@dynamicsoft.com> <39AFAB1E.D73D303D@cs.columbia.edu> <39B1E044.BF12899D@dynamicsoft.com> <39B24D1B.2D64DA2A@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > > I have no problem using a subset of iCal; namely the start and stop > > times, duration, and repitition stuff. The complexity is all in the byX > > attributes. I wouldn't be so concerned about doing these if someone > > could show me some pseudocode about how these might be implemented in a > > reasonable way. If the pseudocode for this is many pages, then I > > definitely need to question whether its worth it... > > I think a subset makes sense for now. OK, so the trick is to define exactly which subset. My initial proposal is: Parameters: dtstart Start of interval (RFC 2445 DATE-TIME) dtend End of interval (RFC 2445 DATE-TIME) duration Length of interval (RFC 2445 DURATION) freq Frequency of recurrence (one of "secondly", "minutely", "hourly", "daily", "weekly", "monthly", or "yearly") interval How often the recurrence repeats until Bound of recurrence (RFC 2445 DATE-TIME) count Number of occurences of recurrence I wouldn't even object to adding the byX attributes under the condition of "contraction", that is, the unit in the by component is always a greater interval than the freq component. These cases are easier to handle, it seems. You compute the start time of the next interval as if there were bo byX parameter, and then check if this start time is within the interval indicated by the byX parameter. What do people think? > > > Regarding extensibility: > > > > Ignoreing unknown attributes and tags (but parsing the content of > > unknown tags) seems a reasonable thing for extensibility, but has the > > unfortunate side effect of eliminating the possibility of DTD > > validation. Is there any way to build extensibility in without ruling > > out validation of a script against the DTD in the baseline CPL > > specification? > > I don't like just ignoring attributes. That's why I suggested that, in > addition, CPL itself has the ability to switch on extensions, so that > one can implement default behavior if a particular feature is not > supported. > > Outside of making extensions just parameter values, it will be hard to > anticipate DTDs. I'm also not sure it matters. If the creator can > generate new features, it presumably can validate them. If the server > doesn't understand the feature, it doesn't much matter whether it is > syntactically correct. The only borderline case is that a new feature is > really just a mis-spelling of an old one. Having the switch around the > feature would tell the server whether it should go checking, but > unfortunately, I suspect that no XML checker would be smart enough for > that. Namespaces? THe problem isn't restricted to mis-spellings. Here is what I am talking about. If I have some extension foo, and I use your approach of having a tag which indicates what to do if the extension isn't supported: This little CPL won't be accepted by baseline CPLs, since they won't know about foo in the DTD and thus the script is immediately rejected. The only way I know of to turn off parsing for subcompnents is via CDATA: ]]> Parsers that do understand foo could conceivably extract the content of the CDATA and then re-validate. A bit of a pain, but it would work. Nesting of if tags is a bit annoying, since the XML parser will pick up the first ]] and not the last, as you would want. Not sure what to do about that... -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Sep 4 21:50:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09909 for ; Mon, 4 Sep 2000 21:50:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1B29144337; Mon, 4 Sep 2000 20:50:27 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id D80CF44337 for ; Mon, 4 Sep 2000 11:45:52 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA04520; Mon, 4 Sep 2000 12:45:25 -0400 (EDT) Message-ID: <39B3D1A5.1812CCAD@cs.columbia.edu> Date: Mon, 04 Sep 2000 12:45:25 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: James Undery , iptel@lists.bell-labs.com Subject: Re: [IPTEL] supporting CPL versions References: <39A4F1A6.87F7A386@indigosw.com> <39A4F5B4.BD3E3EE2@ubiquity.net> <39A5275C.3AADBE1F@dynamicsoft.com> <39A535F1.48928278@ubiquity.net> <39A5FC2D.F49020AB@dynamicsoft.com> <39A6379C.DCC21EA3@ubiquity.net> <39AF5AC2.1016B520@dynamicsoft.com> <39AFAB1E.D73D303D@cs.columbia.edu> <39B1E044.BF12899D@dynamicsoft.com> <39B24D1B.2D64DA2A@cs.columbia.edu> <39B3296F.1D28EC17@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > Parameters: dtstart Start of interval (RFC 2445 DATE-TIME) > dtend End of interval (RFC 2445 DATE-TIME) > duration Length of interval (RFC 2445 DURATION) > freq Frequency of recurrence (one of "secondly", > "minutely", "hourly", "daily", "weekly", > "monthly", or "yearly") > interval How often the recurrence repeats > until Bound of recurrence (RFC 2445 DATE-TIME) > count Number of occurences of recurrence > > I wouldn't even object to adding the byX attributes under the condition > of "contraction", that is, the unit in the by component is always a > greater interval than the freq component. These cases are easier to > handle, it seems. You compute the start time of the next interval as if > there were bo byX parameter, and then check if this start time is within > the interval indicated by the byX parameter. > > What do people think? Seems like a good idea. We should probably check whether this covers the common recurrence cases such as - Tu and Th, some time range - first Monday of the month (as in Labor Day...) > THe problem isn't restricted to mis-spellings. Here is what I am talking > about. If I have some extension foo, and I use your approach of having a > tag which indicates what to do if the extension isn't supported: > > > > > > This little CPL won't be accepted by baseline CPLs, since they won't > know about foo in the DTD and thus the script is immediately rejected. > The only way I know of to turn off parsing for subcompnents is via > CDATA: > > > > ]]> > > > Parsers that do understand foo could conceivably extract the content of > the CDATA and then re-validate. A bit of a pain, but it would work. > Nesting of if tags is a bit annoying, since the XML parser will pick up > the first ]] and not the last, as you would want. Not sure what to do > about that... This seems ugly. Would namespaces help? -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Sep 5 06:18:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26879 for ; Tue, 5 Sep 2000 06:18:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 10C0244345; Tue, 5 Sep 2000 05:18:47 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 67E8144336 for ; Tue, 5 Sep 2000 05:18:43 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id LAA21792; Tue, 5 Sep 2000 11:16:18 +0100 (BST) Message-ID: <39B4C7F4.BD4D03FF@ubiquity.net> Date: Tue, 05 Sep 2000 11:16:20 +0100 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: Jonathan Rosenberg , iptel@lists.bell-labs.com Subject: Re: [IPTEL] supporting CPL versions References: <39A4F1A6.87F7A386@indigosw.com> <39A4F5B4.BD3E3EE2@ubiquity.net> <39A5275C.3AADBE1F@dynamicsoft.com> <39A535F1.48928278@ubiquity.net> <39A5FC2D.F49020AB@dynamicsoft.com> <39A6379C.DCC21EA3@ubiquity.net> <39AF5AC2.1016B520@dynamicsoft.com> <39AFAB1E.D73D303D@cs.columbia.edu> <39B1E044.BF12899D@dynamicsoft.com> <39B24D1B.2D64DA2A@cs.columbia.edu> <39B3296F.1D28EC17@dynamicsoft.com> <39B3D1A5.1812CCAD@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > > > > > > > Parameters: dtstart Start of interval (RFC 2445 DATE-TIME) > > dtend End of interval (RFC 2445 DATE-TIME) > > duration Length of interval (RFC 2445 DURATION) > > freq Frequency of recurrence (one of "secondly", > > "minutely", "hourly", "daily", "weekly", > > "monthly", or "yearly") > > interval How often the recurrence repeats > > until Bound of recurrence (RFC 2445 DATE-TIME) > > count Number of occurences of recurrence > > > > I wouldn't even object to adding the byX attributes under the condition > > of "contraction", that is, the unit in the by component is always a > > greater interval than the freq component. These cases are easier to This is a bit late in the day to have a change of heart, but I've just actually thought about implementing this efficiently, and I can't see what the fuss was. Firstly check all the byX's are satisfied. Secondly find if the if the time lies in a repetition of the time period. Jonathan, correctly state if there is repetition the second step is harder, however, this can be calculated in constant time with the correct time representation (depends on the freq, yearly and monthly RFC 2445 DATE-TIME is good, all other seconds are fine), then normalise your timeframe on dtstart and use modulo arithmetic to check if you are in a repetition. I assume calculating the bounds of occurences (if they exist) cause no problem for anyone. There is a mistake in the spec though "No parameters other than dtstart, dtend and duration SHOULD be specified unless freq is present." The byX parameters need not be excluded as they make perfect sense in a single period. (Also I removed a surplus comma after dtend) > > > handle, it seems. You compute the start time of the next interval as if > > there were bo byX parameter, and then check if this start time is within > > the interval indicated by the byX parameter. > > > > What do people think? > > Seems like a good idea. We should probably check whether this covers the > common recurrence cases such as > > - Tu and Th, some time range