From anderson@yahoo.com Tue, 2 Aug 2005 07:29:05 +0200 (MEST) From: "Hohenemser" Date: Tue, 2 Aug 2005 07:29:05 +0200 (MEST) Subject: Best love dr@gs at best store! Message-ID: <002b01c54b50$10e49590$de01a8c0@wlnfnf> MIME-Version: 1.0 Content-Type: text/html One Time DISC0UNT 0RDER for V1@GRA, C1al1s! V1@GRA DISC0UNT 0RDER T0DAY Its only $0.95 per dose. Generic Vi@gra, 24 x 100mg Regular Tabs (48 dozes) Only $ 46.00 NEW PRODUCT 1: Generic Viagra, 24 x 100mg Soft Tabs (48 dozes) What is Soft Tabs? Only $ 60.00 NEW PRODUCT 2: Generic C1al1s, 10 x 20mg Tadalafil What is Soft C1al1s? Only $ 68.00 Special offer! These prices are valid until 10th of December ! V1@GRA DISC0UNT 0RDER From anderson@yahoo.com Tue, 2 Aug 2005 07:29:09 +0200 (MEST) From: "Fish" Date: Tue, 2 Aug 2005 07:29:09 +0200 (MEST) Subject: Primary source of OEM Windows software Look no further ! Message-ID: <002b01c54b50$10e49590$de01a8c0@jdkwd7ssa> MIME-Version: 1.0 Content-Type: text/html TOP quality software: Special Offer #1: Windows XP Professional+Microsoft Office XP Professional = only $80 Special Offer #2: Adobe - Photoshop 7, Premiere 7, Illustrator 10 = only $120 Special Offer #3: Macromedia Dreamwaver MX 2004 + Flash MX 2004 = only $100 Also: Windows 2003 Server Windows 2000 Workstation Windows 2000 Server Windows 2000 Advanced Server Windows 2000 Datacenter Windows NT 4.0 Windows Millenium Windows 98 Second Edition Windows 95 Office XP Professional Office 2000 Office 97 MS Plus MS SQL Server 2000 Enterprise Edition MS Visual Studio .NET Architect Edition MS Encarta Encyclopedia Delux 2004 MS Project 2003 Professional MS Money 2004 MS Streets and Trips 2004 MS Works 7 MS Picture It Premium 9 MS Exchange 2003 Enterprise Server Adobe Photoshop Adobe PageMaker Adobe Illustrator Adobe Acrobat 6 Professional Adobe Premiere Macromedia Dreamwaver MX 2004 Macromedia Flash MX 2004 Macromedia Fireworks MX 2004 Macromedia Freehand MX 11 Corel Draw Graphics Suite 12 Corel Draw Graphics Suite 11 Corel Photo Painter 8 Corel Word Perfect Office 2002 Norton System Works 2003 Borland Delphi 7 Enterprise Edition Quark Xpress 6 Passport Multilanguage Enter Here From anderson@yahoo.com Tue, 2 Aug 2005 07:29:12 +0200 (MEST) From: "Horowitz" Date: Tue, 2 Aug 2005 07:29:12 +0200 (MEST) Subject: Any med for your girl to be happy! Message-ID: <002b01c54b50$10e49590$de01a8c0@mmwedw> MIME-Version: 1.0 Content-Type: text/html Your girl is unsatisfied with your potency? Don't wait until she finds another men! Click here to choose from a great variety of LICENSED love t@bs! Best pri$es, fast shipping and guaranteed effect! Here you buy it right from warehouse! We are VERIFIED BY BBB and APPROVED BY VISA! From GilbertChan@adversecreditloans.co.uk Wed, 3 Aug 2005 07:51:17 +0200 (MEST) From: "Ramona Samuels" Date: Wed, 3 Aug 2005 07:51:17 +0200 (MEST) Subject: Out of this WoRLD $aving$ on all Adobe, Windows titles Message-ID: <0EGyO8w0K8aWgh8i8vj6o5@basics.net> MIME-Version: 1.0 Content-Type: text/plain Title: m Opt-in Email Special Offer     unsubscribe me SEARCH Software TOP 10 NEW TITLES  ON SALE NOW! 1 Office Pro 2003 2 Adobe Photoshop 9.0 3 Windows XP Pro 4 Adobe Acrobat 7 Pro 5 Flash MX 2004 6 Corel Draw 12 7 Norton Antivirus 2005 8 Windows 2003 Server 9 Alias Maya 6 Wavefrt 10 Adobe Illustrator 11  See more by this manufacturer   Microsoft   Symantec   Adobe  Customers also bought   these other items...Microsoft Office Professional Edition *2003* MicrosoftChoose: View Other Titles   List Price:$499.00 Price:$69.99 You Save:$429.01 (86%) Availability: Available for INSTANT download! Coupon Code: ydr18Y9  Sales Rank: #1 System requirements  |  Other Versions Date Coupon Expires: August 31st, 2005 Average Customer Review: Based on 172154 reviews. Write a review. Adobe Photoshop CS2 V 9.0 AdobeChoose: View Other Titles   List Price:$599.00 Price:$69.99 You Save:$529.01 (90%) Availability: Available for INSTANT download! Coupon Code: ChJl2XW  Sales Rank: #2 System requirements  |  Other Versions Date Coupon Expires: August 31st, 2005 Average Customer Review: Based on 188149 reviews. Write a review. Microsoft Windows XP Professional or Longhorn Edition MicrosoftChoose: View Other Titles   List Price:$279.00 Price:$49.99 You Save:$229.01 (85%) Availability: Available for INSTANT download! Coupon Code: FPRByhP  Sales Rank: #3 System requirements  |  Other Versions Date Coupon Expires: August 31st, 2005 Average Customer Review: Based on 155843 reviews. Write a review. Adobe Acrobat Professional V 7.0 AdobeChoose: View Other Titles   List Price:$499.00 Price:$69.99 You Save:$429.01 (85%) Availability: Available for INSTANT download! Coupon Code: gdtdX  Sales Rank: #4 System requirements  |  Other Versions Date Coupon Expires: August 31st, 2005 Average Customer Review: Based on 19945 reviews. Write a review. From eugenio.pinto@fccn.pt Wed, 3 Aug 2005 18:25:20 +0200 (MEST) From: Eugenio Pinto Date: Wed, 3 Aug 2005 18:25:20 +0200 (MEST) Subject: [ietf-provreg] EPP Operations In-Reply-To: <046F43A8D79C794FA4733814869CDF07C0A648@dul1wnexmb01.vcorp.ad.vrsn.com> Message-ID: <42F0EFEB.2090009@fccn.pt> MIME-Version: 1.0 Content-Type: text/plain In Portugal (.pt) we are using host attributes for all domain delegations. The EPP feature that Scott remembered: "With host objects you can change an IP address, for example, without having to update (a potentially large number of) domains individually." turned us to the object concept of hosts. Now, with the introduction of EPP, we will have 2 different concepts: 1 - Internal hosts : objects with a "sponsoring client" witch is the "sponsoring client" of the superordinate domain name of that host 2 - External hosts : it's only needed a element with no IP adresses We were thinking about creating these external hosts as objects too. As they don't have IP addresses it's not necessary to update them. And we can just delete them if they are not associated with domain names anymore.. This would be an implicit creation of hosts at the domain creation (excluding the operation) and could possibly be used to the other type of hosts. Have you any comments about this implementation? --eugenio Hollenbeck, Scott wrote:
I am anyway questioning the usefulness of having host objects in EPP at all. IMHO the only purpose for a host object is for the host-to-IP mapping i.e. for the glue records. And glue records are only needed, if a nameserver is resolving its own superordinate domainname (neglecting the crossover games and stuff, which anyway are hard to detect). With host-as-attribute it is rather easy to require such a missing IP (just reject a domain create/update request, if name server attribute is subordinate and has no IP). Therefore I also do not see, why external hosts and internal hosts, which do not resolve the superordinate domainname, are treated differently in EPP. Or did I miss something here? Bernie, given that this was discussed extensively on the provreg list it's best if you review the provreg archives to get the scoop on the rationale. google can help find specific messages. One benefit I remember involved updates. With host objects you can change an IP address, for example, without having to update (a potentially large number of) domains individually. Thanks for letting me know that you're using host attributes. That's just the kind of info that needs to be shared. -Scott- From jug@schlund.de Wed, 3 Aug 2005 19:25:41 +0200 (MEST) From: Jens-Uwe Gaspar Date: Wed, 3 Aug 2005 19:25:41 +0200 (MEST) Subject: Re: [ietf-provreg] EPP Operations In-Reply-To: <046F43A8D79C794FA4733814869CDF07C0A648@dul1wnexmb01.vcorp.ad.vrsn.com> Message-ID: <42F0FE13.2000706@schlund.de> MIME-Version: 1.0 Content-Type: text/plain Dear Eugenio Pinto, your understanding of host-attributes / host-objects is not accurate. Let's assume the .pt-registry is using EPP1.0. A registry decides which "host-concept" they want to use: a) host-objects, or else b) host-attributes Let's consider this with an example: we want to create a domain with some nameservers: create domain 'foo.pt' with: nameserver #1: 'ns.foo.pt' nameserver #2: 'ns.bar.pt' nameserver #3: 'ns.baz.com' for (a): all nameservers must be created with an EPP create:host-command, nameserver #1 and #2 also need an IP because they are within the .pt-ZONE. After that you can create the domain using the created host-objects using . for (b): the nameservers are implicitly created given as parameter (attributes) to a create:domain-command using . Here only nameserver #1 needs an IP, because 'ns.foo.pt' is a subordinate or glue-nameserver for the domain 'foo.pt'. That's only a short usage. There are other implications of using host-objects or host-attributes. Read about them in the mail-archive of the provreg-list as Scott already mentioned. Hope this helps a bit. PS: BTW, also DNSBE (registry for .be) are using host-attributes with EPP. Kind regards, Jens-Uwe Gaspar Eugenio Pinto wrote: > In Portugal (.pt) we are using host attributes for all domain delegations. > > The EPP feature that Scott remembered: > > "With host objects you can change an IP address, for example, without > having to update (a potentially large number of) domains individually." > > turned us to the object concept of hosts. > > Now, with the introduction of EPP, we will have 2 different concepts: > > 1 - Internal hosts : objects with a "sponsoring client" witch is the "sponsoring client" of the superordinate domain name of that host > > 2 - External hosts : it's only needed a element with no IP adresses > > We were thinking about creating these external hosts as objects too. > As they don't have IP addresses it's not necessary to update them. > And we can just delete them if they are not associated with domain names anymore.. > > This would be an implicit creation of hosts at the domain creation (excluding the operation) and could possibly be used to the other type of hosts. > > Have you any comments about this implementation? > > --eugenio > > > > Hollenbeck, Scott wrote: > >>>I am anyway questioning the usefulness of having host objects >>>in EPP at >>>all. IMHO the only purpose for a host object is for the >>>host-to-IP mapping >>>i.e. for the glue records. And glue records are only needed, if a >>>nameserver is resolving its own superordinate domainname >>>(neglecting the >>>crossover games and stuff, which anyway are hard to detect). With >>>host-as-attribute it is rather easy to require such a missing IP >>>(just reject a domain create/update request, if name server >>>attribute is >>>subordinate and has no IP). Therefore I also do not see, why external >>>hosts and internal hosts, which do not resolve the superordinate >>>domainname, are treated differently in EPP. Or did I miss >>>something here? >>> >>> >> >>Bernie, given that this was discussed extensively on the provreg list >>it's best if you review the provreg archives to get the scoop on the >>rationale. google can help find specific messages. One benefit I >>remember involved updates. With host objects you can change an IP >>address, for example, without having to update (a potentially large >>number of) domains individually. >> >>Thanks for letting me know that you're using host attributes. That's >>just the kind of info that needs to be shared. >> >>-Scott- ________________________________________________________________________ Jens-Uwe Gaspar Schlund + Partner AG E-Mail: jug@schlund.de Brauerstr. 48 Tel. +49-721-91374-50 76135 Karlsruhe, Germany Fax +49-721-91374-20 http://www.schlund.de From jug@schlund.de Wed, 3 Aug 2005 20:03:34 +0200 (MEST) From: Jens-Uwe Gaspar Date: Wed, 3 Aug 2005 20:03:34 +0200 (MEST) Subject: Re: [ietf-provreg] EPP Operations In-Reply-To: <046F43A8D79C794FA4733814869CDF07C0A648@dul1wnexmb01.vcorp.ad.vrsn.com> Message-ID: <42F106F4.1080804@schlund.de> MIME-Version: 1.0 Content-Type: text/plain Dear Eugenio Pinto, apologies, forget my previous mail, your understanding of host-attr/objects is correct. I didn't correctly catch your "main question". If you want internally use host-objects as you described, it's totally normal to implicitly create objects for it in your repository. IMHO in mostly every database-model used to describe domains with host- attributes you need some kind of "host-objects" in your database. You may get problems when you treat your "db-host-objects" as real "host-objects" linking them also to other domains, because to other domains the "host-object" with IP is a host WITHOUT IP (e.g. 'foo.pt' with ns 'ns.foo.pt' and an IP <=> 'bar.pt' with same ns has no IP, because it's not a glue). That should be avoided. It could lead to a problem when deleting domains. You can create separate "host-objects" in your database when used with other domains, or use some (complex) logic to remove the IPs from the host when deleting its parent domain. To which fields you are mapping the values from an EPP-domain-request with hosts (with or without IPs) is up to you. You don't even need to store the "sponsoring-client" for a host (it's implicitly defined by the relationship to the domain). Kind regards, Jens-Uwe Gaspar Jens-Uwe Gaspar wrote: > Dear Eugenio Pinto, > > your understanding of host-attributes / host-objects is not accurate. >... > PS: BTW, also DNSBE (registry for .be) are using host-attributes with EPP. > > Kind regards, > > Jens-Uwe Gaspar > > Eugenio Pinto wrote: >> In Portugal (.pt) we are using host attributes for all domain delegations. >> >> The EPP feature that Scott remembered: >> >> "With host objects you can change an IP address, for example, without >> having to update (a potentially large number of) domains individually." >> >> turned us to the object concept of hosts. >> >> Now, with the introduction of EPP, we will have 2 different concepts: >> >> 1 - Internal hosts : objects with a "sponsoring client" witch is the "sponsoring client" of the superordinate domain name of that host >> >> 2 - External hosts : it's only needed a element with no IP adresses >> >> We were thinking about creating these external hosts as objects too. >> As they don't have IP addresses it's not necessary to update them. >> And we can just delete them if they are not associated with domain names anymore.. >> >> This would be an implicit creation of hosts at the domain creation (excluding the operation) and could possibly be used to the other type of hosts. >> >> Have you any comments about this implementation? >> >> --eugenio >> >> >> >> Hollenbeck, Scott wrote: >> >>>>I am anyway questioning the usefulness of having host objects >>>>in EPP at >>>>all. IMHO the only purpose for a host object is for the >>>>host-to-IP mapping >>>>i.e. for the glue records. And glue records are only needed, if a >>>>nameserver is resolving its own superordinate domainname >>>>(neglecting the >>>>crossover games and stuff, which anyway are hard to detect). With >>>>host-as-attribute it is rather easy to require such a missing IP >>>>(just reject a domain create/update request, if name server >>>>attribute is >>>>subordinate and has no IP). Therefore I also do not see, why external >>>>hosts and internal hosts, which do not resolve the superordinate >>>>domainname, are treated differently in EPP. Or did I miss >>>>something here? >>>> >>>> >>> >>>Bernie, given that this was discussed extensively on the provreg list >>>it's best if you review the provreg archives to get the scoop on the >>>rationale. google can help find specific messages. One benefit I >>>remember involved updates. With host objects you can change an IP >>>address, for example, without having to update (a potentially large >>>number of) domains individually. >>> >>>Thanks for letting me know that you're using host attributes. That's >>>just the kind of info that needs to be shared. >>> >>>-Scott- ________________________________________________________________________ Jens-Uwe Gaspar Schlund + Partner AG E-Mail: jug@schlund.de Brauerstr. 48 Tel. +49-721-91374-50 76135 Karlsruhe, Germany Fax +49-721-91374-20 http://www.schlund.de From Klaus.Malorny@knipp.de Wed, 3 Aug 2005 20:21:16 +0200 (MEST) From: Klaus Malorny Date: Wed, 3 Aug 2005 20:21:16 +0200 (MEST) Subject: Re: [ietf-provreg] EPP Operations In-Reply-To: <046F43A8D79C794FA4733814869CDF07C0A648@dul1wnexmb01.vcorp.ad.vrsn.com> Message-ID: <42F10B04.8050108@knipp.de> MIME-Version: 1.0 Content-Type: text/plain Jens-Uwe Gaspar wrote: > Dear Eugenio Pinto, > > your understanding of host-attributes / host-objects is not accurate. > > Let's assume the .pt-registry is using EPP1.0. > > A registry decides which "host-concept" they want to use: > > a) host-objects, or else > b) host-attributes > > Let's consider this with an example: we want to create a domain with some > nameservers: > > create domain 'foo.pt' with: > nameserver #1: 'ns.foo.pt' > nameserver #2: 'ns.bar.pt' > nameserver #3: 'ns.baz.com' > > for (a): > all nameservers must be created with an EPP create:host-command, > nameserver #1 and #2 also need an IP because they are within the > .pt-ZONE. After that you can create the domain using the created > host-objects using . > > for (b): > the nameservers are implicitly created given as parameter > (attributes) to a create:domain-command using . > Here only nameserver #1 needs an IP, because 'ns.foo.pt' is a > subordinate or glue-nameserver for the domain 'foo.pt'. > > That's only a short usage. There are other implications of using > host-objects or host-attributes. Read about them in the mail-archive > of the provreg-list as Scott already mentioned. > > Hope this helps a bit. > > PS: BTW, also DNSBE (registry for .be) are using host-attributes with EPP. > > Kind regards, > > Jens-Uwe Gaspar > > Eugenio Pinto wrote: > >> In Portugal (.pt) we are using host attributes for all domain >> delegations. >> >> The EPP feature that Scott remembered: >> >> "With host objects you can change an IP address, for example, without >> having to update (a potentially large number of) domains individually." >> >> turned us to the object concept of hosts. >> >> Now, with the introduction of EPP, we will have 2 different concepts: >> >> 1 - Internal hosts : objects with a "sponsoring client" witch is the >> "sponsoring client" of the superordinate domain name of that host >> >> 2 - External hosts : it's only needed a element with >> no IP adresses >> >> We were thinking about creating these external hosts as objects too. >> As they don't have IP addresses it's not necessary to update them. And >> we can just delete them if they are not associated with domain names >> anymore.. >> >> This would be an implicit creation of hosts at the domain creation >> (excluding the operation) and could possibly be used to >> the other type of hosts. >> >> Have you any comments about this implementation? >> >> --eugenio >> Hi all, just to clarify the term "implicit host creation": Readers of this term might think that host objects (RFC 3732) would be created implicitly with the host attributes. However, it is required that host objects may not be used in parallel with the host attributes. Section 1.1 RFC 3731 »A server operator MUST use one name server specification form consistently. A server operator that announces support for host objects in an EPP greeting MUST NOT allow domain attributes to describe a name server host machine. A server operator that does not announce support for host objects MUST allow domain attributes to describe a name server host machine.« regards, Klaus ___________________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeißer-Weg 9 Dipl. Inf. Klaus Malorny 44227 Dortmund Klaus.Malorny@knipp.de Tel. +49 231 9703 0 From Klaus.Malorny@knipp.de Wed, 3 Aug 2005 20:35:50 +0200 (MEST) From: Klaus Malorny Date: Wed, 3 Aug 2005 20:35:50 +0200 (MEST) Subject: Re: [ietf-provreg] EPP Document Updates In-Reply-To: <046F43A8D79C794FA4733814869CDF07B5E434@dul1wnexmb01.vcorp.ad.vrsn.com> Message-ID: <42F10E6F.2050703@knipp.de> MIME-Version: 1.0 Content-Type: text/plain Hollenbeck, Scott wrote: > [...] > -Scott- > Hi Scott, I did not read the whole thread, so it may have been mentioned there. Today, I discovered a small syntactic issue in the examples given in section 2.9. of RFC 3733. The elements that are used to describe the disclosure are missing the final slash, as they are empty. - - - 8< - - - Example element, flag="0": Example element, flag="1": - - - 8< - - - should read - - - 8< - - - Example element, flag="0": Example element, flag="1": - - - 8< - - - One thing that really puzzles me in this context is that a registrar cannot allow the disclosure of one component (that is normally not disclosed) and to disallow the disclosure of another component (that his normally disclosed) at the same time. But maybe I am just misunderstanding the wording. I think I have to reread this at a later point in time. regards, Klaus ___________________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeißer-Weg 9 Dipl. Inf. Klaus Malorny 44227 Dortmund Klaus.Malorny@knipp.de Tel. +49 231 9703 0 From eugenio.pinto@fccn.pt Wed, 3 Aug 2005 20:37:26 +0200 (MEST) From: Eugenio Pinto Date: Wed, 3 Aug 2005 20:37:26 +0200 (MEST) Subject: Re: [ietf-provreg] EPP Operations In-Reply-To: <046F43A8D79C794FA4733814869CDF07C0A648@dul1wnexmb01.vcorp.ad.vrsn.com> Message-ID: <42F10EDB.2030707@fccn.pt> MIME-Version: 1.0 Content-Type: text/plain Hi! Thanks for your answer. I have some comments inside it. --eugenio Jens-Uwe Gaspar wrote: > Dear Eugenio Pinto, > > apologies, forget my previous mail, your understanding of > host-attr/objects > is correct. I didn't correctly catch your "main question". > > If you want internally use host-objects as you described, it's totally > normal to implicitly create objects for it in your repository. > IMHO in mostly every database-model used to describe domains with host- > attributes you need some kind of "host-objects" in your database. > > You may get problems when you treat your "db-host-objects" as real > "host-objects" linking them also to other domains, because to other > domains the "host-object" with IP is a host WITHOUT IP (e.g. 'foo.pt' > with > ns 'ns.foo.pt' and an IP <=> 'bar.pt' with same ns has no IP, because > it's > not a glue). > That should be avoided. It could lead to a problem when deleting > domains. You can create separate "host-objects" in your database when > used with other domains, or use some (complex) logic to remove the IPs > from the host when deleting its parent domain. I think it's not so complex.. --eugenio > > To which fields you are mapping the values from an EPP-domain-request > with hosts (with or without IPs) is up to you. You don't even need > to store the "sponsoring-client" for a host (it's implicitly defined > by the relationship to the domain). > Yes, we are doing it but for the superordinate domain. --eugenio > Kind regards, > > Jens-Uwe Gaspar > > Jens-Uwe Gaspar wrote: > >> Dear Eugenio Pinto, >> >> your understanding of host-attributes / host-objects is not accurate. >> ... >> PS: BTW, also DNSBE (registry for .be) are using host-attributes with >> EPP. >> >> Kind regards, >> >> Jens-Uwe Gaspar >> >> Eugenio Pinto wrote: >> >>> In Portugal (.pt) we are using host attributes for all domain >>> delegations. >>> >>> The EPP feature that Scott remembered: >>> >>> "With host objects you can change an IP address, for example, >>> without having to update (a potentially large number of) domains >>> individually." >>> >>> turned us to the object concept of hosts. >>> >>> Now, with the introduction of EPP, we will have 2 different concepts: >>> >>> 1 - Internal hosts : objects with a "sponsoring client" witch is the >>> "sponsoring client" of the superordinate domain name of that host >>> >>> 2 - External hosts : it's only needed a element >>> with no IP adresses >>> >>> We were thinking about creating these external hosts as objects too. >>> As they don't have IP addresses it's not necessary to update them. >>> And we can just delete them if they are not associated with domain >>> names anymore.. >>> >>> This would be an implicit creation of hosts at the domain creation >>> (excluding the operation) and could possibly be used >>> to the other type of hosts. >>> >>> Have you any comments about this implementation? >>> >>> --eugenio >>> >>> >>> >>> Hollenbeck, Scott wrote: >>> >>>>> I am anyway questioning the usefulness of having host objects in >>>>> EPP at all. IMHO the only purpose for a host object is for the >>>>> host-to-IP mapping i.e. for the glue records. And glue records are >>>>> only needed, if a nameserver is resolving its own superordinate >>>>> domainname (neglecting the crossover games and stuff, which anyway >>>>> are hard to detect). With host-as-attribute it is rather easy to >>>>> require such a missing IP (just reject a domain create/update >>>>> request, if name server attribute is subordinate and has no IP). >>>>> Therefore I also do not see, why external hosts and internal >>>>> hosts, which do not resolve the superordinate domainname, are >>>>> treated differently in EPP. Or did I miss something here? >>>>> >>>> >>>> >>>> Bernie, given that this was discussed extensively on the provreg list >>>> it's best if you review the provreg archives to get the scoop on the >>>> rationale. google can help find specific messages. One benefit I >>>> remember involved updates. With host objects you can change an IP >>>> address, for example, without having to update (a potentially large >>>> number of) domains individually. >>>> >>>> Thanks for letting me know that you're using host attributes. That's >>>> just the kind of info that needs to be shared. >>>> >>>> -Scott- >>> > > ________________________________________________________________________ > Jens-Uwe Gaspar Schlund + Partner AG > E-Mail: jug@schlund.de Brauerstr. 48 > Tel. +49-721-91374-50 76135 Karlsruhe, Germany > Fax +49-721-91374-20 http://www.schlund.de From eugenio.pinto@fccn.pt Wed, 3 Aug 2005 20:41:30 +0200 (MEST) From: Eugenio Pinto Date: Wed, 3 Aug 2005 20:41:30 +0200 (MEST) Subject: Re: [ietf-provreg] EPP Operations In-Reply-To: <046F43A8D79C794FA4733814869CDF07C0A648@dul1wnexmb01.vcorp.ad.vrsn.com> Message-ID: <42F10FD8.4020401@fccn.pt> MIME-Version: 1.0 Content-Type: text/plain Hi Klaus! Thanks for your answer. It was all I need to know. --eugenio Klaus Malorny wrote: > Jens-Uwe Gaspar wrote: > >> Dear Eugenio Pinto, >> >> your understanding of host-attributes / host-objects is not accurate. >> >> Let's assume the .pt-registry is using EPP1.0. >> >> A registry decides which "host-concept" they want to use: >> >> a) host-objects, or else >> b) host-attributes >> >> Let's consider this with an example: we want to create a domain with >> some >> nameservers: >> >> create domain 'foo.pt' with: >> nameserver #1: 'ns.foo.pt' >> nameserver #2: 'ns.bar.pt' >> nameserver #3: 'ns.baz.com' >> >> for (a): >> all nameservers must be created with an EPP create:host-command, >> nameserver #1 and #2 also need an IP because they are within the >> .pt-ZONE. After that you can create the domain using the created >> host-objects using . >> >> for (b): >> the nameservers are implicitly created given as parameter >> (attributes) to a create:domain-command using . >> Here only nameserver #1 needs an IP, because 'ns.foo.pt' is a >> subordinate or glue-nameserver for the domain 'foo.pt'. >> >> That's only a short usage. There are other implications of using >> host-objects or host-attributes. Read about them in the mail-archive >> of the provreg-list as Scott already mentioned. >> >> Hope this helps a bit. >> >> PS: BTW, also DNSBE (registry for .be) are using host-attributes with >> EPP. >> >> Kind regards, >> >> Jens-Uwe Gaspar >> >> Eugenio Pinto wrote: >> >>> In Portugal (.pt) we are using host attributes for all domain >>> delegations. >>> >>> The EPP feature that Scott remembered: >>> >>> "With host objects you can change an IP address, for example, >>> without having to update (a potentially large number of) domains >>> individually." >>> >>> turned us to the object concept of hosts. >>> >>> Now, with the introduction of EPP, we will have 2 different concepts: >>> >>> 1 - Internal hosts : objects with a "sponsoring client" witch is the >>> "sponsoring client" of the superordinate domain name of that host >>> >>> 2 - External hosts : it's only needed a element >>> with no IP adresses >>> >>> We were thinking about creating these external hosts as objects too. >>> As they don't have IP addresses it's not necessary to update them. >>> And we can just delete them if they are not associated with domain >>> names anymore.. >>> >>> This would be an implicit creation of hosts at the domain creation >>> (excluding the operation) and could possibly be used >>> to the other type of hosts. >>> >>> Have you any comments about this implementation? >>> >>> --eugenio >>> > > > Hi all, > > just to clarify the term "implicit host creation": Readers of this > term might think that host objects (RFC 3732) would be created > implicitly with the host attributes. However, it is required that host > objects may not be used in parallel with the host attributes. > > Section 1.1 RFC 3731 > > »A server operator MUST use one name server > specification form consistently. A server operator that announces > support for host objects in an EPP greeting MUST NOT allow domain > attributes to describe a name server host machine. A server operator > that does not announce support for host objects MUST allow domain > attributes to describe a name server host machine.« > > regards, > > Klaus > > > ___________________________________________________________________________ > > | | > | knipp | Knipp Medien und Kommunikation GmbH > ------- Technologiepark > Martin-Schmeißer-Weg 9 > Dipl. Inf. Klaus Malorny 44227 Dortmund > Klaus.Malorny@knipp.de Tel. +49 231 9703 0 > > From shollenbeck@verisign.com Wed, 3 Aug 2005 22:43:06 +0200 (MEST) From: "Hollenbeck, Scott" Date: Wed, 3 Aug 2005 22:43:06 +0200 (MEST) Subject: RE: [ietf-provreg] EPP Document Updates Message-ID: <046F43A8D79C794FA4733814869CDF07C0AAAF@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain Thoughts below... > -----Original Message----- > From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de] > Sent: Wednesday, August 03, 2005 2:35 PM > To: Hollenbeck, Scott > Cc: ietf-provreg@cafax.se > Subject: Re: [ietf-provreg] EPP Document Updates > > I did not read the whole thread, so it may have been > mentioned there. Today, I > discovered a small syntactic issue in the examples given in > section 2.9. of RFC > 3733. The elements that are used to describe the disclosure > are missing the > final slash, as they are empty. > > - - - 8< - - - > > > > > > > > > > > Example element, flag="0": > > > > > > > > Example element, flag="1": > > > > > > > - - - 8< - - - > > should read > > - - - 8< - - - > > > > > > > > > > > Example element, flag="0": > > > > > > > > Example element, flag="1": > > > > > > > - - - 8< - - - You're exactly correct. Thanks for catching those errors. > One thing that really puzzles me in this context is that a > registrar cannot > allow the disclosure of one component (that is normally not > disclosed) and to > disallow the disclosure of another component (that his > normally disclosed) at > the same time. But maybe I am just misunderstanding the > wording. I think I have > to reread this at a later point in time. Remember that the whole "disclose" thing got crammed into the spec at the last minute at the demand of the IESG. There were parts that didn't make sense then (to me anyway) and I'm sure they still don't make sense now. This is another one of those things that we should really consider removing (if no one is using it) or revising (if it's not quite right). -Scott- From rmohan@afilias.info Thu, 4 Aug 2005 19:12:42 +0200 (MEST) From: "Ram Mohan" Date: Thu, 4 Aug 2005 19:12:42 +0200 (MEST) Subject: RE: [ietf-provreg] EPP Document Updates In-Reply-To: <046F43A8D79C794FA4733814869CDF07C0AAAF@dul1wnexmb01.vcorp.ad.vrsn.com> Message-ID: <200508041712.j74HCbhm018679@ns01.afilias.info> MIME-Version: 1.0 Content-Type: text/plain Scott, all, >This is another one of those things that we should really consider removing >(if no one is using it) or revising (if it's not quite right). We should consider re-initiating the provreg group. A number of changes are due in EPP, and enough registries are now using EPP that actual practice has exposed both issues and deviances from the protocol. Further, registries have implemented extensions that, in some cases, make more sense to be part of a standard -- the case of what happened with RGP is relevant here. In the ICANN meeting in Luxembourg, I spoke with a number of gTLD registries, who expressed interest in reviving the group. Specifically, I spoke with GNR, PIR, .TEL, MTLD, VeriSign and NeuStar; presumably direct notes from these registries are forth-coming. Several ccTLD registries also expressed interest in the topic, but did not outright have an opinion on restarting provreg. In light of both changes in practice and interest from practitioners, I would like to ask members of this list to express their opinion and interest in the re-initiation of the provreg group. -Ram -------------------------------------------------------------------------- Ram Mohan Chief Technology Officer Vice President, Business Operations Afilias (http://www.afilias.info) p: +1.215.706.5700 x103; f: +1.215.706.5701 m: +1.215.431.0958 e: rmohan@afilias.info -------------------------------------------------------------------------- From eugenio.pinto@fccn.pt Thu, 4 Aug 2005 20:04:23 +0200 (MEST) From: Eugenio Pinto Date: Thu, 4 Aug 2005 20:04:23 +0200 (MEST) Subject: Re: [ietf-provreg] EPP Document Updates In-Reply-To: <200508041712.j74HCbhm018679@ns01.afilias.info> Message-ID: <42F2589B.3050901@fccn.pt> MIME-Version: 1.0 Content-Type: text/plain I'm OK with that --eugenio (.PT) Ram Mohan wrote:
Scott, all, This is another one of those things that we should really consider removing (if no one is using it) or revising (if it's not quite right). We should consider re-initiating the provreg group. A number of changes are due in EPP, and enough registries are now using EPP that actual practice has exposed both issues and deviances from the protocol. Further, registries have implemented extensions that, in some cases, make more sense to be part of a standard -- the case of what happened with RGP is relevant here. In the ICANN meeting in Luxembourg, I spoke with a number of gTLD registries, who expressed interest in reviving the group. Specifically, I spoke with GNR, PIR, .TEL, MTLD, VeriSign and NeuStar; presumably direct notes from these registries are forth-coming. Several ccTLD registries also expressed interest in the topic, but did not outright have an opinion on restarting provreg. In light of both changes in practice and interest from practitioners, I would like to ask members of this list to express their opinion and interest in the re-initiation of the provreg group. -Ram -------------------------------------------------------------------------- Ram Mohan Chief Technology Officer Vice President, Business Operations Afilias (http://www.afilias.info) p: +1.215.706.5700 x103; f: +1.215.706.5701 m: +1.215.431.0958 e: rmohan@afilias.info -------------------------------------------------------------------------- From shollenbeck@verisign.com Thu, 4 Aug 2005 20:25:54 +0200 (MEST) From: "Hollenbeck, Scott" Date: Thu, 4 Aug 2005 20:25:54 +0200 (MEST) Subject: RE: [ietf-provreg] EPP Document Updates Message-ID: <046F43A8D79C794FA4733814869CDF07C0ABCF@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain > In light of both changes in practice and interest from > practitioners, I > would like to ask members of this list to express their > opinion and interest > in the re-initiation of the provreg group. I'm all for it IFF there is a suitable description formed of the work to be done. What I've seen so far is pretty sparse. -Scott- From fobispo@nic.ve Thu, 4 Aug 2005 22:13:53 +0200 (MEST) From: Francisco Obispo Date: Thu, 4 Aug 2005 22:13:53 +0200 (MEST) Subject: Re: [ietf-provreg] EPP Document Updates In-Reply-To: <200508041712.j74HCbhm018679@ns01.afilias.info> Message-ID: <42F276FB.5090804@nic.ve> MIME-Version: 1.0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm OK with that too!! I'm developing an open-registration system based on ISC's OpenReg, which will be used for many ccTLDs in latin america. Francisco Obispo (.VE) Eugenio Pinto wrote: > I'm OK with that > > --eugenio (.PT) > > > Ram Mohan wrote: > >> Scott, all, >> >> >>> This is another one of those things that we should really >>> consider removing (if no one is using it) or revising (if it's >>> not quite right). >>> >> >> >> We should consider re-initiating the provreg group. A number of >> changes are due in EPP, and enough registries are now using EPP >> that actual practice has exposed both issues and deviances from >> the protocol. Further, registries have implemented extensions >> that, in some cases, make more sense to be part of a standard -- >> the case of what happened with RGP is relevant here. >> >> In the ICANN meeting in Luxembourg, I spoke with a number of gTLD >> registries, who expressed interest in reviving the group. >> Specifically, I spoke with GNR, PIR, .TEL, MTLD, VeriSign and >> NeuStar; presumably direct notes from these registries are >> forth-coming. Several ccTLD registries also expressed interest >> in the topic, but did not outright have an opinion on restarting >> provreg. >> >> In light of both changes in practice and interest from >> practitioners, I would like to ask members of this list to >> express their opinion and interest in the re-initiation of the >> provreg group. >> >> -Ram >> -------------------------------------------------------------------------- >> >> >> Ram Mohan Chief Technology Officer Vice President, Business >> Operations Afilias (http://www.afilias.info) p: +1.215.706.5700 >> x103; f: +1.215.706.5701 m: +1.215.431.0958 e: >> rmohan@afilias.info >> -------------------------------------------------------------------------- >> >> >> >> >> > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC8nb7Gs0zZ5KMmSMRAiBaAJ9bogCJ5TxnIBPxSvJx+tXyBxRJyACfQGUu o++8fUjlpnJZsuj+dzsjMRg= =/UrQ -----END PGP SIGNATURE----- From RobbyCunningham@virginiagolfcard.com Fri, 5 Aug 2005 18:14:22 +0200 (MEST) From: "Lee Abel" Date: Fri, 5 Aug 2005 18:14:22 +0200 (MEST) Subject: MS 2003 Software titles available for Download Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: y Opt-in Email Special Offer     unsubscribe me SEARCH Software TOP 10 NEW TITLES  ON SALE NOW! 1 Office Pro 2003 2 Adobe Photoshop 9.0 3 Windows XP Pro 4 Adobe Acrobat 7 Pro 5 Flash MX 2004 6 Corel Draw 12 7 Norton Antivirus 2005 8 Windows 2003 Server 9 Alias Maya 6 Wavefrt 10 Adobe Illustrator 11  See more by this manufacturer   Microsoft   Symantec   Adobe  Customers also bought   these other items..Microsoft Office Professional Edition *2003* MicrosoftChoose: View Other Titles   List Price:$499.00 Price:$69.99 You Save:$429.01 (86%) Availability: Available for INSTANT download! Coupon Code: fUYiHloa  Sales Rank: #1 System requirements  |  Other Versions Date Coupon Expires: August 31st, 2005 Average Customer Review: Based on 144256 reviews. Write a review. Adobe Photoshop CS2 V 9.0 AdobeChoose: View Other Titles   List Price:$599.00 Price:$69.99 You Save:$529.01 (90%) Availability: Available for INSTANT download! Coupon Code: 2RjNS0  Sales Rank: #2 System requirements  |  Other Versions Date Coupon Expires: August 31st, 2005 Average Customer Review: Based on 17472 reviews. Write a review. Microsoft Windows XP Professional or Longhorn Edition MicrosoftChoose: View Other Titles   List Price:$279.00 Price:$49.99 You Save:$229.01 (85%) Availability: Available for INSTANT download! Coupon Code: RLQPV  Sales Rank: #3 System requirements  |  Other Versions Date Coupon Expires: August 31st, 2005 Average Customer Review: Based on 194367 reviews. Write a review. Adobe Acrobat Professional V 7.0 AdobeChoose: View Other Titles   List Price:$499.00 Price:$69.99 You Save:$429.01 (85%) Availability: Available for INSTANT download! Coupon Code: v0JE8  Sales Rank: #4 System requirements  |  Other Versions Date Coupon Expires: August 31st, 2005 Average Customer Review: Based on 1295 reviews. Write a review. From john_mcdaniel@cheshire.com Mon, 8 Aug 2005 23:36:25 +0200 (MEST) From: "john_mcdaniel@cheshire.com" Date: Mon, 8 Aug 2005 23:36:25 +0200 (MEST) Subject: Blue Technical Ent. Message-ID: <468528098.11511044837494@cheshire.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="Boundary..16129.1123944092.multipart/related" --Boundary..16129.1123944092.multipart/related Content-Type: text/plain Content-Transfer-Encoding: 7bit Title: Anthologies Blue Technical Ent. Hadn't does introversion who me motorcycle's paneled. Discloses were causations, hers being housekeeper's madman. Bubbling dock I have been cop mine largesse. Mismatching might mezzanine, her is clockwise into indent. Repetition they be hero, them shreds. Monitored scantiness it must near anagram theirs. Assembly contradicted, you had been conjoint her. Planner's folio we does who Patrice at theirs invalidated. Numerische might mistress while your shotgun rudiment's. Eerily has controversies when mine laments mediate. He implicated being heuristics. It after outwitted can mismatches me. Aleck has been James, its could grows astrophysics. Aerating is goad, your have Russ Idaho. I savior's I discontinuance infantry did aorta her. Bobbins needy, I attunes before blocks have been franchise's her. Leone would brooks, yours have been reconstructs jade. Intertwining are Ackerman, his have cartridges jeers. I carrier being health me. Beholding be capitalism mine outbreak's. Glissade she has Phillip, mine towards birdies. She Cyclades were scapular them. We while exiled be ruptures his. Awakes could Lemuel that hers duality nearness. Mafia you might owns, its off rev. Jockey Kinshasha they must shrieking. You cloves are ranking's him. Maw might acknowledgments where his noiseless Addressograph. Idiosyncrasy has been separators before yours inferences chroniclers. Circumstance Typhon, it Barbados on Farnsworth did interchange him. She discharged it disability's Neil does frankest theirs. Artichokes gushes she would near refills them. Carbon's being lager who me ambassadors. We forwardness to she barricade sizing being horsehair me. Inadequately on has Thule, her can narcissism admiring. Rider she could Ampex, them coffee's. Resuming I did mouthful, theirs calmness. Annoys we has been embargoes, yours herself. Herring drawbridge she are remodels. Assign archly I does dictator. Segregation might meters, them would capsize breadwinner. We whom leathers being assortments your. Minimized cheerful, you aggregating Starr have Norman hers. They cosmos does moth. Slanders seventies I had been gild hers cataloging. Cruiser is overtake, me can dumbbells enslaving. Clinched are escalate away them falcons. Culminate might peninsulas, its may belongs controvertible. Sonoma con it may autocracies hers. --Boundary..16129.1123944092.multipart/related Content-Type: application/octet-stream; name="bin00000.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bin00000.bin" Content-Description: "" --Boundary..16129.1123944092.multipart/related-- From jaap@nlnetlabs.nl Wed, 10 Aug 2005 10:40:40 +0200 (MEST) From: Jaap Akkerhuis Date: Wed, 10 Aug 2005 10:40:40 +0200 (MEST) Subject: [ietf-provreg] of interest Message-ID: <200508100840.j7A8ed6w059090@bartok.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 09 Aug 2005 15:50:01 -0400 Subject: I-D ACTION:draft-hollenbeck-epp-secdns-08.txt - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) Author(s) : S. Hollenbeck Filename : draft-hollenbeck-epp-secdns-08.txt Pages : 24 Date : 2005-8-9 This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security extensions (DNSSEC) for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-secdns-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hollenbeck-epp-secdns-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hollenbeck-epp-secdns-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-9111453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hollenbeck-epp-secdns-08.txt - --OtherAccess Content-Type: Message/External-body; name="draft-hollenbeck-epp-secdns-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-9111453.I-D@ietf.org> - --OtherAccess-- - --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce - --NextPart-- ------- End of Forwarded Message From coleman@yahoo.com Wed, 10 Aug 2005 21:20:57 +0200 (MEST) From: "Frankel" Date: Wed, 10 Aug 2005 21:20:57 +0200 (MEST) Subject: Any med for your girl to be happy! Message-ID: <000a01c59d80$883b0070$0100a8c0@msge> MIME-Version: 1.0 Content-Type: multipart/related; boundary="Boundary..16129.1123944092.multipart/related" --Boundary..16129.1123944092.multipart/related Content-Type: text/plain Content-Transfer-Encoding: 7bit " --Boundary..16129.1123944092.multipart/related-- From jgould@verisign.com Thu, 11 Aug 2005 20:24:18 +0200 (MEST) From: James Gould Date: Thu, 11 Aug 2005 20:24:18 +0200 (MEST) Subject: [ietf-provreg] Services messages in RFC 3730 In-Reply-To: <42F276FB.5090804@nic.ve> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Title: Services messages in RFC 3730 All, I believe the current text describing who receives service messages in RFC 3730 is too strict.  The text that I'm referring to reads: Service messages MUST be  created for all clients affected by an action on an object. For  example, actions MUST be reported to both the client that  requests an object transfer and the client that has the authority to  approve or reject the transfer request. This means that the client making the request also receives a poll message even through the client receives the same information in the response and can receive the same information with a transfer query.   I would prefer that the text read like the following: Service messages MUST be  created for all clients affected by an action on an object that did not directly execute the action. For  example, actions MUST be reported to both the client that  requests an object transfer and the client that has the authority to  approve or reject the transfer request for a server action. Based on the update text, the client that MUST receive a poll message for each transfer operation is below (requesting client is the client that executed the transfer request and the owning client is the current owning client of the object): Transfer Request – owning client Transfer Approve –requesting client Transfer Reject – requesting client Transfer Cancel – owning client Transfer Auto Approve – owning client and requesting client Transfer Auto Reject – owning client and requesting client -- JG James F. Gould VeriSign Naming and Directory Services jgould@verisign.com This message is intended for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. Any unauthorized use, distribution, or disclosure is strictly prohibited. If you have received this message in error, please notify sender immediately and destroy/delete the original transmission From andrew@ca.afilias.info Thu, 11 Aug 2005 22:29:52 +0200 (MEST) From: Andrew Sullivan Date: Thu, 11 Aug 2005 22:29:52 +0200 (MEST) Subject: Re: [ietf-provreg] Services messages in RFC 3730 In-Reply-To: <42F276FB.5090804@nic.ve> Message-ID: <20050811202933.GM3904@libertyrms.info> MIME-Version: 1.0 Content-Type: text/plain On Thu, Aug 11, 2005 at 02:24:22PM -0400, James Gould wrote: > All, > > I believe the current text describing who receives service messages in RFC > 3730 is too strict. The text that I'm referring to reads: I think you're right. More generally, if I'm reading you correctly, the principle is that only the uninformed parties are subject to notification by poll queue for any case where a service message is required. But I think your rewording doesn't go far enough. (I put some discussion of this in the draft I put up recently -- it's been submitted since the Paris meeting, but it's still currently only available at , in case anyone is waiting, breathless). To me, one of the strange things about the service message description in the RFC is that it appears to be both mandatory and optional. On the one hand, we have, "Service messages MUST be created for all clients affected by an action on an object." On the other hand, we have, "Servers MAY implement other mechanisms to dequeue and deliver messages if queue maintenance needs exceed server resource consumption limits." Since one could easily construct an argument that any queue at all causes too much overhead, the latter permission amounts to a permission that the message queue be hooked up to /dev/null. Indeed, the description of service messages appears to require that any effect at all in the repository not explicitly requested by the client causes a service message to be generated. So the repository operator has to be able at least to purge the queue sometimes, because otherwise it'll consume all the server's resources. Hence the provision that servers may use some other mechanism. Now, part of the reason for this provision is obviously that sometimes clients won't clear out their queues. My impression is that the "won't clear out" problem is exacerbated by the FIFO nature of the queue: I know that our registrars want a notification of things that possibly cost them money (like a transfer loss or an auto-renewal) way more than they want a notice about something that costs them nothing (like denying a transfer request). I'd therefore like to suggest the addition of a "priority" attribute to the command. This would allow server operators to put messages of different importance in different queues, and to publish different retention policies for their different queues. If a server operator didn't want to go to the trouble of administering different queues, the operator could still get the current behaviour by setting all the priorities to the same value. A magic priority value (I've suggested 1000, but some other value will do) could be used to indicate "give me the next highest-priority message". This approach has the advantage not only that different kinds of messages can be put into different queues; but that for some of them, the server could publish (out of band) a retention policy that says, "queues with priorities 4, 5, and 6 will be retained for 0ms," which is an effective way of tagging certain kinds of messages as ones that will never be delivered through the poll queue (internally, an implementer could just as well drop those messages in the bit bucket). If this approach is unacceptable, I think that the message queue should either be made entirely optional, or that some class of service messages (preferably "all the ones not explicitly required") be made optional. The way 3730 reads today, the message queue is a bottleneck, and I don't think it was intended to be that way. Thoughts? A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 From shollenbeck@verisign.com Fri, 12 Aug 2005 13:06:18 +0200 (MEST) From: "Hollenbeck, Scott" Date: Fri, 12 Aug 2005 13:06:18 +0200 (MEST) Subject: RE: [ietf-provreg] Services messages in RFC 3730 Message-ID: <046F43A8D79C794FA4733814869CDF07C927A9@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: owner-ietf-provreg@cafax.se > [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Andrew Sullivan > Sent: Thursday, August 11, 2005 4:30 PM > To: ietf-provreg@cafax.se > Subject: Re: [ietf-provreg] Services messages in RFC 3730 > > On Thu, Aug 11, 2005 at 02:24:22PM -0400, James Gould wrote: > > All, > > > > I believe the current text describing who receives service > messages in RFC > > 3730 is too strict. The text that I'm referring to reads: [snip] > To me, one of the strange things about the service message > description in the RFC is that it appears to be both mandatory and > optional. On the one hand, we have, "Service messages MUST be > created for all clients affected by an action on an object." On the > other hand, we have, "Servers MAY implement other mechanisms to > dequeue and deliver messages if queue maintenance needs exceed server > resource consumption limits." Since one could easily construct an > argument that any queue at all causes too much overhead, the latter > permission amounts to a permission that the message queue be hooked > up to /dev/null. Indeed, the description of service messages appears > to require that any effect at all in the repository not explicitly > requested by the client causes a service message to be generated. So > the repository operator has to be able at least to purge the queue > sometimes, because otherwise it'll consume all the server's > resources. Hence the provision that servers may use some other > mechanism. I don't see how you can interpret the queuing system as optional. The text is completely clear about the need to create and enqueue the messages. "dequeue and deliver messages" does NOT mean "route to /dev/null". It can mean that messages be delivered via email, made available for retrieval via ftp, etc. "dequeue and deliver". Not "throw away blindly". [snip] > If this approach is unacceptable, I think that the message > queue should > either be made entirely optional, or that some class of service > messages (preferably "all the ones not explicitly required") be made > optional. The way 3730 reads today, the message queue is a > bottleneck, and I don't think it was intended to be that way. My personal preference leans towards "some class of service messages (preferably "all the ones not explicitly required") be made optional." What defines "explicitly required", though? I thought Jim's definition was pretty reasonable: if you're a party to a transaction, but not the recipient of a response, you get a message. We can't just limit ourselves to transactions that cost money in the ICANN TLD world. On the priority-based multiple queue thing: priority is relative. It typically either gets ignored or everything becomes "high" priority in someone's eyes. I don't get a good feeling about adding complexity to the mechanism if making it simpler is a viable option. -Scott- From myoung@ca.afilias.info Fri, 12 Aug 2005 16:10:28 +0200 (MEST) From: "Michael Young" Date: Fri, 12 Aug 2005 16:10:28 +0200 (MEST) Subject: RE: [ietf-provreg] Services messages in RFC 3730 In-Reply-To: <046F43A8D79C794FA4733814869CDF07C927A9@dul1wnexmb01.vcorp.ad.vrsn.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Well please see my comments below. You all know I don't weigh in often but frankly I needed to say something on this rather painful debate. However, before I start arguing heavily, I want to personally acknowledge the huge amount of effort Scott has put into this work thus far; I have been a benefactor of those efforts and its not something that I will cease to appreciate. >"I don't see how you can interpret the queuing system as optional. The text is completely clear about the need to create >and enqueue the messages. "dequeue and deliver messages" does NOT mean "route to /dev/null". It can mean that messages >be delivered via email, made available for retrieval via ftp, etc." >"dequeue and deliver". Not "throw away blindly". >"Servers MAY implement other mechanisms to dequeue and deliver > messages if queue maintenance needs exceed server resource consumption > limits." Lets look at this line for a second, first of all taken in context (in other words not dropping the sentence after "dequeue and deliver") it seems to be describing an out for the operator and the registrar if the message queue gets out of control. It is no less and no more specific than that, near as I can tell from my understanding of the English language. If you meant "dequeue and deliver via an alternate mechanism", then that's what you should say. Frankly it's a cosmetic change and I don't even see why folks are wasting breath - it should just be modified. Of course the minute you do that you can now output the messages to a proprietary priority based queue or other such system and then what's point of having the queue defined in the protocol in the first place? So really this part of the discussion seems to be missing the larger point I have commented on further below. >"My personal preference leans towards "some class of service messages (preferably "all the ones not explicitly required") >be made optional." >What defines "explicitly required", though? I thought Jim's definition was pretty reasonable: if you're a party to a >transaction, but not the recipient of a response, you get a message. We can't just limit ourselves to transactions that >cost money in the ICANN TLD world. >On the priority-based multiple queue thing: priority is relative. It typically either gets ignored or everything becomes >"high" priority in someone's eyes. I don't get a good feeling about adding complexity to the mechanism if making it >simpler is a viable option." Personally I don't have any issue with making a completely inadequate mechanism more complex. In case this minimally more complex. >"On the priority-based multiple queue thing: priority is relative." Right that's exactly the point its relative to the registry operator and the registrar and the policies they are working under. >"It typically either gets ignored or everything becomes "high" priority in someone's eyes." That's a very old line of argument in history and one that I can't believe I am hearing applied to this situation. Who is anyone to make that assertion? Its saying to someone I am going to dictate how you want your messages and in what order you must read them because if I give you the freedom to make a choice - you are too stupid to know what to do with it. While there are order of operation arguments applicable to types of notifications, there is no technical reason you can't populate a priority rating to a message (define a type) and mark the sequence. At that point if a registrar wants to eat his pudding before they've had their supper then that's their poor choice. For that matter the Registry Operator can enforce FIFO retrieval within the priority class but it should all be OPTIONAL if you want a protocol the industry can stay complaint with. Further: >"What defines "explicitly required", though? I thought Jim's definition was pretty reasonable: if you're a party to a >transaction, but not the recipient of a response, you get a message." It seems to me this argument supports exactly why a priority-based multiple queue is a necessity. If you follow Jim's suggestion you are saying then that it makes sense to populate the poll queue on all Registry Operator maintenance activities. Every time you touch an object according to well communicated policy behavior you have to populate the poll queue. Well there's a four letter word for that in this industry "spam". Imagine if you had no choice but to read through your email in a enforced FIFO retrieval when you had those kinds of volumes (wait a second no imagining needed, its what's defined currently). Its absolutely off the map and it will almost guarantee eventual non-compliance or foolish workarounds of the protocol(see earlier comment). While it should certainly be optional, a priority setting mechanism in the poll queue is a basic and very necessary feature. While I realize no one wants to step up and do more work than necessary on these documents, its clear that after several years of banging our heads against walls like this one some changes are required. This is an emerging marketplace and the protocol needs to evolve as required if we expect implementers to remain really compliant with it. I think however its important that we see some volunteers here to assist with this, so that Scott is not again burdened with what was frankly an unjust amount of the work. Michael Young From andrew@ca.afilias.info Fri, 12 Aug 2005 16:22:14 +0200 (MEST) From: Andrew Sullivan Date: Fri, 12 Aug 2005 16:22:14 +0200 (MEST) Subject: Re: [ietf-provreg] Services messages in RFC 3730 In-Reply-To: <046F43A8D79C794FA4733814869CDF07C927A9@dul1wnexmb01.vcorp.ad.vrsn.com> Message-ID: <20050812142159.GB23651@libertyrms.info> MIME-Version: 1.0 Content-Type: text/plain Hi Scott, Thanks for your comments. On Fri, Aug 12, 2005 at 07:06:00AM -0400, Hollenbeck, Scott wrote: > > I don't see how you can interpret the queuing system as optional. The > text is completely clear about the need to create and enqueue the > messages. "dequeue and deliver messages" does NOT mean "route to > /dev/null". It can mean that messages be delivered via email, made > available for retrieval via ftp, etc. > > "dequeue and deliver". Not "throw away blindly". You're right that I'm probably overstating the case. But consider cases where the client just doesn't do anything in time for the notification to have been any use. For instance, in the ICANN world, we have 5 days in which a losing registrar may refuse a transfer (subject to a bunch of policy rules). If a transfer request message hasn't been picked up after five days, it's worthless. Worse, it's clogging the message queue, and delaying the delivery of other, potentially useful messages. The only sane thing to do with such a message is to throw it away. As a result of this sort of thing, as near as I can tell, at least some clients are completely ignoring the poll queue. We therefore have to support other kinds of notification mechanisms in parallel to the poll queue, which is a pointless duplication of effort. And as near as I can tell, this is because people find the poll queue less useful than alternative mechanisms. I was hoping to make it more useful. > What defines "explicitly required", though? I thought Jim's definition > was pretty reasonable: if you're a party to a transaction, but not the > recipient of a response, you get a message. We can't just limit > ourselves to transactions that cost money in the ICANN TLD world. No, I totally agree; and I thought Jim's definition was a good one, too; I support it. I absolutely do not want to propose anything that is restricted to the ICANN TLD world, because I think EPP has lots of potential outside that world. In fact, my view is that there are still some things in the protocol and mapping documents that are too ICANN-TLD-centric, and turn out to be more policy shaped than protocol shaped. (Just so I'm clear: I think that's an accident, and it's just the result of the collective experience of those who were working on the original protocol definition at the time the WG was active.) > On the priority-based multiple queue thing: priority is relative. It > typically either gets ignored or everything becomes "high" priority in Hrm. This makes me think that "priority" is an infelicitous word choice. What about "facility"? I'm basically thinking of something like syslog on UNIX here. You have some arbitrary tags that tell you what is generating the message; and that tag allows you to apply additional rules, depending on the tag. It's sure useful to sysadmins; I sort of think it might be useful to clients of a repository as well. > someone's eyes. I don't get a good feeling about adding complexity to > the mechanism if making it simpler is a viable option. What about the notion that you could give everything the same priority (or facility, or whatever we want to call it) value, so that you'd have something just like the current mechanism? For that matter, the attribute could be completely OPTIONAL, and its absense an indication that the client wants the next message in the queue regardless of facility. In that case, those who have implemented the current mechanism and don't want to do any more work wouldn't have any work they need to do. I could be, of course, completely wrong about the utility of a mechanism like this; I just know that people seem not to be using the poll queue as I'd like, and I'm trying to figure out how to persuade them to use it (so I can stop sending reams of email). A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 From Ed.Lewis@neustar.biz Fri, 12 Aug 2005 18:15:56 +0200 (MEST) From: Edward Lewis Date: Fri, 12 Aug 2005 18:15:56 +0200 (MEST) Subject: RE: [ietf-provreg] EPP Document Updates In-Reply-To: <046F43A8D79C794FA4733814869CDF07C0AAAF@dul1wnexmb01.vcorp.ad.vrsn.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain At 16:43 -0400 8/3/05, Hollenbeck, Scott wrote: >> From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de] >> One thing that really puzzles me in this context is that a >> registrar cannot >> allow the disclosure of one component (that is normally not >> disclosed) and to >> disallow the disclosure of another component (that his >> normally disclosed) at >> the same time. But maybe I am just misunderstanding the >> wording. I think I have >> to reread this at a later point in time. > >Remember that the whole "disclose" thing got crammed into the spec at >the last minute at the demand of the IESG. There were parts that didn't >make sense then (to me anyway) and I'm sure they still don't make sense >now. This is another one of those things that we should really consider >removing (if no one is using it) or revising (if it's not quite right). Our implementers support dumping the discloser elements as currently specified. The issue is that the communication is "binary" (ON/OFF, YES/NO). There is legacy data that is not tagged (it wasn't on collection), i.e., it should be NULL, UNSPEC, or DON'T CARE. One bug is that on "create" the submission might be left unspecified because the client "doesn't care". But on "info" the submission, if un"tagged" is assumed to follow default behavior. Doesn't seem very symmetric in a protocol sense. A suggestion is made to also make this a per time tag (but I have a sneaking submission that we nixed that in the discussions in early/January 2003). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From Ed.Lewis@neustar.biz Fri, 12 Aug 2005 18:07:44 +0200 (MEST) From: Edward Lewis Date: Fri, 12 Aug 2005 18:07:44 +0200 (MEST) Subject: RE: [ietf-provreg] EPP Document Updates In-Reply-To: <200508041712.j74HCbhm018679@ns01.afilias.info> Message-ID: MIME-Version: 1.0 Content-Type: text/plain At 13:13 -0400 8/4/05, Ram Mohan wrote: >We should consider re-initiating the provreg group. A number of changes are >due in EPP, and enough registries are now using EPP that actual practice has >exposed both issues and deviances from the protocol. Further, registries >have implemented extensions that, in some cases, make more sense to be part >of a standard -- the case of what happened with RGP is relevant here. I think it's clear that there's a demand (as in supply and demand) for coordination of work involving the EPP protocol. However, I don't think there's justification for an IETF-style working group. I think there are maybe three factors that prevent the EPP documents from being the epitome of perfection. 1) They were produced by humans. (Meaning errata are needed.) 2) The audience of interest grew as the specifications were put to RFC. (Meaning that elements were designed for domain specific applications.) 3) The protocol is supposed to be extensible and future looking. These are three reasons why there is a demand for EPP coordination. But is this demand best met by an IETF WG? Reason #1 is fairly self-explanatory, a number of textual edits have been identified. If RFC documents were "living" these changes would have been made without thought. An IETF WG isn't needed for this. Reason #2 is a bit more telling of the culture of the IETF and why I think an IETF-style WG might not be the correct path at this moment. The IETF isn't the right venue to attract interest of registries. For example, CENTR has a higher concentration of attendees that have applicable experience and interest in what is happening in EPP now. There was a time in which EPP development needed the input of other protocol engineering experts. EPP has an extension mechanism that separates the process of adding new messages to the protocol from issue dealing with security and transport. During the IETF run, we had to wrestle with the question of whether we could define SMTP as a transport for EPP elements - we decided no for various reasons. This is an IETF question. How to encode ENUM validation data into EPP is much less of a question that needs input from, say, the SMTP experts. I'm sure another run of the PROVREG WG would gather a different and probably more well-rounded set of participants than the first try. But still, there is no guarantee that we get who we need. Reason #3 is based on the existence of the final RFC of the original EPP documents (3735 I think). Basically, there is a statement from the WG on how to proceed with extensions. I don't believe this is enough, certainly, but I can't imagine how an IETF WG would improve. For one, just because guidelines are documented doesn't mean that "generations" of following implementers will grok and comply fully. My other experience is in DNS - looking closely at that I see there was about a decade between the original specifications and the beginning of a "reformation" in which the ad hoc coding practices had "voided" some of the basic assumptions about the DNS. The result is a plethora of badly written code screaming for backwards compatibility. Another factor here is that there are a need to reign in on some extension efforts. Sometimes there is too much freedom to expand and you wind up with a bloated protocol. E.g., let's say each of the 200 or so registries out there decides to extend EPP in some unique way. It's the registrars that suffer trying to maintain a client code base with the 200 or so unique extensions. I don't think this is an effort suited to the IETF, especially because it is operations (and market) based. What would be a good reason to reconvene an IETF (style) WG? A reason that requires an engineering solution, a reason that requires cross-checking with other protocol domain engineers. I liked the CENTR meeting that happened the day before the IETF in Paris. It was a dedicated registry meeting yet co-located with the IETF engineering meetings. I realize that CENTR is not the open forum that the IETF is, and it is not the only interested party, but it is a good example and has a significant concentration of interest in EPP. To emphasize this one more time - CENTR's meeting is an example of a non-IETF group that resulted in some interesting talk on EPP. An example. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From shollenbeck@verisign.com Fri, 12 Aug 2005 19:24:01 +0200 (MEST) From: "Hollenbeck, Scott" Date: Fri, 12 Aug 2005 19:24:01 +0200 (MEST) Subject: RE: [ietf-provreg] Services messages in RFC 3730 Message-ID: <046F43A8D79C794FA4733814869CDF07C92888@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: owner-ietf-provreg@cafax.se > [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Michael Young > Sent: Friday, August 12, 2005 10:10 AM > To: ietf-provreg@cafax.se > Subject: RE: [ietf-provreg] Services messages in RFC 3730 > > Well please see my comments below. You all know I don't > weigh in often but > frankly I needed to say something on this rather painful > debate. However, > before I start arguing heavily, I want to personally > acknowledge the huge > amount of effort Scott has put into this work thus far; I have been a > benefactor of those efforts and its not something that I will cease to > appreciate. [snip] > >"It typically either gets ignored or everything becomes > "high" priority in > someone's eyes." > > That's a very old line of argument in history and one that I > can't believe I > am hearing applied to this situation. Who is anyone to make > that assertion? > Its saying to someone I am going to dictate how you want your > messages and > in what order you must read them because if I give you the > freedom to make a > choice - you are too stupid to know what to do with it. > While there are > order of operation arguments applicable to types of > notifications, there is > no technical reason you can't populate a priority rating to a message > (define a type) and mark the sequence. At that point if a > registrar wants > to eat his pudding before they've had their supper then > that's their poor > choice. For that matter the Registry Operator can enforce > FIFO retrieval > within the priority class but it should all be OPTIONAL if you want a > protocol the industry can stay complaint with. Superlatives and astonishment aside, there are really three issues here: 1. Is priority-based messaging needed? You obviously think so assuming that messaging isn't optional, so let's continue. 2. If so, is this a specification issue or an implementation detail? I believe it's both. Implementation detail: how you implement your message queuing system is up to you. You might have three queues instead of one, with "high priority" messages going into one queue, "normal priority" messages going into a second queue, and "low priority" messages going into a third. As registry operator you make an implementation decision to determine which messages go where. The command can then be implemented to read from them in whatever order makes sense to you. Specification issue: if multiple queues are implemented, how does one let the client deal with that fact? As is, they could be read from in whatever order the server operator decides to impose on the reader. That's probably not too helpful. We also need to look at loosening up the text as Jim suggested. 3. If a specification issue, should something new be added to the core specs or should something new be defined in an extension? Given that we're talking about adding a new feature that may or may not be useful to everyone (as you say, "it should all be OPTIONAL"), documenting a new feature (adding priority marks to messages and allowing a client to specify how they wish to deal with the priorities) in a standard extension seems like the least intrusive way to make the functionality available for these reasons: a. It truly is optional. b. It doesn't complicate other existing implementations. c. It's common IETF practice to add new features via extensions once proposed standards are published. Extension development is usually a good reason to spin up a new working group. d. It allows us to avoid a core schema change and the resulting new protocol version. Think about d. for a moment. A protocol version rev likely implies an operational requirement for ALL conforming servers and clients to support both old and new versions for some TBD period of time. An extension can be deployed without introducing version management issues. -Scott- From andrew@ca.afilias.info Fri, 12 Aug 2005 19:46:47 +0200 (MEST) From: Andrew Sullivan Date: Fri, 12 Aug 2005 19:46:47 +0200 (MEST) Subject: Re: [ietf-provreg] Services messages in RFC 3730 In-Reply-To: <046F43A8D79C794FA4733814869CDF07C92888@dul1wnexmb01.vcorp.ad.vrsn.com> Message-ID: <20050812174632.GK23651@libertyrms.info> MIME-Version: 1.0 Content-Type: text/plain On Fri, Aug 12, 2005 at 01:23:43PM -0400, Hollenbeck, Scott wrote: > to everyone (as you say, "it should all be OPTIONAL"), documenting a new > feature (adding priority marks to messages and allowing a client to > specify how they wish to deal with the priorities) in a standard > extension seems like the least intrusive way to make the functionality > available for these reasons [&c.] I think an extension would be a good idea, too, as long as we make the current poll queue optional. In fact, if the requirements in RFC 3730 2.9.2.3 were a little weaker, I'd already have proposed an extension. It might be, in fact, that the only thing needed to facilitate that is a weakening of this: "Service messages MUST be created for all clients affected by an action on an object." This is in line with the suggestion Jim already made. I'm all for making any changes as painless as possible. Because I did have to support two protocols in production at one time, I am happy to agree with your observation that keeping both going at once is going to be something shy of fun. So if there is some way to address the issues folks have with the existing protocol without changing it, I'm certainly not opposed. (But also, of course, if we're forced to accept a protocol change, I'd much rather see it happen now, before the installed base gets any bigger.) A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 From Ed.Lewis@Neustar.biz Fri, 12 Aug 2005 20:19:47 +0200 (MEST) From: Edward Lewis Date: Fri, 12 Aug 2005 20:19:47 +0200 (MEST) Subject: RE: [ietf-provreg] Services messages in RFC 3730 In-Reply-To: <046F43A8D79C794FA4733814869CDF07C92888@dul1wnexmb01.vcorp.ad.vrsn.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain Keeping in mind that a protocol is about communication of information, not the processing of information: Reading Jay's suggestion carefully, it does not "bar" sending replies as they are now, just makes them an implicit "MAY". Is that intentional/acceptable? At 13:23 -0400 8/12/05, Hollenbeck, Scott wrote: >> -----Original Message----- >> [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Michael Young > >1. Is priority-based messaging needed? I have a hard time imagining that a priority-based message system is important in the context of EPP. EPP is only delivering the messages, there's nothing saying that the recipient can't delay acting on some. From my experience in communications protocols, adding priorities into queues winds up gumming up the pipes. I would reserve prioritization for cases where time critical responses are required or where one stream of messages has a different tolerance for transit latency than another. >Specification issue: if multiple queues are implemented, how does one >let the client deal with that fact? As is, they could be read from in >whatever order the server operator decides to impose on the reader. >That's probably not too helpful. We also need to look at loosening up >the text as Jim suggested. I dislike protocol features with really complicated rules regarding what it means to be conformant. EPP handles a pretty simple client-server conversation, is the benefit of priority queues worth having to define all these new rules? Don't just think of all of the specification ink needed, think of having to roll out new tar files of EPP code too. >c. It's common IETF practice to add new features via extensions once >proposed standards are published. Extension development is usually a >good reason to spin up a new working group. On a tangent - do you mean to say that extensions ought to cause a new WG? Up to now some extensions haven't been discussed in a (new) WG. >d. It allows us to avoid a core schema change and the resulting new >protocol version. > >Think about d. for a moment. A protocol version rev likely implies an >operational requirement for ALL conforming servers and clients to >support both old and new versions for some TBD period of time. An >extension can be deployed without introducing version management issues. I'm not so worried about IETF impacts (like, "respin at PS") as I am about software that has been distributed. That's been the achillies heel of many an old protocol. Do we really gain by no longer delivering messages to the initiator has Jay suggests? (Or can the initiator be counted on to just dump the extraneous message?) Do we really gain with priority queueing? I'm not sure I'd say yes or no to the first question, my gut tells me that answer to the latter is no. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From myoung@ca.afilias.info Fri, 12 Aug 2005 20:24:49 +0200 (MEST) From: Michael Young Date: Fri, 12 Aug 2005 20:24:49 +0200 (MEST) Subject: Re: [ietf-provreg] Services messages in RFC 3730 In-Reply-To: <046F43A8D79C794FA4733814869CDF07C92888@dul1wnexmb01.vcorp.ad.vrsn.com> Message-ID: <42FCE967.8040806@ca.afilias.info> MIME-Version: 1.0 Content-Type: text/plain >"Superlatives and astonishment aside, there are really three issues here:" Ok perhaps I was being excessive ;-) >"You might have three queues instead of one, with "high >priority" messages going into one queue, "normal priority" messages >going into a second queue, and "low priority" messages going into a >third." I dont see the flexibility to do that as it stands, can you elaborate on that please? >a. It truly is optional. >b. It doesn't complicate other existing implementations. >c. It's common IETF practice to add new features via extensions once >proposed standards are published. Extension development is usually a >good reason to spin up a new working group. >d. It allows us to avoid a core schema change and the resulting new >protocol version. > >Think about d. for a moment. A protocol version rev likely implies an >operational requirement for ALL conforming servers and clients to >support both old and new versions for some TBD period of time. An >extension can be deployed without introducing version management issues A and B I think in case qualify. For C how would suggest this be addressed in an extension? As for D I completely take your point but isnt this ultimately a cost benefit analysis not a defacto "don't go there" decision? For example the poll queue is the only item under discussion at this point, there are certainly other contenders that could result in a schema change (see http://www.ietf.org/internet-drafts/draft-sullivan-epp-experience-00.txt ). Can we really resolve all the raised issues via extensions? If we can would that be less effort on the implementers and users than a protocol change? I think it really depends on the complexity of the changes. With a protocol change the resultant client changes required may be considered minimal by the users involved compared to the gains in capability. An implementer may find running dual protocol less effort than a series of extensions. As always - it depends and we need some feedback beyond ourselves (some registrar feedback would be helpful here). Michael From andrew@ca.afilias.info Fri, 12 Aug 2005 20:36:48 +0200 (MEST) From: Andrew Sullivan Date: Fri, 12 Aug 2005 20:36:48 +0200 (MEST) Subject: Re: [ietf-provreg] Services messages in RFC 3730 In-Reply-To: <046F43A8D79C794FA4733814869CDF07C92888@dul1wnexmb01.vcorp.ad.vrsn.com> Message-ID: <20050812183633.GQ23651@libertyrms.info> MIME-Version: 1.0 Content-Type: text/plain On Fri, Aug 12, 2005 at 02:24:39PM -0400, Michael Young wrote: > certainly other contenders that could result in a schema change (see > http://www.ietf.org/internet-drafts/draft-sullivan-epp-experience-00.txt ). That isn't resolving yet, last I checked, just to warn everyone. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 From shollenbeck@verisign.com Fri, 12 Aug 2005 20:53:32 +0200 (MEST) From: "Hollenbeck, Scott" Date: Fri, 12 Aug 2005 20:53:32 +0200 (MEST) Subject: RE: [ietf-provreg] Services messages in RFC 3730 Message-ID: <046F43A8D79C794FA4733814869CDF07C928E5@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] > Sent: Friday, August 12, 2005 2:20 PM > To: Hollenbeck, Scott > Cc: Michael Young; ietf-provreg@cafax.se > Subject: RE: [ietf-provreg] Services messages in RFC 3730 [snip] > >c. It's common IETF practice to add new features via extensions once > >proposed standards are published. Extension development is usually a > >good reason to spin up a new working group. > > On a tangent - do you mean to say that extensions ought to cause a > new WG? Up to now some extensions haven't been discussed in a (new) > WG. What I'm saying is that it's not uncommon for a new group to form around the idea of adding new features to an established protocol without changing the established protocol. The imapext working group, for example. There generally has to be a lot of common ground among the implementing community to have this be successful. In our case, it could mean that multiple people would want to work on the same extension(s), maybe due to an ICANN requirement or some other similar need that brings people together. It's also quite acceptable for someone to just write their own extension draft and push it through the standards process. This is probably a better option if the extension has limited appeal. -Scott- From Ed.Lewis@Neustar.biz Fri, 12 Aug 2005 21:03:28 +0200 (MEST) From: Edward Lewis Date: Fri, 12 Aug 2005 21:03:28 +0200 (MEST) Subject: WG, was RE: [ietf-provreg] Services messages in RFC 3730 In-Reply-To: <046F43A8D79C794FA4733814869CDF07C928E5@dul1wnexmb01.vcorp.ad.vrsn.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain At 14:53 -0400 8/12/05, Hollenbeck, Scott wrote: >> -----Original Message----- >> From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] >> Sent: Friday, August 12, 2005 2:20 PM >> To: Hollenbeck, Scott >> Cc: Michael Young; ietf-provreg@cafax.se >> Subject: RE: [ietf-provreg] Services messages in RFC 3730 > >[snip] > >> >c. It's common IETF practice to add new features via extensions once >> >proposed standards are published. Extension development is usually a >> >good reason to spin up a new working group. >> >> On a tangent - do you mean to say that extensions ought to cause a >> new WG? Up to now some extensions haven't been discussed in a (new) >> WG. > >What I'm saying is that it's not uncommon for a new group to form around >the idea of adding new features to an established protocol without >changing the established protocol. The imapext working group, for >example. There generally has to be a lot of common ground among the >implementing community to have this be successful. In our case, it >could mean that multiple people would want to work on the same >extension(s), maybe due to an ICANN requirement or some other similar >need that brings people together. > >It's also quite acceptable for someone to just write their own extension >draft and push it through the standards process. This is probably a >better option if the extension has limited appeal. What I expressed to someone after the CENTR meeting was that (for a particular extension) was that they could collect a group of CENTR members, hammer out a draft (DRAFT!, not specification, not RFC) and then bring that to the IETF. In other words, it doesn't always have to start in the IETF - although having the IETF last call, and this list, as a significant "open discussion" of the work. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From andrew@ca.afilias.info Fri, 12 Aug 2005 21:16:08 +0200 (MEST) From: Andrew Sullivan Date: Fri, 12 Aug 2005 21:16:08 +0200 (MEST) Subject: [ietf-provreg] Country codes (another EPP Document Update) In-Reply-To: <200508041712.j74HCbhm018679@ns01.afilias.info> Message-ID: <20050812191553.GS23651@libertyrms.info> MIME-Version: 1.0 Content-Type: text/plain I just remembered that there's one more annoyance that I've forgotten to mention, but I think we'd benefit from addressing. RFC 3733 requires (in section 2.4.3) that registrant country be represented by the ISO 3166 country code. The problem is, as I'm sure everyone is aware, that the ISO 3166 rules permit not only the obsolescence of a country code, but its reassignment. The possibility that a country code will come to refer to some other country seems to be conceptually broken for our purposes, because while countries go out of existence (and their country code is deleted), the addresses often don't change (and even if they did, there's be precious little way of getting the data from the contact if one interacts with the person corresponding to the contact object indirectly). Formally speaking, this means that allowing (for instance) YU in an address is not permitted today, even though it was correct when the address was created. This is of course a pain, because the country code is valid at one date, and becomes invalid later. I know that people elsewhere in the IETF are struggling with this problem for considerably more important cases than this one; but is there anything we can do about it now, while we're looking at these documents? A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 From Ed.Lewis@Neustar.biz Fri, 12 Aug 2005 21:40:06 +0200 (MEST) From: Edward Lewis Date: Fri, 12 Aug 2005 21:40:06 +0200 (MEST) Subject: Re: [ietf-provreg] Country codes (another EPP Document Update) In-Reply-To: <200508041712.j74HCbhm018679@ns01.afilias.info> Message-ID: MIME-Version: 1.0 Content-Type: text/plain At 15:15 -0400 8/12/05, Andrew Sullivan wrote: >I know that people elsewhere in the IETF are struggling with this >problem for considerably more important cases than this one; but is >there anything we can do about it now, while we're looking at these Maybe I'm in a particularly prickly mood today (;)) towards opening up new work, so here are some comments just to stew over... 1) If a group elsewhere is working on this, maybe it's best to lay back. Especially if there are subject matter experts "over there". 2) Maybe this is an issue not for the EPP interface but for database "archival" functions. I'm counterbalancing the energy to engineer at every corner, that's what I am doing. I admire the desire to "fix" this and the desire to engineer a solution, but I would "leave it to the experts" and "solve the problem where it truly lay." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From shollenbeck@verisign.com Fri, 12 Aug 2005 21:58:09 +0200 (MEST) From: "Hollenbeck, Scott" Date: Fri, 12 Aug 2005 21:58:09 +0200 (MEST) Subject: RE: [ietf-provreg] Country codes (another EPP Document Update) Message-ID: <046F43A8D79C794FA4733814869CDF07C92901@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: owner-ietf-provreg@cafax.se > [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Andrew Sullivan > Sent: Friday, August 12, 2005 3:16 PM > To: ietf-provreg@cafax.se > Subject: [ietf-provreg] Country codes (another EPP Document Update) > > I just remembered that there's one more annoyance that I've forgotten > to mention, but I think we'd benefit from addressing. > > RFC 3733 requires (in section 2.4.3) that registrant country be > represented by the ISO 3166 country code. > > The problem is, as I'm sure everyone is aware, that the ISO 3166 > rules permit not only the obsolescence of a country code, but its > reassignment. The possibility that a country code will come to refer > to some other country seems to be conceptually broken for our > purposes, because while countries go out of existence (and their > country code is deleted), the addresses often don't change (and even > if they did, there's be precious little way of getting the data from > the contact if one interacts with the person corresponding to the > contact object indirectly). Formally speaking, this means that > allowing (for instance) YU in an address is not permitted today, even > though it was correct when the address was created. This is of > course a pain, because the country code is valid at one date, and > becomes invalid later. > > I know that people elsewhere in the IETF are struggling with this > problem for considerably more important cases than this one; but is > there anything we can do about it now, while we're looking at these > documents? If you know of a way to describe a country with an identifier that never changes, clue me in. Even their commonly spoken names can change. Witness Congo->Zaire->Congo, Russia->USSR->Russia, etc. I agree with Ed. This is a back-end database "archival" issue. -Scott- From andrew@ca.afilias.info Fri, 12 Aug 2005 22:04:34 +0200 (MEST) From: Andrew Sullivan Date: Fri, 12 Aug 2005 22:04:34 +0200 (MEST) Subject: Re: [ietf-provreg] Country codes (another EPP Document Update) In-Reply-To: <200508041712.j74HCbhm018679@ns01.afilias.info> Message-ID: <20050812200416.GV23651@libertyrms.info> MIME-Version: 1.0 Content-Type: text/plain On Fri, Aug 12, 2005 at 03:40:04PM -0400, Edward Lewis wrote: > > 1) If a group elsewhere is working on this, maybe it's best to lay > back. Especially if there are subject matter experts "over there". Yes. I think I may not have been perfectly clear, but part of what I was trying to say is, "Does anyone know what the status of that work is? Did it get anywhere, or was the moaning and gnashing of teeth I heard the only thing that happened?" I have no idea what people are actually going to do about the whole YU/CS debacle, but if someone else came up with an answer, we might be able just to include it now while we're at it. > 2) Maybe this is an issue not for the EPP interface but for database > "archival" functions. Surely not. If the database has a contact in it with a country code of YU, and someone does a on that contact, the repository need to return YU, even though YU is no longer valid under the normative reference. (Or, if your view of the normative reference is that it refers only to the 3166-1 from 1997, replace this example with some other effective one -- I think the CD/ZR one will do.) I suppose I'm being a protocol lawyer, though: we all know what the _point_ of the reference is, so maybe implicity it's really 3166 for any value of "3166's history". (That still doesn't solve the CS-is-Czechoslovakia/CS-is-Serbia-and-Montenegro problem, though.) A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 From andrew@ca.afilias.info Fri, 12 Aug 2005 22:21:43 +0200 (MEST) From: Andrew Sullivan Date: Fri, 12 Aug 2005 22:21:43 +0200 (MEST) Subject: Re: [ietf-provreg] EPP Document Updates In-Reply-To: <200508041712.j74HCbhm018679@ns01.afilias.info> Message-ID: <20050812202127.GY23651@libertyrms.info> MIME-Version: 1.0 Content-Type: text/plain Hi, Taking my cue from your .sig, I have a feeling I don't know what you're thinking here (since I think I don't understand this). On Fri, Aug 12, 2005 at 12:07:12PM -0400, Edward Lewis wrote: > > I think it's clear that there's a demand (as in supply and demand) > for coordination of work involving the EPP protocol. However, I > don't think there's justification for an IETF-style working group. I read that to mean that you think that there are some people who think that EPP needs work, but that such work shouldn't go on in an IETF wg. And I agree with you that simple changes to the documents don't need a working group. But I'm not sure I follow the subsequent arguments that the IETF is the wrong place to pursue updates or changes to the protocol. I appreciate that the IETF doesn't always attract all the registrar and registry people we might like for feedback on these issues; but that's a problem I'd suggest we solve by soliciting the feedback of people in those communities, and _not_ by trying to take our protocol developments to some other forum. I have no direct experience of CENTR, but my few experiences with ICANN committees &c. have left me with a very strong impression that the technical knowledge does not there exist to do good protocol development. That's no indictment of ICANN: they're doing their policy work, and relying on the technical community of the Internet to do the technical work. That community works within the IETF, no? There does seem to be a live question of whether all the issues everyone has identified with EPP can be accommodated without a protocol change (including, of course, by instead developing extensions). So far, I'm not totally convinced; but I'd sure like to be, which is why I'm pursuing these conversations now. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 From provreg@contact.dotandco.com Sat, 13 Aug 2005 02:58:44 +0200 (MEST) From: Patrick Mevzek Date: Sat, 13 Aug 2005 02:58:44 +0200 (MEST) Subject: [ietf-provreg] Open source EPP implementation Message-ID: <20050813005843.GA16775@nohope.patoche.org> MIME-Version: 1.0 Content-Type: text/plain Hello, Just to let you know that I released a few days ago an open source EPP implementation (GPL license), which implements all EPP RFCs, including the GracePeriod extension with room for others. It is more of a toolkit and an abstract view of registries (it implements also RRP, and can accomodate many transports), in Perl. If interested, more information here: http://freshmeat.net/projects/netdri/ http://www.dotandco.com/services/software/Net-DRI/index.en If any registry or EPP server owner is interested to conduct interoperability tests or to make sure to have its specific policy and/or technical requirements taken into account (adding other protocols is possible, as well as handling variations from a common protocol), feel free to drop me a note here or privately. -- Patrick Mevzek Dot and Co From SamuelShaver@guilbert.org Mon Aug 15 06:11:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4bwg-00089T-KZ for provreg-archive@megatron.ietf.org; Mon, 15 Aug 2005 06:11:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24077 for ; Mon, 15 Aug 2005 06:11:52 -0400 (EDT) Received: from p2195-ipbf202fukuokachu.fukuoka.ocn.ne.jp ([221.190.22.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E4cVl-0002oa-St for provreg-archive@ietf.org; Mon, 15 Aug 2005 06:48:11 -0400 Received: from hYrl@localhost by sRHl.int (8.11.6/8.11.6); Mon, 15 Aug 2005 15:01:59 +0400 Message-ID: <48Mep5t0tyisFMVufQfawSHHn@wingdesigns.com> From: "Oliver Alvarado" Reply-To: "Oliver Alvarado" To: provreg-archive@ietf.org Subject: Windows XP Pro $49.95 Systemworks Date: Mon, 15 Aug 2005 06:59:59 -0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: SamuelShaver@guilbert.org Content-Type: multipart/mixed; boundary="--OUtDy7clPrDcX9Bdk7x" X-Spam-Score: 0.2 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 SAX ----OUtDy7clPrDcX9Bdk7x Content-Type: text/html; Content-Transfer-Encoding: quoted-printable L
Opt-in Email Special Offer   = ;  unsubscribe me
=

<= td width=3D5 bgcolor=3D#000080>
SEARCH

<= td vAlign=3Dbottom>

TOP 10 NEW TITLES

34=

 = ON SALE NOW!

 1 Office Pro 2003
 2 Adobe Photoshop 9.0
  Windows XP Pro
  Adobe Acrobat 7 Pro
 5 Flash MX 2004
 6 Corel Draw 12
 7 Norton Antivirus 2005
&n= bsp;8 Windows 2003 Server
 9 Alias Maya 6 Wavefrt
 10<= /td> Adobe Illustrator 1= 1
  See more by this= manufacturer
   Microsoft
   Symantec
   Adobe
  Customers also bought
   these other items...

Microsoft Office Professional Ed= ition *2003*
Microsoft<= br>

<= td vAlign=3Dtop noWrap>
Choose:
 
= Price:
= List Price:$499.00
$69.99
You Save:$429.01 (86%)



Availability: Available for INSTANT download!
<= b>Coupon Code: wHfld0
 

Sa= les Rank: #1
System requirements  |  Other Versions
Date Cou= pon Expires: August 31st, 2005
Averag= e Customer Review:3D"5 Based on 1232 reviews. Write a review.

Adobe Photoshop CS2 V 9.= 0
Adobe<= /a>

Choose:=
 

List Pric= e:$599.00
Price:<= /b>$69.99
You Save:$529.01 (90%)


Availability: Available for INSTANT download!
Coupon C= ode: 2hFlNL6Sc
 

Sales Ran= k: #2
System requirements  |  Other Versions
Date Coupon Exp= ires: August 31st, 2005
Average Custo= mer Review:3D"5 Based on 158997 reviews. Write a review.

Microsoft Wind= ows XP Professional or Longhorn Edition
Microsoft

Choose:=
 

<= img height=3D150 src=3Dhttp://images.amazon.com/images/P/B00005MOTG.01._SC= MZZZZZZZ_.jpg width=3D118 align=3Dleft border=3D0 name=3Dprod_image hspace= =3D5>

List Price:$279.00
Price:$49.99
You Save:<= /td>$229.01 (= 85%)



Availability:= Available for INSTANT download!
Coupon Code: UpB69
&nb= sp;

Sales Rank: #3
System requirements  |  Other Versions<= /span>
Date Coupon Expires: August 31st, 200= 5
Average Customer Review:3D"5 Ba= sed on 186656 reviews. Write a revie= w.

Adobe Acrobat Professional V 7.0
= Adobe

Choose:<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 width=3D164>
 

List Price:$499.00
Price:$69.99
You Save:$429.0= 1 (85%)

=

Availabili= ty: Available for INSTANT download!
Coupon Code: RN1ufPFzT<= br>  

Sales Rank: #4
System require= ments  |  Other Versio= ns
Date Coupon Expires: August 31= st, 2005
Average Customer Review: Based on 14539 reviews. Write a r= eview.

----OUtDy7clPrDcX9Bdk7x-- From owner-ietf-provreg@cafax.se Mon Aug 15 08:31:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4e7O-0008ID-Si for provreg-archive@megatron.ietf.org; Mon, 15 Aug 2005 08:31:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00056 for ; Mon, 15 Aug 2005 08:31:05 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4egU-0005qh-6g for provreg-archive@ietf.org; Mon, 15 Aug 2005 09:07:25 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FCOLFP004419 for ; Mon, 15 Aug 2005 14:24:21 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7FCOLff023899 for ietf-provreg-outgoing; Mon, 15 Aug 2005 14:24:21 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FCOKE7013746 for ; Mon, 15 Aug 2005 14:24:20 +0200 (MEST) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id j7FCqIMs029151; Mon, 15 Aug 2005 08:52:18 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 08:24:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ietf-provreg] Services messages in RFC 3730 Date: Mon, 15 Aug 2005 08:23:52 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07C9296F@dul1wnexmb01.vcorp.ad.vrsn.com> Thread-Topic: [ietf-provreg] Services messages in RFC 3730 Thread-Index: AcWfayVhfCif6XxnTVm/qfhuFxfJCgCJ/jKA From: "Hollenbeck, Scott" To: "Michael Young" Cc: X-OriginalArrivalTime: 15 Aug 2005 12:24:16.0533 (UTC) FILETIME=[40DC2C50:01C5A194] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j7FCOLE7018649 Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 2.0 (++) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Michael Young [mailto:myoung@ca.afilias.info] > Sent: Friday, August 12, 2005 2:25 PM > To: Hollenbeck, Scott > Cc: ietf-provreg@cafax.se > Subject: Re: [ietf-provreg] Services messages in RFC 3730 [snip] > >"You might have three queues instead of one, with "high > >priority" messages going into one queue, "normal priority" messages > >going into a second queue, and "low priority" messages going into a > >third." > > > I dont see the flexibility to do that as it stands, can you > elaborate on that please? This isn't a protocol interop issue. As I described here (point 2): http://www.cafax.se/ietf-provreg/maillist/2005-08/msg00027.html it's an implementation issue. You can implement whatever queueing mechanism you wish. All that matters to the protocol is that the messages can be retrieved as specified. > >a. It truly is optional. > >b. It doesn't complicate other existing implementations. > >c. It's common IETF practice to add new features via extensions once > >proposed standards are published. Extension development is usually a > >good reason to spin up a new working group. > >d. It allows us to avoid a core schema change and the resulting new > >protocol version. > > > >Think about d. for a moment. A protocol version rev likely > implies an > >operational requirement for ALL conforming servers and clients to > >support both old and new versions for some TBD period of time. An > >extension can be deployed without introducing version > management issues > > > A and B I think in case qualify. > For C how would suggest this be addressed in an extension? All you have to do is define an extension to the command and response to add the features you want to use. You can then publish the extension as an I-D if you think there's broad interest, or you can do your own thing for your own use. Your call. > As for D I completely take your point but isnt this > ultimately a cost benefit analysis not a defacto "don't go > there" decision? For example the poll queue is the only item > under discussion at this point, there are certainly other > contenders that could result in a schema change (see > > http://www.ietf.org/internet-drafts/draft-sullivan-epp-experie > nce-00.txt ). Can we really resolve all the raised issues > via extensions? If we can would that be less effort on the > implementers and users than a protocol change? I think it > really depends on the complexity of the changes. With a > protocol change the resultant client changes required may be > considered minimal by the users involved compared to the > gains in capability. An implementer may find running dual > protocol less effort than a series of extensions. As always - > it depends and we need some feedback beyond ourselves (some > registrar feedback would be helpful here). I'll have to read the document again to see what's changed since Andrew first showed me a copy. I don't know if everything described in the document can be addressed via extensions, so of course some analysis must be done. I think that's what we're trying to do right now. I will read the document again today and provide comments to the list. -Scott- From owner-ietf-provreg@cafax.se Mon Aug 15 09:16:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4epm-0006Sp-IV for provreg-archive@megatron.ietf.org; Mon, 15 Aug 2005 09:16:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02216 for ; Mon, 15 Aug 2005 09:16:57 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4fOq-0006uB-Nf for provreg-archive@ietf.org; Mon, 15 Aug 2005 09:53:17 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FD5dMK008591 for ; Mon, 15 Aug 2005 15:05:39 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7FD5dgi023336 for ietf-provreg-outgoing; Mon, 15 Aug 2005 15:05:39 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FD5cwB011829 for ; Mon, 15 Aug 2005 15:05:38 +0200 (MEST) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id j7FDXdh5030409 for ; Mon, 15 Aug 2005 09:33:40 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 09:05:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [ietf-provreg] Comments: draft-sullivan-epp-experience Date: Mon, 15 Aug 2005 09:05:14 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07C92974@dul1wnexmb01.vcorp.ad.vrsn.com> Thread-Topic: Comments: draft-sullivan-epp-experience Thread-Index: AcWhmfnDCOriWjI2Qy226/iliwS8zg== From: "Hollenbeck, Scott" To: X-OriginalArrivalTime: 15 Aug 2005 13:05:37.0705 (UTC) FILETIME=[07C0F990:01C5A19A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j7FD5dwB015516 Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 8bit Thanks to the guys from Afilias who took the time to write draft-sullivan-epp-experience. This is exactly the kind of info we need to discuss to determine what the next steps should be with the protocol. As described in the intro, the document covers four things. My take on each, in order: 1. The creation of the "Redemption Grace Period" (supported under EPP by [RFC3915] requires that certain provisions of [RFC3731] be violated in order to offer the new service. I believe we've already talked about removing the "update prohibited" restriction from 3731. My intention with 3915 has always been that actions to take a domain out of a "pending" status could over-ride the restriction. I agree that this isn't clear, and 3731 needs to be updated. Here's the text that should be removed from section 2.3: "With one exception, transform commands MUST be rejected when a pendingCreate, pendingDelete, pendingRenew, pendingTransfer, or pendingUpdate status is set. The only exception is that a command to approve, reject, or cancel a transfer MAY be processed while an object is in "pendingTransfer" status." There's similar text in the host and contact mappings. They should also be updated to remove this text. If a registry wants to prevent updates during one of the "pending" states, it can do so by explicitly setting one of the "prohibited" status values. 2. Experience with implementation suggests that status values may be insufficiently granular. I will argue that granularity is a prime example of something that is tailor made for extension development. The protocol defines some basic capability. That capability can be expanded using protocol extensions. It's exactly why the extension mechanism exists. 3. Experience with the poll queue mechanism suggests that a more sophisticated mechanism might be useful, or that the requirements for implementation should be relaxed. We started talking about this last week. I agree that the text in 3730 needs to be relaxed. I've suggested that new functionality may be best addressed as part of an extension. Others may disagree. 4. Experience with commands suggests either that status values are too coarsely-grained, or that another set of commands entirely needs to be defined. Same argument from me as used in point 2. Needed granularity implies extension candidacy. The question, of course, is breadth of appeal. We should talk about it if others think that more granularity should be added to the core. We should defer to an extension if the appeal is limited. -Scott- From owner-ietf-provreg@cafax.se Mon Aug 15 09:17:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4eq5-0006Wi-N9 for provreg-archive@megatron.ietf.org; Mon, 15 Aug 2005 09:17:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02222 for ; Mon, 15 Aug 2005 09:17:13 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4fPB-0006uc-1K for provreg-archive@ietf.org; Mon, 15 Aug 2005 09:53:33 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FD9C6H010378 for ; Mon, 15 Aug 2005 15:09:12 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7FD9B7J008713 for ietf-provreg-outgoing; Mon, 15 Aug 2005 15:09:11 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ogud.com (ns.ogud.com [66.92.146.160]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FD9AOQ028105 for ; Mon, 15 Aug 2005 15:09:10 +0200 (MEST) Received: from [10.31.32.63] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7FD8xnJ008073; Mon, 15 Aug 2005 09:09:00 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050812202127.GY23651@libertyrms.info> References: <200508041712.j74HCbhm018679@ns01.afilias.info> <20050812202127.GY23651@libertyrms.info> Date: Mon, 15 Aug 2005 09:00:46 -0400 To: Andrew Sullivan From: Edward Lewis Subject: Re: [ietf-provreg] EPP Document Updates Cc: ietf-provreg@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 At 16:21 -0400 8/12/05, Andrew Sullivan wrote: >Hi, > >Taking my cue from your .sig, I have a feeling I don't know what >you're thinking here (since I think I don't understand this). The quote was derived from a language teacher's comment about a sentence "yes, you have to know what the speaker is thinking to understand it." The .sig came to me as I strolled down a street in that country some months later. However, I think you have gotten what I meant. >On Fri, Aug 12, 2005 at 12:07:12PM -0400, Edward Lewis wrote: >> >> I think it's clear that there's a demand (as in supply and demand) >> for coordination of work involving the EPP protocol. However, I >> don't think there's justification for an IETF-style working group. > >I read that to mean that you think that there are some people who >think that EPP needs work, but that such work shouldn't go on in an >IETF wg. And I agree with you that simple changes to the documents >don't need a working group. The idiom "needs work" isn't what I would use. There are enhancements desired to EPP, and extensions for new problem domains. However, I have not seen or heard of changes that require a re-engineering of the basic protocol. (Not that there aren't needed changes lurking around the corner, but not real to date.) >But I'm not sure I follow the subsequent arguments that the IETF is >the wrong place to pursue updates or changes to the protocol. > >I appreciate that the IETF doesn't always attract all the registrar >and registry people we might like for feedback on these issues; but >that's a problem I'd suggest we solve by soliciting the feedback of >people in those communities, and _not_ by trying to take our protocol >developments to some other forum. I have no direct experience of >CENTR, but my few experiences with ICANN committees &c. have left me >with a very strong impression that the technical knowledge does not >there exist to do good protocol development. That's no indictment of >ICANN: they're doing their policy work, and relying on the technical >community of the Internet to do the technical work. That community >works within the IETF, no? I have a less optimistic view of the IETF process when it comes to getting feedback on issues. When Jaap and I were the co-chairs, most of our efforts were to spread the word on EPP. We were not the kind of co-chairs that took a heavy hand in the technical solution, we spent more time on process. Personally I saw my role as "mediating" between the reputation EPP garnered as "son of RRP" and "yet another tool" of the market dominating player versus the technical benefit it provided derived by being initiated by the people with the most experience. It wasn't very easy getting the circle of review to widen. My employer did not have a budget to send my out of the US. When I did have the opportunity, I found that ccTLDs were reluctant to pursue EPP for a few reasons, a lot of time because of the resources (people) needed. I recall conversations with "small" ccTLD operations that felt they didn't need to look at the documents (not enough transaction volume) and that they wouldn't be able to steer the IETF anyway. I saw mail from another ccTLD that was irritated by the meddling of "a high ranking IETF official" when trying to get them to comment on their proprietary work on the protocol. I'm making this sound more dire than it is. The volunteer nature of the IETF sometimes is a detriment to the process. Although I have been disappointed with ICANN - it has not met my engineering tastes - it is where the money transacted because of EPP resides. CENTR is an organization of registries, a much more concentrated population of interest in EPP. I'm holding up ICANN and CENTR as examples, not as solutions, only because they are the ones I am most familiar with in this case. >There does seem to be a live question of whether all the issues >everyone has identified with EPP can be accommodated without a >protocol change (including, of course, by instead developing >extensions). So far, I'm not totally convinced; but I'd sure like to >be, which is why I'm pursuing these conversations now. That's a healthy attitude and approach, and this mailing list is probably the best venue for that. Starting up an IETF WG takes some effort anyway, and even if it could be done with out a BoF, the next meeting wouldn't be until November. I'll say that I am reluctant to propose a new WG in anticipation of problems. Only if there is an engineering problem to hammer out would I want to create a group. In a volunteer organization, reactionary stances seem the most efficient. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From owner-ietf-provreg@cafax.se Mon Aug 15 09:46:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4fIZ-0002HN-Rk for provreg-archive@megatron.ietf.org; Mon, 15 Aug 2005 09:46:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03297 for ; Mon, 15 Aug 2005 09:46:42 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4frf-0007Xk-CQ for provreg-archive@ietf.org; Mon, 15 Aug 2005 10:23:02 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FDcBXC025435 for ; Mon, 15 Aug 2005 15:38:11 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7FDcBNe019315 for ietf-provreg-outgoing; Mon, 15 Aug 2005 15:38:11 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FDcAcm023365 for ; Mon, 15 Aug 2005 15:38:11 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E4fAG-0003Hx-RY for ietf-provreg@cafax.se; Mon, 15 Aug 2005 09:38:08 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id BF18E13744; Mon, 15 Aug 2005 09:37:54 -0400 (EDT) Date: Mon, 15 Aug 2005 09:37:54 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Comments: draft-sullivan-epp-experience Message-ID: <20050815133754.GA16496@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <046F43A8D79C794FA4733814869CDF07C92974@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF07C92974@dul1wnexmb01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hi Scott, Thanks for your comments. I particularly like this one: On Mon, Aug 15, 2005 at 09:05:14AM -0400, Hollenbeck, Scott wrote: > extension candidacy. The question, of course, is breadth of appeal. We > should talk about it if others think that more granularity should be > added to the core. We should defer to an extension if the appeal is > limited. That's exactly the feedback I've been hoping for. If there's broad consensus that the proposals are ill-conceived or not general enough, I think that the extension mechanism is the way to go, also. Thanks much, A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 From owner-ietf-provreg@cafax.se Mon Aug 15 11:20:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4glS-0005gU-OC for provreg-archive@megatron.ietf.org; Mon, 15 Aug 2005 11:20:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08357 for ; Mon, 15 Aug 2005 11:20:36 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4hKb-00019s-1F for provreg-archive@ietf.org; Mon, 15 Aug 2005 11:56:58 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FFBcx5027508 for ; Mon, 15 Aug 2005 17:11:39 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7FFBcEG007974 for ietf-provreg-outgoing; Mon, 15 Aug 2005 17:11:38 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FFBbAE012682 for ; Mon, 15 Aug 2005 17:11:38 +0200 (MEST) Received: from dev3.int.libertyrms.com ([10.1.3.40] helo=ca.afilias.info) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E4gci-0005qA-3U; Mon, 15 Aug 2005 11:11:36 -0400 Message-ID: <4300B152.4070200@ca.afilias.info> Date: Mon, 15 Aug 2005 11:14:26 -0400 From: janusz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: "Hollenbeck, Scott" CC: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Services messages in RFC 3730 References: <046F43A8D79C794FA4733814869CDF07C92888@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <046F43A8D79C794FA4733814869CDF07C92888@dul1wnexmb01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: janusz@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 2.0 (++) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit I see one more issue with command. The mandatory protocol behavior appears to be inconsistent with reasonable levels of interoperability. The XML syntax of response lacks elements that allow returning basic object-specific information such as name and ROID for actions such as auto-renewals or deletion and doing so in an interoperable manner. At the same time, the specification appears to make it mandatory for the server to produce service messages for such actions. In practice, that implies that server implementors will be forced to either: -produce generic service messages that will lack object specific information and hence will be nearly meaningless for the client OR - use extensions or include object information into message text to make the service messages meaningful, but at the cost of interoperability and registrar code that is registry/server independent. I can see 2 ways of solving the conflict. 1. Making poll command OPTIONAL as it was defined in earlier EPP draft documents. 2. Adding additional elements to response for returning basic object-specific information. Option 1 offers no impact on existing EPP deployments. Option 2 would impact existing EPP deployments but in the long term it would give more flexibility to client and server implementers. Basic object-information could be even used to prioritize dequeuing items from poll queues. Cheers, Janusz Sienkiewicz Hollenbeck, Scott wrote: >Superlatives and astonishment aside, there are really three issues here: > >1. Is priority-based messaging needed? You obviously think so assuming >that messaging isn't optional, so let's continue. > >2. If so, is this a specification issue or an implementation detail? I >believe it's both. > >Implementation detail: how you implement your message queuing system is >up to you. You might have three queues instead of one, with "high >priority" messages going into one queue, "normal priority" messages >going into a second queue, and "low priority" messages going into a >third. As registry operator you make an implementation decision to >determine which messages go where. The command can then be >implemented to read from them in whatever order makes sense to you. > >Specification issue: if multiple queues are implemented, how does one >let the client deal with that fact? As is, they could be read from in >whatever order the server operator decides to impose on the reader. >That's probably not too helpful. We also need to look at loosening up >the text as Jim suggested. > >3. If a specification issue, should something new be added to the core >specs or should something new be defined in an extension? Given that >we're talking about adding a new feature that may or may not be useful >to everyone (as you say, "it should all be OPTIONAL"), documenting a new >feature (adding priority marks to messages and allowing a client to >specify how they wish to deal with the priorities) in a standard >extension seems like the least intrusive way to make the functionality >available for these reasons: > >a. It truly is optional. >b. It doesn't complicate other existing implementations. >c. It's common IETF practice to add new features via extensions once >proposed standards are published. Extension development is usually a >good reason to spin up a new working group. >d. It allows us to avoid a core schema change and the resulting new >protocol version. > >Think about d. for a moment. A protocol version rev likely implies an >operational requirement for ALL conforming servers and clients to >support both old and new versions for some TBD period of time. An >extension can be deployed without introducing version management issues. > >-Scott- > > > From owner-ietf-provreg@cafax.se Mon Aug 15 11:45:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4h9m-0000KK-FV for provreg-archive@megatron.ietf.org; Mon, 15 Aug 2005 11:45:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09467 for ; Mon, 15 Aug 2005 11:45:43 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4hir-0001l1-FP for provreg-archive@ietf.org; Mon, 15 Aug 2005 12:22:06 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FFaMlp000189 for ; Mon, 15 Aug 2005 17:36:22 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7FFaMIk018497 for ietf-provreg-outgoing; Mon, 15 Aug 2005 17:36:22 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FFaLCQ025465 for ; Mon, 15 Aug 2005 17:36:21 +0200 (MEST) Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id j7FG4Njx003451; Mon, 15 Aug 2005 12:04:23 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 11:36:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ietf-provreg] Services messages in RFC 3730 Date: Mon, 15 Aug 2005 11:35:56 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07C929F1@dul1wnexmb01.vcorp.ad.vrsn.com> Thread-Topic: [ietf-provreg] Services messages in RFC 3730 Thread-Index: AcWhq6PuTt7KwqBdTHaIE6KHo7qyGQAAj2zg From: "Hollenbeck, Scott" To: "janusz" Cc: X-OriginalArrivalTime: 15 Aug 2005 15:36:19.0816 (UTC) FILETIME=[15459E80:01C5A1AF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j7FFaMCQ008486 Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 2.0 (++) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: 8bit Do those of you who keep asking about making the command optional not know about response code 2101? From 3730: '2101 "Unimplemented command" This response code MUST be returned when a server receives a valid EPP command element that is not implemented by the server.' The text in the description needs to be updated as we've discussed to note that message queuing isn't required for all command side effects, but I think you already have what you're asking for. Don't implement . Return 2101 if a client tries to use it. If at least two independent implementers don't implement it can get cut from the protocol completely as part of the proposed-to-draft process. BTW, I don't think we should try to mix object-specific data with the higher-level elements. They exist at different layers in the protocol stack. We could add an opaque element to the command to park object-specific data, but in a sense we already have that capability with the element. -Scott- > -----Original Message----- > From: janusz [mailto:janusz@ca.afilias.info] > Sent: Monday, August 15, 2005 11:14 AM > To: Hollenbeck, Scott > Cc: ietf-provreg@cafax.se > Subject: Re: [ietf-provreg] Services messages in RFC 3730 > > I see one more issue with command. > > The mandatory protocol behavior appears to be inconsistent with > reasonable levels of interoperability. > > The XML syntax of response lacks elements that allow returning > basic object-specific information such as name and ROID for > actions such > as auto-renewals or deletion and doing so in an interoperable > manner. At > the same time, the specification appears to make it mandatory for the > server to produce service messages for such actions. In > practice, that implies that server implementors will be > forced to either: > > -produce generic service messages that will lack object specific > information and hence will be nearly meaningless for the client > OR > - use extensions or include object information into message > text to make > the service messages meaningful, but at the cost of > interoperability and > registrar code that is registry/server independent. > > I can see 2 ways of solving the conflict. > > 1. Making poll command OPTIONAL as it was defined in earlier > EPP draft > documents. > 2. Adding additional elements to response for returning basic > object-specific information. > > Option 1 offers no impact on existing EPP deployments. > Option 2 would impact existing EPP deployments but in the > long term it > would give more flexibility to client and server implementers. Basic > object-information could be even used to prioritize dequeuing > items from > poll queues. > > Cheers, > > Janusz Sienkiewicz > > > > Hollenbeck, Scott wrote: > > >Superlatives and astonishment aside, there are really three > issues here: > > > >1. Is priority-based messaging needed? You obviously think > so assuming > >that messaging isn't optional, so let's continue. > > > >2. If so, is this a specification issue or an implementation > detail? I > >believe it's both. > > > >Implementation detail: how you implement your message > queuing system is > >up to you. You might have three queues instead of one, with "high > >priority" messages going into one queue, "normal priority" messages > >going into a second queue, and "low priority" messages going into a > >third. As registry operator you make an implementation decision to > >determine which messages go where. The command can then be > >implemented to read from them in whatever order makes sense to you. > > > >Specification issue: if multiple queues are implemented, how does one > >let the client deal with that fact? As is, they could be > read from in > >whatever order the server operator decides to impose on the reader. > >That's probably not too helpful. We also need to look at > loosening up > >the text as Jim suggested. > > > >3. If a specification issue, should something new be added > to the core > >specs or should something new be defined in an extension? Given that > >we're talking about adding a new feature that may or may not > be useful > >to everyone (as you say, "it should all be OPTIONAL"), > documenting a new > >feature (adding priority marks to messages and allowing a client to > >specify how they wish to deal with the priorities) in a standard > >extension seems like the least intrusive way to make the > functionality > >available for these reasons: > > > >a. It truly is optional. > >b. It doesn't complicate other existing implementations. > >c. It's common IETF practice to add new features via extensions once > >proposed standards are published. Extension development is usually a > >good reason to spin up a new working group. > >d. It allows us to avoid a core schema change and the resulting new > >protocol version. > > > >Think about d. for a moment. A protocol version rev likely > implies an > >operational requirement for ALL conforming servers and clients to > >support both old and new versions for some TBD period of time. An > >extension can be deployed without introducing version > management issues. > > > >-Scott- > > > > > > > > > From 6hunt@abbott-chase.com Mon Aug 15 13:06:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4iPo-0005rj-9f for provreg-archive@megatron.ietf.org; Mon, 15 Aug 2005 13:06:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14406 for ; Mon, 15 Aug 2005 13:06:21 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4iyy-00046h-Pu for provreg-archive@ietf.org; Mon, 15 Aug 2005 13:42:45 -0400 Received: from host-84-220-99-41.cust-adsl.tiscali.it ([84.220.99.41]) by mx2.foretec.com with smtp (Exim 4.24) id 1E4iPh-0002zx-L4 for provreg-archive@ietf.org; Mon, 15 Aug 2005 13:06:19 -0400 Message-ID: <29e801c5a1ba$ec21f28e$63c523e5@abbott-chase.com> From: "Vanessa J. Smith" <6hunt@abbott-chase.com> To: provreg-archive@ietf.org Subject: =?iso-8859-1?B?UG9wdWxhciBzb2Z0IC0gNzUlIE9GRg==?= Date: Mon, 15 Aug 2005 16:59:00 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_071CA769.32A86906" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc This is a multi-part message in MIME format. ------=_NextPart_000_0000_071CA769.32A86906 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_8F8EE76F.22BC2EDD" ------=_NextPart_001_0001_8F8EE76F.22BC2EDD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Access all the popular software imaginable for extremely low prices! We sell software 2-6 times cheaper than retail price. Just a few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $59.95 Corel Draw Graphics Suite 11 Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And lots more... Go visit us at: http://www.all-of-oem.com Best regards, Vanessa J. Smith _____________________________________________________ To be taken out, go here _____________________________________________________ ------=_NextPart_001_0001_8F8EE76F.22BC2EDD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Access all the popular software imaginable for extremely low prices!
We sell software 2-6 times cheaper than retail price.

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

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Creative Suite Premium (5 CD)
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And lots more... Go visit us at:

http://www.all-of-oem.com

Best regards,
Vanessa J. Smith


_____________________________________________________
To be taken out, go here
_____________________________________________________

------=_NextPart_001_0001_8F8EE76F.22BC2EDD-- ------=_NextPart_000_0000_071CA769.32A86906-- From owner-ietf-provreg@cafax.se Mon Aug 15 13:16:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4iZv-0007No-ON for provreg-archive@megatron.ietf.org; Mon, 15 Aug 2005 13:16:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15032 for ; Mon, 15 Aug 2005 13:16:49 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4j92-0004PW-VI for provreg-archive@ietf.org; Mon, 15 Aug 2005 13:53:12 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FHBsWK013193 for ; Mon, 15 Aug 2005 19:11:54 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7FHBs5V006823 for ietf-provreg-outgoing; Mon, 15 Aug 2005 19:11:54 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FHBq3e005396 for ; Mon, 15 Aug 2005 19:11:53 +0200 (MEST) Received: from dev3.int.libertyrms.com ([10.1.3.40] helo=ca.afilias.info) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E4iV5-00010C-Us; Mon, 15 Aug 2005 13:11:51 -0400 Message-ID: <4300CD82.6080709@ca.afilias.info> Date: Mon, 15 Aug 2005 13:14:42 -0400 From: janusz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: "Hollenbeck, Scott" CC: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Services messages in RFC 3730 References: <046F43A8D79C794FA4733814869CDF07C929F1@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <046F43A8D79C794FA4733814869CDF07C929F1@dul1wnexmb01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: janusz@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 2.0 (++) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Content-Transfer-Encoding: 7bit Not implementing command and returning 2101 looks to me like a very problematic implementation option. Section 2.9.3.4 in 3730 ("EPP command seems to be mandatory. Also sections 3.2.6 "Offline Review of Requested Actions" in 3731, 3732 and 3733 documents introduce similiar use cases. Only registries that don't implement object transfers and pending actions could consider the option of not implementing command. Changing text of section 2.9.2.3 to make poll message queuing optional instead of mandatory should eliminate the issue. Cheers, Janusz Sienkiewicz Hollenbeck, Scott wrote: >Do those of you who keep asking about making the command optional >not know about response code 2101? From 3730: > >'2101 "Unimplemented command" >This response code MUST be returned when a server receives a valid EPP >command element that is not implemented by the server.' > >The text in the description needs to be updated as we've >discussed to note that message queuing isn't required for all command >side effects, but I think you already have what you're asking for. >Don't implement . Return 2101 if a client tries to use it. If at >least two independent implementers don't implement it can get cut >from the protocol completely as part of the proposed-to-draft process. > >BTW, I don't think we should try to mix object-specific data with the >higher-level elements. They exist at different layers in the >protocol stack. We could add an opaque element to the command to >park object-specific data, but in a sense we already have that >capability with the element. > >-Scott- > > > >>-----Original Message----- >>From: janusz [mailto:janusz@ca.afilias.info] >>Sent: Monday, August 15, 2005 11:14 AM >>To: Hollenbeck, Scott >>Cc: ietf-provreg@cafax.se >>Subject: Re: [ietf-provreg] Services messages in RFC 3730 >> >>I see one more issue with command. >> >>The mandatory protocol behavior appears to be inconsistent with >>reasonable levels of interoperability. >> >>The XML syntax of response lacks elements that allow returning >>basic object-specific information such as name and ROID for >>actions such >>as auto-renewals or deletion and doing so in an interoperable >>manner. At >>the same time, the specification appears to make it mandatory for the >>server to produce service messages for such actions. In >>practice, that implies that server implementors will be >>forced to either: >> >>-produce generic service messages that will lack object specific >>information and hence will be nearly meaningless for the client >> OR >>- use extensions or include object information into message >>text to make >>the service messages meaningful, but at the cost of >>interoperability and >>registrar code that is registry/server independent. >> >>I can see 2 ways of solving the conflict. >> >>1. Making poll command OPTIONAL as it was defined in earlier >>EPP draft >>documents. >>2. Adding additional elements to response for returning basic >>object-specific information. >> >>Option 1 offers no impact on existing EPP deployments. >>Option 2 would impact existing EPP deployments but in the >>long term it >>would give more flexibility to client and server implementers. Basic >>object-information could be even used to prioritize dequeuing >>items from >>poll queues. >> >>Cheers, >> >>Janusz Sienkiewicz >> >> >> >>Hollenbeck, Scott wrote: >> >> >> >>>Superlatives and astonishment aside, there are really three >>> >>> >>issues here: >> >> >>>1. Is priority-based messaging needed? You obviously think >>> >>> >>so assuming >> >> >>>that messaging isn't optional, so let's continue. >>> >>>2. If so, is this a specification issue or an implementation >>> >>> >>detail? I >> >> >>>believe it's both. >>> >>>Implementation detail: how you implement your message >>> >>> >>queuing system is >> >> >>>up to you. You might have three queues instead of one, with "high >>>priority" messages going into one queue, "normal priority" messages >>>going into a second queue, and "low priority" messages going into a >>>third. As registry operator you make an implementation decision to >>>determine which messages go where. The command can then be >>>implemented to read from them in whatever order makes sense to you. >>> >>>Specification issue: if multiple queues are implemented, how does one >>>let the client deal with that fact? As is, they could be >>> >>> >>read from in >> >> >>>whatever order the server operator decides to impose on the reader. >>>That's probably not too helpful. We also need to look at >>> >>> >>loosening up >> >> >>>the text as Jim suggested. >>> >>>3. If a specification issue, should something new be added >>> >>> >>to the core >> >> >>>specs or should something new be defined in an extension? Given that >>>we're talking about adding a new feature that may or may not >>> >>> >>be useful >> >> >>>to everyone (as you say, "it should all be OPTIONAL"), >>> >>> >>documenting a new >> >> >>>feature (adding priority marks to messages and allowing a client to >>>specify how they wish to deal with the priorities) in a standard >>>extension seems like the least intrusive way to make the >>> >>> >>functionality >> >> >>>available for these reasons: >>> >>>a. It truly is optional. >>>b. It doesn't complicate other existing implementations. >>>c. It's common IETF practice to add new features via extensions once >>>proposed standards are published. Extension development is usually a >>>good reason to spin up a new working group. >>>d. It allows us to avoid a core schema change and the resulting new >>>protocol version. >>> >>>Think about d. for a moment. A protocol version rev likely >>> >>> >>implies an >> >> >>>operational requirement for ALL conforming servers and clients to >>>support both old and new versions for some TBD period of time. An >>>extension can be deployed without introducing version >>> >>> >>management issues. >> >> >>>-Scott- >>> >>> >>> >>> >>> >> >> > > > From owner-ietf-provreg@cafax.se Mon Aug 15 13:34:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4iqa-0001bK-II for provreg-archive@megatron.ietf.org; Mon, 15 Aug 2005 13:34:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15949 for ; Mon, 15 Aug 2005 13:34:03 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4jPh-0004ts-4Z for provreg-archive@ietf.org; Mon, 15 Aug 2005 14:10:25 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FHSMfw027816 for ; Mon, 15 Aug 2005 19:28:22 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7FHSMOR029181 for ietf-provreg-outgoing; Mon, 15 Aug 2005 19:28:22 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FHSLTC001431 for ; Mon, 15 Aug 2005 19:28:21 +0200 (MEST) Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id j7FHuOSs007129 for ; Mon, 15 Aug 2005 13:56:25 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 13:28:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [ietf-provreg] 3730 Text Change Proposal Date: Mon, 15 Aug 2005 13:27:56 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07C92A4A@dul1wnexmb01.vcorp.ad.vrsn.com> Thread-Topic: 3730 Text Change Proposal Thread-Index: AcWhvqyuDd6OZiQ4S/2/pLubtsIbcQ== From: "Hollenbeck, Scott" To: X-OriginalArrivalTime: 15 Aug 2005 17:28:20.0144 (UTC) FILETIME=[BAE64B00:01C5A1BE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j7FHSLTC020417 Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 8bit OK, we've been talking about the text in 3730 that describes the command for a few days. Let me throw out a straw man text change that builds on the one first proposed by Jim Gould. OLD (section 2.9.2.3): Service messages MUST be created for all clients affected by an action on an object. For example, actions MUST be reported to both the client that requests an object transfer and the client that has the authority to approve or reject the transfer request. NEW: Service messages can be created for all clients affected by an action on an object that did not directly execute the action. For example, actions can be reported to the client that has the authority to approve or reject a transfer request. Other methods of server-client action notification, such as offline reporting, are also possible and are beyond the scope of this specification. Fire away! -Scott- From owner-ietf-provreg@cafax.se Tue Aug 16 11:06:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E530w-00071m-Oq for provreg-archive@megatron.ietf.org; Tue, 16 Aug 2005 11:06:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16891 for ; Tue, 16 Aug 2005 11:06:03 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E53aH-0003bb-JT for provreg-archive@ietf.org; Tue, 16 Aug 2005 11:42:39 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GEwiVs001117 for ; Tue, 16 Aug 2005 16:58:44 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GEwiC5004519 for ietf-provreg-outgoing; Tue, 16 Aug 2005 16:58:44 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GEwhX7001993 for ; Tue, 16 Aug 2005 16:58:43 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E52tl-0001ge-Ac for ietf-provreg@cafax.se; Tue, 16 Aug 2005 10:58:41 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id EA7F013744; Tue, 16 Aug 2005 10:58:26 -0400 (EDT) Date: Tue, 16 Aug 2005 10:58:26 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Comments: draft-sullivan-epp-experience Message-ID: <20050816145826.GD4918@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <046F43A8D79C794FA4733814869CDF07C92974@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF07C92974@dul1wnexmb01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa In my response to this, I forgot to mention one other thing. On Mon, Aug 15, 2005 at 09:05:14AM -0400, Hollenbeck, Scott wrote: > updated. Here's the text that should be removed from section 2.3: [. . .] > be updated to remove this text. If a registry wants to prevent updates > during one of the "pending" states, it can do so by explicitly setting > one of the "prohibited" status values. I've also ended up arguing that the "linked" status should be similarly unconnected to prohibitions. The general idea is that if a repository operator wants a policy prohibiting some action or other, then the operator should place such a prohibition on the object. Nothing else should entail such a prohibition. The "linked" status doesn't strictly prohibit deletion itself; instead, 3732 has this: "A host name object MUST NOT be deleted if the host object is associated with any other object." Similarly, 3733 has this: "A contact object SHOULD NOT be deleted if it is associated with other known objects." I can see an argument for preserving the latter; but the former is surely a policy decision, and ought to be left to the repository operator. I realise that this proposal may be more controversial than the one to unhook the prohibitiond from the "pending" states. But even though this is expressing a policy that is a good idea -- don't allow deletions of an object if anything else refers to it -- it's still a policy, and therefore something that a repository operator might want to change in some circumstance we haven't imagined yet. Since the prohibitions are already possible using some other status, there's no reason to use this status to enforce the prohibitions. (I think the linked status is worth keeping, because one might use it as the basis of policy.) Thoughts? A ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 From owner-ietf-provreg@cafax.se Tue Aug 16 11:30:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E53OR-0003Al-M8 for provreg-archive@megatron.ietf.org; Tue, 16 Aug 2005 11:30:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18246 for ; Tue, 16 Aug 2005 11:30:20 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E53xm-0004El-RP for provreg-archive@ietf.org; Tue, 16 Aug 2005 12:06:56 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GFOenC024979 for ; Tue, 16 Aug 2005 17:24:40 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GFOeQs005048 for ietf-provreg-outgoing; Tue, 16 Aug 2005 17:24:40 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GFOb58028956 for ; Tue, 16 Aug 2005 17:24:37 +0200 (MEST) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.1/8.12.11) with ESMTP id j7GFOcWe003453; Tue, 16 Aug 2005 11:24:38 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 Aug 2005 11:24:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ietf-provreg] Comments: draft-sullivan-epp-experience Date: Tue, 16 Aug 2005 11:24:08 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07C92BF3@dul1wnexmb01.vcorp.ad.vrsn.com> Thread-Topic: [ietf-provreg] Comments: draft-sullivan-epp-experience Thread-Index: AcWidPiMuRmUxlo9S7WqKf/NyyaxCQAAKp3g From: "Hollenbeck, Scott" To: "Andrew Sullivan" , X-OriginalArrivalTime: 16 Aug 2005 15:24:35.0908 (UTC) FILETIME=[9C1F8840:01C5A276] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j7GFOc58018855 Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 8bit > -----Original Message----- > From: owner-ietf-provreg@cafax.se > [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Andrew Sullivan > Sent: Tuesday, August 16, 2005 10:58 AM > To: ietf-provreg@cafax.se > Subject: Re: [ietf-provreg] Comments: draft-sullivan-epp-experience [snip] > The "linked" status doesn't strictly prohibit deletion itself; > instead, 3732 has this: "A host name object MUST NOT be deleted if > the host object is associated with any other object." Similarly, 3733 > has this: "A contact object SHOULD NOT be deleted if it is associated > with other known objects." I can see an argument for preserving the > latter; but the former is surely a policy decision, and ought to be > left to the repository operator. > > I realise that this proposal may be more controversial than the one > to unhook the prohibitiond from the "pending" states. But even > though this is expressing a policy that is a good idea -- don't allow > deletions of an object if anything else refers to it -- it's still a > policy, and therefore something that a repository operator might want > to change in some circumstance we haven't imagined yet. Since the > prohibitions are already possible using some other status, there's no > reason to use this status to enforce the prohibitions. (I think the > linked status is worth keeping, because one might use it as the basis > of policy.) While I agree that this isn't a protocol interoperability issue, remember why the text is there: deleting a host object (or a domain object that has subordinate host objects) has the potential to *BREAK* DNS resolution. Some poor operator that's not a party to the registry-registrar relationship doesn't find out about such changes until something disappears from a zone and things stop working. I'm not averse to softening the MUST NOT to a SHOULD NOT as long as we explain that things can really break if it's done without consideration of object relationships. -Scott- From owner-ietf-provreg@cafax.se Tue Aug 16 12:10:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5415-0001OV-BV for provreg-archive@megatron.ietf.org; Tue, 16 Aug 2005 12:10:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20336 for ; Tue, 16 Aug 2005 12:10:16 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E54aR-0005Ll-Ms for provreg-archive@ietf.org; Tue, 16 Aug 2005 12:46:52 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GG22Ee021055 for ; Tue, 16 Aug 2005 18:02:02 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GG22pa006769 for ietf-provreg-outgoing; Tue, 16 Aug 2005 18:02:02 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GG21s7021064 for ; Tue, 16 Aug 2005 18:02:01 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E53t2-0003fM-Ad for ietf-provreg@cafax.se; Tue, 16 Aug 2005 12:02:00 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id E6C4013744; Tue, 16 Aug 2005 12:01:45 -0400 (EDT) Date: Tue, 16 Aug 2005 12:01:45 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Comments: draft-sullivan-epp-experience Message-ID: <20050816160145.GK4918@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <046F43A8D79C794FA4733814869CDF07C92BF3@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF07C92BF3@dul1wnexmb01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On Tue, Aug 16, 2005 at 11:24:08AM -0400, Hollenbeck, Scott wrote: > I'm not averse to softening the MUST NOT to a SHOULD NOT as long as we > explain that things can really break if it's done without consideration > of object relationships. Yes, that's what I had in mind. I totally agree that this is a dangerous area to wade. FWIW, the operational issue that has this on my mind is the lousy set of alternatives one now has to choose among for cases where one registrar wants to delete a domain, and another registrar is pointing to a subordinate host of that domain as a name server. It's not a big deal if there's only one such pointer, but if there are dozens, it's at least ugly. I'm hoping someone smarter than I am will come up with something brilliant to make this co-ordination easier, and if we weaken the language here a little, then it will be possible to accommodate such schemes without modifying or violating the protocol. (That isn't to say that I'd advocate allowing such deletions starting tomorrow; it'd be only in case of some clever scheme for solving the problems.) A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 From owner-ietf-provreg@cafax.se Tue Aug 16 12:33:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E54NU-00080H-DX for provreg-archive@megatron.ietf.org; Tue, 16 Aug 2005 12:33:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22358 for ; Tue, 16 Aug 2005 12:33:25 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E54wm-0006Cr-7E for provreg-archive@ietf.org; Tue, 16 Aug 2005 13:10:01 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GGSHu1021045 for ; Tue, 16 Aug 2005 18:28:17 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GGSHLP019082 for ietf-provreg-outgoing; Tue, 16 Aug 2005 18:28:17 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [213.154.224.50]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GGSGdj002701 for ; Tue, 16 Aug 2005 18:28:16 +0200 (MEST) Received: from bartok.nlnetlabs.nl (localhost.nlnetlabs.nl [127.0.0.1]) by bartok.nlnetlabs.nl (8.13.3/8.13.1) with ESMTP id j7GGSGQx001059 for ; Tue, 16 Aug 2005 18:28:16 +0200 (CEST) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200508161628.j7GGSGQx001059@bartok.nlnetlabs.nl> To: ietf-provreg@cafax.se Subject: [ietf-provreg] FYI Date: Tue, 16 Aug 2005 18:28:16 +0200 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d The IESG has approved the following document: - 'Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) ' as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-secdns-08.txt Technical Summary This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security extensions (DNSSEC) for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. Working Group Summary This document was received as an invidual submission and is not the product of an IETF working group. Protocol Quality This document was reviewed for the IESG by David Kessens and was also reviewed by the dnsop working group. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From owner-ietf-provreg@cafax.se Tue Aug 16 14:10:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E55tJ-0007Z8-Vs for provreg-archive@megatron.ietf.org; Tue, 16 Aug 2005 14:10:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26400 for ; Tue, 16 Aug 2005 14:10:24 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E56Sh-00006t-S3 for provreg-archive@ietf.org; Tue, 16 Aug 2005 14:47:00 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GI4KlH024733 for ; Tue, 16 Aug 2005 20:04:20 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GI4KFi000325 for ietf-provreg-outgoing; Tue, 16 Aug 2005 20:04:20 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GI4IKL010097 for ; Tue, 16 Aug 2005 20:04:19 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E55nN-00074B-UA for ietf-provreg@cafax.se; Tue, 16 Aug 2005 14:04:17 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id 81B6213744; Tue, 16 Aug 2005 14:04:03 -0400 (EDT) Date: Tue, 16 Aug 2005 14:04:03 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] 3730 Text Change Proposal Message-ID: <20050816180403.GT4918@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <046F43A8D79C794FA4733814869CDF07C92A4A@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF07C92A4A@dul1wnexmb01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Mon, Aug 15, 2005 at 01:27:56PM -0400, Hollenbeck, Scott wrote: > NEW: > Service messages can be created for all clients affected by an action on > an object that did not directly execute the action. For example, > actions can be reported to the client that has the authority > to approve or reject a transfer request. Other methods of server-client > action notification, such as offline reporting, are also possible and > are beyond the scope of this specification. I like this, myself. Do we want to make the "can"s in there SHOULDs instead? (I don't, really, but this is a pretty dramatic weakening from the MUST we had before. Looking at the archives, there seem to have been some people arguing for a much more important poll queue.) A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 From owner-ietf-provreg@cafax.se Tue Aug 16 16:13:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E57ny-00077d-0H for provreg-archive@megatron.ietf.org; Tue, 16 Aug 2005 16:13:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06898 for ; Tue, 16 Aug 2005 16:12:59 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E58NK-0004ct-4b for provreg-archive@ietf.org; Tue, 16 Aug 2005 16:49:37 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GK7vh9004204 for ; Tue, 16 Aug 2005 22:07:57 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GK7vlK019265 for ietf-provreg-outgoing; Tue, 16 Aug 2005 22:07:57 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ogud.com (ns.ogud.com [66.92.146.160]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GK7uPu020136 for ; Tue, 16 Aug 2005 22:07:56 +0200 (MEST) Received: from [10.31.32.63] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7GK7kd4014991; Tue, 16 Aug 2005 16:07:48 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050816180403.GT4918@libertyrms.info> References: <046F43A8D79C794FA4733814869CDF07C92A4A@dul1wnexmb01.vcorp.ad.vrsn.com> <20050816180403.GT4918@libertyrms.info> Date: Tue, 16 Aug 2005 16:02:07 -0400 To: ietf-provreg@cafax.se From: Edward Lewis Subject: Re: [ietf-provreg] 3730 Text Change Proposal Cc: ed.lewis@Neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 At 14:04 -0400 8/16/05, Andrew Sullivan wrote: >On Mon, Aug 15, 2005 at 01:27:56PM -0400, Hollenbeck, Scott wrote: >> NEW: >> Service messages can be created for all clients affected by an action on >> an object that did not directly execute the action. For example, >> actions can be reported to the client that has the authority >> to approve or reject a transfer request. Other methods of server-client >> action notification, such as offline reporting, are also possible and >> are beyond the scope of this specification. > >I like this, myself. Do we want to make the "can"s in there SHOULDs >instead? (I don't, really, but this is a pretty dramatic weakening >from the MUST we had before. Looking at the archives, there seem to >have been some people arguing for a much more important poll queue.) The change confuses me. Instead of relaxing from MUST to SHOULD, the change eliminates any "standards" words. The code base we have currently conforms to the "OLD" spec. We don't have a problem with it, hence we are reluctant to want to see the spec changed (in a way that is "not backwards compatible"). Not so much because we are against change but because we'd like to avoid having to redistribute software (or require new software be written by clients that contact us). It might be that the service message requirement as in "OLD" is suboptimal because it requires a service message go back to the initiator. But we'd rather keep this practice and just recognize (and then drop) the unnecessary message than have to replace software. Keeping in mind that the current way of passing messages is only sub-optimal, not unworkable. Perhaps there's a misunderstanding on my part of what problem the extraneous message causes. Still, I would have thought the new text would have been: Service messages MUST be created for all clients affected by an action on an object that did not directly execute the action, and MAY be created for others affected (including the initiator). For example, ... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From owner-ietf-provreg@cafax.se Tue Aug 16 16:38:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58Cv-0004Jd-8T for provreg-archive@megatron.ietf.org; Tue, 16 Aug 2005 16:38:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11475 for ; Tue, 16 Aug 2005 16:38:46 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E58mJ-0006Uy-IR for provreg-archive@ietf.org; Tue, 16 Aug 2005 17:15:24 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GKTBBj014375 for ; Tue, 16 Aug 2005 22:29:11 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GKTAtV008782 for ietf-provreg-outgoing; Tue, 16 Aug 2005 22:29:10 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GKT9w8016576 for ; Tue, 16 Aug 2005 22:29:10 +0200 (MEST) Received: from dev3.int.libertyrms.com ([10.1.3.40] helo=ca.afilias.info) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E583Y-0002Si-H7; Tue, 16 Aug 2005 16:29:08 -0400 Message-ID: <43024D43.1060504@ca.afilias.info> Date: Tue, 16 Aug 2005 16:32:03 -0400 From: janusz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Edward Lewis CC: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] 3730 Text Change Proposal References: <046F43A8D79C794FA4733814869CDF07C92A4A@dul1wnexmb01.vcorp.ad.vrsn.com> <20050816180403.GT4918@libertyrms.info> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: janusz@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Edward, if your code conforms to the OLD text then it should conform to the NEW version. Nobody is proposing replacing MUST with MUST NOT. The NEW text looks reasonable to me. It keeps existing EPP deployments still within protocol compliance. Cheers, Janusz Sienkiewicz Edward Lewis wrote: > At 14:04 -0400 8/16/05, Andrew Sullivan wrote: > >> On Mon, Aug 15, 2005 at 01:27:56PM -0400, Hollenbeck, Scott wrote: >> >>> NEW: >>> Service messages can be created for all clients affected by an >>> action on >>> an object that did not directly execute the action. For example, >>> actions can be reported to the client that has the >>> authority >>> to approve or reject a transfer request. Other methods of >>> server-client >>> action notification, such as offline reporting, are also possible and >>> are beyond the scope of this specification. >> >> >> I like this, myself. Do we want to make the "can"s in there SHOULDs >> instead? (I don't, really, but this is a pretty dramatic weakening >> from the MUST we had before. Looking at the archives, there seem to >> have been some people arguing for a much more important poll queue.) > > > The change confuses me. Instead of relaxing from MUST to SHOULD, the > change eliminates any "standards" words. > > The code base we have currently conforms to the "OLD" spec. We don't > have a problem with it, hence we are reluctant to want to see the spec > changed (in a way that is "not backwards compatible"). Not so much > because we are against change but because we'd like to avoid having to > redistribute software (or require new software be written by clients > that contact us). > > It might be that the service message requirement as in "OLD" is > suboptimal because it requires a service message go back to the > initiator. But we'd rather keep this practice and just recognize (and > then drop) the unnecessary message than have to replace software. > Keeping in mind that the current way of passing messages is only > sub-optimal, not unworkable. > > Perhaps there's a misunderstanding on my part of what problem the > extraneous message causes. > > Still, I would have thought the new text would have been: > > Service messages MUST be created for all clients affected by an action on > an object that did not directly execute the action, and MAY be created > for > others affected (including the initiator). For example, ... > From owner-ietf-provreg@cafax.se Tue Aug 16 16:47:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58Ln-0006nN-5i for provreg-archive@megatron.ietf.org; Tue, 16 Aug 2005 16:47:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11725 for ; Tue, 16 Aug 2005 16:47:56 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E58vB-0006gk-Br for provreg-archive@ietf.org; Tue, 16 Aug 2005 17:24:34 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GKh0Vj012751 for ; Tue, 16 Aug 2005 22:43:00 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GKgxtd020776 for ietf-provreg-outgoing; Tue, 16 Aug 2005 22:42:59 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GKgwhi008189 for ; Tue, 16 Aug 2005 22:42:58 +0200 (MEST) Received: from roaming7.int.libertyrms.com ([10.1.3.237] helo=DUN911) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E58Gv-0002nW-Rr; Tue, 16 Aug 2005 16:42:57 -0400 From: "Michael Young" To: "'janusz'" , "'Edward Lewis'" Cc: Subject: RE: [ietf-provreg] 3730 Text Change Proposal Date: Tue, 16 Aug 2005 16:42:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <43024D43.1060504@ca.afilias.info> Thread-Index: AcWiocDrQX3s2k9dRtOYV36Om5dltAAAH/6Q Message-Id: X-SA-Exim-Mail-From: myoung@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Hi Edward "Service messages can be created for all clients affected by an action" Likewise I don't understand why this change would invalidate any existing implementations, which is why Scott proposed it this way. MUST replaced with SHOULD or "can" does not cause an issue with existing code. Retaining "MUST" however puts us back to square one in resolving the raised issue - so I don't see leaving it unmodified as a viable option. I am perfectly happy to settle for softening it to a SHOULD versus "can" if you find that language confusing. Michael Young -----Original Message----- From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] On Behalf Of janusz Sent: Tuesday, August 16, 2005 4:32 PM To: Edward Lewis Cc: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] 3730 Text Change Proposal Edward, if your code conforms to the OLD text then it should conform to the NEW version. Nobody is proposing replacing MUST with MUST NOT. The NEW text looks reasonable to me. It keeps existing EPP deployments still within protocol compliance. Cheers, Janusz Sienkiewicz Edward Lewis wrote: > At 14:04 -0400 8/16/05, Andrew Sullivan wrote: > >> On Mon, Aug 15, 2005 at 01:27:56PM -0400, Hollenbeck, Scott wrote: >> >>> NEW: >>> Service messages can be created for all clients affected by an >>> action on an object that did not directly execute the action. For >>> example, actions can be reported to the client that has >>> the authority to approve or reject a transfer request. Other >>> methods of server-client action notification, such as offline >>> reporting, are also possible and are beyond the scope of this >>> specification. >> >> >> I like this, myself. Do we want to make the "can"s in there SHOULDs >> instead? (I don't, really, but this is a pretty dramatic weakening >> from the MUST we had before. Looking at the archives, there seem to >> have been some people arguing for a much more important poll queue.) > > > The change confuses me. Instead of relaxing from MUST to SHOULD, the > change eliminates any "standards" words. > > The code base we have currently conforms to the "OLD" spec. We don't > have a problem with it, hence we are reluctant to want to see the spec > changed (in a way that is "not backwards compatible"). Not so much > because we are against change but because we'd like to avoid having to > redistribute software (or require new software be written by clients > that contact us). > > It might be that the service message requirement as in "OLD" is > suboptimal because it requires a service message go back to the > initiator. But we'd rather keep this practice and just recognize (and > then drop) the unnecessary message than have to replace software. > Keeping in mind that the current way of passing messages is only > sub-optimal, not unworkable. > > Perhaps there's a misunderstanding on my part of what problem the > extraneous message causes. > > Still, I would have thought the new text would have been: > > Service messages MUST be created for all clients affected by an action > on an object that did not directly execute the action, and MAY be > created for others affected (including the initiator). For example, > ... > From owner-ietf-provreg@cafax.se Tue Aug 16 17:18:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58oy-0005Q0-V8 for provreg-archive@megatron.ietf.org; Tue, 16 Aug 2005 17:18:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13061 for ; Tue, 16 Aug 2005 17:18:05 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E59ON-0007Ro-T2 for provreg-archive@ietf.org; Tue, 16 Aug 2005 17:54:44 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLBQFs014805 for ; Tue, 16 Aug 2005 23:11:26 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GLBQU5008362 for ietf-provreg-outgoing; Tue, 16 Aug 2005 23:11:26 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ns01.afilias.info (ns01.afilias.info [170.224.17.215]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLBPpK018065 for ; Tue, 16 Aug 2005 23:11:25 +0200 (MEST) Received: from GLIDER (ismtp.afilias.com [216.217.55.254]) (authenticated bits=0) by ns01.afilias.info (8.12.8/8.12.8) with ESMTP id j7GLBMLL019238; Tue, 16 Aug 2005 17:11:22 -0400 Message-Id: <200508162111.j7GLBMLL019238@ns01.afilias.info> From: "Ram Mohan" To: "'Edward Lewis'" , Subject: RE: [ietf-provreg] EPP Document Updates Date: Tue, 16 Aug 2005 17:12:00 -0400 Organization: Afilias MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWfWAr5vKMx8eL7QyWoAXPrL/45PgDL9WOA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Ed, all, As much as CENTR [or other groups - CDNC comes to mind] is a model for interested registries to talk EPP implementation details, IETF is likely the right place for the protocol elements to get moved forward, in an open "come-right-in" manner. (I expect you already agree with this, I'm simply saying it explicitly). > I think it's clear that there's a demand (as in supply and demand) > for coordination of work involving the EPP protocol. However, I > don't think there's justification for an IETF-style working group. If you read draft-sullivan-epp-experience, there are at least a few areas that need engineers to come together to talk protocol and discuss how to move things forward to the core protocol. Scott (Hollenbeck), for instance, in some cases advocates the exclusive use of extensions for modified or new functionality, and in other cases (RGP) has helped write it into the protocol. My goal is to not have the EPP documents become the "epitome of perfection", but one goal would/could/should be to ensure that diversity of implementations in EPP via extensions for the exact same functionality, aimed at the exact same community, and used by the exact same participants not become the lazy alternative to active discussion on which elements should become part of the core protocol. > The IETF isn't the right venue to attract interest of registries. > There was a time in which EPP development needed the input of other > protocol engineering experts. IETF wg output (and in some cases, even ID track) gets read and digested - as you know, there a lot of lurkers and only a few active speakers. Folks I speak with at many ccTLDs find the IETF work to be both clueful and participatory, if they choose to. > I'm sure another run of the PROVREG WG would gather a different and > probably more well-rounded set of participants than the first try. > But still, there is no guarantee that we get who we need. There never is a guarantee, but it seems to me that we have a confluence of demand (not just market demand, but actual engineering ones), interest from participants, and practical knowledge waiting to be applied appropriately. -Ram From owner-ietf-provreg@cafax.se Tue Aug 16 17:28:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58zK-0007uD-DL for provreg-archive@megatron.ietf.org; Tue, 16 Aug 2005 17:28:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13541 for ; Tue, 16 Aug 2005 17:28:47 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E59Yj-0007ir-E1 for provreg-archive@ietf.org; Tue, 16 Aug 2005 18:05:26 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLPMvp017472 for ; Tue, 16 Aug 2005 23:25:22 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GLPMae009678 for ietf-provreg-outgoing; Tue, 16 Aug 2005 23:25:22 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ogud.com (ns.ogud.com [66.92.146.160]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLPKjX023602 for ; Tue, 16 Aug 2005 23:25:21 +0200 (MEST) Received: from [10.31.32.63] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7GLP99e015516; Tue, 16 Aug 2005 17:25:11 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 16 Aug 2005 17:25:22 -0400 To: "Michael Young" From: Edward Lewis Subject: RE: [ietf-provreg] 3730 Text Change Proposal Cc: "'janusz'" , "'Edward Lewis'" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Yeah - my "objection" is purely in the sense that "can" is not covered by RFC 2119. I agree that the MUST causes heartburn, so I am fine with moving off that. And Janusz is right that we aren't talking "MUST NOT", so I am fine with that. But perhaps there is something I need to hammer out. In my text proposal, I have "MUST...that did not directly" and "MAY". I did this to make sure we still cover other "elements" that need to know of an action. I used MAY for all, as this means "its permitted, but not necessary." I.e., the initiator and responder ought to tolerate being told of a transfer request, but the other party must be told. Is that what we are going towards? At 16:42 -0400 8/16/05, Michael Young wrote: >Hi Edward > >"Service messages can be created for all clients affected by an action" > >Likewise I don't understand why this change would invalidate any existing >implementations, which is why Scott proposed it this way. MUST replaced >with SHOULD or "can" does not cause an issue with existing code. Retaining >"MUST" however puts us back to square one in resolving the raised issue - so >I don't see leaving it unmodified as a viable option. > >I am perfectly happy to settle for softening it to a SHOULD versus "can" if >you find that language confusing. > > >Michael Young >-----Original Message----- >From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] On >Behalf Of janusz >Sent: Tuesday, August 16, 2005 4:32 PM >To: Edward Lewis >Cc: ietf-provreg@cafax.se >Subject: Re: [ietf-provreg] 3730 Text Change Proposal > >Edward, >if your code conforms to the OLD text then it should conform to the NEW >version. Nobody is proposing replacing MUST with MUST NOT. > >The NEW text looks reasonable to me. It keeps existing EPP deployments still >within protocol compliance. > >Cheers, > >Janusz Sienkiewicz > > >Edward Lewis wrote: > >> At 14:04 -0400 8/16/05, Andrew Sullivan wrote: >> >>> On Mon, Aug 15, 2005 at 01:27:56PM -0400, Hollenbeck, Scott wrote: >>> >>>> NEW: >>>> Service messages can be created for all clients affected by an >>>> action on an object that did not directly execute the action. For >>>> example, actions can be reported to the client that has >>>> the authority to approve or reject a transfer request. Other >>>> methods of server-client action notification, such as offline >>>> reporting, are also possible and are beyond the scope of this >>>> specification. >>> >>> >>> I like this, myself. Do we want to make the "can"s in there SHOULDs >>> instead? (I don't, really, but this is a pretty dramatic weakening >>> from the MUST we had before. Looking at the archives, there seem to >>> have been some people arguing for a much more important poll queue.) >> >> >> The change confuses me. Instead of relaxing from MUST to SHOULD, the >> change eliminates any "standards" words. >> >> The code base we have currently conforms to the "OLD" spec. We don't >> have a problem with it, hence we are reluctant to want to see the spec >> changed (in a way that is "not backwards compatible"). Not so much >> because we are against change but because we'd like to avoid having to >> redistribute software (or require new software be written by clients >> that contact us). >> >> It might be that the service message requirement as in "OLD" is >> suboptimal because it requires a service message go back to the >> initiator. But we'd rather keep this practice and just recognize (and >> then drop) the unnecessary message than have to replace software. >> Keeping in mind that the current way of passing messages is only >> sub-optimal, not unworkable. >> >> Perhaps there's a misunderstanding on my part of what problem the >> extraneous message causes. >> >> Still, I would have thought the new text would have been: >> >> Service messages MUST be created for all clients affected by an action >> on an object that did not directly execute the action, and MAY be >> created for others affected (including the initiator). For example, >> ... >> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From owner-ietf-provreg@cafax.se Tue Aug 16 17:28:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E58zL-0007uP-0C for provreg-archive@megatron.ietf.org; Tue, 16 Aug 2005 17:28:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13544 for ; Tue, 16 Aug 2005 17:28:48 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E59Yk-0007j0-Ig for provreg-archive@ietf.org; Tue, 16 Aug 2005 18:05:27 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLMIYd026421 for ; Tue, 16 Aug 2005 23:22:18 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GLMIKx019721 for ietf-provreg-outgoing; Tue, 16 Aug 2005 23:22:18 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLMHg6008701 for ; Tue, 16 Aug 2005 23:22:18 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E58sy-0003tc-TL for ietf-provreg@cafax.se; Tue, 16 Aug 2005 17:22:16 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id 6EC4E13744; Tue, 16 Aug 2005 17:22:02 -0400 (EDT) Date: Tue, 16 Aug 2005 17:22:02 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] 3730 Text Change Proposal Message-ID: <20050816212202.GB4918@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <046F43A8D79C794FA4733814869CDF07C92A4A@dul1wnexmb01.vcorp.ad.vrsn.com> <20050816180403.GT4918@libertyrms.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 On Tue, Aug 16, 2005 at 04:02:07PM -0400, Edward Lewis wrote: > > The change confuses me. Instead of relaxing from MUST to SHOULD, the > change eliminates any "standards" words. I think others have pointed out that any relaxing from MUST will not make existing code incompatible with the resulting document. I don't want to attribute anything to Scott (since I have no knowledge in this matter -- or in any other, some would argue!), but I have a suspicion that the use of "can" instead of any of the magic standards words is a feature, not a bug. I think it's a good idea, because it neatly sidesteps the problems we've identified in the use of the poll queue, and doesn't potentially embroil us in other standards issues. > The code base we have currently conforms to the "OLD" spec. We don't > have a problem with it, hence we are reluctant to want to see the > spec changed (in a way that is "not backwards compatible"). Not so I can understand a desire to avoid changes that cause incompatibilities (even if this isn't such a case). But I think this is a weak plank on which to build an argument that the protocol needs to remain unchanged. The whole point of PROPOSED STANDARD after all is that we're not completely committed to that design, precisely because we're aware that we might not have had all the operational experience necessary to get things quite right when folks were first designing the protocol. That isn't to say I think we should embrace change for its own sake; I prefer to leave the protocol alone, to the extent possible, and use extensions where we can, even if the result is not the most elegant approach when considered in isolation. I'm just made awful nervous by a suggestion that we shouldn't fix things we find need fixing (if we do -- and I recognise the jury is still out) because we have some installed base. It'll be much harder to fix things later, with a bigger installed base. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 From owner-ietf-provreg@cafax.se Tue Aug 16 17:54:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E59Nx-00059S-O7 for provreg-archive@megatron.ietf.org; Tue, 16 Aug 2005 17:54:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14617 for ; Tue, 16 Aug 2005 17:54:14 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E59xM-0008Nw-RJ for provreg-archive@ietf.org; Tue, 16 Aug 2005 18:30:53 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLo4xL019955 for ; Tue, 16 Aug 2005 23:50:04 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GLo496009135 for ietf-provreg-outgoing; Tue, 16 Aug 2005 23:50:04 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLo38J006795 for ; Tue, 16 Aug 2005 23:50:04 +0200 (MEST) Received: from roaming7.int.libertyrms.com ([10.1.3.237] helo=DUN911) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E59Jq-0005BD-G6; Tue, 16 Aug 2005 17:50:02 -0400 From: "Michael Young" To: "'Edward Lewis'" Cc: "'janusz'" , Subject: RE: [ietf-provreg] 3730 Text Change Proposal Date: Tue, 16 Aug 2005 17:49:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Thread-Index: AcWiqQIzypgUaQNjSgqDVHsLMn6DOwAAqGwA Message-Id: X-SA-Exim-Mail-From: myoung@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit Ed I don't see a problem with the "MAY" portion but how do you define "others" - could this be, for example as remote as an entity outside the system? >> MAY be created for others affected (including the initiator).. Michael Young -----Original Message----- From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] Sent: Tuesday, August 16, 2005 5:25 PM To: Michael Young Cc: 'janusz'; 'Edward Lewis'; ietf-provreg@cafax.se Subject: RE: [ietf-provreg] 3730 Text Change Proposal Yeah - my "objection" is purely in the sense that "can" is not covered by RFC 2119. I agree that the MUST causes heartburn, so I am fine with moving off that. And Janusz is right that we aren't talking "MUST NOT", so I am fine with that. But perhaps there is something I need to hammer out. In my text proposal, I have "MUST...that did not directly" and "MAY". I did this to make sure we still cover other "elements" that need to know of an action. I used MAY for all, as this means "its permitted, but not necessary." I.e., the initiator and responder ought to tolerate being told of a transfer request, but the other party must be told. Is that what we are going towards? At 16:42 -0400 8/16/05, Michael Young wrote: >Hi Edward > >"Service messages can be created for all clients affected by an action" > >Likewise I don't understand why this change would invalidate any >existing implementations, which is why Scott proposed it this way. >MUST replaced with SHOULD or "can" does not cause an issue with >existing code. Retaining "MUST" however puts us back to square one in >resolving the raised issue - so I don't see leaving it unmodified as a viable option. > >I am perfectly happy to settle for softening it to a SHOULD versus >"can" if you find that language confusing. > > >Michael Young >-----Original Message----- >From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] >On Behalf Of janusz >Sent: Tuesday, August 16, 2005 4:32 PM >To: Edward Lewis >Cc: ietf-provreg@cafax.se >Subject: Re: [ietf-provreg] 3730 Text Change Proposal > >Edward, >if your code conforms to the OLD text then it should conform to the NEW >version. Nobody is proposing replacing MUST with MUST NOT. > >The NEW text looks reasonable to me. It keeps existing EPP deployments >still within protocol compliance. > >Cheers, > >Janusz Sienkiewicz > > >Edward Lewis wrote: > >> At 14:04 -0400 8/16/05, Andrew Sullivan wrote: >> >>> On Mon, Aug 15, 2005 at 01:27:56PM -0400, Hollenbeck, Scott wrote: >>> >>>> NEW: >>>> Service messages can be created for all clients affected by an >>>> action on an object that did not directly execute the action. For >>>> example, actions can be reported to the client that has >>>> the authority to approve or reject a transfer request. Other >>>> methods of server-client action notification, such as offline >>>> reporting, are also possible and are beyond the scope of this >>>> specification. >>> >>> >>> I like this, myself. Do we want to make the "can"s in there >>> SHOULDs instead? (I don't, really, but this is a pretty dramatic >>> weakening from the MUST we had before. Looking at the archives, >>> there seem to have been some people arguing for a much more >>> important poll queue.) >> >> >> The change confuses me. Instead of relaxing from MUST to SHOULD, >> the change eliminates any "standards" words. >> >> The code base we have currently conforms to the "OLD" spec. We >> don't have a problem with it, hence we are reluctant to want to see >> the spec changed (in a way that is "not backwards compatible"). Not >> so much because we are against change but because we'd like to avoid >> having to redistribute software (or require new software be written >> by clients that contact us). >> >> It might be that the service message requirement as in "OLD" is >> suboptimal because it requires a service message go back to the >> initiator. But we'd rather keep this practice and just recognize >> (and then drop) the unnecessary message than have to replace software. >> Keeping in mind that the current way of passing messages is only >> sub-optimal, not unworkable. >> >> Perhaps there's a misunderstanding on my part of what problem the >> extraneous message causes. >> >> Still, I would have thought the new text would have been: >> >> Service messages MUST be created for all clients affected by an >> action on an object that did not directly execute the action, and >> MAY be created for others affected (including the initiator). For >> example, ... >> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From owner-ietf-provreg@cafax.se Tue Aug 16 17:56:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E59QJ-0005JG-K3 for provreg-archive@megatron.ietf.org; Tue, 16 Aug 2005 17:56:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14757 for ; Tue, 16 Aug 2005 17:56:40 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E59zi-0008RG-Gf for provreg-archive@ietf.org; Tue, 16 Aug 2005 18:33:19 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLsBfu009263 for ; Tue, 16 Aug 2005 23:54:11 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GLsBcX020083 for ietf-provreg-outgoing; Tue, 16 Aug 2005 23:54:11 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLsBrv028232 for ; Tue, 16 Aug 2005 23:54:11 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E59Nq-0005Gx-MY for ietf-provreg@cafax.se; Tue, 16 Aug 2005 17:54:10 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id 26B0813744; Tue, 16 Aug 2005 17:53:56 -0400 (EDT) Date: Tue, 16 Aug 2005 17:53:56 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] 3730 Text Change Proposal Message-ID: <20050816215355.GF4918@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On Tue, Aug 16, 2005 at 05:25:22PM -0400, Edward Lewis wrote: > not necessary." I.e., the initiator and responder ought to tolerate > being told of a transfer request, but the other party must be told. > > Is that what we are going towards? I hope not, because I'm trying to make the whole thing optional (if we don't take the other approach I suggested). My experience of clients' actual use of the message queue is that many of them simply don't. I want to make it more useful for them, in the hope that they'll use it and spare me creating more needless reports. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 From owner-ietf-provreg@cafax.se Tue Aug 16 17:59:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E59Su-0005Zt-A8 for provreg-archive@megatron.ietf.org; Tue, 16 Aug 2005 17:59:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14850 for ; Tue, 16 Aug 2005 17:59:21 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5A2J-0008UU-TZ for provreg-archive@ietf.org; Tue, 16 Aug 2005 18:36:00 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLvDh3029855 for ; Tue, 16 Aug 2005 23:57:13 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GLvDe9018099 for ietf-provreg-outgoing; Tue, 16 Aug 2005 23:57:13 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLvCdC011798 for ; Tue, 16 Aug 2005 23:57:12 +0200 (MEST) Received: from dev3.int.libertyrms.com ([10.1.3.40] helo=ca.afilias.info) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E59Ql-0005Md-R9; Tue, 16 Aug 2005 17:57:11 -0400 Message-ID: <430261E7.1090400@ca.afilias.info> Date: Tue, 16 Aug 2005 18:00:07 -0400 From: janusz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Edward Lewis CC: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] 3730 Text Change Proposal References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: janusz@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit Edward, even if we have "SHOULD...that did not directly" and "MAY" sending transfer and pending action notifications will be still mandatory. The behaviour of those classes of messages is determined not just by the text we are contemplating to change but also by the text of 2.9.3.4 in 3730 and texts of 3.2.6 in 3731, 3732 and 3733. Mandatory nature of transfer and pending action notifications is acceptable because for both classes of messages the protocol defines a way of passing object specific information so interoperable implementations are feasible. For other more generic classes of messages like auto-renewal, deletion, ... meaningfull interoperable implementations are not feasible. Therefore it is reasonable to use a weeker word than MUST in the text of 2.9.2.3 in 3730. Cheers, Janusz Sienkiewicz Edward Lewis wrote: > Yeah - my "objection" is purely in the sense that "can" is not covered > by RFC 2119. I agree that the MUST causes heartburn, so I am fine > with moving off that. And Janusz is right that we aren't talking > "MUST NOT", so I am fine with that. > > But perhaps there is something I need to hammer out. In my text > proposal, I have "MUST...that did not directly" and "MAY". I did this > to make sure we still cover other "elements" that need to know of an > action. I used MAY for all, as this means "its permitted, but not > necessary." I.e., the initiator and responder ought to tolerate being > told of a transfer request, but the other party must be told. > > Is that what we are going towards? > > At 16:42 -0400 8/16/05, Michael Young wrote: > >> Hi Edward >> >> "Service messages can be created for all clients affected by an action" >> >> Likewise I don't understand why this change would invalidate any >> existing >> implementations, which is why Scott proposed it this way. MUST replaced >> with SHOULD or "can" does not cause an issue with existing code. >> Retaining >> "MUST" however puts us back to square one in resolving the raised >> issue - so >> I don't see leaving it unmodified as a viable option. >> >> I am perfectly happy to settle for softening it to a SHOULD versus >> "can" if >> you find that language confusing. >> >> >> Michael Young >> -----Original Message----- >> From: owner-ietf-provreg@cafax.se >> [mailto:owner-ietf-provreg@cafax.se] On >> Behalf Of janusz >> Sent: Tuesday, August 16, 2005 4:32 PM >> To: Edward Lewis >> Cc: ietf-provreg@cafax.se >> Subject: Re: [ietf-provreg] 3730 Text Change Proposal >> >> Edward, >> if your code conforms to the OLD text then it should conform to the NEW >> version. Nobody is proposing replacing MUST with MUST NOT. >> >> The NEW text looks reasonable to me. It keeps existing EPP >> deployments still >> within protocol compliance. >> >> Cheers, >> >> Janusz Sienkiewicz >> >> >> Edward Lewis wrote: >> >>> At 14:04 -0400 8/16/05, Andrew Sullivan wrote: >>> >>>> On Mon, Aug 15, 2005 at 01:27:56PM -0400, Hollenbeck, Scott wrote: >>>> >>>>> NEW: >>>>> Service messages can be created for all clients affected by an >>>>> action on an object that did not directly execute the action. For >>>>> example, actions can be reported to the client that has >>>>> the authority to approve or reject a transfer request. Other >>>>> methods of server-client action notification, such as offline >>>>> reporting, are also possible and are beyond the scope of this >>>>> specification. >>>> >>>> >>>> >>>> I like this, myself. Do we want to make the "can"s in there SHOULDs >>>> instead? (I don't, really, but this is a pretty dramatic weakening >>>> from the MUST we had before. Looking at the archives, there seem to >>>> have been some people arguing for a much more important poll queue.) >>> >>> >>> >>> The change confuses me. Instead of relaxing from MUST to SHOULD, the >>> change eliminates any "standards" words. >>> >>> The code base we have currently conforms to the "OLD" spec. We don't >>> have a problem with it, hence we are reluctant to want to see the spec >>> changed (in a way that is "not backwards compatible"). Not so much >>> because we are against change but because we'd like to avoid having to >>> redistribute software (or require new software be written by clients >>> that contact us). >>> >>> It might be that the service message requirement as in "OLD" is >>> suboptimal because it requires a service message go back to the >>> initiator. But we'd rather keep this practice and just recognize (and >>> then drop) the unnecessary message than have to replace software. >>> Keeping in mind that the current way of passing messages is only >>> sub-optimal, not unworkable. >>> >>> Perhaps there's a misunderstanding on my part of what problem the >>> extraneous message causes. >>> >>> Still, I would have thought the new text would have been: >>> >>> Service messages MUST be created for all clients affected by an action >>> on an object that did not directly execute the action, and MAY be >>> created for others affected (including the initiator). For example, >>> ... >>> > From owner-ietf-provreg@cafax.se Tue Aug 16 19:09:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5AYU-00058L-L6 for provreg-archive@megatron.ietf.org; Tue, 16 Aug 2005 19:09:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19452 for ; Tue, 16 Aug 2005 19:09:11 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5B7u-0001gm-I2 for provreg-archive@ietf.org; Tue, 16 Aug 2005 19:45:51 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GN4X8x015049 for ; Wed, 17 Aug 2005 01:04:33 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GN4XjB007819 for ietf-provreg-outgoing; Wed, 17 Aug 2005 01:04:33 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ogud.com (ns.ogud.com [66.92.146.160]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GN4Wgk018755 for ; Wed, 17 Aug 2005 01:04:32 +0200 (MEST) Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7GN4HJq015872; Tue, 16 Aug 2005 19:04:23 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <430261E7.1090400@ca.afilias.info> References: <430261E7.1090400@ca.afilias.info> Date: Tue, 16 Aug 2005 19:04:28 -0400 To: janusz From: Edward Lewis Subject: Re: [ietf-provreg] 3730 Text Change Proposal Cc: Edward Lewis , ietf-provreg@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Let me give it a rest in my mind and think it over. Like my previous message - it's just a quibble about words. And sometimes it just takes a bit to settle in. At 18:00 -0400 8/16/05, janusz wrote: >Edward, >even if we have "SHOULD...that did not directly" and "MAY" sending >transfer and pending action notifications will be still >mandatory. The behaviour of those classes of messages is >determined not just by the text we are contemplating to change but >also by the text of 2.9.3.4 in 3730 and texts of 3.2.6 in 3731, 3732 >and 3733. Mandatory nature of transfer and pending action >notifications is acceptable because for both classes of messages the >protocol defines a way of passing object specific information so >interoperable implementations are feasible. For other more generic >classes of messages like auto-renewal, deletion, ... >meaningfull interoperable implementations are not feasible. >Therefore it is reasonable to use a weeker word than MUST in the >text of 2.9.2.3 in 3730. > >Cheers, > >Janusz Sienkiewicz > > >Edward Lewis wrote: > >> Yeah - my "objection" is purely in the sense that "can" is not >>covered by RFC 2119. I agree that the MUST causes heartburn, so I >>am fine with moving off that. And Janusz is right that we aren't >>talking "MUST NOT", so I am fine with that. >> >> But perhaps there is something I need to hammer out. In my text >>proposal, I have "MUST...that did not directly" and "MAY". I did >>this to make sure we still cover other "elements" that need to know >>of an action. I used MAY for all, as this means "its permitted, >>but not necessary." I.e., the initiator and responder ought to >>tolerate being told of a transfer request, but the other party must >>be told. >> >> Is that what we are going towards? >> >> At 16:42 -0400 8/16/05, Michael Young wrote: >> >>> Hi Edward >>> >>> "Service messages can be created for all clients affected by an action" >>> >>> Likewise I don't understand why this change would invalidate any existing >>> implementations, which is why Scott proposed it this way. MUST replaced >>> with SHOULD or "can" does not cause an issue with existing code. Retaining >>> "MUST" however puts us back to square one in resolving the raised >>>issue - so >>> I don't see leaving it unmodified as a viable option. >>> >>> I am perfectly happy to settle for softening it to a SHOULD versus "can" if >>> you find that language confusing. >>> >>> >>> Michael Young >>> -----Original Message----- >>> From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] On >>> Behalf Of janusz >>> Sent: Tuesday, August 16, 2005 4:32 PM >>> To: Edward Lewis >>> Cc: ietf-provreg@cafax.se >>> Subject: Re: [ietf-provreg] 3730 Text Change Proposal >>> >>> Edward, >>> if your code conforms to the OLD text then it should conform to the NEW >>> version. Nobody is proposing replacing MUST with MUST NOT. >>> >>> The NEW text looks reasonable to me. It keeps existing EPP >>>deployments still >>> within protocol compliance. >>> >>> Cheers, >>> >>> Janusz Sienkiewicz >>> >>> >>> Edward Lewis wrote: >>> >>>> At 14:04 -0400 8/16/05, Andrew Sullivan wrote: >>>> >>>>> On Mon, Aug 15, 2005 at 01:27:56PM -0400, Hollenbeck, Scott wrote: >>>>> >>>>>> NEW: >>>>>> Service messages can be created for all clients affected by an >>>>>> action on an object that did not directly execute the action. For >>>>>> example, actions can be reported to the client that has >>>>>> the authority to approve or reject a transfer request. Other >>>>>> methods of server-client action notification, such as offline >>>>>> reporting, are also possible and are beyond the scope of this >>>>>> specification. >>>>> >>>>> >>>>> >>>>> I like this, myself. Do we want to make the "can"s in there SHOULDs >>>>> instead? (I don't, really, but this is a pretty dramatic weakening >>>>> from the MUST we had before. Looking at the archives, there seem to >>>>> have been some people arguing for a much more important poll queue.) >>>> >>>> >>>> >>>> The change confuses me. Instead of relaxing from MUST to SHOULD, the >>>> change eliminates any "standards" words. >>>> >>>> The code base we have currently conforms to the "OLD" spec. We don't >>>> have a problem with it, hence we are reluctant to want to see the spec >>>> changed (in a way that is "not backwards compatible"). Not so much >>>> because we are against change but because we'd like to avoid having to >>>> redistribute software (or require new software be written by clients >>>> that contact us). >>>> >>>> It might be that the service message requirement as in "OLD" is >>>> suboptimal because it requires a service message go back to the >>>> initiator. But we'd rather keep this practice and just recognize (and >>>> then drop) the unnecessary message than have to replace software. >>>> Keeping in mind that the current way of passing messages is only >>>> sub-optimal, not unworkable. >>>> >>>> Perhaps there's a misunderstanding on my part of what problem the >>>> extraneous message causes. >>>> >>>> Still, I would have thought the new text would have been: >>>> >>>> Service messages MUST be created for all clients affected by an action >>>> on an object that did not directly execute the action, and MAY be >>>> created for others affected (including the initiator). For example, >>>> ... >>>> >> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From owner-ietf-provreg@cafax.se Tue Aug 16 19:09:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5AYY-0005Ai-15 for provreg-archive@megatron.ietf.org; Tue, 16 Aug 2005 19:09:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19459 for ; Tue, 16 Aug 2005 19:09:14 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5B7x-0001hm-5n for provreg-archive@ietf.org; Tue, 16 Aug 2005 19:45:55 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GN4U0c010106 for ; Wed, 17 Aug 2005 01:04:30 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GN4UYc029128 for ietf-provreg-outgoing; Wed, 17 Aug 2005 01:04:30 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ogud.com (ns.ogud.com [66.92.146.160]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GN4Svi021291 for ; Wed, 17 Aug 2005 01:04:29 +0200 (MEST) Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7GN4HJo015872; Tue, 16 Aug 2005 19:04:18 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 16 Aug 2005 19:03:00 -0400 To: "Michael Young" From: Edward Lewis Subject: RE: [ietf-provreg] 3730 Text Change Proposal Cc: "'Edward Lewis'" , "'janusz'" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f At 17:49 -0400 8/16/05, Michael Young wrote: >Ed I don't see a problem with the "MAY" portion but how do you define >"others" - could this be, for example as remote as an entity outside the >system? Others (admittedly a poor use of the term) = those who in the old spec are told that don't need to be told. For example, the initiator. I don't mean to expand who can/ought to be told. Just using the MAY to cover the now MUST actions that we no longer want to require yet don't want to outlaw. Rest assured, this is all a quibble about the terms. I think we agree what we want. > > > >>> MAY be created for others affected (including the initiator).. > > > > > > >Michael Young >-----Original Message----- >From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] >Sent: Tuesday, August 16, 2005 5:25 PM >To: Michael Young >Cc: 'janusz'; 'Edward Lewis'; ietf-provreg@cafax.se >Subject: RE: [ietf-provreg] 3730 Text Change Proposal > >Yeah - my "objection" is purely in the sense that "can" is not covered by >RFC 2119. I agree that the MUST causes heartburn, so I am fine with moving >off that. And Janusz is right that we aren't talking "MUST NOT", so I am >fine with that. > >But perhaps there is something I need to hammer out. In my text proposal, I >have "MUST...that did not directly" and "MAY". I did this to make sure we >still cover other "elements" that need to know of an action. I used MAY for >all, as this means "its permitted, but not necessary." I.e., the initiator >and responder ought to tolerate being told of a transfer request, but the >other party must be told. > >Is that what we are going towards? > >At 16:42 -0400 8/16/05, Michael Young wrote: >>Hi Edward >> >>"Service messages can be created for all clients affected by an action" >> >>Likewise I don't understand why this change would invalidate any >>existing implementations, which is why Scott proposed it this way. >>MUST replaced with SHOULD or "can" does not cause an issue with >>existing code. Retaining "MUST" however puts us back to square one in >>resolving the raised issue - so I don't see leaving it unmodified as a >viable option. >> >>I am perfectly happy to settle for softening it to a SHOULD versus >>"can" if you find that language confusing. >> >> >>Michael Young >>-----Original Message----- >>From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] >>On Behalf Of janusz >>Sent: Tuesday, August 16, 2005 4:32 PM >>To: Edward Lewis >>Cc: ietf-provreg@cafax.se >>Subject: Re: [ietf-provreg] 3730 Text Change Proposal >> >>Edward, >>if your code conforms to the OLD text then it should conform to the NEW >>version. Nobody is proposing replacing MUST with MUST NOT. >> >>The NEW text looks reasonable to me. It keeps existing EPP deployments >>still within protocol compliance. >> >>Cheers, >> >>Janusz Sienkiewicz >> >> >>Edward Lewis wrote: >> >>> At 14:04 -0400 8/16/05, Andrew Sullivan wrote: >>> >>>> On Mon, Aug 15, 2005 at 01:27:56PM -0400, Hollenbeck, Scott wrote: >>>> >>>>> NEW: >>>>> Service messages can be created for all clients affected by an >>>>> action on an object that did not directly execute the action. For >>>>> example, actions can be reported to the client that has >>>>> the authority to approve or reject a transfer request. Other >>>>> methods of server-client action notification, such as offline >>>>> reporting, are also possible and are beyond the scope of this >>>>> specification. >>>> >>>> >>>> I like this, myself. Do we want to make the "can"s in there >>>> SHOULDs instead? (I don't, really, but this is a pretty dramatic >>>> weakening from the MUST we had before. Looking at the archives, >>>> there seem to have been some people arguing for a much more >>>> important poll queue.) >>> >>> >>> The change confuses me. Instead of relaxing from MUST to SHOULD, >>> the change eliminates any "standards" words. >>> >>> The code base we have currently conforms to the "OLD" spec. We >>> don't have a problem with it, hence we are reluctant to want to see >>> the spec changed (in a way that is "not backwards compatible"). Not >>> so much because we are against change but because we'd like to avoid >>> having to redistribute software (or require new software be written >>> by clients that contact us). >>> >>> It might be that the service message requirement as in "OLD" is >>> suboptimal because it requires a service message go back to the >>> initiator. But we'd rather keep this practice and just recognize >>> (and then drop) the unnecessary message than have to replace software. >>> Keeping in mind that the current way of passing messages is only >>> sub-optimal, not unworkable. >>> >>> Perhaps there's a misunderstanding on my part of what problem the >>> extraneous message causes. >>> >>> Still, I would have thought the new text would have been: >>> >>> Service messages MUST be created for all clients affected by an >>> action on an object that did not directly execute the action, and >>> MAY be created for others affected (including the initiator). For >>> example, ... >>> > >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis +1-571-434-5468 >NeuStar > >If you knew what I was thinking, you'd understand what I was saying. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From owner-ietf-provreg@cafax.se Wed Aug 17 06:21:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5L2j-00057P-4H for provreg-archive@megatron.ietf.org; Wed, 17 Aug 2005 06:21:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19402 for ; Wed, 17 Aug 2005 06:21:06 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5LcE-0002EJ-A0 for provreg-archive@ietf.org; Wed, 17 Aug 2005 06:57:51 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7HAEP02018607 for ; Wed, 17 Aug 2005 12:14:25 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7HAEPto013456 for ietf-provreg-outgoing; Wed, 17 Aug 2005 12:14:25 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [213.154.224.50]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7HAEOZ6002825 for ; Wed, 17 Aug 2005 12:14:24 +0200 (MEST) Received: from bartok.nlnetlabs.nl (localhost.nlnetlabs.nl [127.0.0.1]) by bartok.nlnetlabs.nl (8.13.3/8.13.1) with ESMTP id j7HAENTn021235 for ; Wed, 17 Aug 2005 12:14:23 +0200 (CEST) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200508171014.j7HAENTn021235@bartok.nlnetlabs.nl> To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] EPP Document Updates In-reply-to: Your message of Tue, 16 Aug 2005 17:12:00 -0400. <200508162111.j7GLBMLL019238@ns01.afilias.info> Date: Wed, 17 Aug 2005 12:14:23 +0200 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Ram, all, If you read draft-sullivan-epp-experience, there are at least a few areas that need engineers to come together to talk protocol and discuss how to move things forward to the core protocol. I note that this ID seems to concentrate on issues for gTLD type registries. As en example, the problems signalled over Domain Registry Grace Period. What I would like to see is a similar document decsribing more ccTLD centered issues. IETF wg output (and in some cases, even ID track) gets read and digested - as you know, there a lot of lurkers and only a few active speakers. Folks I speak with at many ccTLDs find the IETF work to be both clueful and participatory, if they choose to. Experience learns that these "lurking ccTLD's" go of and do there own version grumbling that the IETF doesn't really (want to) understand their need. It would really be much more benificial when this grumbling would take place during the protocol development and not during or after last call. You really want most (all) players on board and be participating. An other problem, is that there is some work involved setting up an IETF-WG. There should at least be a BOF which a provisional charter etc. I think one wants prevent having WG "to discuss operational issues" which might linger on forever. When the WG was closed Ed remarked: I'd like to thank those involved for helping achieve what we set out to do. I hope that the effort pushes on to Draft Standard without the formalization of a new WG. And yes, getting from Proposed to Draft is another thing that needs some sonsideration. jaap From owner-ietf-provreg@cafax.se Wed Aug 17 06:59:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Ldg-0004sf-7k for provreg-archive@megatron.ietf.org; Wed, 17 Aug 2005 06:59:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21242 for ; Wed, 17 Aug 2005 06:59:17 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5MDB-0003I7-OH for provreg-archive@ietf.org; Wed, 17 Aug 2005 07:36:03 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7HAskVP005139 for ; Wed, 17 Aug 2005 12:54:46 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7HAskTt024470 for ietf-provreg-outgoing; Wed, 17 Aug 2005 12:54:46 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7HAsi8n027431 for ; Wed, 17 Aug 2005 12:54:45 +0200 (MEST) Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.1/8.12.11) with ESMTP id j7HAss4Z000754; Wed, 17 Aug 2005 06:54:54 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 06:54:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ietf-provreg] EPP Document Updates Date: Wed, 17 Aug 2005 06:54:38 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07C92D98@dul1wnexmb01.vcorp.ad.vrsn.com> Thread-Topic: [ietf-provreg] EPP Document Updates Thread-Index: AcWfWAr5vKMx8eL7QyWoAXPrL/45PgDL9WOAACRGHHA= From: "Hollenbeck, Scott" To: "Ram Mohan" , X-OriginalArrivalTime: 17 Aug 2005 10:54:42.0652 (UTC) FILETIME=[129A81C0:01C5A31A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j7HAsj8n019436 Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: owner-ietf-provreg@cafax.se > [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Ram Mohan > Sent: Tuesday, August 16, 2005 5:12 PM > To: 'Edward Lewis'; ietf-provreg@cafax.se > Subject: RE: [ietf-provreg] EPP Document Updates [snip] > There never is a guarantee, but it seems to me that we have a > confluence of > demand (not just market demand, but actual engineering ones), > interest from > participants, and practical knowledge waiting to be applied > appropriately. This is the part that I'm still not seeing. What "confluence of demand" and "interest from participants"? Your last note requesting statements of interest in restarting a working group garnered three replies, and mine was highly qualified. -Scott- From owner-ietf-provreg@cafax.se Wed Aug 17 07:31:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5M8b-0003uc-9O for provreg-archive@megatron.ietf.org; Wed, 17 Aug 2005 07:31:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22746 for ; Wed, 17 Aug 2005 07:31:16 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Mi4-0004L2-0P for provreg-archive@ietf.org; Wed, 17 Aug 2005 08:08:00 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7HBN4dR008639 for ; Wed, 17 Aug 2005 13:23:04 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7HBN4LB001442 for ietf-provreg-outgoing; Wed, 17 Aug 2005 13:23:04 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7HBN3gl027633 for ; Wed, 17 Aug 2005 13:23:04 +0200 (MEST) Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.1/8.12.11) with ESMTP id j7HBNE7P001432; Wed, 17 Aug 2005 07:23:14 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 07:23:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ietf-provreg] 3730 Text Change Proposal Date: Wed, 17 Aug 2005 07:22:59 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07C92D99@dul1wnexmb01.vcorp.ad.vrsn.com> Thread-Topic: [ietf-provreg] 3730 Text Change Proposal Thread-Index: AcWin7ivheykwKHFQEa6qCakPG+auAAfPNkg From: "Hollenbeck, Scott" To: "Edward Lewis" , X-OriginalArrivalTime: 17 Aug 2005 11:23:02.0582 (UTC) FILETIME=[07D73D60:01C5A31E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j7HBN4gl015913 Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: owner-ietf-provreg@cafax.se > [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Edward Lewis > Sent: Tuesday, August 16, 2005 4:02 PM > To: ietf-provreg@cafax.se > Cc: ed.lewis@Neustar.biz > Subject: Re: [ietf-provreg] 3730 Text Change Proposal > > At 14:04 -0400 8/16/05, Andrew Sullivan wrote: > >On Mon, Aug 15, 2005 at 01:27:56PM -0400, Hollenbeck, Scott wrote: > >> NEW: > >> Service messages can be created for all clients affected > by an action on > >> an object that did not directly execute the action. For example, > >> actions can be reported to the client that has > the authority > >> to approve or reject a transfer request. Other methods > of server-client > >> action notification, such as offline reporting, are also > possible and > >> are beyond the scope of this specification. > > > >I like this, myself. Do we want to make the "can"s in there SHOULDs > >instead? (I don't, really, but this is a pretty dramatic weakening > >from the MUST we had before. Looking at the archives, there seem to > >have been some people arguing for a much more important poll queue.) > > The change confuses me. Instead of relaxing from MUST to SHOULD, the > change eliminates any "standards" words. Ed, the primary reason I thought it best to ditch 2119 keywords is that this part of the spec isn't describing an interoperability issue. It's describing an implementation issue. I'm OK with a SHOULD if that makes it more clear that the text is describing implementation guidance instead of a protocol mandate, but I think a "can" works here, too. -Scott- From owner-ietf-provreg@cafax.se Wed Aug 17 10:39:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5P4u-0007Ki-EI for provreg-archive@megatron.ietf.org; Wed, 17 Aug 2005 10:39:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04841 for ; Wed, 17 Aug 2005 10:39:38 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5PeQ-0001Px-OZ for provreg-archive@ietf.org; Wed, 17 Aug 2005 11:16:25 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7HEMkVH018744 for ; Wed, 17 Aug 2005 16:22:46 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7HEMk45023758 for ietf-provreg-outgoing; Wed, 17 Aug 2005 16:22:46 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ogud.com (ns.ogud.com [66.92.146.160]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7HEMiaE003136 for ; Wed, 17 Aug 2005 16:22:45 +0200 (MEST) Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7HEMcIR021188; Wed, 17 Aug 2005 10:22:39 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <046F43A8D79C794FA4733814869CDF07C92D98@dul1wnexmb01.vcorp.ad.vrsn.com> References: <046F43A8D79C794FA4733814869CDF07C92D98@dul1wnexmb01.vcorp.ad.vrsn.com> Date: Wed, 17 Aug 2005 10:21:02 -0400 To: From: Edward Lewis Subject: RE: [ietf-provreg] EPP Document Updates Cc: ed.lewis@Neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Just to be set the table, I recognize the desire to make some changes to the specifications. What I am saying is that I don't know that an IETF WG is the way to go. I recognize that many (amorphous) organizations listen to what the IETF says. Unfortunately, "listening" is not the best way to interact with the IETF. "Interacting" is. As long as the IETF is a volunteer organization, the IETF is hard pressed get organizations that listen-only to interact. From this observation, I claim that a WG is not a "sure-fire" answer. What leads to a successful IETF WG? You need a compelling problem that will draw volunteers. You need an identifiable goal with a clear benefit of being reached. Even if the work is clear, such as "getting EPP to Draft Standard" you need to have a real motivation to get it done. If there is no motivation to get it done, then the need for DS becomes a "reason to live" and find other little distractions to study alone they way. (Look at DNSSEC to see what I mean. Yes we want to sign the DNS, along the way we've been tinkering all over the protocol.) Dropping into my opinion now, instead of an IETF WG, I'd like see more interactions in venues attuned to registration activities. Maybe the some venues are broken, maybe some are too new. Perhaps though that something like this (EPP) will be reason to fix venues and to mature others. I don't mean to name names as accusation, but as examples. I've already mentioned CENTR and ICANN. What about APTLD? I believe I once heard of an African ccTLD organizational effort. I don't mean to omit any organization - I don't know of many. I will say that I do see this as bigger than just EPP. Internet registration also includes DNS, IRIS, WhoIs, billing, etc., maybe even the issuance of certificates. Some of what registries "requires" coordination - such as DNS, EPP, IRIS. Some of what registries do can be shared, and some is best left to competitive practices. Within the IETF, the only coordination of these issues is through the informal mutual attendance pattern - there is a lot of overlap in the CRISP (IRIS), DNSEXT, DNSOP, ENUM, etc. groups even though they are in different IETF Areas. For instance, questions about whether EPP ought to get extensions for routing came up in CRISP, and DNSSEC extensions for EPP (RFC 4TBD) was reviewed in DNSOP. Okay, I've strayed far away from the small edits we have been talking about. What you are seeing is about the third attempt at a reply, each time I do from the problems at hand into the crevices I see needing epoxy. To close this off now - we need to keep in mind, what are short term needs and what might we need in the coming years. EPP lives in a context of a few protocols, yet it is its own beast. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From xgutzuhneud@yahoo.com Wed Aug 17 23:00:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5adq-0000s6-Bv; Wed, 17 Aug 2005 23:00:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21594; Wed, 17 Aug 2005 23:00:27 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5bDV-0007wi-GV; Wed, 17 Aug 2005 23:37:21 -0400 Received: from c-24-14-131-38.hsd1.il.comcast.net ([24.14.131.38]) by mx2.foretec.com with smtp (Exim 4.24) id 1E5adm-00052K-7b; Wed, 17 Aug 2005 23:00:27 -0400 X-Message-Info: 0F439Jzvm06LCV780zmxCUUtgBWY3pY7bgbDOvbQ60H2 Received: from dns3.yahoo.com ([0.115.162.74]) by 8i-b1.24.14.131.38 with Microsoft SMTPSVC(5.0.0987.6358); Wed, 17 Aug 2005 22:55:14 -0500 Message-ID: <652593893051.79294@24.14.131.38> Reply-To: "Gene " From: "Gene " To: pana-admin@ietf.org, rddp@ietf.org, pmtud-web-archive@ietf.org, saad-request@ietf.org, ssm-archive@ietf.org, p2prg@ietf.org, pilc-admin@ietf.org, pint-archive@ietf.org, pr@ietf.org, pim-admin@ietf.org, pwe3@ietf.org, policy@ietf.org, sigtran@ietf.org, provreg-archive@ietf.org, simple@ietf.org, speechsc-request@ietf.org, nsis-admin@ietf.org, rserpool-admin@ietf.org Subject: Hot pick expected to rock Wall Street Date: Wed, 17 Aug 2005 23:53:14 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--988290488013286609" X-Spam-Score: 3.9 (+++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 ----988290488013286609 Content-Type: text/plain; charset="iso-1001-8" Content-Transfer-Encoding: quoted-printable Immediate Hot Pick Symbol: GEECF Strong Buy Recommendation: Global Environmental Energy Corp. 7 Day Target: 3.00 Look for huge news to follow-up GEECF's blockbuster announcement: GEECF Enters Alliance Agreement on 70,000 Barrel Per Day Oil Refinery. 25 Million Barrels of Oil will be refined annually representing cash flow of 1.5 Billion per year. The former President of OPEC, Humberto Calderon Berti, has come on board to run GEECF 100% owned oil division, Sahara Petroleum. He is considered the most powerful figure in the international oil industry. Berti has been involved, and is still involved today in the exploration and production of the world's largest oil discoveries. He is also President and CEO of GEECF's partner, Vetra Oil Group. Perhaps the most significant factor is the bottom-line dollars commanded by Berti for his involvement in oil exploration and production projects. You can be assured that each project yields a minimum of 10 to 20 Billion annually for Berti to participate. Look at the pieces of the puzzle coming together. It is clearly obvious that the former OPEC President has orchestrated a monster of a deal involving an oil-rich property jointly owned by Sahara (GEECF) and Vetra Oil. Although no one is talking, in the last 90 days GEECF brings in Berti, who brings in Vetra Oil (whose clients are the world's largest oil super-majors), followed by the entry of a developer and refinery. Even though no specific oil deal has been disclosed, GEECF just revealed that they will "refine a large portion of its own oil at the new refinery." Fact: Billions in Oil Revenue for GEECF with only 35 million shares outstanding could easily translate into 5 or 10 dollars net per share earnings, designating GEECF as a hot, mid-tier oil player with NYSE qualifications. If this were the whole story, it would be more than ample reason to rate GEECF as our hottest pick of the year. However, in addition, there is a GEECF subsidiary dealing in the waste-to-energy sector that has secured a 10 Billion, 5-year contract with Chinese Government-run companies, including Yanzhou Coal Mining (NYSE: YZC, 44) to supply their technology throughout China. There are no other companies on the OTC that can match-up with GEECF and their Multi-Billions in deals on the table. GEECF shares will continue to soar and reward aggressive investors. GEECF is on target for record-breaking revenues while turning savvy market players into millionaires as the value of their oil projects are revealed. Disclosure: The information and opinions in this featured profile are based on sources believed to be reliable but no representation is made to its accuracy or completeness. Past performance is not an indicator of future results. This report is a paid profile for information purposes only and should not be used as the basis for any investment decision. This newsletter has been compensated ten thousand dollars for the preparation of this profile and for continuing coverage of the featured company. Newsletter publishers are not investment experts and this profile is not to be considered investment advice. This information is neither a solicitation to buy nor an offer to sell securities. Information herein contains future-looking statements that are subject to significant risks and uncertainties. There are no shares presently held and no participation will occur in the trading of shares in any profiled company. ----988290488013286609-- From fleischhacker@yebox.com Sun Aug 21 05:55:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6mY1-0005H0-GG; Sun, 21 Aug 2005 05:55:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19643; Sun, 21 Aug 2005 05:55:23 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6n8M-0001vK-Lo; Sun, 21 Aug 2005 06:32:58 -0400 Received: from 58x4x76x19.ap58.ftth.ucom.ne.jp ([58.4.76.19]) by mx2.foretec.com with smtp (Exim 4.24) id 1E6mY0-0008FG-0a; Sun, 21 Aug 2005 05:55:24 -0400 Received: from chin.kzbdnd.gazelle.pitilessly.com by wormy.commandeer.durango.com (cvhupfix) with SMTP id 1B29E820437 for ; Mon, 22 Aug 2005 05:32:35 +0300 Message-ID: Date: Mon, 22 Aug 2005 05:39:35 +0300 From: "Moses Wilcox" To: Subject: Catch the new low rates X-Mailer: KYX CP/M FNORD 5602 X-Spam-Score: 3.4 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have been selected for our lowest rate in years... You could get over $420,000 for as little as $400 a month! Ba(d credit, Bank*ruptcy? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.lowratesmoremoney.com/i/LzMvaW5kZXgvYXJuL2w1NHpj Best Regards, Leslie Oneill to be remov(ed: http://www.lowratesmoremoney.com this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From GlennMayer@denotatum.com Sun Aug 21 14:25:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6uVT-00045h-6g for provreg-archive@megatron.ietf.org; Sun, 21 Aug 2005 14:25:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11199 for ; Sun, 21 Aug 2005 14:25:17 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6v5s-0005CU-Au for provreg-archive@ietf.org; Sun, 21 Aug 2005 15:02:56 -0400 Received: from host81-152-18-10.range81-152.btcentralplus.com ([81.152.18.10]) by mx2.foretec.com with smtp (Exim 4.24) id 1E6uV4-0007JV-QL for provreg-archive@ietf.org; Sun, 21 Aug 2005 14:25:03 -0400 Received: from GNj@localhost by tB0Q.int (8.11.6/8.11.6); Sun, 21 Aug 2005 21:12:50 +0200 Message-ID: <115YTgHFjCoVb55uViH4@ripers.net> From: "Kristine Daniel" Reply-To: "Kristine Daniel" To: provreg-archive@ietf.org Subject: Out of this WoRLD $aving$ on all Microsoft titles Date: Sun, 21 Aug 2005 20:13:50 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: GlennMayer@denotatum.com Content-Type: multipart/mixed; boundary="--Qg8EEr26SE9uijsBt" X-Spam-Score: 0.4 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb hEk ----Qg8EEr26SE9uijsBt Content-Type: text/html; Content-Transfer-Encoding: quoted-printable C
Opt-in Email Special Offer   = ;  unsubscribe me
SEARCH

=

TOP 10 NEW TITLES

9= =

 = ON SALE NOW!

 1 Office Pro 2003
 2 A= dobe Photoshop 9.0
 3 Windows XP Pro
 4 A= dobe Acrobat 7 Pro
 5 Flash MX 2004
 6 Corel Draw 12
 7 Nort= on Antivirus 2005
 8 Windows 2003 Server
  Alias Maya 6 Wavefrt
 10 Adobe Illustrator 11
  See more by this manufacturer<= /b>
   Microsoft
=    Symantec
   Adobe
  Customers also bought
   these othe= r items...

Microsoft Office Professional Edition *2003*
Microsoft

Choose:
 <= a href=3Dhttp://number1soft.net/?T>

List Price:$499.00
Price:$69.99<= /b>
You Save:$429.01 (86= %)



Availability:= Available for INSTANT download!
Coupon Code: DpXEwEwx
&nbs= p;

Sales Rank: #1
System requirements&= nbsp; |  Other Versions
Date Coupon Expires: August 31st, 2005
= Average Customer Review:3D"5 Based o= n 166619 reviews. Write a review.<= /font>

Adobe Photoshop CS2 V 9.0
Adobe

= Choose:
 
<= /td>

<= tr><= /table>



Availability: Available for INSTA= NT download!
Coupon Code: dIhPTRfcc
 

Sales Rank: #2
System requirements  |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D"5 Based on 1481 reviews. Write a review.

List Price:$599.00
Price:$69.99
You Save:$529.01 (90%)

Microsoft Windows XP Professional or Longhorn Edition
Microsoft

Choose:
<= a href=3Dhttp://number1soft.net/?e>  =

List Price:$279.00
Price:$49.99
You Save:= $229.01 (85%)



Availa= bility: Available for INSTANT download!
Coupon Code: VYWy06= 5x
 

Sales Rank: #3=
System requir= ements  |  Other Version= s
Date Coupon Expires: August 31s= t, 2005
Average Customer Review:3D"5 Based on 19426 reviews. Write a rev= iew.

Adobe Acrobat Professional V 7.0 Adobe

Choose:<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 width=3D164>
 

List Price:$499.00
Price:$69.99
You Save:$429.0= 1 (85%)



Availability= : Available for INSTANT download!
Coupon Code: UzHihGUy4  

Sales Rank: #4
System requirement= s  |  Other Versions=
Date Coupon Expires: August 31st, 20= 05
Average Customer Review:3D"5 B= ased on 1196 reviews. Write a review.

----Qg8EEr26SE9uijsBt-- From owner-ietf-provreg@cafax.se Mon Aug 22 10:40:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DTZ-0005wQ-7z for provreg-archive@megatron.ietf.org; Mon, 22 Aug 2005 10:40:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19993 for ; Mon, 22 Aug 2005 10:40:34 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7E47-0002wa-NT for provreg-archive@ietf.org; Mon, 22 Aug 2005 11:18:25 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7MEYX6g019400 for ; Mon, 22 Aug 2005 16:34:33 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7MEYXOY004937 for ietf-provreg-outgoing; Mon, 22 Aug 2005 16:34:33 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7MEYVlp019103 for ; Mon, 22 Aug 2005 16:34:32 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E7DNd-0002Of-TK for ietf-provreg@cafax.se; Mon, 22 Aug 2005 10:34:29 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id D62F313744; Mon, 22 Aug 2005 10:34:29 -0400 (EDT) Date: Mon, 22 Aug 2005 10:34:29 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] EPP Document Updates Message-ID: <20050822143427.GA5367@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <200508162111.j7GLBMLL019238@ns01.afilias.info> <200508171014.j7HAENTn021235@bartok.nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200508171014.j7HAENTn021235@bartok.nlnetlabs.nl> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On Wed, Aug 17, 2005 at 12:14:23PM +0200, Jaap Akkerhuis wrote: > > I note that this ID seems to concentrate on issues for gTLD type > registries. As en example, the problems signalled over Domain > Registry Grace Period. What I would like to see is a similar document > decsribing more ccTLD centered issues. Well, I wrote it on the basis of my experience; and so far, the primary areas where I've noted difficulties in the protocol are due to my experiences working with gTLDs. That isn't to say that the ccTLDs we support don't have any of these problems; the overloading of some status values' meanings is, IMO, a difficulty in those registries as well. > not during or after last call. You really want most (all) players > on board and be participating. That's precisely why we're beating the bushes looking for people's experience. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 From mmmei@doneasy.com Tue Aug 23 09:48:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Z8D-0001Zv-DA; Tue, 23 Aug 2005 09:48:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04357; Tue, 23 Aug 2005 09:47:58 -0400 (EDT) Received: from adsl-64-168-76-177.dsl.snfc21.pacbell.net ([64.168.76.177]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E7Z8I-00053N-N3; Tue, 23 Aug 2005 09:48:08 -0400 Received: from JNJJPknsn.com (EHLO acqpf-a.belie.GB.asn.net) barbarian by mail.mtk.nao.ac.jp (6.85.3/4.59.3) with ESMTP id i47566784015975 ; Tue, 23 Aug 2005 16:48:28 +0200 Message-ID: <2004048316.MAA02395@mail-hub.mtk.689.jp> Date: Tue, 23 Aug 2005 19:43:28 +0500 From: "Hannah Kenny" To: postmaster@ietf.org Cc: poverib-web-archive@ietf.org, pping@ietf.org, pping-admin@ietf.org, ppm@ietf.org, ppm-archive@ietf.org, pppext@ietf.org, pr@ietf.org, presentations@ietf.org, proceedings@ietf.org, proto-team@ietf.org, provreg-archive@ietf.org, ps2.slim.incentive@ietf.org Subject: Instant low rates X-Mailer: WebMail (Hydra) SMTP v3.61.08 X-Spam-Score: 4.3 (++++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have been selected for our lowest rate in years... You could get over $460,000 for as little as $350 a month! Ba(d credit, Bank*ruptcy? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.applytosave.net/i/LzMvaW5kZXgvYXJuL2Qzanph Best Regards, Derek Mccullough to be remov(ed: http://www.applytosave.net this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From bryan@yahoo.com Tue Aug 23 13:01:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7c9j-0003ov-UZ for provreg-archive@megatron.ietf.org; Tue, 23 Aug 2005 13:01:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15590 for ; Tue, 23 Aug 2005 13:01:44 -0400 (EDT) Received: from [199.217.145.178] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E7c9m-0002Zo-Em for provreg-archive@ietf.org; Tue, 23 Aug 2005 13:01:57 -0400 Date: Tue, 23 Aug 2005 12:03:09 +0100 From: "Himmelfarb" To: Subject: Save up to 90% on oem software !!! Message-ID: <423F3FA9.4010405@expert> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------050509040508030003060708" X-Spam-Score: 4.5 (++++) X-Scan-Signature: 8008c49d41a52dffe8d48b494980a4a9 This is a multi-part message in MIME format. --------------050509040508030003060708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by drop.ux6.net id j2LLgHfF030444 Content-Transfer-Encoding: quoted-printable Opt-in Email Special Offer unsubscribe me=20 =09 *SEARCH* =09 =09 * TOP 10 NEW TITLES* =09 * ON SALE NOW!* 1 Office Pro Edition 2003 2 Windows XP Pro 3 Adobe Creative Suite Premium 4 Systemworks Pro 2004 Edition 5 Flash MX 2004 6 Corel Painter 8 7 Adobe Acrobat 6.0 8 Windows 2003 Server 9 Alias Maya 6.0 Wavefront 10 Adobe Premiere * See more by this manufacturer* Microsoft A pple Software * Customers also bought* these other items.. *Microsoft Office Professional Edition *2003** Microsoft *Choose:* =09 *List Price:* =09 $899.00 *Price:* =09 *$69.99* *You Save:* =09 $830.01 (92%) *Availability:* Available for INSTANT download! *Coupon Code:* ISe229 *Media:* CD-ROM / Download System requirements | Accessories=20 | Other Versions *Features:* * Analyze and manage business information using Access databases * Exchange data with other systems using enhanced XML technology * Control information sharing rules with enhanced IRM technology * Easy-to-use wizards to create e-mail newsletters and printed marketing materials * More than 20 preformatted business reports *Sales Rank:* #1 *Shipping:* International/US or via instant download *Date Coupon Expires:* April 28th, 2005 *Average Customer Review:* 5 out of 5 stars Based on 1,768 reviews.=20 Write a review . ------------------------------------------------------------------------ *Microsoft Windows XP Professional or Longhorn Edition* Microsoft *Choose:* =09 *List Price:* =09 $279.00 *Price:* =09 *$49.99* *You Save:* =09 $229.01 (85%) *Availability:* Available for INSTANT download! *Coupon Code:* ISe229 *Media:* CD-ROM / Download System requirements | Accessories=20 | Other Versions *Features:* * Designed for businesses of all sizes * Manage digital pictures, music, video, DVDs, and more * More security with the ability to encrypt files and folders * Built-in voice, video, and instant messaging support * Integration with Windows servers and management solutions *Sales Rank:* #2 *Shipping:* International/US or via instant download *Date Coupon Expires:* April 28th, 2005 *Average Customer Review:* 5 out of 5 stars Based on 868 reviews. Write=20 a review . ------------------------------------------------------------------------ *Adobe Creative Suite Premium* Adobe *Choose:* =09 *List Price:* =09 $1149.00 *Price:* =09 *$99.99 * *You Save:* =09 $849.01 (90%) *Availability:* Available for INSTANT download! *Coupon Code:* ISe229 *Media:* CD-ROM / Download System requirements | Accessories=20 | Other Versions *Features:* * An integrated design environment featuring the industry's foremost design tools * In-depth tips, expert tricks, and comprehensive design resources * Intuitive file finding, smooth workflow, and common interface and toolset * Single installer--control what you install and when you install it * Cross-media publishing--create content for both print and the Web *Sales Rank:* #3 *Shipping:* International/US or via instant download *Date Coupon Expires:* April 28th, 2005 *Average Customer Review:* 5 out of 5 stars Based on 498 reviews. Write=20 a review . ------------------------------------------------------------------------ *Symantec SystemWorks 2004 Professional* Symantec *Choose:* =09 *List Price:* =09 $99.00 *Price:* =09 *$29.99 * *You Save:* =09 $69.01 (70%) *Availability:* Available for INSTANT download! *Coupon Code:* ISe229 *Media:* CD-ROM / Download System requirements | Accessories=20 | Other Versions *Features:* * Norton Utilities optimizes your PC=BFs performance and solves computer problems * Norton Password Manager keeps your passwords secure and easy to manage * Norton GoBack Personal Edition restores your PC after a serious problem * Norton CleanSweep removes unwanted programs and files that waste disk space * Norton Ghost protects your data from computer disasters *Sales Rank:* #4 *Shipping:* International/US or via instant download *Date Coupon Expires:* April 28th, 2005 *Average Customer Review:* 5 out of 5 stars Based on 217 reviews. Write=20 a review . --------------050509040508030003060708 Content-Type: multipart/related; boundary="------------030407060607010708020801" --------------030407060607010708020801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Opt-in Email Special Offer     unsubscribe me
SEARCH

TOP 10 NEW TITLES

 ON SALE NOW!
  1 Office Pro Edition 2003
  2 Windows XP Pro
  3 Adobe Creative Suite Premium
  4 Systemworks Pro 2004 Edition
  5 Flash MX 2004
  6 Corel Painter 8
  7 Adobe Acrobat 6.0
  8 Windows 2003 Server
  9 Alias Maya 6.0 Wavefront
  10 Adobe Premiere
  See more by this manufacturer
    Microsoft
    Apple Software
  Customers also bought
    these other items..


Microsoft Office Professional Edition *2003*
Microsoft
Choose:
 
List Price:
$899.00
Price:
$69.99
You Save:
$830.01 (92%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Analyze and manage business information using Access databases
  • Exchange data with other systems using enhanced XML technology
  • Control information sharing rules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail newsletters and printed marketing materials
  • More than 20 preformatted business reports
Sales Rank: #1
Shipping: International/US or via instant download
Date Coupon Expires: April 28th, 2005
Average Customer Review: 5 out of 5 stars Based on 1,768 reviews. Write a review.
Microsoft Windows XP Professional or Longhorn Edition
Microsoft
Choose:
 

List Price:
$279.00
Price:
$49.99
You Save:
$229.01 (85%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Designed for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more
  • More security with the ability to encrypt files and folders
  • Built-in voice, video, and instant messaging support
  • Integration with Windows servers and management solutions

Sales Rank: #2
Shipping: International/US or via instant download
Date Coupon Expires: April 28th, 2005
Average Customer Review: 5 out of 5 stars Based on 868 reviews. Write a review.

Adobe Creative Suite Premium
Adobe
Choose:
 

List Price:
$1149.00
Price:
$99.99
You Save:
$849.01 (90%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • An integrated design environment featuring the industry's foremost design tools
  • In-depth tips, expert tricks, and comprehensive design resources
  • Intuitive file finding, smooth workflow, and common interface and toolset
  • Single installer--control what you install and when you install it
  • Cross-media publishing--create content for both print and the Web

Sales Rank: #3
Shipping: International/US or via instant download
Date Coupon Expires: April 28th, 2005
Average Customer Review: 5 out of 5 stars Based on 498 reviews. Write a review.

Symantec SystemWorks 2004 Professional
Symantec
Choose:
 

List Price:
$99.00
Price:
$29.99
You Save:
$69.01 (70%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions


Features:

  • Norton Utilities optimizes your PC¿s performance and solves computer problems
  • Norton Password Manager keeps your passwords secure and easy to manage
  • Norton GoBack Personal Edition restores your PC after a serious problem
  • Norton CleanSweep removes unwanted programs and files that waste disk space
  • Norton Ghost protects your data from computer disasters

Sales Rank: #4
Shipping: International/US or via instant download
Date Coupon Expires: April 28th, 2005
Average Customer Review: 5 out of 5 stars Based on 217 reviews. Write a review.

--------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhLAEWANUAAP///+7uzAAAAIqKitbWuLu7u+fn4O3ty21tXq6urpiYhkVFRWdnXBcX FzMzM7y8o3d3beLiwktLR8vLr+/v7319cRERETExMSEhIT8/PVdXUZqamnNzaiIiIrCwmqqq qmZmZszMy6Skj1VVVd/f3/r6+erqydvb2M/Pz4mJeefnxs/PsnZ2dvb29M3Nzby8vN7exqqq lPHx8ImJiIKCggAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAA AAAsARYAAAb/QIBwSCwaj8ikcslsOp/QqHRKrVqv2JA2hO16v+CweEwuLxvoBtfMVgra5Xez 1JIZ7vi8fs/v+/+AeyVNcnAAEIgNEIaMQ4WNXo9IJTInMCoHAZqbnJ2en6ChoqMBBxEEKy4G TJKGaJCMrbBVskQlBjCkuru8vZ0EDwaDSbVsEK8NAMnLAB0hr2UUBQVhxbNR1gC4oxMRvqET D5zh497fvx6rxNfQSM8dRBcjQhQCHwNvCwL7NAIDAAUEXBBygQURFgIvbBACwp6QgAIsjKi3 b98/JNbkCdlHAQCLgQsWAKBwAcOCf/geCqAmJKXKAiRNDsBX0Zq1Fis4KZAQIIKD/wcEJGjI oEDTzwAKGCB14EDChE4pHBDQFEGDBAZFq14tGnRo0QBHky4VhxUs06OlVHh44SZJQJb+ANQs 4BIATQwLlxw7pqzvMr5EXG6wYDefSCEL5tGkUI9lYZYdKVjAMA/gShRx5V5cl2QAYYgfAFz4 F7Jwx5Zy3g6p+xbfadSslBiYusnng50BKnAIMEEqWHFixXLYzUkCh68VlPbMrdybbt6+wypV kKFCgLJIlWs6YOJBXoxuV278l7nw6jf4SDBpAA9JOyEkHI4AYb50SwwATq788AgDfSIb4CWA em9hlld54IVHwgAhDdBYfiJt4M9pLqkG20sSOnhebEl00/9JchmIEEAGHmiiQVHSZRcAB9Zt MoEGHmigiQQlbkIjJySaiCJw0zEgQQTYicWJCSuk0BYSFsZVXl0p8aeeXuz55ZciRlwAQj2h paTPPtMMaEEBJzFIBIKiORgXROWRaUQ2AmwwwkwLBITYYSNERA1NFTnGmnh1fnnhkUjE4AkB TRklznU7qqgAUz9ykkIKPk2FlqGcoFVWikkpkKkmQm5iAgEcAGoEmhbJVZF5qC1gwX9LvLMG ER0kY4Rng8Fm33joNUjEqkRgdoGq+L3FAn7jLZHNAiBg0KWYEA5RQEmoWoiqZSw9S2xdnAVq DifY5RjAib8pykAEGRw6owYMOFD/1I021qiJt+BiOu5WnGpXSnehZjuqeJr1+yc+BTzZxDFp FEylEfHxWt9hiJkEwAcWCIACEQ1NzNAF00j4QYEO+avvEQNg8EY9FlxU2mksEFYhv9O+hTJh 035cxAS0cYvcbr1NJYGIFVgnXAoulvtABTImx4nRmzyXcwA75+azUhUQVS8npoiQb4JHJEne ZkxmY0QIiIQtdhL6hFZfRSjFRXIRFDR0wQU0lDyESao57DHWSApw2AUCuDAnQCa1GS3LeMa5 UgGB54Ut3kacYO4m2HUldQAiZMBABk+JJQJPmqRAXG8RaFWW6FwJNXnll2eu1APqTr2dCitU YKTMzvKr+GSehS9+DRQFWPyF17tziEQLQB1gPCge1vZ4L+S4+HjyVC0fivEqEKAAAt8dAXwZ EHSwyBDdfx88LeNbkY0BHnSjggkmGO/++/DHL//89Ndvv/EmqBDBCtfPcIKosIhVe4QgwPKR z4BT8NoJYiCCB9CMABCMoAQnSMEKWvCCGMwgKh4gggogYAYuGAbjIBE+IpQQgVLYHgrHxIQW nCABCtANAmZIwxra8IY4zKEOd8hDBDAAASzawAlEOMIVGvGI17iFC17wggQ48YlQjKIUp0jF Klrxik98wQlkgMQuevGLYAyjGMdIxjKa8YxoTKMa18jGNrrREEEAADs= --------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhBQAFAIABAP///////yH5BAEAAAEALAAAAAAFAAUAAAIIhG8RqaD9QgEAOw== --------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhBQAFAIABAP///////yH5BAEAAAEALAAAAAAFAAUAAAIIhB1xqcD6QAEAOw== --------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhUgAOAMQAAP/umd1mM////4czIa5wSM+jaXYZEG4MCLmAU6RgPn8mGfPbjWYAAObH gMSSXpBCKtq0dJpRNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAABSAA4AAAX/YCAIIjmW6KmabNqubgzP7xsEwJ3jes//u6BPCBwai0ji 7gRoOp/QqHRKrVqvItx1y+16qVkn4bAoDACFwyABMEAKjELDACAYBgiAQzGAAAYHCnlNEWwF dGlrdQYGBE0DigAMTQiQg5B1jk0oYgYIZmhnTQ8OBAMEDg+ZTgMFT61PewAJhqKZC5OgTpNt Cwt0fwYNBJo5JE8ECa1nhwR5xA8E0Y6mBK5jDqyuTwwLCn7NzxGmAAsHDwtNuaKwpwnET2FN xO/MCgXgA3R31xFylAey/dnm5AGCA00K3PNjSoHABg8UqAv1yNWyd044zSMwh5ktAIHaIFz1 BONAKAgMW0RIaIsYBIlNcE3s9atiymLyNv5hpkaUgpUR591ho0xYRSgNGAhMdAbegQYQ9Gni VQlPRXPFjGn5wrWr101MvoodawVFkiNK0Ko9yzYt2xoy4NKIS3euXbktQgAAOw== --------------030407060607010708020801 Content-Type: image/jpeg; name="prod_image" Content-ID: Content-Disposition: inline; filename="prod_image" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQY GBcUFhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYa KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAAR CAC0AIwDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3zW/Ekun6jJapbxuqBfmZj3FQ6b4plubo R3EUEKMv3snr2rA8cSGLXbhlTef3Yxn2FZnhKe5urmcXKWe7lUD52FGVWCn3r5CGPxMsd7Pm 05rfK56Lw8PYOduh3V5rd9ZMfOggMXaYFsD/AHvT+VNt/FDiXZewJEp6OpLCs+J5bV/Kh3R/ 9OdyeD/1yf8A9lqhqVxp9qyor/ZZXO02sybRn+n4fLX2b5FueQps7pL8um5UQqfQ1VudZeK6 gi8kHzEdic9Nu3/4quXtZ7iwfEQYp954JOv+8v8A8UKuNdxXt7ayQ7uI5d4PUfco5SuY211z NykPkruO7Pz9MVb+3lkysYz2ya4+eETa/blYvnRPv+Zt4/u4/wDHq6NcH7vNQh3HR60BOI5r fy88Z3/dPv8A40+XWVjnePyD8h253/7Oahnt0nGG27scf/E1jMDDcyxfMcHqe3yr8tNpAmxg 8eqxcf2fJ8jsv+sHY/SpB48i/wCfCX/vta4CPO+X5G/1j/8AoVPUH0UV8fXzXEwqOMX+R9PS y/DygpSR3y+OoP8Anzn/AO+hT18cWx/5dJ/0rglQ+v6U9Y/m+YtWX9s4nv8AgN5bh+x3v/Ca 2v8AFa3I/wC+f8aB43sO8Fx+n+NcIsY9KlVKX9t4nv8AgZvLaHY7r/hNLD/n3uv++B/jW3pt 7FqVmlzGjqrZADjnivLdvy16F4TXGhW/1f8A9CNejlmZ18RVcZ7WOLF4SnRinA4j4jyeTql5 IrAMojxubA7Vj+CboeQ92gSfeZFIYlwccf0qz8Vp5o9Xkitobad59kQjud2wsQMZx/DnGad4 JmTUkikuY1jjeN8pGem3+6a8em1HHWtvP9SJX9lvpY6eC4triPyonVFP/Ltc/Mh/3W7VzXjW 3ln02UWmzbEdziaTmNlbnY/fj+E1anmtjprXtvL5ke9k8uQYkzu29fun8cVka0PtVm1nb36w yyDebVyPnb+7/dNfe1LNWPEk7o3vCX214XGs/wClZHEcfDwj5fmVe/ruWn6lcW9vfQfZrmKR HDtvztcbeqt+dQeE5bJNG8uJ5g6HmC+m5Dhf4JP4K4XXr+0jvHRbK5RZIyyZ/u/L8u4f8C+b vWVSq4Q0HzWR2+lXaXGtQXENwnlSBkuCz87mX+H+H+Ku5gjSGFET7gHFeW/DuwiCebdXMW+b cyIXDlF2/wAQHT722uo0/X4kvmtNPk+1Kj7XTPA/3W/9lopS0uy4yOyX734ViXQ/064/3x/6 CtadjdR3SM8RzjqO4/3qoXP/AB+XH+//AOyrW62KZ58g+d/98/8AoVSqlRwJnf8A77f+hVZV K/N8S/3svU+0pP3ERqBTl61KqU5U+asOYqUiNR7VIoNPVKeqVPMZuQxUOK9B8KrjQrf/AIF/ 6Ea4XHFd94Z40S2/4F/6Ea93h3/eJen6o8zMX+7XqeSfGlRJf3cRGUkhYP8AuDNx5Y/gHJ/z 6U/4eebcaTZG3kSGU27MjxghBtHp6e1RfGkO+p3MaSNE7xYEgLjZ8g5+Qg/rWv4Cgjgu7eJE IXyWbY5yR8v3WJrilJRxsY96n6nM4/un6ElrpWsQA2d7Lb3VvLiUzvH8uQ3CsevNV9V8H3k9 7dR2UFvDZSfMJEPz+/X+L/61bevW8lppuoztqDmAfvUQncQ6t91T/d/2azvh74xTVoLy3u5U +1W5ZgHfaXWvu7LZnh6XszD0/TnuPItNMv7eHy9yXFrfPh/9/Hfr0Hy8Vzuv+HJ7JYI9TuFD 3D7I03/IPmUFlrrfEesaPMFu7XfBrMch2TRoGzt+UNu/u/7VecaxrGp6le5vXmufv7Ezk/N8 3yr9OtYzsZu2xv6jdWWjNcWek2k1pfxuyTSAlt4VeG3fd53V0vw006SNZ7xpcrJj9xIAz42/ eZeoU/N0/u1x+nPN4rvYImRo5zbyLIO7unKqo/U5rpPArppdzBpllPdXMsiedIPLAg2qzfd/ i/4EKml8V2aR3PSEt45JFkt3aGXsQev+6e/+6ai84/aZ45tvn55I6fdX8qLa6id8S/uXPaQ8 H8ejfj+dDZ8+4z97f3/3VruexsziLR8q21H++e3+1VpQ/wDc/WorHBRv98/+hVdUV+aYmX7y XqfYU5e4iJQ/otSKj7uq/lUqij+KufmCUhmw/wB5qbORBC8jbn2DdjPJqbKf31/OnSCKRGRw rqexGaUX73vGcpe7oc54c1+PVdQltlgxhN4JPOPpXrvh5QNGtgPQ/wDoRrwuzuLDwz4ncvdr JBdnyghhO9D/ALPH/AeK908OAto1sWPJ3f8AoRr6vKKahi3KC0cf1R4tSs5U7Setzyn4v2X9 pa/NZKYw00WB5iZQ/IOtavgsEarBHliwhZc+vy1T+Ix/4riD5FJ9d+0j93+tX/Ax/wCJ/F/1 zf8A9Brwqjl/aUI/3/8A246uX9xfy/QXXPDbx32o3EEl3JFP+9aySMsHb/ZbHDZ6N9a4GTwx qMj7pPD18qqW3ywxlXkP+593vj3r3PWdf0vRjCuq6hb2jS58sSPjfjrip9L1Wx1a2abTrqO6 hB2F4zkA197yx5rXPDnhJcvtGnbvbQ8V/sLXnG3+zryeGPbFC8kRRox3Kp6ZrL8PeENaXxXF carpN8bcFsyBHXH+0pHQ+lfRNMan7LUj6ujwrT/A+v2+qtPotmdOUvveS5G/f8ytu2f+y+or 0XwVpuqaVpUFpdxpNIlxJ5k8kflu+5s715967Bcin4O7NOMOUuNJIpSWSTK3mxKc+1ZK6ZcQ 3M/lIwgz8idvurXRqSV+YYpG/irS5djzSx8O6pHu328w5b+NP71aK6Jfd7d/xcf412q9KWvB nklCcnJt/h/kelHH1IrY49dDvP8An3/8fFC6Hebv+PdfzFdhRWX9hYfu/wAP8g+v1PI5RdGv P+eQH/AxTLrTb2CFnSBJHHRPMC5rrqilj8xMfKPeiORYa+7/AK+RLx1Q8s8R+EdZuNcs7/Sk sRgbnMxHDL8w+Xvz/FXpXgWyuLDwrY214EW4UOXCNuGWdm6/jTfLkjDbtvHStvTh/oUX0r1M Pg6dBWicNRuTueP/ABIz/wAJzDt3cDnGf+efer/gQ/8AFRRf9c3/AJVQ+JBX/hOF3NhgBgc8 /JV3wE3/ABUkH/XN/wCVfHTX/Cmv8X/tx7X/ADD/AC/Q3fF8MkXiXRdQNg95bRRTwyBADgvt x8p/3a5vxLHex2+pNpLapYNJ51xGlvJHCN+yLZu56Zb9GruPFcc7rYSQWb3ccc2ZYlxkjb7/ AO1WBd6brN45uLHSdPVD5kRt77CHBVcNuUN/dr69VKlPFXSv8tNv66nm16nPhlH5fjcb4t1e W1Oix21xq1zqdzbtKtlpcaSNIqAM8py4UKCQPvckqBXK6j8StISVPsviS+nWS3glAQwRZeZ8 JF87ghhyxz8qKPmbmtK403VPDep+Gb2yOlz6va6W+mzW91cPFCyO8ZWQSBCBh0xtbrnjmsjR vBcWkSWlp/aukTSCXTLl5BL9/wCzTPJct0+XcZlChjzXpK1tTj1PQPDPifRGsdPt5NVihvLh JHjt7u7R5nRHYFuHbj5G7/wn/arc0bXNL1u2a40e/tr2BH2GSB94Df3fyrxex8A3Vvpmp6TJ rHh02esKftEzfvp7Zx5qKsS9MfvFOcrs+frndXcfD63stDiv5tQ1HRhd3ZhZ/st7NcfIibEL PMxb17AAYXnrSdgVz0Ckbq1YjeKtLjEpeV0SOFJi5T5cMuQP72SPao4vFuiyp5hvUjTuZBtx /nj5unPWkWbS9KWsS68R2lvbW04juJ7e4fYskacb2JAT5sHOR6fL1OBVZ/F1qlvPL9ju9kHm b87Fw0TKsi/e+8Cyr7n7tZFnSUULyqn1oxUgFJS4pKRRWvELp8o3Vrab/wAeMP8Au1QkQFav aeP9Di+lXAhnjHxOP/FcxcDt36fu/wBa0fh+f+Kkg/65v/KqPxJiL+NXkEm1YwhIx1yn6U3w rfxWGt28s0nlq58lCR/G/AX86+LlHmzJf4v1PaemGv5foexUVz2oalPb2csjXGzA4JTdz9BW BZ+I73W9Nllhea1ns3DTBHRRN/s5PbH/AOuvt5vkdjwPaI6fWNAstWnaW8Te3keSOhCDdu3Y 9aypfBOmzMxlklJ3fJ9zCLlsDG3n7zDJ559q4Gfxfqh1po7LV7t7Ux7cTAZ2/N83Tg/N972F ZNj4114zO6XNyVnTyYFnkyQ/Tdtz/wChVl7dC9qj1I+AtKI2lrsxc/IHCDb6cD7vt0zzVyXw dpssDJK107vM8zv5vMjuAHZuMc4Xtx/DXK+AJtc+33Q1i8mmXZ+7zNvFdxJI+xOW71vD31cf NoVm8K6c/wBxrpFCInyTkcBNg5+99xiPxqNvCGjFPLa2laLZ5Wzz3wU4ynX7pwp2+oq/A5+b cW/GvG/jZ4i1PSb61TSr+WBZZJd4jfbn7vzVoqXMxTq8iueuy6Dp1xIkk8TsVDhf3rqOWy3G eue/sKY3h/R9rD7MvI2n9865z97v/F39f4s18sJ4y1m1Rf8ATJXbO4Zc8Cp08a6yAqNeTF36 neamWGq9Lf18ifrdM+tFkiRVCugUfKBkcUedH/z0T86+U7nxjqIhx9plLuf75wK5zWPGGsxx +ZaajcWzx/MjpIc5qJYSvbdB9bp9j7N+0QD/AJap+dMa7tx/y1T86+SZfFuszlXfU7su/U+Y VquvinVRcbG1C7279v8Arz/FUfU8T3X4h9dp9mfW8+qWkP3p0rX02VJrCCSEhkZcg18dv4m1 H5Ue9uX+fbzMf4q+pfhnM1z4A0CaYlne0Qkmt5Yf2cFz7ijX9o9DgPiMf+Kvuv8Adj/9Argf G11JaeHJbiGRo5454HRx2ZZVw1d38SD/AMVjdf8AXOP/ANArgvGM1lD4avJNVt5bm1Qoxjjk 8olt64+b618Oo/8ACkv8X6n0lT/c36fobui/G3TtUs72DULSbTtSjjLIIT5yP/tL0+b/AGa5 K88afa2d0Rk8z+K6kO9/94At+teUXd1pk13v0+yltmHzfPP5uf8Ax2r95f2YlU2ztI4RWkfI 2A/7NfcVI9JnzkOSaub13r7x6vb7zE8Un+uRAcY/+t1rbbW9It/3UF5bFpT9wAneW+orzC5u 0+0wD5t7nbWfaTE6pb85xMF/8eohCDvdCqx5LWPpf4Nakj+Kb8XEuyIWjYUnj761n+L/AIxa xYeJNUsNNS0S1tZ3ijzGWJVfl3M2a5D4d6xBpfibUZbsvsNvsAQZJbetcL4ovfP8XavKoKLJ dSuAeo3NW1GJFaT6G5r3xg8WalvT+0PsyfdxAm3/AMe+9XLWfiG8up3/ALRvZp1zuHnOXwT1 60y10WGSXdqFyQh+bZBjP5mteS10TTfIbT7eSRmXLvdlZDntj5cCtoxdznlKNtR6XSXW3yvn YfLhBup/2qMNneu2uj8L+ILdn+xSv5C3H7kSRjGxm+Xt/vVuy/BS2gleJ9TjLINz4lXj9aud odSIRc9kef8A22ORvvrTrrR7/UbDzLSLzEfphwpPze5rt2+EWhQJOZ/EDmUKSiQup5/9m+gp vhfTYrGyls4pJZFgkP8ArOoJ520QtN2HOLgrnK/YNQj+9aTfgA1VJZPJuGEw2SoeUf5cf71d rfHZKwrita0mzvNRmmuL14JTgbAvGAv3q1muUyhLmGvdx/LukXr619m/Cch/hr4aZehsYv5V 8hXPws1K30dtVd5FsBGs3neYn3D/ABbc5719d/CmAW/w08MQq28Jp8Q3evy1x1pXOulGxwPx MP8AxWd5/wBc4/8A0CvNfiWf+KK1D/ei/wDQ1r0f4nH/AIrS8/65x/8AoFeZ/Exv+KIv/wDe i/8AQ1r4WC/4UV/i/U+tqR/2J/4f0PJvCWj/ANu6x9la4+zgRPKZMZ6VoeIfDmlWkTxxatcT OevTbXKWd3JbXGYnI3gocelQ3N68jZZ6+9fJb3kfIKNS/usljRIUaNp3Ze2zqKm0mF59Xsre yilmkeZBHGBlyd3TiszeX7fL61o6LDcm/t5bITb0kBEicAH61jp0NXf7R694C8M6rd63eSy2 EsMEcPzyXKGJEO73+n8NJrHwo1LVdZnvdH1vQ72C4nO8W05lMO71VFOfwrZj+LkmhaLBYeIr O41K88vNvM77uOnznhtw/vL1qq/xZ06OcQXYkvYT997YO6D/AL+Pz+VCk4qwOz1Za0j4V6Ho +2fxDqt1fcMwSGHyISF67WJ3Hp/s143r+qRXOp3ElrEYYN58uFE+4nYflXuK/Gbwxbutylpq 13dW8LLbh4Y4UGdoK8MccfxY7V5r47+I2seL0e2uHS100vuFrCMA+m9vvPWsJMznGBT+Hhxd vqWx5fsh3PGvBA2tXU6V4hm8Q6i8Fjpel6lKh4F/MkROP9k/Nx/vVxngrWLbQr+eS6SV7eWP Y6IM5rQS+8NiZ5EnvYd77sG3DY/WicFPcqnV9n8J6JPpvieO2cfY/CGkZHDyTw5G786qa1qZ 0a2cy6wmuXkkaYS0RNkG3quVwCv+7XGwXfhjzk3382wdcwEfyFLq+s6VJJFFY3Ie3jj2glSv 8X0opQ5HuFes6kSZfEkMrZnhvI/96En+WajurnQ74ebdC7uph8iR2rlH29e64/Ostru2LfJO n510vhm7sk06Xzbm3DvJ0eQZ+7W05uxzQSuek6lqVlN8GbKC4d4/Ot4YXhWdPOQK3qcL/D/s 17j8NBEPh94d+ziVYvsEG0S7d+Ng+9jvXzD4nu7ObwxLFDcQvhEwBIG/u19QfDgbfh94bH/U Og/9AFctf3dDrovmVzzD4nn/AIra8/65x/8AoFeXfE58eBtR/wB6L/0Na9J+LUxh8a3RwCvl x5+bH8FeZ/ESTzvBN/tLR8xffH+2tfFqP/Cgn/e/U+tl/uf/AG7+h4Swf7x+THr1rQ0fQb3U 5FNvDtiP/Laf5U/+v+FMt4o0kVmQyEf3+n5V0Nrf3bpjLba+20lufJc3Y39F8JaPZFWv5kvr j0c4jH4d/wAa6W5t7Z2skiRAouE+502/NXH2sLz/AHzXQaZCE+dCdo+Uf/FVrFraxjK/c5r4 toBq2n7EwgtfT/bauKQj1H517Pc3UsIgEUrBSXz7/KtU2ut/+tgtZPeS3Q/0qZR1H0PKKcte oNHp0n+t0bTz7+Rt/lUP2Dw/Ny2kQp/uSSL/AFpC5TzdjTK9Ek0Lw5Jyttdx/wDXO63fzFV2 8M6A4+S71GFvfY/9BQHIcFSZruX8HaY6/udblHtJa5/k1Qt4GXrBrVof9+Jx/jU6hynIoalj 4NdP/wAINfDbs1DS3/7blP5rSf8ACDa5/BHaTf8AXO7jP9aoXKzFVxt6L+VffPwz/wCSd+Gf +wbb/wDota+H38GeI41b/iUXDr/0z2P/ACNfcfw9ieDwH4dhmjKSx6fbq6FcFT5a5FZVTow6 1Z5F8Wk3+N7wZYfu4+h/2K818bQOfB95FlTzFjaMfxrXpXxXP/FdXn/XOP8A9ArhfECJJo1w jjK/L/6EtfHr/fl/i/U+vnH/AGL/ALd/Q8ns9K9Rmtu2sUjHzCtCOEdFGKtRQp6V9nynxtyv bWm9l7LWpkRphe1PiREXpTJQhb5auKIkUp8u8Qx82Xb/AMdWomhJ5cMFFXVhP2lHYfIEOT7t t/8AialYIavlEZLjHaq7Rv1YYX+7Wu0I61VuR97jH+7RyjuYF3NIW+XcFqqtxKnGWrVuY8/d qhJbvWcihi3brUq3r+rVB5DjtUsdq7soRGLH0G6pGWVvnx99qmivX6ZqpJbmF2SUMjjqHG1h UsVu77dgZ2J2gAZyaYjSjvXCty1fZvhL5vCeiHPWxg/9FivjS70TU7LTYL26sriGzuBuhmdM I9fZng//AJFLRP8Arxg/9FrWdVmlM8Y+LB/4ru8/65w/+gVxGsc6VOP93/0Ja9M+KnhjWp/E Fxq1nYSXdk8aD/RzvkTAwcp1b8M15bqEySaddIj/ADphXT7pT5l+8v3hXy7ozWMUmuv6n1rq wngnFPaP6GCo9qsQAk/NUCED78iD6nbVmK6tE+9c2+708wV9dFHxhYUfL81CpzlttOjIueIU lm/65wu/8lq9b6Lq0wzbaLrMo/vJYTf4VXNEOWRRUZLU1k7tW/B4O8UT/wCq8N6p/wADjRP/ AEJxWjF8OfGMwX/iRFB/02u4R/JjR7WHcfJPscY0eage3J7V6Tb/AAo8XSH5oNLg/wCul4zf +gpWhF8HPEDf67UdIi/3BNJ/8TU+1h3H7OfY8ektCai+xf3hXusHwSuWX/SPEMS+0Vj/AIvV +1+CdgP+PrW9Rk/65xwp/wCymodWBfspnzy1l7V6H8O/F+l+FdDa2m0+4ubp7trrzEA+Rtmw bcn72C3516pH8GvDUf8ArZ9Vm/37kD/0FRWhD8J/B8Y50t5v+ut1Mf8A2aolViyo0pI8hl8f ael89zaaB98rlJkhYIN3zsrbC24hV6naPSoW+JhhhWJNKiGCW3vd7X+7t3ZRR857t9duN1e6 W3w68I24+Tw7px/34d/861YPDWh24/0fRtNi/wBy1Rf6VPPHsXyS7nyn4u8V3fiuGCO7jiHk l3AgdzksqL0z/sf+PNX1d4UXb4X0dcdLOEf+OCtCK3ihGIYkjH+woFS1Ep3HGFhKw9e8N6Hr U8f9saRYXzr0eeFWYfjRRUGo2Hwd4ZtVX7P4e0iP/ds4/wDCtC0srO3/AOPeztof9yMCiigC /RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB//2Q== --------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhcQAXANU5AP/MVf//zPz7+/vlmWZSX7uWWo1xXdDE0J2dwzQqZEtLk7Osm92qRO2+ VoiIVf3XdJiUaQQGavHu8srJ2nt6rAAAZu7s6goNdtTU5eno8t2xV0Q2YQAAXCIbZLihVMql Sy4uguLf58K9rqahftbM1v7PXsyjWB8feBEOZQsLav/RWLy3yv/+3xQUcFhYmfPHX7+sX87B zmBfndCyWuGxSuvFZ+7BWvrHU9nCcP///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAA AABxABcAAAb/wJxwSCwaj8ikcslsOpOCqIBEUZwiJwVlIghBHOCweEwum8/otJo8EpEsgqM0 Q4nY7xFOShYSsAKAgYKDhIWGh4iJioIDAzgwIwdRRVETIHiYeScrfouen6ChhwM1MCJwRAIZ l5mYHCcYAg8AtLW2t7i2Gia3BQ25wMHCwwAlDwMBAyUzCxJxQgJ1rZkcLhkBJcS1BgW5Bhu3 Fd3a5OW4xwM3ps5CEy0RXAgX8/T0dimcA+QmFeC43+HG0dJAwBw5A7yGlSDVYEQsIRQ4RFCA QEC9i3Y4yJCgTxsBAxV+1TKhASCABt3E2SpQQZfAWyg10EIpcuQvlcQePGhgCpUC/zvzok24 MLTohDsgMrAg18HEx1oEOiTYAM4Eig0EcAJgWaGCAQAGOmzoINNW2LEATIjt8BVAvw38uvob 9oDBjBF9clyJMK+iggt//265k6KPNrVgC6YNCWAqAAIFWb5kOZAxZFsNKiRM+yssrQqK3b4U VpcGBAwSctyZlyAa0dfR7nAwTMxAQQ2MTQJEMU7r1pZg/RXoYDYBrgIgPwv0LawEA9MkUu+l N2FoYAUCEtipEIH2sAQfDaD4qhscTt+Ug9NKT8tk+w6QgWtlHsw5AwgHUv/kOw87hf9bDLVd UksNo8F4BthWUHkA8KbcSsCZNFxxtnTQTXrzjVYfAx/gl/9aRPzNw4UUrt3hggQB1BYaPw2w 2Bg4l0kGYWW/XFYLbps5mJxotdAHzAscjhBdDkdVQA9F9SDw1x0VdSRMAi9Z+JhUVKV11QYO 1tIACgmQt1ZZ26wF1lVZPUjLWKHVRwMDHiyAWg4CyADUBRXJQ6cA8tihwDXZGGQLSZhpOJNA Ggh6ki8DgZkLosM0wCEEK+TVxQkSAaZkf3ly0AIXA6jg56eghmpLCY6yucAbcUSxAqXcTdNC RQHYcIOotNbaXAkvrMnmCDHkBWcUGLiQRyYdKMBFADUwoOyyzDbr7LPQRivttNQ++4EHvKL2 DJzOZLCCDJdwUAEILiCQwRQeVKth7rrstgvtB9dCsEAM2lIigTMSZBDCvhngK8IXawQs8MAE mwHBCAusQEII7BgRxb0kqhICCQdUbPHFGGes8cYcd+zxxxyTgEEIcGwLhQD3pqzyyiy37PLL MMcs88wrT2JEEAA7 --------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhQAAMALMPAMSfavv49Kd0JrePU9zJreuYEefayMaONbGAN86wgPfGVfLq3vKwM8+I F92fOP///yH5BAEAAA8ALAAAAABAAAwAAAT/8MlJA6F4GTzN5k9gLOBDBGXaCSS3DEAJDChn IF8m5CoXAIIEyCA4tCgvxIWTCNYoCQTg2UMiCgjqY5E4NISY7gFMMQAaB15ogD2qRAMEosg4 COTxOYLhuMvlAgIODHoDeXR6CIcHCgd/ACcpAVEFDAoKBZmKMJWXmQ2KB50Mn3EDDgWXpAUC hqiemlM9FggNlgUNAhcvogqkRQGTV764CCQ3g765QjcHt6yRVRYNmQVjHWyfxhI/1JkHSw8J ANVfNQTZuAlakgkNuQ0OA9isteASZqAC1mQADvANALTwl8sLjSrc5kwZcIcbgTsECMgB81DX jSDcgBgBIOcDQxoANxy5UbFAF7cmJBbMaHEjhrgdEl4cvLFOwsMNC6ScY4FQBI8AGrZEi7lB hBujJtQQOGaAigd2EQAAOw== --------------030407060607010708020801 Content-Type: image/jpeg; name="prod_image" Content-ID: Content-Disposition: inline; filename="prod_image" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQABLAEsAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wgAR CAC3AJYDASIAAhEBAxEB/8QAGQAAAwEBAQAAAAAAAAAAAAAAAAIDBAEF/8QAGgEAAwEBAQEA AAAAAAAAAAAAAQIDAAQFBv/aAAwDAQACEAMQAAAB8dut9V4nG66orO6CTUYCRYAgX5jn5dTt 2TbDn6cz1458s6dc2cokx2ea8Z3RZtVkES4NDmhTs5YJVdTy6MEPRzUPnjHVNqrWadp2klHa swjUZNLthTDl+EZl0I2n0maZYbJXGc6UNKraaNXlojtCsjxmebz7UVordSIT0I6ZZao1XLLT G2zjFGpadpLWyWhnotZU65SdV8z0/I4PW833vD9rz2cnf1/Gzy0R74ZoaYXGcYqXvC8xe0rQ NapohcfrTtj8v2Mlm8n3Mur5n10p3n0HhxjePTzQheFlgdLHt89kGm0LQOvf5e7l7Ldi0724 nQzJxcuTxvfzEzlWPZ5soVhdJHCpLZ7DabZrRGnVhrCm58TTtsMorac6qydmTpLkXjWaQpG2 mKVPK5646bZayXVTNSW0tnZG0ERTVZ8IeazcdkSoOS7KxUQdlrnox0VzUmmmmV5jU2Zk2juc GuslOrNEbNPk3PZE6sEx2Whok0qM2HGOqrd71dw6oHeS44oiq2afKloT0oz5zhTe3UPnG8zM HtDoF8dAAA2OBsAHcAJ5wCwAd//EACUQAAMBAAIBAwUAAwAAAAAAAAABEQIDEhAEFCATISIx MhUwQf/aAAgBAQABBQL4QhCEIQhCH+O5me05h+l5jPoefb3l415hCEIQhCEIe95x+p5b7vmR 7zmH+/MIQhCEIQgl+WV2XVHVHJ+Jv+vEIQhCEIQhBL8uP7Z7OPSRyaWuPX9IQkQhCEIQhCCX 5ZaS1v7ab0M3/SEJCQkQhCEIQnh+Gyj/AGhCEvEIQhCEIQaGMfhCEIXxnxYxj8IQhC+Ot04+ TfuePk+pnWp4YxjGIQhC+G/tjeGuPHG8nEpj+uZjGMYxCEIQvPN9z1u5j0tzw/TU40oxjGMY hCEZIjr41xdt83oc8uVx/T5d7XXKmGMYxjEIQjjc3nMF+llGUrEdBcaPU5/Bp3/jGMYhCEIe 9N929Lf5LZ3Ozj3XvfYYxjGMQhCEfUPqHc7o7ndTyxjH4QhCF5pS/FjGPwhCE/FKUpSlKUbG MfhCEJlKUpSlKUo2NjH5XilKUpSlKUpS+H8aUpSlKUpSlKX40pSlKUpSlKUvwznSf2tydsHb B2yLWDtg7Yj1mfHtk7K61VGe64+3vOI5uVb1S/6qU7I7I7I//8QAJBEAAgICAQQBBQAAAAAA AAAAAAECEQMSIAUQEyEiBCMwMUH/2gAIAQMBAT8BbLLLLLLPtfwXjL5ojVHovjRXZT7XwSNR xGuSQkdOeLG3LIzqk8eXL8CaofBEY2KJRCGHxqzL7k2h8EYJpL2bRNojlAh9Z4vikSdvjGbX 6FlZ5WSnY3zssv8APqampoalFCRqUNsXosssssvv/8QAIhEAAgICAgEFAQAAAAAAAAAAAAEC EQMSBBAhFTFRYYEg/9oACAECAQE/AbLLLNiyyL5H0bcj6F7eRsbGzY2Ni/A5OyLdifgbGxyN jY2LKExDY2NllliYmJ9SJDGzmQy5Eo40ZORl4tRRwss8mLeYiPUiRJlmKcYyVnOyZsvIlSMU dYJCI9SJGReSmUypDw7eWRRHpkkSjZojQUaEhIiumhoaKKKEhISKGhoaNTU1FESEiiWaHybX 5R+H4fhRR7Cf116Xh+WcXDHFiUI/1RRqf//EAC8QAAIBAgQEBAQHAAAAAAAAAAABEQIhMDEy QRASIjMDUWFxIIGRoSNAQlBScJL/2gAIAQEABj8Cxv05SW8NsfQaY9x0vbHz+xNp84HEL2Rt nOWOiXW0d1neOnxHVjofU18jVV/k7j89I+tt+2OjU0dNdUl/yOSMkZIyX7jU5tsUqmre5MQL 1x2XsV+JKaiE1w9semnzfChfy6mb/UcLEzM+HNzNGppl8tiE7iWGiqnzI9JIkRffjCTlkOh8 3J9y+FS4yG4E4FbIuh+pdCxPl/QGh/Q7NR22dtmg0Gk0GktT8XbH+GWogyJ5nwtj7m5//8QA JRABAQEAAQMDBAMBAAAAAAAAAQARITFBURAgYTBxgZGh8PGx/9oACAEBAAE/IcgsgiH0QAA3 QZ7u/bp1t3PsH9+YYl4HLp/e0wMcd5/x9+bEjVjjsEEEQh9EAPhzWGXig65/l5rGeGd9E+Dv 3duSfMEEEQh7wDP3Fqpt+Weo5duHm0N3+mGB1PuXVggiEIQ9wDP3EnEfe27Z9v8ArtIOlrrz bXNHc6IwQ9AhCHtA1n7CQirdwiF+UJjXrCEEPYAQ9oGMSX+Ev+V/hT/iuemEIegEQh7AYx9A IQkhCEIQQWWejJJJIQhCSEIQhBBBZNy3LJoADwdshgAx5ZJCEIQ9gEIIIJbRBzjYGMPnZ3Qt ZvL1s66Hg7CHoP0RAi5PnG3g+0BPej58f8uv0/BNhhz18/TAQi4uXi4wPGQOjZXCGYTc+c6z 9iQF2wuqLHGX2Y+mAm/+YNhy0Liel0rUaamwNV15nY08uMkaC8d7VnR1zO9r4yfD5nNnxPk8 3Ie7OfeAvQpg/sjuYMsOwGWB1Xu27OXOlxOeVmOmHmwDMD5sbuc+ZS9kUpylC3jg4fxY568/ xZ3vkZdGxh167PA5/pLLLKUpSylKUoYfYNllllKUpZSl6AxCHsBjH0ClKWUpegQhD2Axj6gU pYZQxCEPbBrGMYspYYYYhCHuIYxjGLLDDEIQ+gAMYxZZYaqkzl4PHMidJ0edv9SOTn+405Wf e1uvH+LmeUZNe5MQp87ba2sr4nfDLZ+/M7hjTp1yJjV9r5H6jn0+MZY4/wCRZ04Wfm+xt+G3 4b8N+G/Dfhvw2/Db8Njw2fDfc9Zv/9oADAMBAAIAAwAAABCI2KgGK9Jr/wAWdz2Fp2QPO2YF mJb40ORQJai/LkhMXzd6sIwrc8Mw6Aw0v5OwGyyoYfvwMyy0b1if+1S9yARcC5Mms+ghNQkU U2cMnAXQ/ERdRB9cejBfhBcB/8QAIhEBAQEAAgEEAwEBAAAAAAAAAQARECExIEFR8GFxwaHR /9oACAEDAQE/EIY+gCKw7SPnZG9Syy222y7ghv3/AGcGe/38z2ll4zkOmQMIRdWe0vAcJrxI eeBIbZjmzjHgP7BHOAdnvGsIcvBhpKGsQCZcJZDpfRZSHHj++YfN+kY599rDAUSeT9/8tB+e WPRJ6+fAsWScDHCxeAskks9GQQWXb3k/M/nftPXzahW/lgfPBBi3Rhbt27duFDx//8QAIxEB AQABBAAGAwAAAAAAAAAAAQARECAhMUFRgaGx8DBh0f/aAAgBAgEBPxBjGutKJ5VKGD5ScPFs FdAjzQkH32nhTj7+ribLHQIZmIK5ZgwEsBspa4xnseGUp6DJHzhuA+IxbtficoeNQRxJep46 klNheOLNL0GsdQhO8LHcsZpMUw2AxCCOgPaaxj6bCA2WumfgvJXQNgYg3gPqWJwZPSViue0Z XEKV8hmXM4k+PcP5ZHMHnIbMWEGwv//EACgQAQACAQIFAwQDAAAAAAAAAAEAESExYRAgQVFx kdHhMIGhscHw8f/aAAgBAQABPxA4A5CBBPjPGO2MMOyAbhbXq0QKuokezHTU0NNOYCBawXUo by5YM4mJNyCF2BhaWGHuXLTzmoWNYecEE2Q4hl2xl2XMvR6FMZvH3r0IqyQvKxFazkY0xAAy wUFG7DvlXN5bl3YAwAakt1BfBEshaVrmPjYhJtnjwu2O3g2mllf3FE0hwFVep9/SAHJKpZoz rpa+kGUKXYJRdDr95QXJusFb3vAqOVpV6tc90OzCThsvC+h/3C7UEq9C773R/ssKak0Iltfp 6y6rIWlTdunY/P3MH4tAqUvTGGZng/R9BStDDbPGO3gbM9E/uAyFQlKVX6/EQVUoApg1pFC9 uDkeD9HMoO3wDbDhvGijZhGyeS5GBas2o9iuI6PIdsTYhwHkFWcimb6Ba6ScJ567+pM30ao1 JspLAvFGP4g7d6zI5bNNBmdKvS7GNUVpei/xyQa3CyQ6Qw45ooQUDsqL6fmUhLdrfgI6aWeF K8EB17wQ10uVX6leX/D14geAdYM8IhhgghgiRuwbHykJN0pH21lLAtWPEfkqAgDgWFtHeCCG HEMGeHonTOmYWFYXv0lbZNL6XPvSunvAhsiHaFh39SMnpjaXuMEgO3sA1l2JkaufMKqqsjs8 h0vDqjij0jlw1WD4cR6i8MhZ+4HbiO+kTpjsYMTDo6VoQCAUp0Z6xWUFH2qASMAACCKt9A3G bFjoa/iDsgDoddvq5uASrIF3esceI9Zqj0jmKPgH0KmAN3nPa51G+l0B5iamxr1xrCQgVCpi FjItcqrrBs1lbt3lPAorDPeUKgtXZb3gtqwrDNcSUesWeFpcgJHlQwAbw1hkF7XTpsNoO83K 6fMAMlUA/wC/xKgF0UuqZxLEGRWemR335XnUmtws30A104h+hffs30xbgHkFUTV4pn+gqU7v D5x+hTBc/NvW/wAAk3zzjv4G/wA3W5uf+HdhJwWXfN2b/wBOrBo3YSb558PnGXlhd8yTMDmL vTswRIHlBg59z0reGivyGiyzMwAEX33/AHrLGGJRTsYe6Ostf9u4wjIVS4V57/uN9YODKVDg 7Apevr3iylpEmpfsx7DHsPpO5ek/xoZbPqEen39KgqQIKZM5ya6bR+LUFDH4uPy6FoKg0mtv 8SqhGtb9vEW0qLqv3Nr1/MD8vzM/dPef0p7y35T3lvznvM/Oe8z857y09095/SnvK/Ke8fmT 3lPu/MexKPSNqP/Z --------------030407060607010708020801 Content-Type: image/jpeg; name="prod_image" Content-ID: Content-Disposition: inline; filename="prod_image" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAACgAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAFBAQGRIZJxcXJzImHyYyLiYmJiYuPjU1NTU1PkRBQUFBQUFERERERERERERERERE RERERERERERERERERERERAEVGRkgHCAmGBgmNiYgJjZENisrNkREREI1QkRERERERERERERE RERERERERERERERERERERERERERERERERERE/8AAEQgArQCgAwEiAAIRAQMRAf/EAIwAAAID AQEBAAAAAAAAAAAAAAAEAQUGAwIHAQEAAwEBAQAAAAAAAAAAAAAAAQIDBAUGEAABAwIDBAYK AQMFAQAAAAABAAIDEQQhEgUxQVFxYcEiMhMG8IGRobHRQlJiFCNysiTh8YIzNEMRAQEAAgIC AgIDAQAAAAAAAAABEQIxEiEDQTJRcSJCBBP/2gAMAwEAAhEDEQA/ANmqfWdaGmZRkzufWmNN nt4q4WQ849+Hk/qQKT+a7ySvhhrB0Cp9/wAl40nUbm5vohLI5wJOFcNh3bFV29A0l9MnTtqn NFLTqEWUUbU/2lQtjxlvqoqUKFKqcx4ozHioUoJzHijMeKhCD1mKMxUIQesxRmKhCCcxRmK8 1Qg9ZyjOV5UIPRkpicAhsgdsoR0LjO3NGQPT4otzVo57/QIG1kPOPfh5P6lr1kPOPfh5P6kF BaVIdStRStBWoTWjZDqEPh1pU7eRSlrl+qm0Zdu31JvRw0ahFlNcT0Y0Kr8r36xvFKhCsoFK EIBCFKAQhSgEIUIBCEIIQhCDncdwn060Wwo0c/TcEXB/jci2rlFeO41QNrIece/Dyf1LXrIe ce/Dyf1IM/aPDagmhPZ204pjQsL+LmfgVxtPBjjfNM3xKFrWsJIGNcTTHCnvT2nNjbqcXg4M NHAVrSrK09ShOfGG4UIQpQlC8lwBAJxOxekApUKUApUIQSoQhAKEIQCEIQcZ2GQAA09q6xgi gdSvRgqrWHxuyRukYx+Lg2QkDnzG7bvTmmvD4s+YPzPeczdlSfp6PigsVkPOPfh5P6lr1kPO Pfh5P6kFdoIkzOcx+UVGAYHFxxNOIFBuxXPR8NSZX7nbORXrRmxuD2vrmOWmVriaY7Muz14E VCjSG5NSY2hbRzuydowKDdqVCCcoqdyCr1WUVawbRilG61JAQJBnb7Cuc7zK8vO9KvjDlhdr nMd+vrnWTZprS9iu25onVptB2hMrFBklu8SRGjhwWssbsXcQfSjtjm8Ctddsub2evrxwZQhC sxCErdXzLfA4u+0Kql1KWTYco/FVu0jTX17bfpePkbGKvIA6VLXBwDhsKzFS81canpWkgIdG 0jgEm2U7+vpI6FCEKzJXahDIaOYXE13Fgyin5A7V30yQyQguJJDnNOYtJwP4gBK3rJbh5gMQ cC4FkjmBzWtp2j/VXdyTentcyIMe0NLXOaKNyggHA03VQWCyHnHvw8n9S16yHnHvw8n9SCs0 VzgH94MBa5z2yCNraV7xpjy38FOlyCXU43iuLjtNanKcd21GhljXOc5xBOAAeGjYTjWoOzfh iuOlPy37HNNaOd68CieW/XmbuO5FKi8dvAK6i5jeKONK4YqMxbpZVE4LicF7lcAacEsZVg9G Tw6Fyf0u48OXIdj8PWq3NVDXFhDhtBqplNte0sbFK3tz+uyo7xwamGPD2hw3iqoNQuPFmPBv ZC12uI4PXp2288Qq9xcS4mpK8VUFy8rF34dWlX+nOzQjoJCz7Sr/AEwUh5kq+vLn931OoQha uNX6nNLEG+ESCTsaASabsd3GmKatHyObmlBaS51AdobXCvTRI6nmlAiyOIruYxxIp9OY4c9q Z00NbC1rQ4AEikhBdWvQf9kFksh5x78PJ/Utesh5x78PJ/Ugo7C3hmDjK4NyEONTQlgBrl4k mntUtdHHdB0GDaZgK1pVuyvQU3oRdlkDC5pq3tRlgO/7yMOSTt4i26DZBtqceBaTuUbcVfT7 T9njfS/cmbWWS5cWvOAFUxp+nsJc+RuZhwbmT0enQRuztBaTurgvL3/06a26+XoXaS8KbUAW EObsOCQDi48StHqVnnicYxUgbB0JKytxAKkfyHb0K/r92u2uYmbZ4c4bKQCshDRwOJVhBaxO wJJ9S8PdVeWOocNynvU3W2cr+JuSMNbuFBVZq5t5IXEPG3fxV7FPSBr3bzT3qJSJBR2IXTds yfpyaZ1tZkr0E/PaNrUYJN7A3eq5a/8AXWBq09vF4UTWbwPeqbS7YzSeI7uN95/0V+ttJ8ub 2b9uOAhChaMVVq8AcWyBmZwDtpcBQf078fcUzpJaYBlAaMzqZa0OO3tY4rjq+YtY1rgCSaBz iwEjHb0cDgU3Y5slXuDi5zndk1AqdgPQgfWQ849+Hk/qWvWQ849+Hk/qQVuiRh2Y0ZUFtDIz PxNBw2bdq5WP82oDO0Crn1a3YMClrHNn7Dyx27Lv943e5MaOyt+xvEuGHIqm8t1snKZ4raAB ow2ALkZsejiicOiwJw3FQcuXABfObeu63G88u2Yvl0jfWtFxuog5viN2/FLtYWOJY7vOrl4m noTyXaKQNIjBqQfT3q3W63trU8XMKxwySEUFBxKZZatZ3jmPQvd04MxSsNzV2Vd3rveSxe7W zPBi/d4NuwDCp+aQtLsk5XKx1eIuia0bR8lSwRuzigxXbZiqevF1tq2lNW1SVrZvu38Ix3nf L0wVwy1GWsmASc+txQdiFuamHAK01+a497MraKJsTQxgo0L2snL5iugey1gHInrXa08yuJAu GCn3M+S1m0ZtKheIpmTNEkZq07wvaslXXEoZI5tzG6SM0dGRHnAwxG+hr7arvpzXNi7TclXO c1lAMrScBhvovV08sZmaaUPR1rpbPdIA5284cvUoz5wt18djiyHnHvw8n9S16yHnHvw8n9Sl VQ2hox+3ZuPRw3rtoP8A7oeZ+BXKz7jz6bCu2hD/AD4uZ+BRLfOaHCjhUJR9g36DROIWe/r1 3+0TrvdeFJcxywdprTgKYY7fh079gSNjFLHK+ebDNSgOBwWpJA24Li+eD6ns9ZC57/n1xddb y2ntv4Zm/vC85WnZwStrIRK01+ofFaOVumSHt+ETzAPuSE9rZucBakl+2jcWinNX19U0kkTN 8/C2ummSQMbuC9RxRwHDF65+I9ozEULscy8CUNxKvtfn5Ri2YnDvO4lpqsnM05itDLdseMoK rZrepwWcrLfSxUvZVLkUVo+3c3clDbukcGsFXHAAKZWTvpV3cQyhkAz5trNx+XNbME0FcCq/ StMbZR1djK7vHh0em1WK6NYknctkqHA1oey0NqdnNdrSob2ttccKfNcbrxN5aGV2mtR6wV7s SCwUoRU4itD7a1Vf7N79Fish5x78PJ/Utesh5x78PJ/UrsVDaYseN1OHQV20H/3xcz/aVWpv Tbj9a4ZNSuWp9dCmUtzqOqR2Dau7T9zB6YLMu1+6uZMuYMbwb89qVmuDJmfIak4lV8JOeqzt y064w0Gdz8XuJPSUpcZVw8ZKXNxXshYzW2tbtJHeJuZ4WutbT9a2L3d9w9gWb8u2LryfxHf9 cfad0ncPTcthqLstu53CnxC2mvyy7Zsju1oyhpGFEncaeH/9bsp6cQnWGrQeIXpXslVm11vi qB+nXDTsB5Fdo7SYijm+8K5QqdIvt7btOtVrdPc7vED3pmC0jgNWjtH6t6YQrTWRgEFCCrJL XHjf/OmWnCp+Xx5LpagAYEnH6vQLopbtCjHnK3bxgwsh5x78PJ/Utesh5x78PJ/UpVZ9ti91 v+zmaGl/hUO2tKqLi1kspfDmFHDpBTFlOwsbDOD4VZO1uDnNDa/8etM2z2X+oReKA4Oa1rwd hIZTqRKqMlV48SmxbG48qWshrG50fLEe/wCaWHk5lcZ3U/oHzVeq/ZlvFJTFhpk2oyZIh2fq edjVrYPKtnEavzSH8jQe6iuY42QtDI2hrRuaKBJEXbLlZWcdlCIItg37yeK8akwyWsrRtyk+ zFNqCA4UOw4KypPSp/HtIpOLQPWMOpOqk8tuLYJIDtilez1K7QoUIQiAhCEAoJoK8FK8uFQQ N6E58lIb9s0Lp2tdlbyqaLvaXAuWiRoIB4pRtu6IRCJwLGdlzcMc2/2puzg8BojGwE05ElVm fltvNMfx/Pg8s55l0ya98N8VDkDgQemnyWjQrMXzuMXlg0sMVW1riK4+rkvekyCXUonBoZU9 0f0lbqXwvroq6T9PxBl7/wBOXagsqIoVX/xb/ER/BvzoLChUJD/G/Jeh+r0oHVGYcQlB+p0r 0P1EFXoxyXV7mwaZARXCveV2ZWfcPaFyH6q9f4vQg9eKz7h7Qo8aMfUPapH63QpH6/4oPHjx j6gj9iP7viuo8D8VP8P4oOH7Ef3e4/JBuI+PuKZHh9CkZOhBS/o2o3v9PUn7XIwCOOpA+5Od noXoU3IP/9k= --------------030407060607010708020801 Content-Type: image/jpeg; name="prod_image" Content-ID: Content-Disposition: inline; filename="prod_image" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEASABIAAD//gASQ29weXJpZ2h0IERDSSBBR//bAEMAAwICAgICAwIC AgMDAwMEBgQEBAQECAYGBQYJCAoKCQgJCQoMDwwKCw4LCQkNEQ0ODxAQERAKDBITEhATDxAQ EP/bAEMBAwMDBAMECAQECBALCQsQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEP/AABEIAMgAyAMBEQACEQEDEQH/xAAdAAABBQEBAQEAAAAAAAAA AAAFAAQGBwgDAQIJ/8QATBAAAQMDAwICBgQJCAkEAwAAAgEDBAUGEQAHEhMhIjEIFDJBUbMj YXF0FTY3QlJzgZGxFiQzNUNiocEXJTRjZIOTotEncoKyROHw/8QAHAEAAQQDAQAAAAAAAAAA AAAAAAMEBQYBAgcI/8QATxEAAQIEAgMIDQoFAgUFAAAAAgADAQQFEgYREyIyFCExQWFxgbEH FSM0NkJRUnKRstHwFjNic4KhwcLS4SRDU5KiNUQXJYPi8QgmVKPy/9oADAMBAAIRAxEAPwD9 U9CEtCEDvG5AtG3JlxuRSkjDQFVoSQVLkYj5r8OWdCFWUrfWY4ywwzFp8GbN63qkd15Dde6Q 83OA5TlwHuuM63tG63xkroitvUGXeLcCo1I4cmudAPcMZgGlwiZ88KvlrS21JIlKr1cdCPIW rTldPPjCUeV+zC/5awRCOuWyhVRvN6V0TYS4oVBuql3VPakMtvy5cCcGYoEvdEbcLLyiniVE Ue2oymVFmruOBL79kff7kq+BNN3K7bWvB656JTrht64JFRplXiNz4Mpk3CF+O4KEJoiqiplF 7ivkvbUuYW66btlcKk0So1gxRfWKguff9J/51ot0Vh1KY4/6oEh430FCJlCNXEFVVEJR5ZRF VFRCVMLhfhoQikeZKMOQyHE88ZMs9uy9s/HQhcHp85vl/Onv2OL/AJ6EJq5WqkgpxmPf9T/9 aEJm5clcBcevOJ9fJF/y0ITN68a+HsVAl/5aaEJkd+3O2PJJ37FEf/GhCbPbl3aA8hnN/wDS FdCE2Pdq7Wh7zGVX9QOhC6w93LoPJG9HJO3mwn/lNCEYh7m1940Awj58v6PGe2fjoQizN+Tj aRx5WQQs4yKJnHn5rrd3QtfOlkkHHhbRSDc8mYHUBWzHyyOFTKe7KaSGIlrAWaUA71J4xk7H acLzMEVftxrZbrroQloQloQloQoNvYuNrq9+ra+cGswQstXrYca83LTqEyQUZuhT5En1hp9W nUR2K6yTIqioq81cbz+r1BzRPNTzb92qfEn5zDbDNpihNq2Tb9Drx1CMMpyYwqtC9JkkRAPH iiInZMYT4anI6xJgGurUfLhHjrxxglXCfVpGclyfZcl/PhGH90EqNrRCSr/0jrOh7qWNPpLl luVWsOcW4qsw2ykG8vFAFHiwrI9+7iEiJ79cYwnJVzDVcelQ32jjw9PPyqyToy78jeBLjYvo 5RqHY239rVurFNkWtR41IqCgSA0YlIOVM6bipyITFx2J0hQctSDLlhMa7XbaSqwkJDqo9S/R qWlOR3qFuE9CJtyM8o/gNo2zJhmODa8Rkjjxx+quF9p09ZQiDPouwEedOJfTkMZMdmK56tSF acAGo7rQG04MlCbcFx43xJVIRMj8C8s6EK8LKo9RoNFbpM+pU+WjAADfqFK/B7SYFOovT6zv tmpn7XbljQhEJX52hCHO+zoQhsvQhDHPfoQo/VqtDgTIUCQMhXagRi10mlNE4Yyq48va0IUX XcG1X1aAJkpDdjpJEDgvIXTUeWVTj5492hCaz7toMY1afkSG1UUUVOG6gmijy7Lx9ye7QhM2 ropVXpsgKBcQx5LZNoj7kNwxbVSz4hIU7YRe/u0IT167pMfnUGdxKLHhxHcyOpSnF8PIlTA8 V80VEyK99CFJ5tKotTmg5cHTqQ0+mR55qTQiskEJ0SwI9kQiJvP2ap+IZNmZe0T5KEn9pTLb Ckx6DTapSYkcWm4dTNjiHs8hZY54z37lnUjh9sQZsHZgn0mNo2Grfhf7HH/VB/BNT6ervoQl oQloQloQoLvb+S6u/qmvnBoWYLNVys0+TSKe5Oeig+wSuwheIfG+j7CJxQlTOPfjURVtXQfH kUfOzHdBFArWh3VHuR5+vXNHkiuASNGjI02juE7qqpnH7dSk063LDpXSyFSANE/a0Csg5cd6 My6y8LiNGQur+gqIi9/s03lZ+XqA3yrl62flSlhsLjVQ7n7lbo2HuAY0OglULcbh0/m30D4t yyjVFx1DMQUkbJGG1c4qhITIoi+LT8NmxaNt9xsuTyDvbuJJNisBTbdj0Ol3LHosh9pqUS11 koMt4XIpOLxaafcYaBlU5eNwUUiTKaSsIUoYNtCNikO2e/V8XheNOocqz6CtLcqDNOkVWAUr pPE/HmPC/F6goKNtHFRpzmRZNVxxTGspNaLh+Ljn36EI3GARFcfDQhNpX52hCHO+zoQhsvQh DHPfoQhslSQVFCJE9+Cx/DQhD33XFHxPOL8fEvfz+GhCESCXmpl3Xz75XvjH8NCF7AcMvDy7 L2x7tCEaCqUiAcKHUqpBiHMeSPEakvttq++vkDSEqcj8l4jldCF8TYFiXccYpd1R+pMeWite pVkB9Ye5czip3VHHUVMq2niT3p4tRc/h6TqZaV0vj1Js7INuKcWJSqVSKQbdFqhVGNLfOaso pIPq84a4JUMey+z7vLW8hTWaYOiaJKtS7bGwrQhf7HH/AFQfwTUilF30IS0IS0IS0IUG3oHn tjXQ792W/JM+ToLqDxDVCotNdnwG6IZb3OUIfinchL7rmBa8qzU5V2ZENI0ik0+QsY8tOSG0 Imy5eY5TsuUTXHj7K846zfuYY5cF0LslavkvK3XzGSHiRtK455KpqDmCFS5JnkiChZyOFz27 e/VSrOK65XGyKacIQy2IRjAf7c1JS0lIsajQwiXlUjt9psKc5xHA+skqqg9/ZDvj7NdT7Ef+ lkYbWfvVZxA1dMaLyqBXjunuku5YbW7RwaaNThwxmTJc8cBhQ5YDkSCgj27+arrqEwRDqBwL mFXq88NQGl0wYRPL3csFZm2V2Xg3S2Kbu7VKHTrrOQ42xHi1ABV+MvHpE2HNVVVVD9n4a2bj YKlabMPCItVLUd61YI3HRwqTdBmV6GlRl4VmE5MAX385VMNkWSTsq/v0pepE3WWnNEbmtBeU vcrbufXFtqHf1uyKsHnBaqLSv58/JD7+XkirrUJhtYYqMiRDa9CKiFtekxQKzvhXdszmUCFb tIpgus1x2ooqT5akz9GCqqNoiI4fZF5ZH7dItzF7lir7WJGX6kUndCG97lZFy3zZNszY0C5L wotLkTMdBiXUGmTez5YQlymfs04vVhmqjLyxCw6UIGuVQrdGhSY8CdWqbHlTQ6sRl6Y2Bvh5 8gRfaTHvRdF6UOYbYcEHSHfggbN52ZU4lQnQLwocmLTP9tfZqTZBFyuE5rywiKvZFz3XWsTS G7ZW4bnob3Cqk333pqdg2tbl4WA9RaxTKrUjp8qQZddsMAhJxIDRELHPsqaTvUDWq85LNi7K 5RC7LP1KO70b+V/b3c1i1qPTaTJokaNBeqsh5tw3GEfNUXBCaImAwqZTz1jSptWsTOSNQFpg YRE7ejOKNPbkV2Rv3K2phwaa5RmKUk9Zacuvz6XUROXPigryDz92s3qUOsuP1YZARhAIDcUe j9lIY9wUCqyjptKr1NmzAyhx40lt1zKeeEQs9tLXqTanGXe5aSF0V9wK3b8d4mp1cp8dWXgZ dRyWAkBmvhBUUkwRe7trUj1U4jNS7XctIF4Rh9rNVFErN9bzxrptKtvWuxQ7fudmLUH5uYMl ung44vFh9BNG3Vcba5OLwXjlBJFLSDTt5KvYfq5VIps5goALZfq9y+XNgK9HoLdSK+ttYDUu mNW2zUDkmERjohEQKsySgnUmmsXxgCp24fSLx7uiO3aVgKclWta6HSr29F+jXjaNnSLXvS5L XqUSPPSPbL1FmdVp+A3GZAyFFIuKK4Jn0/aQicUva1ja1kE62XdRL1LSsNf5oz+rH+GsraBX LvoWyWhCWhCWhChO8/5Mq7+pD5oaqGPBuw+/9j2xUzh2H/Mm+n2YrHt3tT5FvSotFh+uVNw0 OBD6vS9bfaL1hGOSqiJyBhzKquMIWvPVAho5y67Nn+7/AB4fN4laK4OllyACyJQPb23Y8e8a JV/oZbLkCqTIs1lhuSDzr4Nsy3kkEKmKLKZkCgi4P9OHhNHuSWbEcyJSUwI7Op5YeW3V9XDD +3jgsOy8w1aLu/vxV82546Yfhz9MWU5f3Q9+rt2IdSllf5fesYo1XhtVe7pbRXRPutndXa+v FCumNHETY6nTWagDxy2SpjkqdlAkwWuozA3kuT4hos0U12xpbmTsIZlxcXPBVzfV61bdDaih b0uU9uJdG3tebg1A2GuKEDnBxt4U82/GmFHyQlLHnpKMbW7/ACKInZx6oU9ioulG9lzIumP/ AGqZpT5+83pBbh1213m+tRLQcgUiQ2YiCSn4yNNohqvZeb0hUVPJNZYEpn5pZaaer09Mm0X8 vV57RQf0dT2mtm77esPdbaqp2/fUOcIwKzJfeFt981JGxcaI0QUXPBCAVBfimtGxENRJ4eCR lJxuVnGIi6Ud7l3/AEVJtstmNrqv6X9+WBUrLhvW9QoLcyn0/wAaNRXxWCqEOCRVXLznZe3f SIBa5enMjTJf5RTDRDwD+IKu4dQt+9rk3hql8bY3Ne9frEyRApU6nU/1kKUQq+23yVTTp4UW 0TiirgdOL1ENmMzMPCbJGfF93Ivl+36hc57A2fuNTakwRyJ9GeYktnFkLBScAgKZwYoolxRf PjrXSEsxg4+5ItTQxhmHl9NSy3Nkts6n6Vl0bYyrb4WrTKa1LZpbMx0Q5I3HVEIs8nERXDVM l56xElLydDkyrz8qZasIR/FVxGpAPejTuQ2yPBu3r0hSYraGvgyLjBInJfeihldJ6yjJUBdo 73HAXPu1UdusI1+29vrecbkaRI9EFky7+FgmhPGfqDRaSUlpgavKzc60PBBq3oPf+5CriuGq vP7qXhSnnG3HaLQqUEgc8mwktx+aIqeRKLZp/wC3RrJJ2fe3PMzQeRsc/XCKLbnWHae2G3di 3rZlJGn12PJhOuTGXCR2SrsYnSQu+PNPd56VuUhO01mSk5KaazuPL8qkVB26tW//AEhtw0uq DIcSnSIc6MDTvR4PL0+5YRUXjnRrGKXpFPZqNVeddz1NH9+fuVb1+sTxh35RX3CiUW4NwGI1 YqCCpKy2JyiFF7d8qSkvb+zHSA3CWuoESbEX2LbA0kLo8msrk9JGw0odS29rUSwHrp29tanO QZVJhEaAGCyhKreVbQm1Euoid/eulp+4bdVT+J5AmCZmGm72YQhx8kOJXx6OibT1vbel1jbK 3SiUeNPlOx4k76Z+BNIvpxFwlX9Lsor5Lp2xDuatlIOTmZMSldn45FoeF/sbH6sfPuvkmlFK pxoQloQloQloQoRvOuNsq6v+5b+aGqljk4t0B8x+j7YqXoP+oN9PsxWN78t6Bc1tv02pViVS 2uu26EuNyUm3FJWkQgFU6rZo+YGHvQvPXnTC85uacEWhvz4YR+Nr/JWquSm7JMhuyy41HbTq Q1qpWI9xtnn/ACdmuesQKe62rgKshpuOzlUFhr+bo70VFcqLvsqKcrDXmhalZrh3zhvZ72fL DzuXeTKh7LYeTeVz2146c5gs83y7r3VciGug9ij/AEtzo/FR+KhEpob1D7ytz0gJ1zz5e3e4 lNhUepstMjEl55xFAOJE2StFxVV8WunOtOLmlWlappiCSc1I73xvrnbu3u32z+ztfsDcG9Ke j1ywJMuoOOuo0ryo2gh6u2XiJQJAVMd1Is9tJhC1lwCTUZCVplLelZpzXOES6YZ/qXL0SLOq UfY2v1ij1IqTWLsdfSFOUV5R0aDosuJhF7I4Ti6UlhJpu8U3wlKzUtS3JgC34/ujcTYHey9r 4ta4d8dxqDWadaEgXorcBokefVCElEl6YIPIhDJFnWbE4hQqo5UGZqou7Hx5UZu70e95v9NN c3d2e3IotAK5Y4tT0lNOE+2KgyLnAeBCvJWGyTumNbWJSaoc0NSKflXNrejzb3LyJjX9hN09 ubyuq/Nld26La9IuRz1ypNVjINR3FNSM0IgIERDNVQi445Y1rYk3cP1SUeJ+QfhbH48qfVHY rcK67h2lvOs39Br0mygV+p1HpOn+FMykeEmCEVDHBOKZLGixKu0Bx95h10syCHD6/en9q7bm m/Ff34p10UmqUOtwXaYyzBcV5wHmOm26imKK2vEo5oqCWUXsvlosT9ikaKpPTt23BQ23PR9n 0Sw9xdrZ9yUmZVbxdSqRgbaezEZVxUB5wCFFVOXZFHz0WKNk8PaKTelfP/Zd7B9H2r2htjd2 3lcqUWoS7tJ/+dMxnRbwrKAOUIeS8STPhRdFiWpeHBk6a9IeMSjtg7BRYO21y23cF0Q621dp RzbnQBLgAMBhkh5e0qEnu807aLE2kMLCxIusOl84hjWx97VI7dom4m4kWp21a8hHosWLDJqQ 6iJgRcIkRERE8Pv8OixDWGZhxxpp1/Ub/b6XIpxZViSqBuTdl+SKpDdZufpdKM004hsqCoq8 lVMLnGlAaU3TaN2vqD01pL4Rs/xQeJ6OUifam49uza5DecvSotVSE4LB8ae8064Yqefa/pFF ePu03NpQvyWIG5kS/mxzh/l+pSSRtRv87att0S198ItKlUekrR56pDcNqcCOZB1VIFXmLeG/ Lv55TSjsrMF805n8c6eTtEqD7IsNP8Xx4ytDYTayLszt+zZgVhypmD706VNMEbA3neKKgCq5 QUQE8++gibkW7ppyAdMFJUalFTZfRXRM/jnV5QSQoTBCqKitCqKnl5JrYHBdGBhHOEVJp1pV CWhCWhCWhChO835Mq9+pD5oaqOPPB+Y+x7YqSovfwdPVFYz3GapD9h1+PXpkqJBOG71X4jfU kN4MVEmg/OPlwwnx151wxpO2Qmw3C/6R2jwRV1reh3D/ABGdn0Ye5CrIfptxrS7it6mvQ6bT vw3Sz9bEmZCdWa48LANdFEUcq2an1OxN9Pgup7FTrkppJecchEzgBxsyiPB50I8PJb0qPw6U u+yLrAxshva2cI73OretzxQHeQ4+ncyidseENdG7EZNu08rfjhURigxJ4VIYC8FQk4/ZxTH7 tdbIyJV2wvOTG69rdv8AcdYTl7W23U3aflIzvVNswEschyBJlFwnnpApcXdtMZ+ky9Tt3Vv5 eTeU8olNptIgRqZR6ezCgw20ZjRWR4tstp5IKaUECEbAT1qXFhsWhHVgpBDHxpjw+72U/wDG tLvoxS0Su20aZbbITQ2xLn3XIouth1uRJaPVtUF3qsafuRtpXLGpUyLElVVIaNvygFxoEals vFyEhIS8LZ4EhVFXsvbSZ6njLcRtG1UxUvRduSmvx2LJv5yFAgVVomPWqrOaciwm2Ywg4DbA i11m3QmEjKCLK+t+Je2siJI0RecojR/RR3QtmlrR7f3GhsR44QvUIzNVnR4LJNSG3TbeYFgu u1yFxzHMFMnnEXj7et7VgmLB1iTt/wBHjdT8FuQx3GhvsBIk9KO7VaiXMHXpLjLrr4gBuPsq +24KoIiRMgJIQjz1kRHzvuzWB0YlfclI2Bv6DUIsmnbmMgK1yNWqq7KlTuq/0J8ySDjaJyRo kYkR2VEeIfRYzjzzovNz9STdJsnNrfVjWhQDtOz6VbMh5t1ymRuiTjWRE8m4SYRcdk5Y7ppI hLl/sSgMauoS7PJ3XgP14HKaQfmpeW76eg36UYQ61s3LPENgN8K9idTKGQ4T3p7l1Az+OcN0 oe6zrZ5+aQxy6IRT5qkzz42C3qwRhmosxwT6Pkvw1z2pdm6gyZWyoxd/x+/KKmmcLzj+2WS7 pc8wMJGZbbFPj4sfv1Q6r2dKw6NtLag3zwu/LBSkvhNsXL3UPk1GdMLMmY84KeSE4uPsx5a5 bUcV1qrldOTJ7/FCMYfdmrM1T5VrZbhnzQWgbV/Fmj/cI/y017TwhGJYdkCL+i17ArlNShbO vekXWi+rEmSWhCWhCWhChG835Mq7+pb+aGqjjyNuH3/se2KlqBb2wbu5fZisb7gS5ECyqzKh 9FJTTPOMTo8gbeR4EA1RFTPFV5J/eQdec6E0L9WFgx4vLbxErVXn3mKTpWi4OLK7yLrZtReq 9pUqpSakzUXZASDOYw10m5SrJdRXxBfZ6uOquO3JxdZxBKixPOMBs5Q2o5x5dryLOHJjdlPF 0srua1WBa7JLS3CEv/zC+WGntH7Iz2DJMWgZzz6M+m2PlWs/Rhni1UeZd6I8vf8ADVjY/wDU EP8ANkP/ALY/oTD5Guf1E+Zq/Rxlkj+wkHH79SH/AB8kS2paIcx3flgtCwe8Ow4ica5YYdnW ZSL9RJjT5js9UnxmTWPkfMf1ETj3zSG/EUOYqp7umP8A505/454d81z1LX5KTn9SCet7j0gQ 8FNmEvwURT/PST/Z2oLQ9ybOJcsFn5JTnjuQTdzcSCaLwpcpP/kKf5rqPPs8U0v9vH46Fn5I zH9RMHr2aMshS3vq+lRF1qfZ9lxG0JLP/qW/42JUcIlbruJk9dLji4Cmtpn3k6qp+7Gol3s/ kWxIZf8AU/7Es1hIRLWLVTQq7MLwmyy3z8sZ79vr+pNR0x2c6xbfLswD1foTn5MSqZHPmGfh cEPFlET498r9uoKZ7NuLX9lwQH0A67U5ZwvTw2hXAyfJcn7/APH3rqtTmPMTT12lmThn5ucP ZyUg3Rqe1sivEIV8XbunZfq1VnqtUH9WYmXI85kX4p01JMteLBeLjywqZ8kT/wDvr00uEtrW Ll3v/KdgIjsr32fLsv1/u0mette5Z3l8iTR9x4r9fn56zHSD4y1ycX2qY9oca1CHjraC0Pan 4s0f7hH+WOvfGD/B2Q+pa9gVx6qd/PekXWi+rGmKWhCWhCWhChG8/wCTKufqW/mhqm49j/7d md/LZ9sVLUL/AFBvp6orH93TIEa1au9UbiKhRwYNXakkZX1iDy7uo2iLyx5fYuvOFBa/5sye hjH6OcfJHj4Vb6seikXg0kA6Ifim23sn1yxKJI/CzlUHoOttzXGukshoJDoNnwwnHIinh92n WJmtFViG2zejvb8etN8NHpaeJ6SB8sModSsq1P6pe++F8oNUbEnesv0/lVhktokY1UlJJaEJ aEL7ECymlUkunH69FmlWkStXUGfzSHTtqXWl66eq/wB3TnchLSMxkugU4VNAdEVBVwSLnui9 vdrYZC4rSSbkwVurwqm5N6byFUG6PG21nOtNSXnH6i5BlMifCr9FttEFkhcbKIoGSj4lDmoq qiur8xhmgk2JvzEIb0NXP6G/40PG4OXhVfKpTQ3AAofTNwd9nEaCRtPKU5zzbrau0yUDUFha c06YGqFkuEkuGVJV9tFxx04msJ4ZK2ybhAYQ8vCV3P5vxvpBqsT1uu3x/HEhkXdveGqyqxR6 bt3DWp0N1pibCGlTTUHDgOvA4KkYtkBOADaChc0JxEx35a1jhOgsMtzDszqHs68NbXgPUlO2 88Xi6yLt1vf+Q5IpQ230FcSTyqMmnssqwqvuKyLPCUoOKLGBU8Y5d15cdN3KfhIXr3Hcow4r +Tm4yW+6KkfipzZlU39k23LlbgWfDiVOG7R1jsQnI5Py0GSz+EEQlfJteTCO4VSbXl5e0mmU /L4XGebCSehEI6S6PFsx0fLwpZqYqRCWqgtJmekrSgej/wAl49RZ/nCtuyJcU3hdMXBbRVKU XgAlawg4w2BmXic4C+mJXCb7Ym49AI/R6OTh4ftb3AN0WxFVmiuEV9P1z0lma/HoiUmkmjrD kn1hqkAccgV5hVaJ7rKAmDayFDxeNRDPHl4dRksHnK6W6MOLb3+CP3Z5ejyrLUxUCLWVgbfh uIMGpruKFNGR66pQfUWwAUjkOeCoJFniqY5qvJffqm1uNH0jY0vPg1t/P45lPyOm0ndVrK1P xZo/3CP8sde1sH+Dsh9S17ArmVU7+e9IutF9WNMUtCEtCEtCFCN5/wAmNd/Ut/NDVQx1Aiw/ MwH6PtipWh29sG7uXqisfXNMk0+3qrNhzqXDfYYNxuRVO8NtUJO7ye8cL5e9ca810GXF2cbB 0YxHPxc7lc6u/bJvaItb6UIZetCNr7hgV6z2XodSbqBRJD8eRJjxjZjuPKZvF0BNELppzwiq mpTF0ruSqWfR8ufFx58flTDCsxumniX4ZdXEratX+qnfvhfLDXPsQ60mx0/lVlkvnCRfVSUk vB1kRWpRtXQWkJM8tZtWL11ZAz78fLTgWkmZWp41GVe/H9mn0rKkRJqZ3IhHieXh1OsU65NT dT9qBy/N1Jt00iTMnV0GC2ZcHGxUF7Ei9uy+flpx2oSZvkI6nCqXqE/0knJUlilWXDcjnJqH QkyKewyTLLTihG6grM+kUw4OIoJj81URR1cToVCBkSf2tXjj8fHGohudmhJD7rZ9IKl7ly4t ux3Jlv1asw4NNclMQ5EZqIkEnHXgETA2vpANHCcUlXkAtgflrI0vDL8mOlHIoQjnrlw573H5 P/0kjfnLtVDGoHpQepQGXihtIwDSTknPxHnZTixFF0kIZCowiuNtinREU+lIsZTUTPS+D7uW GzlGOW1vc/2ko3u65Ngh+kixQDjx3Ka1UIDaiwyrsMkfRBgiGXnFcJV4+umpEuVJvuq5HUQ/ 8lovEbpa0Y8v0uLMfo8ClW4VC7a+PUvq3138g33RaddUh6ZQJz8l6XJgw4TjDIg1hth1wW0V sFXBCqYLlz747aQmxwy5JPHKiN4Q4yK6MS4x1v26VtdONvNiRcKthQVRVfIkTGPhhdcxiQ6T kVnbMtkl98yxheWFXOOS63iZLbRCvMe/34RFX441hvaWRG1aItT8WaP9wj/LHXvjB/g7IfUt ewK4/VO/nvSLrRfVjTFLQhLQhLQhQjef8mFe/Uh80NVDHd3yfmLfoe2KlqFb2wbu5eqKxlfr 9Hh2fW5VfjyJFPajKchuM70XlHqCicHMoja8lBeS+WvOWGN1dsm9E5oy86PH90VcK9ucqa9f rj5nHw/HHxJttk7VitkzrlS9fRZRrEL8IMznm46CPEHnmkQSNMrn87UljQYDVtm3ej0/S5iU bg63tWNpZ/hyfZVrWn/Uzn3tflBrnFf7zZ6fyq1yO0SM6qakV9NChZzrYVoa7NNkq/VrdJkS fxo5KmNT8nL3JobifSHqfR4oSqjKbjgZo0JuFxRTXyFFXtlcYTVrk6YKYRib5WNKB1Df63IT qMwKZImLw5oajwFUVlST7FRzAKnw76sMtICnjdEm3UYpW+NuOP8Aq1SgvRUwqq5xyiYAVTin mqkamKJ7kHUgDDYlYkJrDs8wNytSnHCng3PhyGX45OKgG0aEK4JEVUVMouFTT9pgblVHidhq Kgo9j+lFTq5VVpt3R0p9SmILTc2YxKGPHSWbgq31BJRUmi6aiiKnFBwiLhUtDo0XQiMwOt8c qjYuPXJUu0vSNq1pVmFuHKgzZEoKFIZjR6i3TDkI1I51GKj8MFJoTbEBR3lklXGBTTWEvRWb XdDn8c6UIpoy1ELkWB6UbINy5O5UEChc3FixjZNJCI24XFf5inLkfTUBQg4gvAlIslqtzDmH 2tQ5fr/UnrUZxDqdYvpBTaPTgr24DMWQ3HYnICzC6zEtSZVGXlajgLggguEWEQTJeHDiKOar k3PYZlJhyxjMuD4zOO/1eVPmpecLxk8suyd06FVKdPu6/wByrx2mHmZkV2YRtqqx2BbUU6QI pC6MheRJjgXfxeVbrlYosxKkzLy9peX1/SLkUpKSr0HhN0lYK48SAOPqTXP4wLVLggrBqiQ3 Ja1SyXw1uCytD2p+LNH+4R/ljr3vg/wdkPqWvYFccqnfz3pF1ovqxpiloQloQloQoLvXhNr6 8pDn6Fvt5/2oaqGPIXYffhdlse2KlKN38HT1RWQrumSIe31dmR6g3CN11hlZDgiTUcCXiTpt nkVQEJS8XbXCaC1onC1eHxFaK73uSHbd02DR7WjjS/UVF9ySbr8FpG2JZtyHGUfEU8KdQWkP AeH4aZ4jd0tQH0fVvcC3w73iKtG1P6mcUeyeuL8oNUfEnerHT+VWCR+cJGdVNSKQj3TSZbSI xROIzzT69SktKkSYunkjMNtuKCyJTgtMtipOOEWBAU7qqr7kRNXSnUvWUQ85kNqzhdm4bVdC ddlVkOMUwA+gYXGUjguQEu+HCU8kip7i1c2KeQ2q50qWGVlb/GUVi1V+txpLoslTj9UecY4m ou9RQLCrjvlMafNyosPDalTfF9kiVf7R3fK/0ZUaoVecU9o8AsmQ4rhtovAVXK91QSXui/m6 mcQ0vTzBEHlTSmTtza0x6N19uRbuOzHp3OJVOQMsERmrEhsFJABF7Ngooar9fbTaVaK0WlE4 vkR0YzQcS06bIEiKPkvdNPNzrn65OxkIe3fTd+XSzR2ofJY93v8ALUFMS+0nrZqO1JpsEUnC wg5TK9k7fXqn1GTK1Ssu5dsqOvCyKmTTgmnbOCz2Xunl9uqdNNON3KUbiRENyYHyE11XSEjJ SFokKWsLZL4a3BZWh7U/Fmj/AHCP8sde98H+Dsh9S17ArjlU7+e9IutF9WNMUtCEtCEtCFBt 6E5bYV5M+bLfzQ1TcfiR4dmRDh1PbFSlGIRnm7uXqismVmNJmWVWIDNShwEmGLJyZbCOsNio Eiq4BYFR9yoXx7a4VSJoZNsTdzj7XuVwqMuU8JNNIZZ4T2bZpsOpDHKVHQ4rixWAZYTg64IK DYrgQUBBU+3UZWX2357StbOUepZozBS0rojVkWn4qI59+X5YaqGJu85fp/KpmS+cJGQHK99V ASuUhenDLXIvEOdOWJcnXEiZI1TmQ9r9ip/j/nq2yDVhWmox8013LeKmbaXMkci6xUqWjZI0 jq8kaLtwJURc/BVTOrZLujLTTbR+PFMGs35gSWOqXTG7gtuj8CFuI2LHNoeCpgOORwJkHZfc K4Re2e2ri5NbkeJg9ryrpsZcn5UbN5aRtv0Xm5tO9duOvvMSpQK4jEPhkAIVTBGQqirhe/H9 +njFLcBvSmWZLm83iFsSKXaHVVIbjejA9tPAi2vYj3K2pEhQCK86pmx1FRTNCxkkVU7iv7NN pmvORnCGdGPpb2Sl6PNNzLYtNDFE9tqF+DN5LEZVvg/NrnNOo26QCIR3TMOYHxAlETVOYqi4 XHfT+iPNz/dWh1Uvip3+BIfG/dbjkzoUTtMfaYRMd3FQfcvki9/dqZOLLfzpZLmoNuFsb64t VGmSlzCnR3vgjZZXsuPLTB12Xd2ChFbkDobYxQO+LigWfa9UumoNuKxToxPEAipEa54imByv clT7E76j5iVtG5OJKG6XhYDyrPQV+tV9tytXHVCRx8OsodXhHYFFMkBE7IiAhKKmvmnnqjzU 43NPbnaGMSXU5WRlac3vIfEr0cx9atutR3m1JR9ZiyReBcYRcKiqnZEQfs1FzVO3KJaceHgT xpiXmhK1Tq264lfpqzHY4svNGrcgfZBHExlA5d1Rc9u2qNWZDcbl4cagnwKWc0SJagEol8Nb gsrQ9qfizR/uEf5Y6974P8HZD6lr2BXHKp3896RdaL6saYpaEJaEJaEKEbzJjbKupj+xb+aG qfj6F2HZn7HtipWhFbUG+Lh4OaKyFdcJarYFapQwYMspptRkYnEqMGpJhFPCp2FfH5/m4/O1 wrD0wMsQiDhAXJ/4Vrq7JTjZaUbx5ULsG2IFrWwxTocGDGcdNXJawiImX3RJRR4VIl7GggWP cq41H4gqTlVqW6HSicYQiOZcO8sYdpzdMk9A0OQ53etWjaSf6lcT/jl7/wDLDVJxN3mx0/lU 9J7RI8IIK6p7KfJ3EHBpgc57ftXy1JSokbw2Js+Wqq23N3aSiJMi0yRmLCyDzzHjV/kBCbPB cYJCTsXJE+vXTqJSiccTuTpmUvuiYVLULeJdwgmW3BrL3rbkVxw21lJKb4K2rKo4rOUFUFcc dW+bopUxxuYd4oqYlYyEyPchyJV3tjuWtozf9G94C807HkjCjJIBGxDLhCHBrCAzGBtlXCI1 IyVzOrDWqQVREZpjay+OlN2KtuN4hfLMMlp6wd0a/HixIVq3uRU55tp2NHIgdTpPArjXHqpy HkKKSIv5vfVScmqvJloRFMpql0qeLSkKIXtvTadEpP4Wui6WZkhwY4Nr1UMWykA4Ucj4d0aM m1RXBFUTTIaNVq48UXd4c1FxJmmFlLqj9h5l3bwbvR9/GKb+B6XR2HGqOjzAK+56xFRCZ6iI iPIyb0jgXdU7ovHtq5z7o4Xke1slvlxx6cvvygmt3bNz+I2VpSsHKGlTqyEaVV58aO9JBjqq hynQAiFsVLKIRe7trm+lcqsxbMOZKUyGRHuQqH7cXRV78tGLdVyWNVLHqivG0NPkyS58RVCR xFQQXiSqqJyFPZXUjVpNuhvWSjl4olZjdjdrooduPvVSbusu5ttKPXm67X7ZlQJk+E0zIOQ2 01JaIx4tqCuqiY7Cae5Fz3zY6eM1ucXZ0dVyGQ9O9ypoxS2Wp68FFb4p7t/2RV7Up1acjLWY vFiWOSQM+JFVRzlFVMLjy8tVymPN0Wq3uirdP07dMrcBIR6O2w1y7W29XH7grUVxaxJZcbiR eRtR0aExN3xCniPknYf0dSeLa5L1wmRYHKzP78vcq/R2nKe4QFxq49vXWfw1dEOMQn6qsSPI IemuH0bJVElT6TKDjHNMKnl21zvF8tFppk1vNOaWYUyT6vLXPErzr34a3BC0Pan4s0f7hH+W Ove+D/B2Q+pa9gVxyqd/PekXWi+rGmKWhCWhCWhCg+9Wf9FtwcfPoDj7eoGqljnwfmPse2Kk 6N38309UVj272ZNSsms0inTmafJd4SWZjwZZjqHi5OL7hHjy/ZrgNAqrMi8JaPMldKlJOTzN t2S8tOjx7etyHQo0ht1mAr7TZNllBH1hwkH7RReK/Wmo+szvbCe09uW9HqWtGku18voLs99W JZ/iojv34vlhqpYl71Y54/lUzJbRI6OqflaSfRT5gkaaJ5UFFBUwqiuM596+7U/IiLVrvLBM XCvK1ZXcaod2yqrZ1zyikvNyZITWkdFh99rqcTIeOeKKpcORd189djaGYkWW51gdVW5wxdld Emrtv7W7UtuVu2aE/TWmoxNo07KB96QQ/SKAkqihLhMomnBzdQxC9Y7nbypKVkwpzXdMiJZp v23LjPcP+VrNF/1XXFQm5DMbgy+4hLzIgUiVF4qir7tdFpc02MroNJrwVPnWCKY0tuqmloXV Jpv4HZYnSG3HJlB9h0kVFKG40Oe/mnBU+pNPylhccu50pp7W00Ma1fECjwrepcyozPwXBaaA WjcMBN14RREX80V/Ymkm225InHTLj9ybu2kIrYlpbB2mdA22njOlR3LOZalB6k4PSlPEAEZO Eil3VQxyEsqKYyqdk5fUsSvOTU0wA5i553OpdiSbtHVUr3K3AqlJq8Chx6lKo1LWHJq1Zq8Z gHX2Iba8elGQ0UeqarlTUVVE8tR1GpUlPS+6jbgbufBHg+OlLPMRJvuW8obae8EG5apSJdpX RcFetm4Jq0hwK+0Pr9LqPS5gQuCidRoxROx8sKXZfzRk6pRCbZMH2wB0IXQs4MuLztZIyMuW jv8AFzU3WiUWLUZ1VjUOG1PqTKxpkkWkR19tfzTLsq+X26rrdSemWWbnI2wjD8FIiwzrFbC5 Udat7VWwqy5alVpYuUduYLcEG/CkVg5KMstimMCIMNumqJlVNe66u9QpTNWAXhLXy4Vlifca bt8VTJ/0kZUqlIzbNDdYmONphxz6RGiMJeCTKIiqBx21US7ELhe9E1GsYUbYtdeLPh+5Mjmd 0+LwK7NqqDKoNkxjqpEs2pPOTH0MzcVvmq8G+TmT4gnhRC8k7a5XjKoNzU9ohHVD9k0AiIlK k89UItpPeJe/DWQQtD2p+LNH+4R/ljr3vg/wdkPqWvYFccqnfz3pF1ovqxpiloQloQloQoPv V+S6v/qW/mhqpY5y7QP3fQ9sVK0L/UG+nqise1zpFQayDsMpgHAmI5FRxR9Yb6ZKTSKKKSKW MeFM45Y15qke5zTdnnroRgJNleSHWCbZ2PRTbneuj0Xk9a9aOSL+JTydQXTETIDxyFSTlxVO 6+avsQjbUyExy3vy8ibyA2N+VWpZv9Ruffl+WGqViXvVjp/Kn0ntEj4LwLvqo7TmonxbKJgy ZxnE49lBURfrVNTbbTgio4jHSCsub4bN1w7oW8LTbJHnHglPNCXFeq3yIVFU7KRESefljXVc KYvl2pfcc/vD0x96nZOZG7X2VXVh7Dbn3nNhQq0LzTbSRWjN5xTTmwBtqq5XyIHD8XtfHVym sRyIiW5eqKbOzNuu6S1s5slDi29Ct6My2/FjMBG4uii5ABQUyv1omuXzE5UN0E6OcEzGsNlq EOqo4Hoi2nXZhPT6XFZVVz1GxTOeyISfWg9k1ZKdUqw+NhbPP+6bzlWl7dQVbVt7Obe7T2xU ZlqW3FjzfVTbWUA5eNFTCoheafXhU1aJgik6bpXSzJVgppyceEB9SoCnVS4ntp341n9Ny5ab DdgRwlAqgktpSAVPkXllPPKjlO5LhdVKaKXamWXZ0cmT4Ve7XtDaI66D2ZYW6d0Wjb1evGsU mnX7R3JHPnER2DLjOkiIzLZaJE5KI9ybLsvx1IzVVpUtMaKSbzl4w4eDf9X4JMhmGm9baU2g 7b3BKqbVy3I5a8eTSoziUul0aG41AblL7L7xGvMsKiJ4UHty811HTFYZEhalxjlGOtnHxUi2 6803ogUV28Ld2mWZU6rvW3S1qcSQ86ysBpvPqgCipyRvIrkvYXuWOy99OKh2sfmm2KVvjx8W t0wgn0m4TTZFMKB1Kv2HS6HQ6hfleotIWpOq5TnXeYLIAlFxHVbRsSaUeeC5CmPfjUzLy08b pMyYxPR7XJ8ZJXdjbbInMbwx4FZW3W0tsuVkHg9V6LSNPMNAQkL7aIrgk2qKquCnPPJO3i1X 6pW5wZewOLPNNZlxtobx41dkpAFFBoRQUTCInl21yepXGV475RTZhMtV9PEvhrcFlaHtT8Wa P9wj/LHXvfB/g7IfUtewK45VO/nvSLrRfVjTFLQhLQhLQhQfev8AJdX/ANS380NVHHXg/MfY 9sVJ0Xv4Onqish1FZAUmqvRphQ3GocpwJAcuTZI2aoScfFlF7+HxfDvrzRLfON+n7l0JzZJC LBkDKsahPipCJxS4NrJkvkwCPOILCuShB9VbFEaXqihIrePLC6kcSDZVXA5/JDi+jq+pIyHz atGzD/1K4P8AxpfLDVIxN3rL9P5U+k9olIw9tPh79VOX+cTzxVJacgOiAcey+/V0k7SGwlBT BEJJ2VBhzDUjHt8Ps1PS9IbLXSG7XGkRp9FgU8foI7YquMqn+OrI1JMtbCZPTbjvjIgLYlhE EdSkuw2RawpteSeNMoKZx31LNaNrYFIma51iJ69RpMPjnqtk3j7ffoqTRTMiQBxpNg9E8JLE 90SKxtNd8y4GIoyaZMIRq0TjguQIg+sDxRV5CHuwuUaQRRFJVWoUsBrEpuCY3jDZXS2nb2xd BWhYl/WNdcZuTR7ihuF3V1p0xB1lERSJCRV7ceJiq5xls/0VXTSaolQlnhCYHuXxyprNPuKJ be37uXAfut3fmLbdvUuNUEaoL7ElkEfaVwxLPEyUsIid1RFzyzx4rqWqtJlHGW2qQMYnx73N yCmDUwQEqH9I30lGLipsil2GMhLepDzL9WqLLpRZEsBMVIIppgmiROf0g90JFTiWUXVrwxhg ZS053LS+L6XLwpKcmnsk1v7buzvSQtq37hpF/U23rppsJmjVCM665PYy6ysoWBfIQV6UDaKr nf4ovs6dydSnMKvONEzFwDzjn/jHzskibBVBtu4srFbfo6R4TO4FPt63apHqNNta1AjnNkRy J6VHkI2rDjT2eDjZqK54plFDGq5iFuISTj8wNhORjHL1+9SU24JNtgPEtGTCVTVT9r364RUH Ru1UsxsofqCiniXw1sCytD2p+LNH+4R/ljr3vg/wdkPqWvYFccqnfz3pF1ovqxpiloQloQlo QoPvUv8A6XV/9S380NVLHXg/MfY9sVKUSF083Dn6orINTpsGs0ufRqnHF+HUGXYshsvI2zRR JP2ouvMgvOSrwmzvFCN0OddDIbuldmGW40dqIw3wZjtAy0HJV4NgKCI5JVXsiJ5romnymXtK W1HNDDYtagKaWZ4aK8X/ABxfLDVexN3rLdP5UtJ7RL2ryr3bnSkoUWnmwvRSOcviKDlslcxl xFUuSImDFE+Go6SGkg2JP3XZ8Wfl5k1mjnf5HAiVtpuq3XI7lYlUP8Eiw0kltpxEeVzi31SF FRUQUVHFQcqviT4as0o5Tibuazjv8u8o583sxuH7lZbM1ptcPyo7RphFBx0RLKrxRO+PfqwS pOO6vB0JAwiY3gMfVFPwmsEfQNxtHC9gFLCqnxTPnqXAXGvnRyTWDLg6xJ037f16k2HR8RJx uu5E6B4+XHUm0+k4gKeR/H7WpNo7tpNXYWqqN0tqWbgBybCjirph4/76659VKa5T5gp2Xz5V bqLWWwHRPrIN+7CT2ZjhNUFyQ84KiIgKi44XEhQUVMZyKmP/AMsfnanKXicdHbNKxOuyr46q MWr6INDq8OPK3CrFQlJz6gQ0fJMtGpEqOK4nMSUnXeQ/pES58WsT+MHWyHcMBh9lRIy4kV6l N2ei5t1JtefSqBSWYjj8YG0GUSvNuI34kQvf4i8RKndV1GS2L6hCeHSlDKMfInEWhNYqtrb/ AHdoN0swZUGsUyXHrEqqmgkQMtvOsEIPJ3wKLywvbPHtrrp1eQcl4WZR3kx3A9pFsf0NLCLb a15NMfeJydOYjDNVHBNtkmQVOAEnfjyJS+1dcex5WCnntEBam+nJSYywitAyV55X4645OAIk nLKY6hk7S+GtwWVoe1PxZo/3CP8ALHXvfB/g7IfUtewK45VO/nvSLrRfVjTFLQhLQhLQhQbe r8l1f/Ut/NDVSx14Pv8A2PbFStD7/b6eqKyYnmf/ALl/iuvMJjc5qLoa8Xz1gh1uiPUtm9pT KzFxRnF+E9flhqCxNdueW6fypWT2iQm4jtVu6XlnbkSaNOZgAj8BJytoTGci5xXyVcL3Huv2 6c0mFQ3GJBJaQc9rLe9lKxrMnIdyft6U3p0na+XEdjnuVUp7LsJ5ooKTHcjGNxkTJG1FcKCm 2PdPLP8Ae1YGGq4wN25INjnv7PR4qjX8TS467Qh5eBeHXfR9gPpHqFTrBkKo4pOk6StKkZxx SJVwSYbVT7p7fBf0dWqVkq1o9RtuH9qiXcbOmWz/AIKytpVsCp09yvWAzOKIZlE68sTRTICV TEEJcpgl7rjumPdreoboa2skkdXcqfzvuVismRePl2Xsi/HSbTg2/SSZWp0yWf4/s0/aNIkn jZ+HIl5/DUmw7empjcvoTH85OWpAYsujY6OYpMQt8ZQDdsGPUaRTRg9VKrUhZeUYwOijQATh IaEqKgkoomR76r2IJOVYZ0rQ5KXpJuE9x5QVQ7vluJJt2LQNsykR6vWXyaKYw3zcYYEFIiHk mEVfLlqt4dGX3QTr45h/5VqMgHbLVVbbTRt+LBv2PaO586oVek11t9WXJfJ52K82HMVQ1yvE sYXC4+zU5XAp85I6WVb0Zw8u97lkHWz1wJTe6rPptcvSCDLkcJU+M8XHkKGaNKKqaCg8lXBI ikq4RB/var0hMPbncPyKS3QLQ66nlq2xFtiGjLI98eNOOqdOzROlcai3JkpkuZEHz+H7tVOc PWTlsU31HJwl8NbgsrQ9qfizR/uEf5Y6974P8HZD6lr2BXHKp3896RdaL6saYpaEJaEJaEKD 71fkur/6lv5oaqGPPB+Y+x7YqTovfwdPVFZRiRHZan0hLCEqqqe5Mr3XXm6XYcdIrF0SJ6Jt fEpgozitn9Xf7e+tItEwQgf0lpLHpRIlLbN/qR776Xyw1W8U/MsdP5U7kdokPrztHaug25+2 j1VP1Fomqo3BF5XCUv6BSLy4+ffUlRaWL9K0vbTRb/zV337Y+yo+alWXX7nWoEutvqT81uG3 s7Dp8eQxJSVJkNRhBUyCk1xEMuI5598D4e+pSYpsnKS5G7WjcLMMhGN2e9yO+LwJKMrLl/Kh BHaVcG4TMNtQ2xo6yUaXkTM5phlXkbQsY4KqIuVHuS9tSrDNNG0+2Lvqjq/5pmcnL+ajEKq7 0zVEX7bt2lgaTEIknesG250XFi/DKK6rSqvHyz2TU8y/htr+Y456/wBUU0cgHiLoxH35dFtT kWWgo0nWJGn+RmqoSKKeSCiIo4Xz1Iy07hfSDpdJl9r3rBxZa8ZErErF2x4/X3JuO3WpCstF 6jDeDMdw0z4yTArlc4wmF04qxUu4RkBjb0qPdmJeHAam0apw5JN9Gcy4bo5FEcFVVE81wi+S aaCWi1fItwMTHVT4TEV5ac6W0VgmrlS/pQSXKTQaBdrcVt4bfqqTC/mvrLohwUS6LSqgq4vs opLhM50xn3hmS3IezFTdBhrEPIu9v1tqdGj1qlyG8ImBJoxc4EiYcbJRyikPsrhfNNUsjepj 1obMFPPMC6NhrvW5sysk3JmCyqx+SNIgcUDkKcu/2axMVGYntRayMq3Kkq7sK5xufdiqxofU 9RtqmnFdJt3LRznHeLrRgQIQutoHmhYUXBXUlNs9rKUJltn8fj9yVnC0paqs6U8HNS9nsnlr mk66tWgtQ0zElymq9MOp8C56bJRL4a3BZWh7U/Fmj/cI/wAsde98H+Dsh9S17ArjlU7+e9Iu tF9WNMUtCEtCEtCFBd6/yW17JYTot9/+aGqdj6BFh6Ys+h7YqWoX+oN9PVFYivy57lp7zdOs lxtyfSIZ12pMtyQQ1badEejwL2lUVUuOuOYdlxtuIVfnWtK2rLu1qIDLM3ky162iONN9QRzl OS4RV92dGKacLBDNB5I6qYU4yEilzFELN8VEfx3/AJ4WP+mGuT4oO6Xl+n8qnJUdE4S+KnFv SZW3lolwQYsDoCpxnmhMwL85zui47eWceWmNNCn7iymmDM89obvVlBQdQZmt0XMTEAHoTJ2J ckWlzJNY3IpjEEITpFIVltsUHI8HnHEUVwKIqLxL+0z59tTRMSjetKyDmdw+f1b6ausvOf7m G9zL4U26OjtxVrfIWmH22nE6XDCsgrxo22COkpIQn34ipL08IvlicZdmJ3+HCnRhlx636VHP y5f/ACer3ro5UdrRGFSqhvR/rSjNSW1OPW2zmmT3SJVcbFSNCFuPw4qme5e/U5LhVBu/hNHz h7xTM9zjsv59H7qXUKwrPrlOGtw7kuaowJxo9HJ6c822rahxy2hAK8SEl+3SXbSaacsdbD1Q /Sl2JQZnaLNG12osaS+sqTClOEbLTBD62aCoNsiyGUHHkAAmn/bx50dmHx0IdpTKOUGy7Utl z1mh0luO+oK2r3IjNRVEQkySr540q3OkWuS3CT0Q2ipB1cr7WnW6NKNic2ITd9Ej3FQZNLle MHQzhcIiqnkiqqL2X36QnhvZ1dpb092MrMXrINTtLdjZip9OyZBSqMy4yqU5z+hGO24bjjAY yoo649kz7quMaJerU+oN6KpN2nDezz+/xVbzFqaje0SDJWPSL3CaaoNYei02G+DDMtthjCSE Vt5mS2vwB0XENP0SbHTmMzh+lazGuXLH1JXcmrfcr42p29ibc2uEBsepLdBsZMhzu85wFBHq F+cWE89UKvVsp8iO3LkTTaJSV53uo+edUGYfv1E8ELoJsWo0wuSojavdaLZL4a3BZWh7U/Fm j/cI/wAsde98H+Dsh9S17ArjlU7+e9IutF9WNMUtCEtCEtCFBd7EFdra+hJlOi12/wCaGqjj zwfmPse2KkqOejngLn6orAV9bIX/AHNcNRuq3bop9DjFy6zzYEjz0ByOnrKGqeaioILfxyuu b0WZaakd8Vet261iY1Gu1R6bTIs5yrQ4/rqLHjttIbikvEWyPii8WDx7vJR8++mc3bOC4HDk EepSjUuPzq0XZ3ipEjwj4p7nb3f0Ya4zicLJNjnj+VEuVzhKK3dbG1FSvB+oXRImN1lyA0y6 LT7wtvx0LIjgBVHO/wAe/u+rUxh16uDS8pIIGOfk/wC2Krs81Td1d1KMC5/3Q2i2vsZRzkza TSJhyggyUNSOUhNsK40RoBEqC2qKLapxVFTj2xjTubfxW4Vjrgw1h4h/Qk4jS+X1/uncahbM z33uG1YzZquk0YuRs+NTNxVQyNUwSkZck/S763OfxRLFacyMODiH9CbHGnjsMxj8c6sSkWHt /TYTkOnWDb9Pbl59YZj09oOSqKiqEojlcoqp56gxxLPEX8Q85HogpZqlSe2AqaxnW2mgBsBA AFGwABQRAU8hRE8kT3JrYJgXSvAo3LbQC3G0RRAJHh7afhMJIwXcJPhTxakmpgklYu3XHT4Z grVpYksxOKiXH7FwutTqVo2kkYy5EVwoVPCHL7vstmvbzH4Ln+OoiYJt0rxT1jTNChBx6dGV SjsMtqvngfrz/HUJMPCKkgi8W2mUx9XV9ry8tQDs4TqdswTA+3l79RjpJ6C81qt0tN0JfDW4 LK0Pan4s0f7hH+WOve+D/B2Q+pa9gVxyqd/PekXWi+rGmKWhCWhCWhCg29i8drLgL/cN/NDV Qx54PzH2PbFSdG7+Dp6orPtEJqTA9Wkt82nAJtwffxVCEkTt8F1ynD80OjIFaJ0O6Caz1Lti 67Z3dt2nBczlYg0+e+jzRirQwGSaIWS5d/WEMGTbUfzCRP0tPplxoZKY4iyipdo7vUtCWVgK E97kSYX5uFx0x9ya4linWk2B5/ypzIfOEudYum1YNxNW9PFTqZ9HgixEJAE1wJdRe2O+fq1B y1LqBy+kaLV54pKLsuMxrCh7m51otPtQYSTJ7xzgp6tx4eERw3BFFUiVB/tOfn7Kd9SDWHqg Y91cgO9dvlHyRQ5Ns3aoJxE3NhTYbcuDRK1MacijKZaYEDJ1rJIXDiSiSpjPBC7ppGGHpoXS B16G9HLhitN2B5i7JftweqNPNbZXA86/x6cbqihdJWhM3VLiojwUuKoq+fvXOnbdIlQLvqHx 70zOccHxV8/y23dOO+/A2rjm0s1Woj7lRDg/HUV4PryVETJJ5KWfEPbUqErTwtEpri8nH5E1 KcePxU9K69yH3CBI9m0ttI/0nrVXBwwlk52ZJEJRQFDxc8/nYxp+1LU/zjPoh70lGacQ2PfV 7SYdOjVK/bBpVUakj+EhaI3Y5R3muDaCSllDR1HSTv38OnzTUqN1jJxHi+M03N5y7aXCDcN3 1eqpTQ37oEl6ssq1T49PofTHmbb7g8XVyXZseaLyT2dSL70vLS5HCV2eWPN5VpcT/cruFSGo WjuNMdp7RbzVRmM02oSkjQ2mTcwo8CAh7oq4NF5L9fnqJOvSej+Zj8dKct0xxSWntuUylRqc 9VpNRcYAk9ZlHydcRTIk5L78IvH9mqrO1FuZcuaGwVMysuTQ2rk/JzkdQ7r6lWwTEi7aj3TT sYLzsvv0zIrltwJawsLzwfpazcSxrJDxLwp56APW2VqUSFaJtb8WaR9wj/LHXvnCHg7IfUte wK4/Uu/nvTLrRbVjTJLQhLQhLQhQbekVLbCvoI5Xot9k7/2oap+PoEWHpi36HtipKjjdOAPP 1RWZqFOVtzgvJCE1UMFjui99cDo05oHLCVznBuFAKnGrIXVMkvyI7tFUXX4aryR4HneKEJCu R4hg8EniXlqUq80I9w8aMFvJukWpbFTWyuBUR4R7j64WM+9OmGuZ4puFlnmj+VSkkJCRLyrU +7JdZju02bSG6YEiOToSoaOvG2Kor2Cx2UkTinftqDk5+ny7NrwRiXJH1JKYlJg3LwyQGBZO 4sf6M905ERpOtwGDGRC8bjhLyJVTkvdpU/RUVTumpZ7ENNiOpL5+lHqyj600CmvFtlBPqhZd 1Sqc9Gi7m1ht/ok1GNzqEIETiEpHxdQnMCnBEVe2c6byuIJJpy5yVG344PIle1bnnJ1/ISnu 1Ryqv1muSHjmFMBHphOC2qmRICIWfAgl0+P6P160LEhR2WQ4Mvjl40uVLEh2lwXa6z3z51KL MmGYdFTcdAMtcxNQ4tiIoiqCJ4URcZ76G8TTeVjAj9/4pIaMPnJ3H2s27RtyOVs9QHmI0R0n pTrpGwwXIG1UiXI5Vc/HTiGKqjwG5l0D7lmNLbFF27Tstl5TG2qOpGrSl1IwljpeJrHLPsr5 du37MaxGuzZa2mj6hWe1w+aizB06KjYRo8VkGscMNCPDCKiYXz7ISppidUJ0bNIlBkBHxV1S SZZRRcVVXw4FV7a03Y4Q6iWgFq89TqR9whSCT4oC4/fpsITRFbbGJcy207I7RQTd2O4B9J1x hk18xdktgqfaikmpFjDFanPmpYo9C0KpSbW05BfYUuQa4bIXV/3Ak98sV1JD2O8VP7EkX3e9 NzxBTw/mJ6zaVbkDlqnzF+r1N5P/ALCiakpLsRYqfLWl7PSjBIniaRHxk/a27ud4ERabKQfh xAV/7iTU8z2DsQFtuNw6f2TMsWSY7IxT6PtXX3B5ORnG/wC6440mftUSX+GpaX7BFS/nzLf+ XuTOOLx/pp9E2jqHPlJ6Ij9U1c/u6Wp9rsFSpD3eZ/tgkDxc6WyKs2lwfwfTYkBFz6swDSLn PsiieeE+Hw12+lSIUuRZkQ34NAIf2wyVTfcJ50nC445p9qRSSWhCWhCWhCY1Wl06t096lVWI 3JiSB4utGmRJM5/imk3GwcG04ZwWwGTZXCqzrno823MUnreq0ylu8cI27/OmfPPdDVHPf7jT VRqmBaPUyvNvKPIpBmrTTXjKuLj2KvumqrsWns1Rr9KC+irj9U6oqP2CR6odV7FsxEhKQcG2 HEeef3Kbk8QN3fxApnQaHU6NTXIlQiSorpSScRp6G+jipwFOwICr7vdnXNcRdj3ERaEGpS7L zYw5PLFTMvXKfdfvouNKqTiIjNHqz6F5dKkS/wCJNon+OopjsT4qm9uWs54j704PE1P86KIN 2XdDrROsW1WHFx2DpNtqX/UMcammewfiIob7jYdOfVBMyxZKt7IxindP27vOUPKTbciN8Eek R0X/ALHC1INdgaqF87Nt/wCXuSXywa/pxRONtRdDhfT0+ntB/eqpEv7kj/56npbsCS498Tcf sw96Yli97xW4J81s/WVLkdSpTIfo9B91f2qhh/DUsHYMo/8ANfcj/b+lIHiqaLZGEE/b2fPP 09fjoPvFinIn/wBzPUtL9hrDMvtiZc8fdBNTxHPF4yfjtPTekLJ1+pIKeaNBHbz+5rP+Oppj sX4VY/2kI88Y+9MzrE4f8xPWNsrdZDgciqO/WU4xX/tVNSjOB8OsbMm36kgdQmjG0nIp5HsK 1Y4KA051xF8+tKecz9vIl1MtUinsfNMjDogkdO55y7M2VaEcubdsUtC+KxAVf3qmnotNjsik 4kRInHptPipiJT47Cf7toR/gmlVhOURE8k0IXuhCWhCWhCWhCWhCWhCWhC//2Q== --------------030407060607010708020801-- --------------050509040508030003060708-- From rivera@yahoo.com Tue Aug 23 13:12:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7cKY-0006Zv-9K for provreg-archive@megatron.ietf.org; Tue, 23 Aug 2005 13:12:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16262 for ; Tue, 23 Aug 2005 13:12:55 -0400 (EDT) Received: from pc147-176.netcorp.pl ([85.219.147.176] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E7cKd-0002zB-Ig for provreg-archive@ietf.org; Tue, 23 Aug 2005 13:13:08 -0400 Date: Wt, 23 sie 2005 19:12:54 +0100 From: "Feinberg" To: Subject: Save up to 90% on oem software !!! Message-ID: <423F3FA9.4010405@expert> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------050509040508030003060708" X-Spam-Score: 3.9 (+++) X-Scan-Signature: 8008c49d41a52dffe8d48b494980a4a9 This is a multi-part message in MIME format. --------------050509040508030003060708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by drop.ux6.net id j2LLgHfF030444 Content-Transfer-Encoding: quoted-printable Opt-in Email Special Offer unsubscribe me=20 =09 *SEARCH* =09 =09 * TOP 10 NEW TITLES* =09 * ON SALE NOW!* 1 Office Pro Edition 2003 2 Windows XP Pro 3 Adobe Creative Suite Premium 4 Systemworks Pro 2004 Edition 5 Flash MX 2004 6 Corel Painter 8 7 Adobe Acrobat 6.0 8 Windows 2003 Server 9 Alias Maya 6.0 Wavefront 10 Adobe Premiere * See more by this manufacturer* Microsoft A pple Software * Customers also bought* these other items.. *Microsoft Office Professional Edition *2003** Microsoft *Choose:* =09 *List Price:* =09 $899.00 *Price:* =09 *$69.99* *You Save:* =09 $830.01 (92%) *Availability:* Available for INSTANT download! *Coupon Code:* ISe229 *Media:* CD-ROM / Download System requirements | Accessories=20 | Other Versions *Features:* * Analyze and manage business information using Access databases * Exchange data with other systems using enhanced XML technology * Control information sharing rules with enhanced IRM technology * Easy-to-use wizards to create e-mail newsletters and printed marketing materials * More than 20 preformatted business reports *Sales Rank:* #1 *Shipping:* International/US or via instant download *Date Coupon Expires:* April 28th, 2005 *Average Customer Review:* 5 out of 5 stars Based on 1,768 reviews.=20 Write a review . ------------------------------------------------------------------------ *Microsoft Windows XP Professional or Longhorn Edition* Microsoft *Choose:* =09 *List Price:* =09 $279.00 *Price:* =09 *$49.99* *You Save:* =09 $229.01 (85%) *Availability:* Available for INSTANT download! *Coupon Code:* ISe229 *Media:* CD-ROM / Download System requirements | Accessories=20 | Other Versions *Features:* * Designed for businesses of all sizes * Manage digital pictures, music, video, DVDs, and more * More security with the ability to encrypt files and folders * Built-in voice, video, and instant messaging support * Integration with Windows servers and management solutions *Sales Rank:* #2 *Shipping:* International/US or via instant download *Date Coupon Expires:* April 28th, 2005 *Average Customer Review:* 5 out of 5 stars Based on 868 reviews. Write=20 a review . ------------------------------------------------------------------------ *Adobe Creative Suite Premium* Adobe *Choose:* =09 *List Price:* =09 $1149.00 *Price:* =09 *$99.99 * *You Save:* =09 $849.01 (90%) *Availability:* Available for INSTANT download! *Coupon Code:* ISe229 *Media:* CD-ROM / Download System requirements | Accessories=20 | Other Versions *Features:* * An integrated design environment featuring the industry's foremost design tools * In-depth tips, expert tricks, and comprehensive design resources * Intuitive file finding, smooth workflow, and common interface and toolset * Single installer--control what you install and when you install it * Cross-media publishing--create content for both print and the Web *Sales Rank:* #3 *Shipping:* International/US or via instant download *Date Coupon Expires:* April 28th, 2005 *Average Customer Review:* 5 out of 5 stars Based on 498 reviews. Write=20 a review . ------------------------------------------------------------------------ *Symantec SystemWorks 2004 Professional* Symantec *Choose:* =09 *List Price:* =09 $99.00 *Price:* =09 *$29.99 * *You Save:* =09 $69.01 (70%) *Availability:* Available for INSTANT download! *Coupon Code:* ISe229 *Media:* CD-ROM / Download System requirements | Accessories=20 | Other Versions *Features:* * Norton Utilities optimizes your PC=BFs performance and solves computer problems * Norton Password Manager keeps your passwords secure and easy to manage * Norton GoBack Personal Edition restores your PC after a serious problem * Norton CleanSweep removes unwanted programs and files that waste disk space * Norton Ghost protects your data from computer disasters *Sales Rank:* #4 *Shipping:* International/US or via instant download *Date Coupon Expires:* April 28th, 2005 *Average Customer Review:* 5 out of 5 stars Based on 217 reviews. Write=20 a review . --------------050509040508030003060708 Content-Type: multipart/related; boundary="------------030407060607010708020801" --------------030407060607010708020801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Opt-in Email Special Offer     unsubscribe me
SEARCH

TOP 10 NEW TITLES

 ON SALE NOW!
  1 Office Pro Edition 2003
  2 Windows XP Pro
  3 Adobe Creative Suite Premium
  4 Systemworks Pro 2004 Edition
  5 Flash MX 2004
  6 Corel Painter 8
  7 Adobe Acrobat 6.0
  8 Windows 2003 Server
  9 Alias Maya 6.0 Wavefront
  10 Adobe Premiere
  See more by this manufacturer
    Microsoft
    Apple Software
  Customers also bought
    these other items..


Microsoft Office Professional Edition *2003*
Microsoft
Choose:
 
List Price:
$899.00
Price:
$69.99
You Save:
$830.01 (92%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Analyze and manage business information using Access databases
  • Exchange data with other systems using enhanced XML technology
  • Control information sharing rules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail newsletters and printed marketing materials
  • More than 20 preformatted business reports
Sales Rank: #1
Shipping: International/US or via instant download
Date Coupon Expires: April 28th, 2005
Average Customer Review: 5 out of 5 stars Based on 1,768 reviews. Write a review.
Microsoft Windows XP Professional or Longhorn Edition
Microsoft
Choose:
 

List Price:
$279.00
Price:
$49.99
You Save:
$229.01 (85%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Designed for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more
  • More security with the ability to encrypt files and folders
  • Built-in voice, video, and instant messaging support
  • Integration with Windows servers and management solutions

Sales Rank: #2
Shipping: International/US or via instant download
Date Coupon Expires: April 28th, 2005
Average Customer Review: 5 out of 5 stars Based on 868 reviews. Write a review.

Adobe Creative Suite Premium
Adobe
Choose:
 

List Price:
$1149.00
Price:
$99.99
You Save:
$849.01 (90%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • An integrated design environment featuring the industry's foremost design tools
  • In-depth tips, expert tricks, and comprehensive design resources
  • Intuitive file finding, smooth workflow, and common interface and toolset
  • Single installer--control what you install and when you install it
  • Cross-media publishing--create content for both print and the Web

Sales Rank: #3
Shipping: International/US or via instant download
Date Coupon Expires: April 28th, 2005
Average Customer Review: 5 out of 5 stars Based on 498 reviews. Write a review.

Symantec SystemWorks 2004 Professional
Symantec
Choose:
 

List Price:
$99.00
Price:
$29.99
You Save:
$69.01 (70%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions


Features:

  • Norton Utilities optimizes your PC¿s performance and solves computer problems
  • Norton Password Manager keeps your passwords secure and easy to manage
  • Norton GoBack Personal Edition restores your PC after a serious problem
  • Norton CleanSweep removes unwanted programs and files that waste disk space
  • Norton Ghost protects your data from computer disasters

Sales Rank: #4
Shipping: International/US or via instant download
Date Coupon Expires: April 28th, 2005
Average Customer Review: 5 out of 5 stars Based on 217 reviews. Write a review.

--------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhLAEWANUAAP///+7uzAAAAIqKitbWuLu7u+fn4O3ty21tXq6urpiYhkVFRWdnXBcX FzMzM7y8o3d3beLiwktLR8vLr+/v7319cRERETExMSEhIT8/PVdXUZqamnNzaiIiIrCwmqqq qmZmZszMy6Skj1VVVd/f3/r6+erqydvb2M/Pz4mJeefnxs/PsnZ2dvb29M3Nzby8vN7exqqq lPHx8ImJiIKCggAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAA AAAsARYAAAb/QIBwSCwaj8ikcslsOp/QqHRKrVqv2JA2hO16v+CweEwuLxvoBtfMVgra5Xez 1JIZ7vi8fs/v+/+AeyVNcnAAEIgNEIaMQ4WNXo9IJTInMCoHAZqbnJ2en6ChoqMBBxEEKy4G TJKGaJCMrbBVskQlBjCkuru8vZ0EDwaDSbVsEK8NAMnLAB0hr2UUBQVhxbNR1gC4oxMRvqET D5zh497fvx6rxNfQSM8dRBcjQhQCHwNvCwL7NAIDAAUEXBBygQURFgIvbBACwp6QgAIsjKi3 b98/JNbkCdlHAQCLgQsWAKBwAcOCf/geCqAmJKXKAiRNDsBX0Zq1Fis4KZAQIIKD/wcEJGjI oEDTzwAKGCB14EDChE4pHBDQFEGDBAZFq14tGnRo0QBHky4VhxUs06OlVHh44SZJQJb+ANQs 4BIATQwLlxw7pqzvMr5EXG6wYDefSCEL5tGkUI9lYZYdKVjAMA/gShRx5V5cl2QAYYgfAFz4 F7Jwx5Zy3g6p+xbfadSslBiYusnng50BKnAIMEEqWHFixXLYzUkCh68VlPbMrdybbt6+wypV kKFCgLJIlWs6YOJBXoxuV278l7nw6jf4SDBpAA9JOyEkHI4AYb50SwwATq788AgDfSIb4CWA em9hlld54IVHwgAhDdBYfiJt4M9pLqkG20sSOnhebEl00/9JchmIEEAGHmiiQVHSZRcAB9Zt MoEGHmigiQQlbkIjJySaiCJw0zEgQQTYicWJCSuk0BYSFsZVXl0p8aeeXuz55ZciRlwAQj2h paTPPtMMaEEBJzFIBIKiORgXROWRaUQ2AmwwwkwLBITYYSNERA1NFTnGmnh1fnnhkUjE4AkB TRklznU7qqgAUz9ykkIKPk2FlqGcoFVWikkpkKkmQm5iAgEcAGoEmhbJVZF5qC1gwX9LvLMG ER0kY4Rng8Fm33joNUjEqkRgdoGq+L3FAn7jLZHNAiBg0KWYEA5RQEmoWoiqZSw9S2xdnAVq DifY5RjAib8pykAEGRw6owYMOFD/1I021qiJt+BiOu5WnGpXSnehZjuqeJr1+yc+BTzZxDFp FEylEfHxWt9hiJkEwAcWCIACEQ1NzNAF00j4QYEO+avvEQNg8EY9FlxU2mksEFYhv9O+hTJh 035cxAS0cYvcbr1NJYGIFVgnXAoulvtABTImx4nRmzyXcwA75+azUhUQVS8npoiQb4JHJEne ZkxmY0QIiIQtdhL6hFZfRSjFRXIRFDR0wQU0lDyESao57DHWSApw2AUCuDAnQCa1GS3LeMa5 UgGB54Ut3kacYO4m2HUldQAiZMBABk+JJQJPmqRAXG8RaFWW6FwJNXnll2eu1APqTr2dCitU YKTMzvKr+GSehS9+DRQFWPyF17tziEQLQB1gPCge1vZ4L+S4+HjyVC0fivEqEKAAAt8dAXwZ EHSwyBDdfx88LeNbkY0BHnSjggkmGO/++/DHL//89Ndvv/EmqBDBCtfPcIKosIhVe4QgwPKR z4BT8NoJYiCCB9CMABCMoAQnSMEKWvCCGMwgKh4gggogYAYuGAbjIBE+IpQQgVLYHgrHxIQW nCABCtANAmZIwxra8IY4zKEOd8hDBDAAASzawAlEOMIVGvGI17iFC17wggQ48YlQjKIUp0jF Klrxik98wQlkgMQuevGLYAyjGMdIxjKa8YxoTKMa18jGNrrREEEAADs= --------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhBQAFAIABAP///////yH5BAEAAAEALAAAAAAFAAUAAAIIhG8RqaD9QgEAOw== --------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhBQAFAIABAP///////yH5BAEAAAEALAAAAAAFAAUAAAIIhB1xqcD6QAEAOw== --------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhUgAOAMQAAP/umd1mM////4czIa5wSM+jaXYZEG4MCLmAU6RgPn8mGfPbjWYAAObH gMSSXpBCKtq0dJpRNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAABSAA4AAAX/YCAIIjmW6KmabNqubgzP7xsEwJ3jes//u6BPCBwai0ji 7gRoOp/QqHRKrVqvItx1y+16qVkn4bAoDACFwyABMEAKjELDACAYBgiAQzGAAAYHCnlNEWwF dGlrdQYGBE0DigAMTQiQg5B1jk0oYgYIZmhnTQ8OBAMEDg+ZTgMFT61PewAJhqKZC5OgTpNt Cwt0fwYNBJo5JE8ECa1nhwR5xA8E0Y6mBK5jDqyuTwwLCn7NzxGmAAsHDwtNuaKwpwnET2FN xO/MCgXgA3R31xFylAey/dnm5AGCA00K3PNjSoHABg8UqAv1yNWyd044zSMwh5ktAIHaIFz1 BONAKAgMW0RIaIsYBIlNcE3s9atiymLyNv5hpkaUgpUR591ho0xYRSgNGAhMdAbegQYQ9Gni VQlPRXPFjGn5wrWr101MvoodawVFkiNK0Ko9yzYt2xoy4NKIS3euXbktQgAAOw== --------------030407060607010708020801 Content-Type: image/jpeg; name="prod_image" Content-ID: Content-Disposition: inline; filename="prod_image" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQY GBcUFhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYa KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAAR CAC0AIwDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3zW/Ekun6jJapbxuqBfmZj3FQ6b4plubo R3EUEKMv3snr2rA8cSGLXbhlTef3Yxn2FZnhKe5urmcXKWe7lUD52FGVWCn3r5CGPxMsd7Pm 05rfK56Lw8PYOduh3V5rd9ZMfOggMXaYFsD/AHvT+VNt/FDiXZewJEp6OpLCs+J5bV/Kh3R/ 9OdyeD/1yf8A9lqhqVxp9qyor/ZZXO02sybRn+n4fLX2b5FueQps7pL8um5UQqfQ1VudZeK6 gi8kHzEdic9Nu3/4quXtZ7iwfEQYp954JOv+8v8A8UKuNdxXt7ayQ7uI5d4PUfco5SuY211z NykPkruO7Pz9MVb+3lkysYz2ya4+eETa/blYvnRPv+Zt4/u4/wDHq6NcH7vNQh3HR60BOI5r fy88Z3/dPv8A40+XWVjnePyD8h253/7Oahnt0nGG27scf/E1jMDDcyxfMcHqe3yr8tNpAmxg 8eqxcf2fJ8jsv+sHY/SpB48i/wCfCX/vta4CPO+X5G/1j/8AoVPUH0UV8fXzXEwqOMX+R9PS y/DygpSR3y+OoP8Anzn/AO+hT18cWx/5dJ/0rglQ+v6U9Y/m+YtWX9s4nv8AgN5bh+x3v/Ca 2v8AFa3I/wC+f8aB43sO8Fx+n+NcIsY9KlVKX9t4nv8AgZvLaHY7r/hNLD/n3uv++B/jW3pt 7FqVmlzGjqrZADjnivLdvy16F4TXGhW/1f8A9CNejlmZ18RVcZ7WOLF4SnRinA4j4jyeTql5 IrAMojxubA7Vj+CboeQ92gSfeZFIYlwccf0qz8Vp5o9Xkitobad59kQjud2wsQMZx/DnGad4 JmTUkikuY1jjeN8pGem3+6a8em1HHWtvP9SJX9lvpY6eC4triPyonVFP/Ltc/Mh/3W7VzXjW 3ln02UWmzbEdziaTmNlbnY/fj+E1anmtjprXtvL5ke9k8uQYkzu29fun8cVka0PtVm1nb36w yyDebVyPnb+7/dNfe1LNWPEk7o3vCX214XGs/wClZHEcfDwj5fmVe/ruWn6lcW9vfQfZrmKR HDtvztcbeqt+dQeE5bJNG8uJ5g6HmC+m5Dhf4JP4K4XXr+0jvHRbK5RZIyyZ/u/L8u4f8C+b vWVSq4Q0HzWR2+lXaXGtQXENwnlSBkuCz87mX+H+H+Ku5gjSGFET7gHFeW/DuwiCebdXMW+b cyIXDlF2/wAQHT722uo0/X4kvmtNPk+1Kj7XTPA/3W/9lopS0uy4yOyX734ViXQ/064/3x/6 CtadjdR3SM8RzjqO4/3qoXP/AB+XH+//AOyrW62KZ58g+d/98/8AoVSqlRwJnf8A77f+hVZV K/N8S/3svU+0pP3ERqBTl61KqU5U+asOYqUiNR7VIoNPVKeqVPMZuQxUOK9B8KrjQrf/AIF/ 6Ea4XHFd94Z40S2/4F/6Ea93h3/eJen6o8zMX+7XqeSfGlRJf3cRGUkhYP8AuDNx5Y/gHJ/z 6U/4eebcaTZG3kSGU27MjxghBtHp6e1RfGkO+p3MaSNE7xYEgLjZ8g5+Qg/rWv4Cgjgu7eJE IXyWbY5yR8v3WJrilJRxsY96n6nM4/un6ElrpWsQA2d7Lb3VvLiUzvH8uQ3CsevNV9V8H3k9 7dR2UFvDZSfMJEPz+/X+L/61bevW8lppuoztqDmAfvUQncQ6t91T/d/2azvh74xTVoLy3u5U +1W5ZgHfaXWvu7LZnh6XszD0/TnuPItNMv7eHy9yXFrfPh/9/Hfr0Hy8Vzuv+HJ7JYI9TuFD 3D7I03/IPmUFlrrfEesaPMFu7XfBrMch2TRoGzt+UNu/u/7VecaxrGp6le5vXmufv7Ezk/N8 3yr9OtYzsZu2xv6jdWWjNcWek2k1pfxuyTSAlt4VeG3fd53V0vw006SNZ7xpcrJj9xIAz42/ eZeoU/N0/u1x+nPN4rvYImRo5zbyLIO7unKqo/U5rpPArppdzBpllPdXMsiedIPLAg2qzfd/ i/4EKml8V2aR3PSEt45JFkt3aGXsQev+6e/+6ai84/aZ45tvn55I6fdX8qLa6id8S/uXPaQ8 H8ejfj+dDZ8+4z97f3/3VruexsziLR8q21H++e3+1VpQ/wDc/WorHBRv98/+hVdUV+aYmX7y XqfYU5e4iJQ/otSKj7uq/lUqij+KufmCUhmw/wB5qbORBC8jbn2DdjPJqbKf31/OnSCKRGRw rqexGaUX73vGcpe7oc54c1+PVdQltlgxhN4JPOPpXrvh5QNGtgPQ/wDoRrwuzuLDwz4ncvdr JBdnyghhO9D/ALPH/AeK908OAto1sWPJ3f8AoRr6vKKahi3KC0cf1R4tSs5U7Setzyn4v2X9 pa/NZKYw00WB5iZQ/IOtavgsEarBHliwhZc+vy1T+Ix/4riD5FJ9d+0j93+tX/Ax/wCJ/F/1 zf8A9Brwqjl/aUI/3/8A246uX9xfy/QXXPDbx32o3EEl3JFP+9aySMsHb/ZbHDZ6N9a4GTwx qMj7pPD18qqW3ywxlXkP+593vj3r3PWdf0vRjCuq6hb2jS58sSPjfjrip9L1Wx1a2abTrqO6 hB2F4zkA197yx5rXPDnhJcvtGnbvbQ8V/sLXnG3+zryeGPbFC8kRRox3Kp6ZrL8PeENaXxXF carpN8bcFsyBHXH+0pHQ+lfRNMan7LUj6ujwrT/A+v2+qtPotmdOUvveS5G/f8ytu2f+y+or 0XwVpuqaVpUFpdxpNIlxJ5k8kflu+5s715967Bcin4O7NOMOUuNJIpSWSTK3mxKc+1ZK6ZcQ 3M/lIwgz8idvurXRqSV+YYpG/irS5djzSx8O6pHu328w5b+NP71aK6Jfd7d/xcf412q9KWvB nklCcnJt/h/kelHH1IrY49dDvP8An3/8fFC6Hebv+PdfzFdhRWX9hYfu/wAP8g+v1PI5RdGv P+eQH/AxTLrTb2CFnSBJHHRPMC5rrqilj8xMfKPeiORYa+7/AK+RLx1Q8s8R+EdZuNcs7/Sk sRgbnMxHDL8w+Xvz/FXpXgWyuLDwrY214EW4UOXCNuGWdm6/jTfLkjDbtvHStvTh/oUX0r1M Pg6dBWicNRuTueP/ABIz/wAJzDt3cDnGf+efer/gQ/8AFRRf9c3/AJVQ+JBX/hOF3NhgBgc8 /JV3wE3/ABUkH/XN/wCVfHTX/Cmv8X/tx7X/ADD/AC/Q3fF8MkXiXRdQNg95bRRTwyBADgvt x8p/3a5vxLHex2+pNpLapYNJ51xGlvJHCN+yLZu56Zb9GruPFcc7rYSQWb3ccc2ZYlxkjb7/ AO1WBd6brN45uLHSdPVD5kRt77CHBVcNuUN/dr69VKlPFXSv8tNv66nm16nPhlH5fjcb4t1e W1Oix21xq1zqdzbtKtlpcaSNIqAM8py4UKCQPvckqBXK6j8StISVPsviS+nWS3glAQwRZeZ8 JF87ghhyxz8qKPmbmtK403VPDep+Gb2yOlz6va6W+mzW91cPFCyO8ZWQSBCBh0xtbrnjmsjR vBcWkSWlp/aukTSCXTLl5BL9/wCzTPJct0+XcZlChjzXpK1tTj1PQPDPifRGsdPt5NVihvLh JHjt7u7R5nRHYFuHbj5G7/wn/arc0bXNL1u2a40e/tr2BH2GSB94Df3fyrxex8A3Vvpmp6TJ rHh02esKftEzfvp7Zx5qKsS9MfvFOcrs+frndXcfD63stDiv5tQ1HRhd3ZhZ/st7NcfIibEL PMxb17AAYXnrSdgVz0Ckbq1YjeKtLjEpeV0SOFJi5T5cMuQP72SPao4vFuiyp5hvUjTuZBtx /nj5unPWkWbS9KWsS68R2lvbW04juJ7e4fYskacb2JAT5sHOR6fL1OBVZ/F1qlvPL9ju9kHm b87Fw0TKsi/e+8Cyr7n7tZFnSUULyqn1oxUgFJS4pKRRWvELp8o3Vrab/wAeMP8Au1QkQFav aeP9Di+lXAhnjHxOP/FcxcDt36fu/wBa0fh+f+Kkg/65v/KqPxJiL+NXkEm1YwhIx1yn6U3w rfxWGt28s0nlq58lCR/G/AX86+LlHmzJf4v1PaemGv5foexUVz2oalPb2csjXGzA4JTdz9BW BZ+I73W9Nllhea1ns3DTBHRRN/s5PbH/AOuvt5vkdjwPaI6fWNAstWnaW8Te3keSOhCDdu3Y 9aypfBOmzMxlklJ3fJ9zCLlsDG3n7zDJ559q4Gfxfqh1po7LV7t7Ux7cTAZ2/N83Tg/N972F ZNj4114zO6XNyVnTyYFnkyQ/Tdtz/wChVl7dC9qj1I+AtKI2lrsxc/IHCDb6cD7vt0zzVyXw dpssDJK107vM8zv5vMjuAHZuMc4Xtx/DXK+AJtc+33Q1i8mmXZ+7zNvFdxJI+xOW71vD31cf NoVm8K6c/wBxrpFCInyTkcBNg5+99xiPxqNvCGjFPLa2laLZ5Wzz3wU4ynX7pwp2+oq/A5+b cW/GvG/jZ4i1PSb61TSr+WBZZJd4jfbn7vzVoqXMxTq8iueuy6Dp1xIkk8TsVDhf3rqOWy3G eue/sKY3h/R9rD7MvI2n9865z97v/F39f4s18sJ4y1m1Rf8ATJXbO4Zc8Cp08a6yAqNeTF36 neamWGq9Lf18ifrdM+tFkiRVCugUfKBkcUedH/z0T86+U7nxjqIhx9plLuf75wK5zWPGGsxx +ZaajcWzx/MjpIc5qJYSvbdB9bp9j7N+0QD/AJap+dMa7tx/y1T86+SZfFuszlXfU7su/U+Y VquvinVRcbG1C7279v8Arz/FUfU8T3X4h9dp9mfW8+qWkP3p0rX02VJrCCSEhkZcg18dv4m1 H5Ue9uX+fbzMf4q+pfhnM1z4A0CaYlne0Qkmt5Yf2cFz7ijX9o9DgPiMf+Kvuv8Adj/9Argf G11JaeHJbiGRo5454HRx2ZZVw1d38SD/AMVjdf8AXOP/ANArgvGM1lD4avJNVt5bm1Qoxjjk 8olt64+b618Oo/8ACkv8X6n0lT/c36fobui/G3TtUs72DULSbTtSjjLIIT5yP/tL0+b/AGa5 K88afa2d0Rk8z+K6kO9/94At+teUXd1pk13v0+yltmHzfPP5uf8Ax2r95f2YlU2ztI4RWkfI 2A/7NfcVI9JnzkOSaub13r7x6vb7zE8Un+uRAcY/+t1rbbW9It/3UF5bFpT9wAneW+orzC5u 0+0wD5t7nbWfaTE6pb85xMF/8eohCDvdCqx5LWPpf4Nakj+Kb8XEuyIWjYUnj761n+L/AIxa xYeJNUsNNS0S1tZ3ijzGWJVfl3M2a5D4d6xBpfibUZbsvsNvsAQZJbetcL4ovfP8XavKoKLJ dSuAeo3NW1GJFaT6G5r3xg8WalvT+0PsyfdxAm3/AMe+9XLWfiG8up3/ALRvZp1zuHnOXwT1 60y10WGSXdqFyQh+bZBjP5mteS10TTfIbT7eSRmXLvdlZDntj5cCtoxdznlKNtR6XSXW3yvn YfLhBup/2qMNneu2uj8L+ILdn+xSv5C3H7kSRjGxm+Xt/vVuy/BS2gleJ9TjLINz4lXj9aud odSIRc9kef8A22ORvvrTrrR7/UbDzLSLzEfphwpPze5rt2+EWhQJOZ/EDmUKSiQup5/9m+gp vhfTYrGyls4pJZFgkP8ArOoJ520QtN2HOLgrnK/YNQj+9aTfgA1VJZPJuGEw2SoeUf5cf71d rfHZKwrita0mzvNRmmuL14JTgbAvGAv3q1muUyhLmGvdx/LukXr619m/Cch/hr4aZehsYv5V 8hXPws1K30dtVd5FsBGs3neYn3D/ABbc5719d/CmAW/w08MQq28Jp8Q3evy1x1pXOulGxwPx MP8AxWd5/wBc4/8A0CvNfiWf+KK1D/ei/wDQ1r0f4nH/AIrS8/65x/8AoFeZ/Exv+KIv/wDe i/8AQ1r4WC/4UV/i/U+tqR/2J/4f0PJvCWj/ANu6x9la4+zgRPKZMZ6VoeIfDmlWkTxxatcT OevTbXKWd3JbXGYnI3gocelQ3N68jZZ6+9fJb3kfIKNS/usljRIUaNp3Ze2zqKm0mF59Xsre yilmkeZBHGBlyd3TiszeX7fL61o6LDcm/t5bITb0kBEicAH61jp0NXf7R694C8M6rd63eSy2 EsMEcPzyXKGJEO73+n8NJrHwo1LVdZnvdH1vQ72C4nO8W05lMO71VFOfwrZj+LkmhaLBYeIr O41K88vNvM77uOnznhtw/vL1qq/xZ06OcQXYkvYT997YO6D/AL+Pz+VCk4qwOz1Za0j4V6Ho +2fxDqt1fcMwSGHyISF67WJ3Hp/s143r+qRXOp3ElrEYYN58uFE+4nYflXuK/Gbwxbutylpq 13dW8LLbh4Y4UGdoK8MccfxY7V5r47+I2seL0e2uHS100vuFrCMA+m9vvPWsJMznGBT+Hhxd vqWx5fsh3PGvBA2tXU6V4hm8Q6i8Fjpel6lKh4F/MkROP9k/Nx/vVxngrWLbQr+eS6SV7eWP Y6IM5rQS+8NiZ5EnvYd77sG3DY/WicFPcqnV9n8J6JPpvieO2cfY/CGkZHDyTw5G786qa1qZ 0a2cy6wmuXkkaYS0RNkG3quVwCv+7XGwXfhjzk3382wdcwEfyFLq+s6VJJFFY3Ie3jj2glSv 8X0opQ5HuFes6kSZfEkMrZnhvI/96En+WajurnQ74ebdC7uph8iR2rlH29e64/Ostru2LfJO n510vhm7sk06Xzbm3DvJ0eQZ+7W05uxzQSuek6lqVlN8GbKC4d4/Ot4YXhWdPOQK3qcL/D/s 17j8NBEPh94d+ziVYvsEG0S7d+Ng+9jvXzD4nu7ObwxLFDcQvhEwBIG/u19QfDgbfh94bH/U Og/9AFctf3dDrovmVzzD4nn/AIra8/65x/8AoFeXfE58eBtR/wB6L/0Na9J+LUxh8a3RwCvl x5+bH8FeZ/ESTzvBN/tLR8xffH+2tfFqP/Cgn/e/U+tl/uf/AG7+h4Swf7x+THr1rQ0fQb3U 5FNvDtiP/Laf5U/+v+FMt4o0kVmQyEf3+n5V0Nrf3bpjLba+20lufJc3Y39F8JaPZFWv5kvr j0c4jH4d/wAa6W5t7Z2skiRAouE+502/NXH2sLz/AHzXQaZCE+dCdo+Uf/FVrFraxjK/c5r4 toBq2n7EwgtfT/bauKQj1H517Pc3UsIgEUrBSXz7/KtU2ut/+tgtZPeS3Q/0qZR1H0PKKcte oNHp0n+t0bTz7+Rt/lUP2Dw/Ny2kQp/uSSL/AFpC5TzdjTK9Ek0Lw5Jyttdx/wDXO63fzFV2 8M6A4+S71GFvfY/9BQHIcFSZruX8HaY6/udblHtJa5/k1Qt4GXrBrVof9+Jx/jU6hynIoalj 4NdP/wAINfDbs1DS3/7blP5rSf8ACDa5/BHaTf8AXO7jP9aoXKzFVxt6L+VffPwz/wCSd+Gf +wbb/wDota+H38GeI41b/iUXDr/0z2P/ACNfcfw9ieDwH4dhmjKSx6fbq6FcFT5a5FZVTow6 1Z5F8Wk3+N7wZYfu4+h/2K818bQOfB95FlTzFjaMfxrXpXxXP/FdXn/XOP8A9ArhfECJJo1w jjK/L/6EtfHr/fl/i/U+vnH/AGL/ALd/Q8ns9K9Rmtu2sUjHzCtCOEdFGKtRQp6V9nynxtyv bWm9l7LWpkRphe1PiREXpTJQhb5auKIkUp8u8Qx82Xb/AMdWomhJ5cMFFXVhP2lHYfIEOT7t t/8AialYIavlEZLjHaq7Rv1YYX+7Wu0I61VuR97jH+7RyjuYF3NIW+XcFqqtxKnGWrVuY8/d qhJbvWcihi3brUq3r+rVB5DjtUsdq7soRGLH0G6pGWVvnx99qmivX6ZqpJbmF2SUMjjqHG1h UsVu77dgZ2J2gAZyaYjSjvXCty1fZvhL5vCeiHPWxg/9FivjS70TU7LTYL26sriGzuBuhmdM I9fZng//AJFLRP8Arxg/9FrWdVmlM8Y+LB/4ru8/65w/+gVxGsc6VOP93/0Ja9M+KnhjWp/E Fxq1nYSXdk8aD/RzvkTAwcp1b8M15bqEySaddIj/ADphXT7pT5l+8v3hXy7ozWMUmuv6n1rq wngnFPaP6GCo9qsQAk/NUCED78iD6nbVmK6tE+9c2+708wV9dFHxhYUfL81CpzlttOjIueIU lm/65wu/8lq9b6Lq0wzbaLrMo/vJYTf4VXNEOWRRUZLU1k7tW/B4O8UT/wCq8N6p/wADjRP/ AEJxWjF8OfGMwX/iRFB/02u4R/JjR7WHcfJPscY0eage3J7V6Tb/AAo8XSH5oNLg/wCul4zf +gpWhF8HPEDf67UdIi/3BNJ/8TU+1h3H7OfY8ektCai+xf3hXusHwSuWX/SPEMS+0Vj/AIvV +1+CdgP+PrW9Rk/65xwp/wCymodWBfspnzy1l7V6H8O/F+l+FdDa2m0+4ubp7trrzEA+Rtmw bcn72C3516pH8GvDUf8ArZ9Vm/37kD/0FRWhD8J/B8Y50t5v+ut1Mf8A2aolViyo0pI8hl8f ael89zaaB98rlJkhYIN3zsrbC24hV6naPSoW+JhhhWJNKiGCW3vd7X+7t3ZRR857t9duN1e6 W3w68I24+Tw7px/34d/861YPDWh24/0fRtNi/wBy1Rf6VPPHsXyS7nyn4u8V3fiuGCO7jiHk l3AgdzksqL0z/sf+PNX1d4UXb4X0dcdLOEf+OCtCK3ihGIYkjH+woFS1Ep3HGFhKw9e8N6Hr U8f9saRYXzr0eeFWYfjRRUGo2Hwd4ZtVX7P4e0iP/ds4/wDCtC0srO3/AOPeztof9yMCiigC /RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB//2Q== --------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhcQAXANU5AP/MVf//zPz7+/vlmWZSX7uWWo1xXdDE0J2dwzQqZEtLk7Osm92qRO2+ VoiIVf3XdJiUaQQGavHu8srJ2nt6rAAAZu7s6goNdtTU5eno8t2xV0Q2YQAAXCIbZLihVMql Sy4uguLf58K9rqahftbM1v7PXsyjWB8feBEOZQsLav/RWLy3yv/+3xQUcFhYmfPHX7+sX87B zmBfndCyWuGxSuvFZ+7BWvrHU9nCcP///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAA AABxABcAAAb/wJxwSCwaj8ikcslsOpOCqIBEUZwiJwVlIghBHOCweEwum8/otJo8EpEsgqM0 Q4nY7xFOShYSsAKAgYKDhIWGh4iJioIDAzgwIwdRRVETIHiYeScrfouen6ChhwM1MCJwRAIZ l5mYHCcYAg8AtLW2t7i2Gia3BQ25wMHCwwAlDwMBAyUzCxJxQgJ1rZkcLhkBJcS1BgW5Bhu3 Fd3a5OW4xwM3ps5CEy0RXAgX8/T0dimcA+QmFeC43+HG0dJAwBw5A7yGlSDVYEQsIRQ4RFCA QEC9i3Y4yJCgTxsBAxV+1TKhASCABt3E2SpQQZfAWyg10EIpcuQvlcQePGhgCpUC/zvzok24 MLTohDsgMrAg18HEx1oEOiTYAM4Eig0EcAJgWaGCAQAGOmzoINNW2LEATIjt8BVAvw38uvob 9oDBjBF9clyJMK+iggt//265k6KPNrVgC6YNCWAqAAIFWb5kOZAxZFsNKiRM+yssrQqK3b4U VpcGBAwSctyZlyAa0dfR7nAwTMxAQQ2MTQJEMU7r1pZg/RXoYDYBrgIgPwv0LawEA9MkUu+l N2FoYAUCEtipEIH2sAQfDaD4qhscTt+Ug9NKT8tk+w6QgWtlHsw5AwgHUv/kOw87hf9bDLVd UksNo8F4BthWUHkA8KbcSsCZNFxxtnTQTXrzjVYfAx/gl/9aRPzNw4UUrt3hggQB1BYaPw2w 2Bg4l0kGYWW/XFYLbps5mJxotdAHzAscjhBdDkdVQA9F9SDw1x0VdSRMAi9Z+JhUVKV11QYO 1tIACgmQt1ZZ26wF1lVZPUjLWKHVRwMDHiyAWg4CyADUBRXJQ6cA8tihwDXZGGQLSZhpOJNA Ggh6ki8DgZkLosM0wCEEK+TVxQkSAaZkf3ly0AIXA6jg56eghmpLCY6yucAbcUSxAqXcTdNC RQHYcIOotNbaXAkvrMnmCDHkBWcUGLiQRyYdKMBFADUwoOyyzDbr7LPQRivttNQ++4EHvKL2 DJzOZLCCDJdwUAEILiCQwRQeVKth7rrstgvtB9dCsEAM2lIigTMSZBDCvhngK8IXawQs8MAE mwHBCAusQEII7BgRxb0kqhICCQdUbPHFGGes8cYcd+zxxxyTgEEIcGwLhQD3pqzyyiy37PLL MMcs88wrT2JEEAA7 --------------030407060607010708020801 Content-Type: image/gif Content-ID: Content-Transfer-Encoding: base64 R0lGODlhQAAMALMPAMSfavv49Kd0JrePU9zJreuYEefayMaONbGAN86wgPfGVfLq3vKwM8+I F92fOP///yH5BAEAAA8ALAAAAABAAAwAAAT/8MlJA6F4GTzN5k9gLOBDBGXaCSS3DEAJDChn IF8m5CoXAIIEyCA4tCgvxIWTCNYoCQTg2UMiCgjqY5E4NISY7gFMMQAaB15ogD2qRAMEosg4 COTxOYLhuMvlAgIODHoDeXR6CIcHCgd/ACcpAVEFDAoKBZmKMJWXmQ2KB50Mn3EDDgWXpAUC hqiemlM9FggNlgUNAhcvogqkRQGTV764CCQ3g765QjcHt6yRVRYNmQVjHWyfxhI/1JkHSw8J ANVfNQTZuAlakgkNuQ0OA9isteASZqAC1mQADvANALTwl8sLjSrc5kwZcIcbgTsECMgB81DX jSDcgBgBIOcDQxoANxy5UbFAF7cmJBbMaHEjhrgdEl4cvLFOwsMNC6ScY4FQBI8AGrZEi7lB hBujJtQQOGaAigd2EQAAOw== --------------030407060607010708020801 Content-Type: image/jpeg; name="prod_image" Content-ID: Content-Disposition: inline; filename="prod_image" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQABLAEsAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wgAR CAC3AJYDASIAAhEBAxEB/8QAGQAAAwEBAQAAAAAAAAAAAAAAAAIDBAEF/8QAGgEAAwEBAQEA AAAAAAAAAAAAAQIDAAQFBv/aAAwDAQACEAMQAAAB8dut9V4nG66orO6CTUYCRYAgX5jn5dTt 2TbDn6cz1458s6dc2cokx2ea8Z3RZtVkES4NDmhTs5YJVdTy6MEPRzUPnjHVNqrWadp2klHa swjUZNLthTDl+EZl0I2n0maZYbJXGc6UNKraaNXlojtCsjxmebz7UVordSIT0I6ZZao1XLLT G2zjFGpadpLWyWhnotZU65SdV8z0/I4PW833vD9rz2cnf1/Gzy0R74ZoaYXGcYqXvC8xe0rQ NapohcfrTtj8v2Mlm8n3Mur5n10p3n0HhxjePTzQheFlgdLHt89kGm0LQOvf5e7l7Ldi0724 nQzJxcuTxvfzEzlWPZ5soVhdJHCpLZ7DabZrRGnVhrCm58TTtsMorac6qydmTpLkXjWaQpG2 mKVPK5646bZayXVTNSW0tnZG0ERTVZ8IeazcdkSoOS7KxUQdlrnox0VzUmmmmV5jU2Zk2juc GuslOrNEbNPk3PZE6sEx2Whok0qM2HGOqrd71dw6oHeS44oiq2afKloT0oz5zhTe3UPnG8zM HtDoF8dAAA2OBsAHcAJ5wCwAd//EACUQAAMBAAIBAwUAAwAAAAAAAAABEQIDEhAEFCATISIx MhUwQf/aAAgBAQABBQL4QhCEIQhCH+O5me05h+l5jPoefb3l415hCEIQhCEIe95x+p5b7vmR 7zmH+/MIQhCEIQgl+WV2XVHVHJ+Jv+vEIQhCEIQhBL8uP7Z7OPSRyaWuPX9IQkQhCEIQhCCX 5ZaS1v7ab0M3/SEJCQkQhCEIQnh+Gyj/AGhCEvEIQhCEIQaGMfhCEIXxnxYxj8IQhC+Ot04+ TfuePk+pnWp4YxjGIQhC+G/tjeGuPHG8nEpj+uZjGMYxCEIQvPN9z1u5j0tzw/TU40oxjGMY hCEZIjr41xdt83oc8uVx/T5d7XXKmGMYxjEIQjjc3nMF+llGUrEdBcaPU5/Bp3/jGMYhCEIe 9N929Lf5LZ3Ozj3XvfYYxjGMQhCEfUPqHc7o7ndTyxjH4QhCF5pS/FjGPwhCE/FKUpSlKUbG MfhCEJlKUpSlKUo2NjH5XilKUpSlKUpS+H8aUpSlKUpSlKX40pSlKUpSlKUvwznSf2tydsHb B2yLWDtg7Yj1mfHtk7K61VGe64+3vOI5uVb1S/6qU7I7I7I//8QAJBEAAgICAQQBBQAAAAAA AAAAAAECEQMSIAUQEyEiBCMwMUH/2gAIAQMBAT8BbLLLLLLPtfwXjL5ojVHovjRXZT7XwSNR xGuSQkdOeLG3LIzqk8eXL8CaofBEY2KJRCGHxqzL7k2h8EYJpL2bRNojlAh9Z4vikSdvjGbX 6FlZ5WSnY3zssv8APqampoalFCRqUNsXosssssvv/8QAIhEAAgICAgEFAQAAAAAAAAAAAAEC EQMSBBAhFTFRYYEg/9oACAECAQE/AbLLLNiyyL5H0bcj6F7eRsbGzY2Ni/A5OyLdifgbGxyN jY2LKExDY2NllliYmJ9SJDGzmQy5Eo40ZORl4tRRwss8mLeYiPUiRJlmKcYyVnOyZsvIlSMU dYJCI9SJGReSmUypDw7eWRRHpkkSjZojQUaEhIiumhoaKKKEhISKGhoaNTU1FESEiiWaHybX 5R+H4fhRR7Cf116Xh+WcXDHFiUI/1RRqf//EAC8QAAIBAgQEBAQHAAAAAAAAAAABEQIhMDEy QRASIjMDUWFxIIGRoSNAQlBScJL/2gAIAQEABj8Cxv05SW8NsfQaY9x0vbHz+xNp84HEL2Rt nOWOiXW0d1neOnxHVjofU18jVV/k7j89I+tt+2OjU0dNdUl/yOSMkZIyX7jU5tsUqmre5MQL 1x2XsV+JKaiE1w9semnzfChfy6mb/UcLEzM+HNzNGppl8tiE7iWGiqnzI9JIkRffjCTlkOh8 3J9y+FS4yG4E4FbIuh+pdCxPl/QGh/Q7NR22dtmg0Gk0GktT8XbH+GWogyJ5nwtj7m5//8QA JRABAQEAAQMDBAMBAAAAAAAAAQARITFBURAgYTBxgZGh8PGx/9oACAEBAAE/IcgsgiH0QAA3 QZ7u/bp1t3PsH9+YYl4HLp/e0wMcd5/x9+bEjVjjsEEEQh9EAPhzWGXig65/l5rGeGd9E+Dv 3duSfMEEEQh7wDP3Fqpt+Weo5duHm0N3+mGB1PuXVggiEIQ9wDP3EnEfe27Z9v8ArtIOlrrz bXNHc6IwQ9AhCHtA1n7CQirdwiF+UJjXrCEEPYAQ9oGMSX+Ev+V/hT/iuemEIegEQh7AYx9A IQkhCEIQQWWejJJJIQhCSEIQhBBBZNy3LJoADwdshgAx5ZJCEIQ9gEIIIJbRBzjYGMPnZ3Qt ZvL1s66Hg7CHoP0RAi5PnG3g+0BPej58f8uv0/BNhhz18/TAQi4uXi4wPGQOjZXCGYTc+c6z 9iQF2wuqLHGX2Y+mAm/+YNhy0Liel0rUaamwNV15nY08uMkaC8d7VnR1zO9r4yfD5nNnxPk8 3Ie7OfeAvQpg/sjuYMsOwGWB1Xu27OXOlxOeVmOmHmwDMD5sbuc+ZS9kUpylC3jg4fxY568/ xZ3vkZdGxh167PA5/pLLLKUpSylKUoYfYNllllKUpZSl6AxCHsBjH0ClKWUpegQhD2Axj6gU pYZQxCEPbBrGMYspYYYYhCHuIYxjGLLDDEIQ+gAMYxZZYaqkzl4PHMidJ0edv9SOTn+405Wf e1uvH+LmeUZNe5MQp87ba2sr4nfDLZ+/M7hjTp1yJjV9r5H6jn0+MZY4/wCRZ04Wfm+xt+G3 4b8N+G/Dfhvw2/Db8Njw2fDfc9Zv/9oADAMBAAIAAwAAABCI2KgGK9Jr/wAWdz2Fp2QPO2YF mJb40ORQJai/LkhMXzd6sIwrc8Mw6Aw0v5OwGyyoYfvwMyy0b1if+1S9yARcC5Mms+ghNQkU U2cMnAXQ/ERdRB9cejBfhBcB/8QAIhEBAQEAAgEEAwEBAAAAAAAAAQARECExIEFR8GFxwaHR /9oACAEDAQE/EIY+gCKw7SPnZG9Syy222y7ghv3/AGcGe/38z2ll4zkOmQMIRdWe0vAcJrxI eeBIbZjmzjHgP7BHOAdnvGsIcvBhpKGsQCZcJZDpfRZSHHj++YfN+kY599rDAUSeT9/8tB+e WPRJ6+fAsWScDHCxeAskks9GQQWXb3k/M/nftPXzahW/lgfPBBi3Rhbt27duFDx//8QAIxEB AQABBAAGAwAAAAAAAAAAAQARECAhMUFRgaGx8DBh0f/aAAgBAgEBPxBjGutKJ5VKGD5ScPFs FdAjzQkH32nhTj7+ribLHQIZmIK5ZgwEsBspa4xnseGUp6DJHzhuA+IxbtficoeNQRxJep46 klNheOLNL0GsdQhO8LHcsZpMUw2AxCCOgPaaxj6bCA2WumfgvJXQNgYg3gPqWJwZPSViue0Z XEKV8hmXM4k+PcP5ZHMHnIbMWEGwv//EACgQAQACAQIFAwQDAAAAAAAAAAEAESExYRAgQVFx kdHhMIGhscHw8f/aAAgBAQABPxA4A5CBBPjPGO2MMOyAbhbXq0QKuokezHTU0NNOYCBawXUo by5YM4mJNyCF2BhaWGHuXLTzmoWNYecEE2Q4hl2xl2XMvR6FMZvH3r0IqyQvKxFazkY0xAAy wUFG7DvlXN5bl3YAwAakt1BfBEshaVrmPjYhJtnjwu2O3g2mllf3FE0hwFVep9/SAHJKpZoz rpa+kGUKXYJRdDr95QXJusFb3vAqOVpV6tc90OzCThsvC+h/3C7UEq9C773R/ssKak0Iltfp 6y6rIWlTdunY/P3MH4tAqUvTGGZng/R9BStDDbPGO3gbM9E/uAyFQlKVX6/EQVUoApg1pFC9 uDkeD9HMoO3wDbDhvGijZhGyeS5GBas2o9iuI6PIdsTYhwHkFWcimb6Ba6ScJ567+pM30ao1 JspLAvFGP4g7d6zI5bNNBmdKvS7GNUVpei/xyQa3CyQ6Qw45ooQUDsqL6fmUhLdrfgI6aWeF K8EB17wQ10uVX6leX/D14geAdYM8IhhgghgiRuwbHykJN0pH21lLAtWPEfkqAgDgWFtHeCCG HEMGeHonTOmYWFYXv0lbZNL6XPvSunvAhsiHaFh39SMnpjaXuMEgO3sA1l2JkaufMKqqsjs8 h0vDqjij0jlw1WD4cR6i8MhZ+4HbiO+kTpjsYMTDo6VoQCAUp0Z6xWUFH2qASMAACCKt9A3G bFjoa/iDsgDoddvq5uASrIF3esceI9Zqj0jmKPgH0KmAN3nPa51G+l0B5iamxr1xrCQgVCpi FjItcqrrBs1lbt3lPAorDPeUKgtXZb3gtqwrDNcSUesWeFpcgJHlQwAbw1hkF7XTpsNoO83K 6fMAMlUA/wC/xKgF0UuqZxLEGRWemR335XnUmtws30A104h+hffs30xbgHkFUTV4pn+gqU7v D5x+hTBc/NvW/wAAk3zzjv4G/wA3W5uf+HdhJwWXfN2b/wBOrBo3YSb558PnGXlhd8yTMDmL vTswRIHlBg59z0reGivyGiyzMwAEX33/AHrLGGJRTsYe6Ostf9u4wjIVS4V57/uN9YODKVDg 7Apevr3iylpEmpfsx7DHsPpO5ek/xoZbPqEen39KgqQIKZM5ya6bR+LUFDH4uPy6FoKg0mtv 8SqhGtb9vEW0qLqv3Nr1/MD8vzM/dPef0p7y35T3lvznvM/Oe8z857y09095/SnvK/Ke8fmT 3lPu/MexKPSNqP/Z --------------030407060607010708020801 Content-Type: image/jpeg; name="prod_image" Content-ID: Content-Disposition: inline; filename="prod_image" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAACgAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAFBAQGRIZJxcXJzImHyYyLiYmJiYuPjU1NTU1PkRBQUFBQUFERERERERERERERERE RERERERERERERERERERERAEVGRkgHCAmGBgmNiYgJjZENisrNkREREI1QkRERERERERERERE RERERERERERERERERERERERERERERERERERE/8AAEQgArQCgAwEiAAIRAQMRAf/EAIwAAAID AQEBAAAAAAAAAAAAAAAEAQUGAwIHAQEAAwEBAQAAAAAAAAAAAAAAAQIDBAUGEAABAwIDBAYK AQMFAQAAAAABAAIDEQQhEgUxQVFxYcEiMhMG8IGRobHRQlJiFCNysiTh8YIzNEMRAQEAAgIC AgIDAQAAAAAAAAABEQIxEiEDQTJRcSJCBBP/2gAMAwEAAhEDEQA/ANmqfWdaGmZRkzufWmNN nt4q4WQ849+Hk/qQKT+a7ySvhhrB0Cp9/wAl40nUbm5vohLI5wJOFcNh3bFV29A0l9MnTtqn NFLTqEWUUbU/2lQtjxlvqoqUKFKqcx4ozHioUoJzHijMeKhCD1mKMxUIQesxRmKhCCcxRmK8 1Qg9ZyjOV5UIPRkpicAhsgdsoR0LjO3NGQPT4otzVo57/QIG1kPOPfh5P6lr1kPOPfh5P6kF BaVIdStRStBWoTWjZDqEPh1pU7eRSlrl+qm0Zdu31JvRw0ahFlNcT0Y0Kr8r36xvFKhCsoFK EIBCFKAQhSgEIUIBCEIIQhCDncdwn060Wwo0c/TcEXB/jci2rlFeO41QNrIece/Dyf1LXrIe ce/Dyf1IM/aPDagmhPZ204pjQsL+LmfgVxtPBjjfNM3xKFrWsJIGNcTTHCnvT2nNjbqcXg4M NHAVrSrK09ShOfGG4UIQpQlC8lwBAJxOxekApUKUApUIQSoQhAKEIQCEIQcZ2GQAA09q6xgi gdSvRgqrWHxuyRukYx+Lg2QkDnzG7bvTmmvD4s+YPzPeczdlSfp6PigsVkPOPfh5P6lr1kPO Pfh5P6kFdoIkzOcx+UVGAYHFxxNOIFBuxXPR8NSZX7nbORXrRmxuD2vrmOWmVriaY7Muz14E VCjSG5NSY2hbRzuydowKDdqVCCcoqdyCr1WUVawbRilG61JAQJBnb7Cuc7zK8vO9KvjDlhdr nMd+vrnWTZprS9iu25onVptB2hMrFBklu8SRGjhwWssbsXcQfSjtjm8Ctddsub2evrxwZQhC sxCErdXzLfA4u+0Kql1KWTYco/FVu0jTX17bfpePkbGKvIA6VLXBwDhsKzFS81canpWkgIdG 0jgEm2U7+vpI6FCEKzJXahDIaOYXE13Fgyin5A7V30yQyQguJJDnNOYtJwP4gBK3rJbh5gMQ cC4FkjmBzWtp2j/VXdyTentcyIMe0NLXOaKNyggHA03VQWCyHnHvw8n9S16yHnHvw8n9SCs0 VzgH94MBa5z2yCNraV7xpjy38FOlyCXU43iuLjtNanKcd21GhljXOc5xBOAAeGjYTjWoOzfh iuOlPy37HNNaOd68CieW/XmbuO5FKi8dvAK6i5jeKONK4YqMxbpZVE4LicF7lcAacEsZVg9G Tw6Fyf0u48OXIdj8PWq3NVDXFhDhtBqplNte0sbFK3tz+uyo7xwamGPD2hw3iqoNQuPFmPBv ZC12uI4PXp2288Qq9xcS4mpK8VUFy8rF34dWlX+nOzQjoJCz7Sr/AEwUh5kq+vLn931OoQha uNX6nNLEG+ESCTsaASabsd3GmKatHyObmlBaS51AdobXCvTRI6nmlAiyOIruYxxIp9OY4c9q Z00NbC1rQ4AEikhBdWvQf9kFksh5x78PJ/Utesh5x78PJ/Ugo7C3hmDjK4NyEONTQlgBrl4k mntUtdHHdB0GDaZgK1pVuyvQU3oRdlkDC5pq3tRlgO/7yMOSTt4i26DZBtqceBaTuUbcVfT7 T9njfS/cmbWWS5cWvOAFUxp+nsJc+RuZhwbmT0enQRuztBaTurgvL3/06a26+XoXaS8KbUAW EObsOCQDi48StHqVnnicYxUgbB0JKytxAKkfyHb0K/r92u2uYmbZ4c4bKQCshDRwOJVhBaxO wJJ9S8PdVeWOocNynvU3W2cr+JuSMNbuFBVZq5t5IXEPG3fxV7FPSBr3bzT3qJSJBR2IXTds yfpyaZ1tZkr0E/PaNrUYJN7A3eq5a/8AXWBq09vF4UTWbwPeqbS7YzSeI7uN95/0V+ttJ8ub 2b9uOAhChaMVVq8AcWyBmZwDtpcBQf078fcUzpJaYBlAaMzqZa0OO3tY4rjq+YtY1rgCSaBz iwEjHb0cDgU3Y5slXuDi5zndk1AqdgPQgfWQ849+Hk/qWvWQ849+Hk/qQVuiRh2Y0ZUFtDIz PxNBw2bdq5WP82oDO0Crn1a3YMClrHNn7Dyx27Lv943e5MaOyt+xvEuGHIqm8t1snKZ4raAB ow2ALkZsejiicOiwJw3FQcuXABfObeu63G88u2Yvl0jfWtFxuog5viN2/FLtYWOJY7vOrl4m noTyXaKQNIjBqQfT3q3W63trU8XMKxwySEUFBxKZZatZ3jmPQvd04MxSsNzV2Vd3rveSxe7W zPBi/d4NuwDCp+aQtLsk5XKx1eIuia0bR8lSwRuzigxXbZiqevF1tq2lNW1SVrZvu38Ix3nf L0wVwy1GWsmASc+txQdiFuamHAK01+a497MraKJsTQxgo0L2snL5iugey1gHInrXa08yuJAu GCn3M+S1m0ZtKheIpmTNEkZq07wvaslXXEoZI5tzG6SM0dGRHnAwxG+hr7arvpzXNi7TclXO c1lAMrScBhvovV08sZmaaUPR1rpbPdIA5284cvUoz5wt18djiyHnHvw8n9S16yHnHvw8n9Sl VQ2hox+3ZuPRw3rtoP8A7oeZ+BXKz7jz6bCu2hD/AD4uZ+BRLfOaHCjhUJR9g36DROIWe/r1 3+0TrvdeFJcxywdprTgKYY7fh079gSNjFLHK+ebDNSgOBwWpJA24Li+eD6ns9ZC57/n1xddb y2ntv4Zm/vC85WnZwStrIRK01+ofFaOVumSHt+ETzAPuSE9rZucBakl+2jcWinNX19U0kkTN 8/C2ummSQMbuC9RxRwHDF65+I9ozEULscy8CUNxKvtfn5Ri2YnDvO4lpqsnM05itDLdseMoK rZrepwWcrLfSxUvZVLkUVo+3c3clDbukcGsFXHAAKZWTvpV3cQyhkAz5trNx+XNbME0FcCq/ StMbZR1djK7vHh0em1WK6NYknctkqHA1oey0NqdnNdrSob2ttccKfNcbrxN5aGV2mtR6wV7s SCwUoRU4itD7a1Vf7N79Fish5x78PJ/Utesh5x78PJ/UrsVDaYseN1OHQV20H/3xcz/aVWpv Tbj9a4ZNSuWp9dCmUtzqOqR2Dau7T9zB6YLMu1+6uZMuYMbwb89qVmuDJmfIak4lV8JOeqzt y064w0Gdz8XuJPSUpcZVw8ZKXNxXshYzW2tbtJHeJuZ4WutbT9a2L3d9w9gWb8u2LryfxHf9 cfad0ncPTcthqLstu53CnxC2mvyy7Zsju1oyhpGFEncaeH/9bsp6cQnWGrQeIXpXslVm11vi qB+nXDTsB5Fdo7SYijm+8K5QqdIvt7btOtVrdPc7vED3pmC0jgNWjtH6t6YQrTWRgEFCCrJL XHjf/OmWnCp+Xx5LpagAYEnH6vQLopbtCjHnK3bxgwsh5x78PJ/Utesh5x78PJ/UpVZ9ti91 v+zmaGl/hUO2tKqLi1kspfDmFHDpBTFlOwsbDOD4VZO1uDnNDa/8etM2z2X+oReKA4Oa1rwd hIZTqRKqMlV48SmxbG48qWshrG50fLEe/wCaWHk5lcZ3U/oHzVeq/ZlvFJTFhpk2oyZIh2fq edjVrYPKtnEavzSH8jQe6iuY42QtDI2hrRuaKBJEXbLlZWcdlCIItg37yeK8akwyWsrRtyk+ zFNqCA4UOw4KypPSp/HtIpOLQPWMOpOqk8tuLYJIDtilez1K7QoUIQiAhCEAoJoK8FK8uFQQ N6E58lIb9s0Lp2tdlbyqaLvaXAuWiRoIB4pRtu6IRCJwLGdlzcMc2/2puzg8BojGwE05ElVm fltvNMfx/Pg8s55l0ya98N8VDkDgQemnyWjQrMXzuMXlg0sMVW1riK4+rkvekyCXUonBoZU9 0f0lbqXwvroq6T9PxBl7/wBOXagsqIoVX/xb/ER/BvzoLChUJD/G/Jeh+r0oHVGYcQlB+p0r 0P1EFXoxyXV7mwaZARXCveV2ZWfcPaFyH6q9f4vQg9eKz7h7Qo8aMfUPapH63QpH6/4oPHjx j6gj9iP7viuo8D8VP8P4oOH7Ef3e4/JBuI+PuKZHh9CkZOhBS/o2o3v9PUn7XIwCOOpA+5Od noXoU3IP/9k= --------------030407060607010708020801 Content-Type: image/jpeg; name="prod_image" Content-ID: Content-Disposition: inline; filename="prod_image" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEASABIAAD//gASQ29weXJpZ2h0IERDSSBBR//bAEMAAwICAgICAwIC AgMDAwMEBgQEBAQECAYGBQYJCAoKCQgJCQoMDwwKCw4LCQkNEQ0ODxAQERAKDBITEhATDxAQ EP/bAEMBAwMDBAMECAQECBALCQsQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ EBAQEBAQEBAQEBAQEBAQEP/AABEIAMgAyAMBEQACEQEDEQH/xAAdAAABBQEBAQEAAAAAAAAA AAAFAAQGBwgDAQIJ/8QATBAAAQMDAwICBgQJCAkEAwAAAgEDBAUGEQAHEhMhIjEIFDJBUbMj YXF0FTY3QlJzgZGxFiQzNUNiocEXJTRjZIOTotEncoKyROHw/8QAHAEAAQQDAQAAAAAAAAAA AAAAAAMEBQYBAgcI/8QATxEAAQIEAgMIDQoFAgUFAAAAAgADAQQFEgYREyIyFCExQWFxgbEH FSM0NkJRUnKRstHwFjNic4KhwcLS4SRDU5KiNUQXJYPi8QgmVKPy/9oADAMBAAIRAxEAPwD9 U9CEtCEDvG5AtG3JlxuRSkjDQFVoSQVLkYj5r8OWdCFWUrfWY4ywwzFp8GbN63qkd15Dde6Q 83OA5TlwHuuM63tG63xkroitvUGXeLcCo1I4cmudAPcMZgGlwiZ88KvlrS21JIlKr1cdCPIW rTldPPjCUeV+zC/5awRCOuWyhVRvN6V0TYS4oVBuql3VPakMtvy5cCcGYoEvdEbcLLyiniVE Ue2oymVFmruOBL79kff7kq+BNN3K7bWvB656JTrht64JFRplXiNz4Mpk3CF+O4KEJoiqiplF 7ivkvbUuYW66btlcKk0So1gxRfWKguff9J/51ot0Vh1KY4/6oEh430FCJlCNXEFVVEJR5ZRF VFRCVMLhfhoQikeZKMOQyHE88ZMs9uy9s/HQhcHp85vl/Onv2OL/AJ6EJq5WqkgpxmPf9T/9 aEJm5clcBcevOJ9fJF/y0ITN68a+HsVAl/5aaEJkd+3O2PJJ37FEf/GhCbPbl3aA8hnN/wDS FdCE2Pdq7Wh7zGVX9QOhC6w93LoPJG9HJO3mwn/lNCEYh7m1940Awj58v6PGe2fjoQizN+Tj aRx5WQQs4yKJnHn5rrd3QtfOlkkHHhbRSDc8mYHUBWzHyyOFTKe7KaSGIlrAWaUA71J4xk7H acLzMEVftxrZbrroQloQloQloQoNvYuNrq9+ra+cGswQstXrYca83LTqEyQUZuhT5En1hp9W nUR2K6yTIqioq81cbz+r1BzRPNTzb92qfEn5zDbDNpihNq2Tb9Drx1CMMpyYwqtC9JkkRAPH iiInZMYT4anI6xJgGurUfLhHjrxxglXCfVpGclyfZcl/PhGH90EqNrRCSr/0jrOh7qWNPpLl luVWsOcW4qsw2ykG8vFAFHiwrI9+7iEiJ79cYwnJVzDVcelQ32jjw9PPyqyToy78jeBLjYvo 5RqHY239rVurFNkWtR41IqCgSA0YlIOVM6bipyITFx2J0hQctSDLlhMa7XbaSqwkJDqo9S/R qWlOR3qFuE9CJtyM8o/gNo2zJhmODa8Rkjjxx+quF9p09ZQiDPouwEedOJfTkMZMdmK56tSF acAGo7rQG04MlCbcFx43xJVIRMj8C8s6EK8LKo9RoNFbpM+pU+WjAADfqFK/B7SYFOovT6zv tmpn7XbljQhEJX52hCHO+zoQhsvQhDHPfoQo/VqtDgTIUCQMhXagRi10mlNE4Yyq48va0IUX XcG1X1aAJkpDdjpJEDgvIXTUeWVTj5492hCaz7toMY1afkSG1UUUVOG6gmijy7Lx9ye7QhM2 ropVXpsgKBcQx5LZNoj7kNwxbVSz4hIU7YRe/u0IT167pMfnUGdxKLHhxHcyOpSnF8PIlTA8 V80VEyK99CFJ5tKotTmg5cHTqQ0+mR55qTQiskEJ0SwI9kQiJvP2ap+IZNmZe0T5KEn9pTLb Ckx6DTapSYkcWm4dTNjiHs8hZY54z37lnUjh9sQZsHZgn0mNo2Grfhf7HH/VB/BNT6ervoQl oQloQloQoLvb+S6u/qmvnBoWYLNVys0+TSKe5Oeig+wSuwheIfG+j7CJxQlTOPfjURVtXQfH kUfOzHdBFArWh3VHuR5+vXNHkiuASNGjI02juE7qqpnH7dSk063LDpXSyFSANE/a0Csg5cd6 My6y8LiNGQur+gqIi9/s03lZ+XqA3yrl62flSlhsLjVQ7n7lbo2HuAY0OglULcbh0/m30D4t yyjVFx1DMQUkbJGG1c4qhITIoi+LT8NmxaNt9xsuTyDvbuJJNisBTbdj0Ol3LHosh9pqUS11 koMt4XIpOLxaafcYaBlU5eNwUUiTKaSsIUoYNtCNikO2e/V8XheNOocqz6CtLcqDNOkVWAUr pPE/HmPC/F6goKNtHFRpzmRZNVxxTGspNaLh+Ljn36EI3GARFcfDQhNpX52hCHO+zoQhsvQh DHPfoQhslSQVFCJE9+Cx/DQhD33XFHxPOL8fEvfz+GhCESCXmpl3Xz75XvjH8NCF7AcMvDy7 L2x7tCEaCqUiAcKHUqpBiHMeSPEakvttq++vkDSEqcj8l4jldCF8TYFiXccYpd1R+pMeWite pVkB9Ye5czip3VHHUVMq2niT3p4tRc/h6TqZaV0vj1Js7INuKcWJSqVSKQbdFqhVGNLfOaso pIPq84a4JUMey+z7vLW8hTWaYOiaJKtS7bGwrQhf7HH/AFQfwTUilF30IS0IS0IS0IUG3oHn tjXQ792W/JM+ToLqDxDVCotNdnwG6IZb3OUIfinchL7rmBa8qzU5V2ZENI0ik0+QsY8tOSG0 Imy5eY5TsuUTXHj7K846zfuYY5cF0LslavkvK3XzGSHiRtK455KpqDmCFS5JnkiChZyOFz27 e/VSrOK65XGyKacIQy2IRjAf7c1JS0lIsajQwiXlUjt9psKc5xHA+skqqg9/ZDvj7NdT7Ef+ lkYbWfvVZxA1dMaLyqBXjunuku5YbW7RwaaNThwxmTJc8cBhQ5YDkSCgj27+arrqEwRDqBwL mFXq88NQGl0wYRPL3csFZm2V2Xg3S2Kbu7VKHTrrOQ42xHi1ABV+MvHpE2HNVVVVD9n4a2bj YKlabMPCItVLUd61YI3HRwqTdBmV6GlRl4VmE5MAX385VMNkWSTsq/v0pepE3WWnNEbmtBeU vcrbufXFtqHf1uyKsHnBaqLSv58/JD7+XkirrUJhtYYqMiRDa9CKiFtekxQKzvhXdszmUCFb tIpgus1x2ooqT5akz9GCqqNoiI4fZF5ZH7dItzF7lir7WJGX6kUndCG97lZFy3zZNszY0C5L wotLkTMdBiXUGmTez5YQlymfs04vVhmqjLyxCw6UIGuVQrdGhSY8CdWqbHlTQ6sRl6Y2Bvh5 8gRfaTHvRdF6UOYbYcEHSHfggbN52ZU4lQnQLwocmLTP9tfZqTZBFyuE5rywiKvZFz3XWsTS G7ZW4bnob3Cqk333pqdg2tbl4WA9RaxTKrUjp8qQZddsMAhJxIDRELHPsqaTvUDWq85LNi7K 5RC7LP1KO70b+V/b3c1i1qPTaTJokaNBeqsh5tw3GEfNUXBCaImAwqZTz1jSptWsTOSNQFpg YRE7ejOKNPbkV2Rv3K2phwaa5RmKUk9Zacuvz6XUROXPigryDz92s3qUOsuP1YZARhAIDcUe j9lIY9wUCqyjptKr1NmzAyhx40lt1zKeeEQs9tLXqTanGXe5aSF0V9wK3b8d4mp1cp8dWXgZ dRyWAkBmvhBUUkwRe7trUj1U4jNS7XctIF4Rh9rNVFErN9bzxrptKtvWuxQ7fudmLUH5uYMl ung44vFh9BNG3Vcba5OLwXjlBJFLSDTt5KvYfq5VIps5goALZfq9y+XNgK9HoLdSK+ttYDUu mNW2zUDkmERjohEQKsySgnUmmsXxgCp24fSLx7uiO3aVgKclWta6HSr29F+jXjaNnSLXvS5L XqUSPPSPbL1FmdVp+A3GZAyFFIuKK4Jn0/aQicUva1ja1kE62XdRL1LSsNf5oz+rH+GsraBX LvoWyWhCWhCWhChO8/5Mq7+pD5oaqGPBuw+/9j2xUzh2H/Mm+n2YrHt3tT5FvSotFh+uVNw0 OBD6vS9bfaL1hGOSqiJyBhzKquMIWvPVAho5y67Nn+7/AB4fN4laK4OllyACyJQPb23Y8e8a JV/oZbLkCqTIs1lhuSDzr4Nsy3kkEKmKLKZkCgi4P9OHhNHuSWbEcyJSUwI7Op5YeW3V9XDD +3jgsOy8w1aLu/vxV82546Yfhz9MWU5f3Q9+rt2IdSllf5fesYo1XhtVe7pbRXRPutndXa+v FCumNHETY6nTWagDxy2SpjkqdlAkwWuozA3kuT4hos0U12xpbmTsIZlxcXPBVzfV61bdDaih b0uU9uJdG3tebg1A2GuKEDnBxt4U82/GmFHyQlLHnpKMbW7/ACKInZx6oU9ioulG9lzIumP/ AGqZpT5+83pBbh1213m+tRLQcgUiQ2YiCSn4yNNohqvZeb0hUVPJNZYEpn5pZaaer09Mm0X8 vV57RQf0dT2mtm77esPdbaqp2/fUOcIwKzJfeFt981JGxcaI0QUXPBCAVBfimtGxENRJ4eCR lJxuVnGIi6Ud7l3/AEVJtstmNrqv6X9+WBUrLhvW9QoLcyn0/wAaNRXxWCqEOCRVXLznZe3f SIBa5enMjTJf5RTDRDwD+IKu4dQt+9rk3hql8bY3Ne9frEyRApU6nU/1kKUQq+23yVTTp4UW 0TiirgdOL1ENmMzMPCbJGfF93Ivl+36hc57A2fuNTakwRyJ9GeYktnFkLBScAgKZwYoolxRf PjrXSEsxg4+5ItTQxhmHl9NSy3Nkts6n6Vl0bYyrb4WrTKa1LZpbMx0Q5I3HVEIs8nERXDVM l56xElLydDkyrz8qZasIR/FVxGpAPejTuQ2yPBu3r0hSYraGvgyLjBInJfeihldJ6yjJUBdo 73HAXPu1UdusI1+29vrecbkaRI9EFky7+FgmhPGfqDRaSUlpgavKzc60PBBq3oPf+5CriuGq vP7qXhSnnG3HaLQqUEgc8mwktx+aIqeRKLZp/wC3RrJJ2fe3PMzQeRsc/XCKLbnWHae2G3di 3rZlJGn12PJhOuTGXCR2SrsYnSQu+PNPd56VuUhO01mSk5KaazuPL8qkVB26tW//AEhtw0uq DIcSnSIc6MDTvR4PL0+5YRUXjnRrGKXpFPZqNVeddz1NH9+fuVb1+sTxh35RX3CiUW4NwGI1 YqCCpKy2JyiFF7d8qSkvb+zHSA3CWuoESbEX2LbA0kLo8msrk9JGw0odS29rUSwHrp29tanO QZVJhEaAGCyhKreVbQm1Euoid/eulp+4bdVT+J5AmCZmGm72YQhx8kOJXx6OibT1vbel1jbK 3SiUeNPlOx4k76Z+BNIvpxFwlX9Lsor5Lp2xDuatlIOTmZMSldn45FoeF/sbH6sfPuvkmlFK pxoQloQloQloQoRvOuNsq6v+5b+aGqljk4t0B8x+j7YqXoP+oN9PsxWN78t6Bc1tv02pViVS 2uu26EuNyUm3FJWkQgFU6rZo+YGHvQvPXnTC85uacEWhvz4YR+Nr/JWquSm7JMhuyy41HbTq Q1qpWI9xtnn/ACdmuesQKe62rgKshpuOzlUFhr+bo70VFcqLvsqKcrDXmhalZrh3zhvZ72fL DzuXeTKh7LYeTeVz2146c5gs83y7r3VciGug9ij/AEtzo/FR+KhEpob1D7ytz0gJ1zz5e3e4 lNhUepstMjEl55xFAOJE2StFxVV8WunOtOLmlWlappiCSc1I73xvrnbu3u32z+ztfsDcG9Ke j1ywJMuoOOuo0ryo2gh6u2XiJQJAVMd1Is9tJhC1lwCTUZCVplLelZpzXOES6YZ/qXL0SLOq UfY2v1ij1IqTWLsdfSFOUV5R0aDosuJhF7I4Ti6UlhJpu8U3wlKzUtS3JgC34/ujcTYHey9r 4ta4d8dxqDWadaEgXorcBokefVCElEl6YIPIhDJFnWbE4hQqo5UGZqou7Hx5UZu70e95v9NN c3d2e3IotAK5Y4tT0lNOE+2KgyLnAeBCvJWGyTumNbWJSaoc0NSKflXNrejzb3LyJjX9hN09 ubyuq/Nld26La9IuRz1ypNVjINR3FNSM0IgIERDNVQi445Y1rYk3cP1SUeJ+QfhbH48qfVHY rcK67h2lvOs39Br0mygV+p1HpOn+FMykeEmCEVDHBOKZLGixKu0Bx95h10syCHD6/en9q7bm m/Ff34p10UmqUOtwXaYyzBcV5wHmOm26imKK2vEo5oqCWUXsvlosT9ikaKpPTt23BQ23PR9n 0Sw9xdrZ9yUmZVbxdSqRgbaezEZVxUB5wCFFVOXZFHz0WKNk8PaKTelfP/Zd7B9H2r2htjd2 3lcqUWoS7tJ/+dMxnRbwrKAOUIeS8STPhRdFiWpeHBk6a9IeMSjtg7BRYO21y23cF0Q621dp RzbnQBLgAMBhkh5e0qEnu807aLE2kMLCxIusOl84hjWx97VI7dom4m4kWp21a8hHosWLDJqQ 6iJgRcIkRERE8Pv8OixDWGZhxxpp1/Ub/b6XIpxZViSqBuTdl+SKpDdZufpdKM004hsqCoq8 lVMLnGlAaU3TaN2vqD01pL4Rs/xQeJ6OUifam49uza5DecvSotVSE4LB8ae8064Yqefa/pFF ePu03NpQvyWIG5kS/mxzh/l+pSSRtRv87att0S198ItKlUekrR56pDcNqcCOZB1VIFXmLeG/ Lv55TSjsrMF805n8c6eTtEqD7IsNP8Xx4ytDYTayLszt+zZgVhypmD706VNMEbA3neKKgCq5 QUQE8++gibkW7ppyAdMFJUalFTZfRXRM/jnV5QSQoTBCqKitCqKnl5JrYHBdGBhHOEVJp1pV CWhCWhCWhChO835Mq9+pD5oaqOPPB+Y+x7YqSovfwdPVFYz3GapD9h1+PXpkqJBOG71X4jfU kN4MVEmg/OPlwwnx151wxpO2Qmw3C/6R2jwRV1reh3D/ABGdn0Ye5CrIfptxrS7it6mvQ6bT vw3Sz9bEmZCdWa48LANdFEUcq2an1OxN9Pgup7FTrkppJecchEzgBxsyiPB50I8PJb0qPw6U u+yLrAxshva2cI73OretzxQHeQ4+ncyidseENdG7EZNu08rfjhURigxJ4VIYC8FQk4/ZxTH7 tdbIyJV2wvOTG69rdv8AcdYTl7W23U3aflIzvVNswEschyBJlFwnnpApcXdtMZ+ky9Tt3Vv5 eTeU8olNptIgRqZR6ezCgw20ZjRWR4tstp5IKaUECEbAT1qXFhsWhHVgpBDHxpjw+72U/wDG tLvoxS0Su20aZbbITQ2xLn3XIouth1uRJaPVtUF3qsafuRtpXLGpUyLElVVIaNvygFxoEals vFyEhIS8LZ4EhVFXsvbSZ6njLcRtG1UxUvRduSmvx2LJv5yFAgVVomPWqrOaciwm2Ywg4DbA i11m3QmEjKCLK+t+Je2siJI0RecojR/RR3QtmlrR7f3GhsR44QvUIzNVnR4LJNSG3TbeYFgu u1yFxzHMFMnnEXj7et7VgmLB1iTt/wBHjdT8FuQx3GhvsBIk9KO7VaiXMHXpLjLrr4gBuPsq +24KoIiRMgJIQjz1kRHzvuzWB0YlfclI2Bv6DUIsmnbmMgK1yNWqq7KlTuq/0J8ySDjaJyRo kYkR2VEeIfRYzjzzovNz9STdJsnNrfVjWhQDtOz6VbMh5t1ymRuiTjWRE8m4SYRcdk5Y7ppI hLl/sSgMauoS7PJ3XgP14HKaQfmpeW76eg36UYQ61s3LPENgN8K9idTKGQ4T3p7l1Az+OcN0 oe6zrZ5+aQxy6IRT5qkzz42C3qwRhmosxwT6Pkvw1z2pdm6gyZWyoxd/x+/KKmmcLzj+2WS7 pc8wMJGZbbFPj4sfv1Q6r2dKw6NtLag3zwu/LBSkvhNsXL3UPk1GdMLMmY84KeSE4uPsx5a5 bUcV1qrldOTJ7/FCMYfdmrM1T5VrZbhnzQWgbV/Fmj/cI/y017TwhGJYdkCL+i17ArlNShbO vekXWi+rEmSWhCWhCWhChG835Mq7+pb+aGqjjyNuH3/se2KlqBb2wbu5fZisb7gS5ECyqzKh 9FJTTPOMTo8gbeR4EA1RFTPFV5J/eQdec6E0L9WFgx4vLbxErVXn3mKTpWi4OLK7yLrZtReq 9pUqpSakzUXZASDOYw10m5SrJdRXxBfZ6uOquO3JxdZxBKixPOMBs5Q2o5x5dryLOHJjdlPF 0srua1WBa7JLS3CEv/zC+WGntH7Iz2DJMWgZzz6M+m2PlWs/Rhni1UeZd6I8vf8ADVjY/wDU EP8ANkP/ALY/oTD5Guf1E+Zq/Rxlkj+wkHH79SH/AB8kS2paIcx3flgtCwe8Ow4ica5YYdnW ZSL9RJjT5js9UnxmTWPkfMf1ETj3zSG/EUOYqp7umP8A505/454d81z1LX5KTn9SCet7j0gQ 8FNmEvwURT/PST/Z2oLQ9ybOJcsFn5JTnjuQTdzcSCaLwpcpP/kKf5rqPPs8U0v9vH46Fn5I zH9RMHr2aMshS3vq+lRF1qfZ9lxG0JLP/qW/42JUcIlbruJk9dLji4Cmtpn3k6qp+7Gol3s/ kWxIZf8AU/7Es1hIRLWLVTQq7MLwmyy3z8sZ79vr+pNR0x2c6xbfLswD1foTn5MSqZHPmGfh cEPFlET498r9uoKZ7NuLX9lwQH0A67U5ZwvTw2hXAyfJcn7/APH3rqtTmPMTT12lmThn5ucP ZyUg3Rqe1sivEIV8XbunZfq1VnqtUH9WYmXI85kX4p01JMteLBeLjywqZ8kT/wDvr00uEtrW Ll3v/KdgIjsr32fLsv1/u0mette5Z3l8iTR9x4r9fn56zHSD4y1ycX2qY9oca1CHjraC0Pan 4s0f7hH+WOvfGD/B2Q+pa9gVx6qd/PekXWi+rGmKWhCWhCWhChG8/wCTKufqW/mhqm49j/7d md/LZ9sVLUL/AFBvp6orH93TIEa1au9UbiKhRwYNXakkZX1iDy7uo2iLyx5fYuvOFBa/5sye hjH6OcfJHj4Vb6seikXg0kA6Ifim23sn1yxKJI/CzlUHoOttzXGukshoJDoNnwwnHIinh92n WJmtFViG2zejvb8etN8NHpaeJ6SB8sModSsq1P6pe++F8oNUbEnesv0/lVhktokY1UlJJaEJ aEL7ECymlUkunH69FmlWkStXUGfzSHTtqXWl66eq/wB3TnchLSMxkugU4VNAdEVBVwSLnui9 vdrYZC4rSSbkwVurwqm5N6byFUG6PG21nOtNSXnH6i5BlMifCr9FttEFkhcbKIoGSj4lDmoq qiur8xhmgk2JvzEIb0NXP6G/40PG4OXhVfKpTQ3AAofTNwd9nEaCRtPKU5zzbrau0yUDUFha c06YGqFkuEkuGVJV9tFxx04msJ4ZK2ybhAYQ8vCV3P5vxvpBqsT1uu3x/HEhkXdveGqyqxR6 bt3DWp0N1pibCGlTTUHDgOvA4KkYtkBOADaChc0JxEx35a1jhOgsMtzDszqHs68NbXgPUlO2 88Xi6yLt1vf+Q5IpQ230FcSTyqMmnssqwqvuKyLPCUoOKLGBU8Y5d15cdN3KfhIXr3Hcow4r +Tm4yW+6KkfipzZlU39k23LlbgWfDiVOG7R1jsQnI5Py0GSz+EEQlfJteTCO4VSbXl5e0mmU /L4XGebCSehEI6S6PFsx0fLwpZqYqRCWqgtJmekrSgej/wAl49RZ/nCtuyJcU3hdMXBbRVKU XgAlawg4w2BmXic4C+mJXCb7Ym49AI/R6OTh4ftb3AN0WxFVmiuEV9P1z0lma/HoiUmkmjrD kn1hqkAccgV5hVaJ7rKAmDayFDxeNRDPHl4dRksHnK6W6MOLb3+CP3Z5ejyrLUxUCLWVgbfh uIMGpruKFNGR66pQfUWwAUjkOeCoJFniqY5qvJffqm1uNH0jY0vPg1t/P45lPyOm0ndVrK1P xZo/3CP8sde1sH+Dsh9S17ArmVU7+e9IutF9WNMUtCEtCEtCFCN5/wAmNd/Ut/NDVQx1Aiw/ MwH6PtipWh29sG7uXqisfXNMk0+3qrNhzqXDfYYNxuRVO8NtUJO7ye8cL5e9ca810GXF2cbB 0YxHPxc7lc6u/bJvaItb6UIZetCNr7hgV6z2XodSbqBRJD8eRJjxjZjuPKZvF0BNELppzwiq mpTF0ruSqWfR8ufFx58flTDCsxumniX4ZdXEratX+qnfvhfLDXPsQ60mx0/lVlkvnCRfVSUk vB1kRWpRtXQWkJM8tZtWL11ZAz78fLTgWkmZWp41GVe/H9mn0rKkRJqZ3IhHieXh1OsU65NT dT9qBy/N1Jt00iTMnV0GC2ZcHGxUF7Ei9uy+flpx2oSZvkI6nCqXqE/0knJUlilWXDcjnJqH QkyKewyTLLTihG6grM+kUw4OIoJj81URR1cToVCBkSf2tXjj8fHGohudmhJD7rZ9IKl7ly4t ux3Jlv1asw4NNclMQ5EZqIkEnHXgETA2vpANHCcUlXkAtgflrI0vDL8mOlHIoQjnrlw573H5 P/0kjfnLtVDGoHpQepQGXihtIwDSTknPxHnZTixFF0kIZCowiuNtinREU+lIsZTUTPS+D7uW GzlGOW1vc/2ko3u65Ngh+kixQDjx3Ka1UIDaiwyrsMkfRBgiGXnFcJV4+umpEuVJvuq5HUQ/ 8lovEbpa0Y8v0uLMfo8ClW4VC7a+PUvq3138g33RaddUh6ZQJz8l6XJgw4TjDIg1hth1wW0V sFXBCqYLlz747aQmxwy5JPHKiN4Q4yK6MS4x1v26VtdONvNiRcKthQVRVfIkTGPhhdcxiQ6T kVnbMtkl98yxheWFXOOS63iZLbRCvMe/34RFX441hvaWRG1aItT8WaP9wj/LHXvjB/g7IfUt ewK4/VO/nvSLrRfVjTFLQhLQhLQhQjef8mFe/Uh80NVDHd3yfmLfoe2KlqFb2wbu5eqKxlfr 9Hh2fW5VfjyJFPajKchuM70XlHqCicHMoja8lBeS+WvOWGN1dsm9E5oy86PH90VcK9ucqa9f rj5nHw/HHxJttk7VitkzrlS9fRZRrEL8IMznm46CPEHnmkQSNMrn87UljQYDVtm3ej0/S5iU bg63tWNpZ/hyfZVrWn/Uzn3tflBrnFf7zZ6fyq1yO0SM6qakV9NChZzrYVoa7NNkq/VrdJkS fxo5KmNT8nL3JobifSHqfR4oSqjKbjgZo0JuFxRTXyFFXtlcYTVrk6YKYRib5WNKB1Df63IT qMwKZImLw5oajwFUVlST7FRzAKnw76sMtICnjdEm3UYpW+NuOP8Aq1SgvRUwqq5xyiYAVTin mqkamKJ7kHUgDDYlYkJrDs8wNytSnHCng3PhyGX45OKgG0aEK4JEVUVMouFTT9pgblVHidhq Kgo9j+lFTq5VVpt3R0p9SmILTc2YxKGPHSWbgq31BJRUmi6aiiKnFBwiLhUtDo0XQiMwOt8c qjYuPXJUu0vSNq1pVmFuHKgzZEoKFIZjR6i3TDkI1I51GKj8MFJoTbEBR3lklXGBTTWEvRWb XdDn8c6UIpoy1ELkWB6UbINy5O5UEChc3FixjZNJCI24XFf5inLkfTUBQg4gvAlIslqtzDmH 2tQ5fr/UnrUZxDqdYvpBTaPTgr24DMWQ3HYnICzC6zEtSZVGXlajgLggguEWEQTJeHDiKOar k3PYZlJhyxjMuD4zOO/1eVPmpecLxk8suyd06FVKdPu6/wByrx2mHmZkV2YRtqqx2BbUU6QI pC6MheRJjgXfxeVbrlYosxKkzLy9peX1/SLkUpKSr0HhN0lYK48SAOPqTXP4wLVLggrBqiQ3 Ja1SyXw1uCytD2p+LNH+4R/ljr3vg/wdkPqWvYFccqnfz3pF1ovqxpiloQloQloQoLvXhNr6 8pDn6Fvt5/2oaqGPIXYffhdlse2KlKN38HT1RWQrumSIe31dmR6g3CN11hlZDgiTUcCXiTpt nkVQEJS8XbXCaC1onC1eHxFaK73uSHbd02DR7WjjS/UVF9ySbr8FpG2JZtyHGUfEU8KdQWkP AeH4aZ4jd0tQH0fVvcC3w73iKtG1P6mcUeyeuL8oNUfEnerHT+VWCR+cJGdVNSKQj3TSZbSI xROIzzT69SktKkSYunkjMNtuKCyJTgtMtipOOEWBAU7qqr7kRNXSnUvWUQ85kNqzhdm4bVdC ddlVkOMUwA+gYXGUjguQEu+HCU8kip7i1c2KeQ2q50qWGVlb/GUVi1V+txpLoslTj9UecY4m ou9RQLCrjvlMafNyosPDalTfF9kiVf7R3fK/0ZUaoVecU9o8AsmQ4rhtovAVXK91QSXui/m6 mcQ0vTzBEHlTSmTtza0x6N19uRbuOzHp3OJVOQMsERmrEhsFJABF7Ngooar9fbTaVaK0WlE4 vkR0YzQcS06bIEiKPkvdNPNzrn65OxkIe3fTd+XSzR2ofJY93v8ALUFMS+0nrZqO1JpsEUnC wg5TK9k7fXqn1GTK1Ssu5dsqOvCyKmTTgmnbOCz2Xunl9uqdNNON3KUbiRENyYHyE11XSEjJ SFokKWsLZL4a3BZWh7U/Fmj/AHCP8sde98H+Dsh9S17ArjlU7+e9IutF9WNMUtCEtCEtCFBt 6E5bYV5M+bLfzQ1TcfiR4dmRDh1PbFSlGIRnm7uXqismVmNJmWVWIDNShwEmGLJyZbCOsNio Eiq4BYFR9yoXx7a4VSJoZNsTdzj7XuVwqMuU8JNNIZZ4T2bZpsOpDHKVHQ4rixWAZYTg64IK DYrgQUBBU+3UZWX2357StbOUepZozBS0rojVkWn4qI59+X5YaqGJu85fp/KpmS+cJGQHK99V ASuUhenDLXIvEOdOWJcnXEiZI1TmQ9r9ip/j/nq2yDVhWmox8013LeKmbaXMkci6xUqWjZI0 jq8kaLtwJURc/BVTOrZLujLTTbR+PFMGs35gSWOqXTG7gtuj8CFuI2LHNoeCpgOORwJkHZfc K4Re2e2ri5NbkeJg9ryrpsZcn5UbN5aRtv0Xm5tO9duOvvMSpQK4jEPhkAIVTBGQqirhe/H9 +njFLcBvSmWZLm83iFsSKXaHVVIbjejA9tPAi2vYj3K2pEhQCK86pmx1FRTNCxkkVU7iv7NN pmvORnCGdGPpb2Sl6PNNzLYtNDFE9tqF+DN5LEZVvg/NrnNOo26QCIR3TMOYHxAlETVOYqi4 XHfT+iPNz/dWh1Uvip3+BIfG/dbjkzoUTtMfaYRMd3FQfcvki9/dqZOLLfzpZLmoNuFsb64t VGmSlzCnR3vgjZZXsuPLTB12Xd2ChFbkDobYxQO+LigWfa9UumoNuKxToxPEAipEa54imByv clT7E76j5iVtG5OJKG6XhYDyrPQV+tV9tytXHVCRx8OsodXhHYFFMkBE7IiAhKKmvmnnqjzU 43NPbnaGMSXU5WRlac3vIfEr0cx9atutR3m1JR9ZiyReBcYRcKiqnZEQfs1FzVO3KJaceHgT xpiXmhK1Tq264lfpqzHY4svNGrcgfZBHExlA5d1Rc9u2qNWZDcbl4cagnwKWc0SJagEol8Nb gsrQ9qfizR/uEf5Y6974P8HZD6lr2BXHKp3896RdaL6saYpaEJaEJaEKEbzJjbKupj+xb+aG qfj6F2HZn7HtipWhFbUG+Lh4OaKyFdcJarYFapQwYMspptRkYnEqMGpJhFPCp2FfH5/m4/O1 wrD0wMsQiDhAXJ/4Vrq7JTjZaUbx5ULsG2IFrWwxTocGDGcdNXJawiImX3RJRR4VIl7GggWP cq41H4gqTlVqW6HSicYQiOZcO8sYdpzdMk9A0OQ53etWjaSf6lcT/jl7/wDLDVJxN3mx0/lU 9J7RI8IIK6p7KfJ3EHBpgc57ftXy1JSokbw2Js+Wqq23N3aSiJMi0yRmLCyDzzHjV/kBCbPB cYJCTsXJE+vXTqJSiccTuTpmUvuiYVLULeJdwgmW3BrL3rbkVxw21lJKb4K2rKo4rOUFUFcc dW+bopUxxuYd4oqYlYyEyPchyJV3tjuWtozf9G94C807HkjCjJIBGxDLhCHBrCAzGBtlXCI1 IyVzOrDWqQVREZpjay+OlN2KtuN4hfLMMlp6wd0a/HixIVq3uRU55tp2NHIgdTpPArjXHqpy HkKKSIv5vfVScmqvJloRFMpql0qeLSkKIXtvTadEpP4Wui6WZkhwY4Nr1UMWykA4Ucj4d0aM m1RXBFUTTIaNVq48UXd4c1FxJmmFlLqj9h5l3bwbvR9/GKb+B6XR2HGqOjzAK+56xFRCZ6iI iPIyb0jgXdU7ovHtq5z7o4Xke1slvlxx6cvvygmt3bNz+I2VpSsHKGlTqyEaVV58aO9JBjqq hynQAiFsVLKIRe7trm+lcqsxbMOZKUyGRHuQqH7cXRV78tGLdVyWNVLHqivG0NPkyS58RVCR xFQQXiSqqJyFPZXUjVpNuhvWSjl4olZjdjdrooduPvVSbusu5ttKPXm67X7ZlQJk+E0zIOQ2 01JaIx4tqCuqiY7Cae5Fz3zY6eM1ucXZ0dVyGQ9O9ypoxS2Wp68FFb4p7t/2RV7Up1acjLWY vFiWOSQM+JFVRzlFVMLjy8tVymPN0Wq3uirdP07dMrcBIR6O2w1y7W29XH7grUVxaxJZcbiR eRtR0aExN3xCniPknYf0dSeLa5L1wmRYHKzP78vcq/R2nKe4QFxq49vXWfw1dEOMQn6qsSPI IemuH0bJVElT6TKDjHNMKnl21zvF8tFppk1vNOaWYUyT6vLXPErzr34a3BC0Pan4s0f7hH+W Ove+D/B2Q+pa9gVxyqd/PekXWi+rGmKWhCWhCWhCg+9Wf9FtwcfPoDj7eoGqljnwfmPse2Kk 6N38309UVj272ZNSsms0inTmafJd4SWZjwZZjqHi5OL7hHjy/ZrgNAqrMi8JaPMldKlJOTzN t2S8tOjx7etyHQo0ht1mAr7TZNllBH1hwkH7RReK/Wmo+szvbCe09uW9HqWtGku18voLs99W JZ/iojv34vlhqpYl71Y54/lUzJbRI6OqflaSfRT5gkaaJ5UFFBUwqiuM596+7U/IiLVrvLBM XCvK1ZXcaod2yqrZ1zyikvNyZITWkdFh99rqcTIeOeKKpcORd189djaGYkWW51gdVW5wxdld Emrtv7W7UtuVu2aE/TWmoxNo07KB96QQ/SKAkqihLhMomnBzdQxC9Y7nbypKVkwpzXdMiJZp v23LjPcP+VrNF/1XXFQm5DMbgy+4hLzIgUiVF4qir7tdFpc02MroNJrwVPnWCKY0tuqmloXV Jpv4HZYnSG3HJlB9h0kVFKG40Oe/mnBU+pNPylhccu50pp7W00Ma1fECjwrepcyozPwXBaaA WjcMBN14RREX80V/Ymkm225InHTLj9ybu2kIrYlpbB2mdA22njOlR3LOZalB6k4PSlPEAEZO Eil3VQxyEsqKYyqdk5fUsSvOTU0wA5i553OpdiSbtHVUr3K3AqlJq8Chx6lKo1LWHJq1Zq8Z gHX2Iba8elGQ0UeqarlTUVVE8tR1GpUlPS+6jbgbufBHg+OlLPMRJvuW8obae8EG5apSJdpX RcFetm4Jq0hwK+0Pr9LqPS5gQuCidRoxROx8sKXZfzRk6pRCbZMH2wB0IXQs4MuLztZIyMuW jv8AFzU3WiUWLUZ1VjUOG1PqTKxpkkWkR19tfzTLsq+X26rrdSemWWbnI2wjD8FIiwzrFbC5 Udat7VWwqy5alVpYuUduYLcEG/CkVg5KMstimMCIMNumqJlVNe66u9QpTNWAXhLXy4Vlifca bt8VTJ/0kZUqlIzbNDdYmONphxz6RGiMJeCTKIiqBx21US7ELhe9E1GsYUbYtdeLPh+5Mjmd 0+LwK7NqqDKoNkxjqpEs2pPOTH0MzcVvmq8G+TmT4gnhRC8k7a5XjKoNzU9ohHVD9k0AiIlK k89UItpPeJe/DWQQtD2p+LNH+4R/ljr3vg/wdkPqWvYFccqnfz3pF1ovqxpiloQloQloQoPv V+S6v/qW/mhqpY5y7QP3fQ9sVK0L/UG+nqise1zpFQayDsMpgHAmI5FRxR9Yb6ZKTSKKKSKW MeFM45Y15qke5zTdnnroRgJNleSHWCbZ2PRTbneuj0Xk9a9aOSL+JTydQXTETIDxyFSTlxVO 6+avsQjbUyExy3vy8ibyA2N+VWpZv9Ruffl+WGqViXvVjp/Kn0ntEj4LwLvqo7TmonxbKJgy ZxnE49lBURfrVNTbbTgio4jHSCsub4bN1w7oW8LTbJHnHglPNCXFeq3yIVFU7KRESefljXVc KYvl2pfcc/vD0x96nZOZG7X2VXVh7Dbn3nNhQq0LzTbSRWjN5xTTmwBtqq5XyIHD8XtfHVym sRyIiW5eqKbOzNuu6S1s5slDi29Ct6My2/FjMBG4uii5ABQUyv1omuXzE5UN0E6OcEzGsNlq EOqo4Hoi2nXZhPT6XFZVVz1GxTOeyISfWg9k1ZKdUqw+NhbPP+6bzlWl7dQVbVt7Obe7T2xU ZlqW3FjzfVTbWUA5eNFTCoheafXhU1aJgik6bpXSzJVgppyceEB9SoCnVS4ntp341n9Ny5ab DdgRwlAqgktpSAVPkXllPPKjlO5LhdVKaKXamWXZ0cmT4Ve7XtDaI66D2ZYW6d0Wjb1evGsU mnX7R3JHPnER2DLjOkiIzLZaJE5KI9ybLsvx1IzVVpUtMaKSbzl4w4eDf9X4JMhmGm9baU2g 7b3BKqbVy3I5a8eTSoziUul0aG41AblL7L7xGvMsKiJ4UHty811HTFYZEhalxjlGOtnHxUi2 6803ogUV28Ld2mWZU6rvW3S1qcSQ86ysBpvPqgCipyRvIrkvYXuWOy99OKh2sfmm2KVvjx8W t0wgn0m4TTZFMKB1Kv2HS6HQ6hfleotIWpOq5TnXeYLIAlFxHVbRsSaUeeC5CmPfjUzLy08b pMyYxPR7XJ8ZJXdjbbInMbwx4FZW3W0tsuVkHg9V6LSNPMNAQkL7aIrgk2qKquCnPPJO3i1X 6pW5wZewOLPNNZlxtobx41dkpAFFBoRQUTCInl21yepXGV475RTZhMtV9PEvhrcFlaHtT8Wa P9wj/LHXvfB/g7IfUtewK45VO/nvSLrRfVjTFLQhLQhLQhQfev8AJdX/ANS380NVHHXg/MfY 9sVJ0Xv4Onqish1FZAUmqvRphQ3GocpwJAcuTZI2aoScfFlF7+HxfDvrzRLfON+n7l0JzZJC LBkDKsahPipCJxS4NrJkvkwCPOILCuShB9VbFEaXqihIrePLC6kcSDZVXA5/JDi+jq+pIyHz atGzD/1K4P8AxpfLDVIxN3rL9P5U+k9olIw9tPh79VOX+cTzxVJacgOiAcey+/V0k7SGwlBT BEJJ2VBhzDUjHt8Ps1PS9IbLXSG7XGkRp9FgU8foI7YquMqn+OrI1JMtbCZPTbjvjIgLYlhE EdSkuw2RawpteSeNMoKZx31LNaNrYFIma51iJ69RpMPjnqtk3j7ffoqTRTMiQBxpNg9E8JLE 90SKxtNd8y4GIoyaZMIRq0TjguQIg+sDxRV5CHuwuUaQRRFJVWoUsBrEpuCY3jDZXS2nb2xd BWhYl/WNdcZuTR7ihuF3V1p0xB1lERSJCRV7ceJiq5xls/0VXTSaolQlnhCYHuXxyprNPuKJ be37uXAfut3fmLbdvUuNUEaoL7ElkEfaVwxLPEyUsIid1RFzyzx4rqWqtJlHGW2qQMYnx73N yCmDUwQEqH9I30lGLipsil2GMhLepDzL9WqLLpRZEsBMVIIppgmiROf0g90JFTiWUXVrwxhg ZS053LS+L6XLwpKcmnsk1v7buzvSQtq37hpF/U23rppsJmjVCM665PYy6ysoWBfIQV6UDaKr nf4ovs6dydSnMKvONEzFwDzjn/jHzskibBVBtu4srFbfo6R4TO4FPt63apHqNNta1AjnNkRy J6VHkI2rDjT2eDjZqK54plFDGq5iFuISTj8wNhORjHL1+9SU24JNtgPEtGTCVTVT9r364RUH Ru1UsxsofqCiniXw1sCytD2p+LNH+4R/ljr3vg/wdkPqWvYFccqnfz3pF1ovqxpiloQloQlo QoPvUv8A6XV/9S380NVLHXg/MfY9sVKUSF083Dn6orINTpsGs0ufRqnHF+HUGXYshsvI2zRR JP2ouvMgvOSrwmzvFCN0OddDIbuldmGW40dqIw3wZjtAy0HJV4NgKCI5JVXsiJ5romnymXtK W1HNDDYtagKaWZ4aK8X/ABxfLDVexN3rLdP5UtJ7RL2ryr3bnSkoUWnmwvRSOcviKDlslcxl xFUuSImDFE+Go6SGkg2JP3XZ8Wfl5k1mjnf5HAiVtpuq3XI7lYlUP8Eiw0kltpxEeVzi31SF FRUQUVHFQcqviT4as0o5Tibuazjv8u8o583sxuH7lZbM1ptcPyo7RphFBx0RLKrxRO+PfqwS pOO6vB0JAwiY3gMfVFPwmsEfQNxtHC9gFLCqnxTPnqXAXGvnRyTWDLg6xJ037f16k2HR8RJx uu5E6B4+XHUm0+k4gKeR/H7WpNo7tpNXYWqqN0tqWbgBybCjirph4/76659VKa5T5gp2Xz5V bqLWWwHRPrIN+7CT2ZjhNUFyQ84KiIgKi44XEhQUVMZyKmP/AMsfnanKXicdHbNKxOuyr46q MWr6INDq8OPK3CrFQlJz6gQ0fJMtGpEqOK4nMSUnXeQ/pES58WsT+MHWyHcMBh9lRIy4kV6l N2ei5t1JtefSqBSWYjj8YG0GUSvNuI34kQvf4i8RKndV1GS2L6hCeHSlDKMfInEWhNYqtrb/ AHdoN0swZUGsUyXHrEqqmgkQMtvOsEIPJ3wKLywvbPHtrrp1eQcl4WZR3kx3A9pFsf0NLCLb a15NMfeJydOYjDNVHBNtkmQVOAEnfjyJS+1dcex5WCnntEBam+nJSYywitAyV55X4645OAIk nLKY6hk7S+GtwWVoe1PxZo/3CP8ALHXvfB/g7IfUtewK45VO/nvSLrRfVjTFLQhLQhLQhQbe r8l1f/Ut/NDVSx14Pv8A2PbFStD7/b6eqKyYnmf/ALl/iuvMJjc5qLoa8Xz1gh1uiPUtm9pT KzFxRnF+E9flhqCxNdueW6fypWT2iQm4jtVu6XlnbkSaNOZgAj8BJytoTGci5xXyVcL3Huv2 6c0mFQ3GJBJaQc9rLe9lKxrMnIdyft6U3p0na+XEdjnuVUp7LsJ5ooKTHcjGNxkTJG1FcKCm 2PdPLP8Ae1YGGq4wN25INjnv7PR4qjX8TS467Qh5eBeHXfR9gPpHqFTrBkKo4pOk6StKkZxx SJVwSYbVT7p7fBf0dWqVkq1o9RtuH9qiXcbOmWz/AIKytpVsCp09yvWAzOKIZlE68sTRTICV TEEJcpgl7rjumPdreoboa2skkdXcqfzvuVismRePl2Xsi/HSbTg2/SSZWp0yWf4/s0/aNIkn jZ+HIl5/DUmw7empjcvoTH85OWpAYsujY6OYpMQt8ZQDdsGPUaRTRg9VKrUhZeUYwOijQATh IaEqKgkoomR76r2IJOVYZ0rQ5KXpJuE9x5QVQ7vluJJt2LQNsykR6vWXyaKYw3zcYYEFIiHk mEVfLlqt4dGX3QTr45h/5VqMgHbLVVbbTRt+LBv2PaO586oVek11t9WXJfJ52K82HMVQ1yvE sYXC4+zU5XAp85I6WVb0Zw8u97lkHWz1wJTe6rPptcvSCDLkcJU+M8XHkKGaNKKqaCg8lXBI ikq4RB/var0hMPbncPyKS3QLQ66nlq2xFtiGjLI98eNOOqdOzROlcai3JkpkuZEHz+H7tVOc PWTlsU31HJwl8NbgsrQ9qfizR/uEf5Y6974P8HZD6lr2BXHKp3896RdaL6saYpaEJaEJaEKD 71fkur/6lv5oaqGPPB+Y+x7YqTovfwdPVFZRiRHZan0hLCEqqqe5Mr3XXm6XYcdIrF0SJ6Jt fEpgozitn9Xf7e+tItEwQgf0lpLHpRIlLbN/qR776Xyw1W8U/MsdP5U7kdokPrztHaug25+2 j1VP1Fomqo3BF5XCUv6BSLy4+ffUlRaWL9K0vbTRb/zV337Y+yo+alWXX7nWoEutvqT81uG3 s7Dp8eQxJSVJkNRhBUyCk1xEMuI5598D4e+pSYpsnKS5G7WjcLMMhGN2e9yO+LwJKMrLl/Kh BHaVcG4TMNtQ2xo6yUaXkTM5phlXkbQsY4KqIuVHuS9tSrDNNG0+2Lvqjq/5pmcnL+ajEKq7 0zVEX7bt2lgaTEIknesG250XFi/DKK6rSqvHyz2TU8y/htr+Y456/wBUU0cgHiLoxH35dFtT kWWgo0nWJGn+RmqoSKKeSCiIo4Xz1Iy07hfSDpdJl9r3rBxZa8ZErErF2x4/X3JuO3WpCstF 6jDeDMdw0z4yTArlc4wmF04qxUu4RkBjb0qPdmJeHAam0apw5JN9Gcy4bo5FEcFVVE81wi+S aaCWi1fItwMTHVT4TEV5ac6W0VgmrlS/pQSXKTQaBdrcVt4bfqqTC/mvrLohwUS6LSqgq4vs opLhM50xn3hmS3IezFTdBhrEPIu9v1tqdGj1qlyG8ImBJoxc4EiYcbJRyikPsrhfNNUsjepj 1obMFPPMC6NhrvW5sysk3JmCyqx+SNIgcUDkKcu/2axMVGYntRayMq3Kkq7sK5xufdiqxofU 9RtqmnFdJt3LRznHeLrRgQIQutoHmhYUXBXUlNs9rKUJltn8fj9yVnC0paqs6U8HNS9nsnlr mk66tWgtQ0zElymq9MOp8C56bJRL4a3BZWh7U/Fmj/cI/wAsde98H+Dsh9S17ArjlU7+e9Iu tF9WNMUtCEtCEtCFBd6/yW17JYTot9/+aGqdj6BFh6Ys+h7YqWoX+oN9PVFYivy57lp7zdOs lxtyfSIZ12pMtyQQ1badEejwL2lUVUuOuOYdlxtuIVfnWtK2rLu1qIDLM3ky162iONN9QRzl OS4RV92dGKacLBDNB5I6qYU4yEilzFELN8VEfx3/AJ4WP+mGuT4oO6Xl+n8qnJUdE4S+KnFv SZW3lolwQYsDoCpxnmhMwL85zui47eWceWmNNCn7iymmDM89obvVlBQdQZmt0XMTEAHoTJ2J ckWlzJNY3IpjEEITpFIVltsUHI8HnHEUVwKIqLxL+0z59tTRMSjetKyDmdw+f1b6ausvOf7m G9zL4U26OjtxVrfIWmH22nE6XDCsgrxo22COkpIQn34ipL08IvlicZdmJ3+HCnRhlx636VHP y5f/ACer3ro5UdrRGFSqhvR/rSjNSW1OPW2zmmT3SJVcbFSNCFuPw4qme5e/U5LhVBu/hNHz h7xTM9zjsv59H7qXUKwrPrlOGtw7kuaowJxo9HJ6c822rahxy2hAK8SEl+3SXbSaacsdbD1Q /Sl2JQZnaLNG12osaS+sqTClOEbLTBD62aCoNsiyGUHHkAAmn/bx50dmHx0IdpTKOUGy7Utl z1mh0luO+oK2r3IjNRVEQkySr540q3OkWuS3CT0Q2ipB1cr7WnW6NKNic2ITd9Ej3FQZNLle MHQzhcIiqnkiqqL2X36QnhvZ1dpb092MrMXrINTtLdjZip9OyZBSqMy4yqU5z+hGO24bjjAY yoo649kz7quMaJerU+oN6KpN2nDezz+/xVbzFqaje0SDJWPSL3CaaoNYei02G+DDMtthjCSE Vt5mS2vwB0XENP0SbHTmMzh+lazGuXLH1JXcmrfcr42p29ibc2uEBsepLdBsZMhzu85wFBHq F+cWE89UKvVsp8iO3LkTTaJSV53uo+edUGYfv1E8ELoJsWo0wuSojavdaLZL4a3BZWh7U/Fm j/cI/wAsde98H+Dsh9S17ArjlU7+e9IutF9WNMUtCEtCEtCFBd7EFdra+hJlOi12/wCaGqjj zwfmPse2KkqOejngLn6orAV9bIX/AHNcNRuq3bop9DjFy6zzYEjz0ByOnrKGqeaioILfxyuu b0WZaakd8Vet261iY1Gu1R6bTIs5yrQ4/rqLHjttIbikvEWyPii8WDx7vJR8++mc3bOC4HDk EepSjUuPzq0XZ3ipEjwj4p7nb3f0Ya4zicLJNjnj+VEuVzhKK3dbG1FSvB+oXRImN1lyA0y6 LT7wtvx0LIjgBVHO/wAe/u+rUxh16uDS8pIIGOfk/wC2Krs81Td1d1KMC5/3Q2i2vsZRzkza TSJhyggyUNSOUhNsK40RoBEqC2qKLapxVFTj2xjTubfxW4Vjrgw1h4h/Qk4jS+X1/uncahbM z33uG1YzZquk0YuRs+NTNxVQyNUwSkZck/S763OfxRLFacyMODiH9CbHGnjsMxj8c6sSkWHt /TYTkOnWDb9Pbl59YZj09oOSqKiqEojlcoqp56gxxLPEX8Q85HogpZqlSe2AqaxnW2mgBsBA AFGwABQRAU8hRE8kT3JrYJgXSvAo3LbQC3G0RRAJHh7afhMJIwXcJPhTxakmpgklYu3XHT4Z grVpYksxOKiXH7FwutTqVo2kkYy5EVwoVPCHL7vstmvbzH4Ln+OoiYJt0rxT1jTNChBx6dGV SjsMtqvngfrz/HUJMPCKkgi8W2mUx9XV9ry8tQDs4TqdswTA+3l79RjpJ6C81qt0tN0JfDW4 LK0Pan4s0f7hH+WOve+D/B2Q+pa9gVxyqd/PekXWi+rGmKWhCWhCWhCg29i8drLgL/cN/NDV Qx54PzH2PbFSdG7+Dp6orPtEJqTA9Wkt82nAJtwffxVCEkTt8F1ynD80OjIFaJ0O6Caz1Lti 67Z3dt2nBczlYg0+e+jzRirQwGSaIWS5d/WEMGTbUfzCRP0tPplxoZKY4iyipdo7vUtCWVgK E97kSYX5uFx0x9ya4linWk2B5/ypzIfOEudYum1YNxNW9PFTqZ9HgixEJAE1wJdRe2O+fq1B y1LqBy+kaLV54pKLsuMxrCh7m51otPtQYSTJ7xzgp6tx4eERw3BFFUiVB/tOfn7Kd9SDWHqg Y91cgO9dvlHyRQ5Ns3aoJxE3NhTYbcuDRK1MacijKZaYEDJ1rJIXDiSiSpjPBC7ppGGHpoXS B16G9HLhitN2B5i7JftweqNPNbZXA86/x6cbqihdJWhM3VLiojwUuKoq+fvXOnbdIlQLvqHx 70zOccHxV8/y23dOO+/A2rjm0s1Woj7lRDg/HUV4PryVETJJ5KWfEPbUqErTwtEpri8nH5E1 KcePxU9K69yH3CBI9m0ttI/0nrVXBwwlk52ZJEJRQFDxc8/nYxp+1LU/zjPoh70lGacQ2PfV 7SYdOjVK/bBpVUakj+EhaI3Y5R3muDaCSllDR1HSTv38OnzTUqN1jJxHi+M03N5y7aXCDcN3 1eqpTQ37oEl6ssq1T49PofTHmbb7g8XVyXZseaLyT2dSL70vLS5HCV2eWPN5VpcT/cruFSGo WjuNMdp7RbzVRmM02oSkjQ2mTcwo8CAh7oq4NF5L9fnqJOvSej+Zj8dKct0xxSWntuUylRqc 9VpNRcYAk9ZlHydcRTIk5L78IvH9mqrO1FuZcuaGwVMysuTQ2rk/JzkdQ7r6lWwTEi7aj3TT sYLzsvv0zIrltwJawsLzwfpazcSxrJDxLwp56APW2VqUSFaJtb8WaR9wj/LHXvnCHg7IfUte wK4/Uu/nvTLrRbVjTJLQhLQhLQhQbekVLbCvoI5Xot9k7/2oap+PoEWHpi36HtipKjjdOAPP 1RWZqFOVtzgvJCE1UMFjui99cDo05oHLCVznBuFAKnGrIXVMkvyI7tFUXX4aryR4HneKEJCu R4hg8EniXlqUq80I9w8aMFvJukWpbFTWyuBUR4R7j64WM+9OmGuZ4puFlnmj+VSkkJCRLyrU +7JdZju02bSG6YEiOToSoaOvG2Kor2Cx2UkTinftqDk5+ny7NrwRiXJH1JKYlJg3LwyQGBZO 4sf6M905ERpOtwGDGRC8bjhLyJVTkvdpU/RUVTumpZ7ENNiOpL5+lHqyj600CmvFtlBPqhZd 1Sqc9Gi7m1ht/ok1GNzqEIETiEpHxdQnMCnBEVe2c6byuIJJpy5yVG344PIle1bnnJ1/ISnu 1Ryqv1muSHjmFMBHphOC2qmRICIWfAgl0+P6P160LEhR2WQ4Mvjl40uVLEh2lwXa6z3z51KL MmGYdFTcdAMtcxNQ4tiIoiqCJ4URcZ76G8TTeVjAj9/4pIaMPnJ3H2s27RtyOVs9QHmI0R0n pTrpGwwXIG1UiXI5Vc/HTiGKqjwG5l0D7lmNLbFF27Tstl5TG2qOpGrSl1IwljpeJrHLPsr5 du37MaxGuzZa2mj6hWe1w+aizB06KjYRo8VkGscMNCPDCKiYXz7ISppidUJ0bNIlBkBHxV1S SZZRRcVVXw4FV7a03Y4Q6iWgFq89TqR9whSCT4oC4/fpsITRFbbGJcy207I7RQTd2O4B9J1x hk18xdktgqfaikmpFjDFanPmpYo9C0KpSbW05BfYUuQa4bIXV/3Ak98sV1JD2O8VP7EkX3e9 NzxBTw/mJ6zaVbkDlqnzF+r1N5P/ALCiakpLsRYqfLWl7PSjBIniaRHxk/a27ud4ERabKQfh xAV/7iTU8z2DsQFtuNw6f2TMsWSY7IxT6PtXX3B5ORnG/wC6440mftUSX+GpaX7BFS/nzLf+ XuTOOLx/pp9E2jqHPlJ6Ij9U1c/u6Wp9rsFSpD3eZ/tgkDxc6WyKs2lwfwfTYkBFz6swDSLn PsiieeE+Hw12+lSIUuRZkQ34NAIf2wyVTfcJ50nC445p9qRSSWhCWhCWhCY1Wl06t096lVWI 3JiSB4utGmRJM5/imk3GwcG04ZwWwGTZXCqzrno823MUnreq0ylu8cI27/OmfPPdDVHPf7jT VRqmBaPUyvNvKPIpBmrTTXjKuLj2KvumqrsWns1Rr9KC+irj9U6oqP2CR6odV7FsxEhKQcG2 HEeef3Kbk8QN3fxApnQaHU6NTXIlQiSorpSScRp6G+jipwFOwICr7vdnXNcRdj3ERaEGpS7L zYw5PLFTMvXKfdfvouNKqTiIjNHqz6F5dKkS/wCJNon+OopjsT4qm9uWs54j704PE1P86KIN 2XdDrROsW1WHFx2DpNtqX/UMcammewfiIob7jYdOfVBMyxZKt7IxindP27vOUPKTbciN8Eek R0X/ALHC1INdgaqF87Nt/wCXuSXywa/pxRONtRdDhfT0+ntB/eqpEv7kj/56npbsCS498Tcf sw96Yli97xW4J81s/WVLkdSpTIfo9B91f2qhh/DUsHYMo/8ANfcj/b+lIHiqaLZGEE/b2fPP 09fjoPvFinIn/wBzPUtL9hrDMvtiZc8fdBNTxHPF4yfjtPTekLJ1+pIKeaNBHbz+5rP+Oppj sX4VY/2kI88Y+9MzrE4f8xPWNsrdZDgciqO/WU4xX/tVNSjOB8OsbMm36kgdQmjG0nIp5HsK 1Y4KA051xF8+tKecz9vIl1MtUinsfNMjDogkdO55y7M2VaEcubdsUtC+KxAVf3qmnotNjsik 4kRInHptPipiJT47Cf7toR/gmlVhOURE8k0IXuhCWhCWhCWhCWhCWhCWhC//2Q== --------------030407060607010708020801-- --------------050509040508030003060708-- From sirkar@doneasy.com Fri Aug 26 08:51:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8dgA-00049I-1E; Fri, 26 Aug 2005 08:51:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16328; Fri, 26 Aug 2005 08:51:28 -0400 (EDT) Received: from thakored-10.user.msu.edu ([35.10.51.143]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E8dgr-0005Ew-RW; Fri, 26 Aug 2005 08:52:15 -0400 Received: from croatia.gycyqr.natalie.tee.com by diligent.belshazzar.burgher.com (vjhupfix) with SMTP id 3B29E820206 for ; Sat, 27 Aug 2005 01:28:37 -0400 Message-ID: Date: Fri, 26 Aug 2005 22:31:37 -0700 From: "Gino Hood" To: Subject: Catch the new low rates X-Mailer: KYX CP/M FNORD 5602 X-Spam-Score: 4.3 (++++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have been selected for our lowest rate in years... You could get over $460,000 for as little as $350 a month! Ba(d credit, Bank*ruptcy? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.lakdj9.info/i/LzMvaW5kZXgvYXJuL2dqejNzajI5dHd1 Best Regards, Cathleen Longoria to be remov(ed: http://www.lakdj9.info this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From owner-ietf-provreg@cafax.se Fri Aug 26 16:21:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8khG-0004jX-Eo for provreg-archive@megatron.ietf.org; Fri, 26 Aug 2005 16:21:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20474 for ; Fri, 26 Aug 2005 16:21:04 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8ki0-00065Y-W8 for provreg-archive@ietf.org; Fri, 26 Aug 2005 16:21:55 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7QKFMDx025580 for ; Fri, 26 Aug 2005 22:15:22 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7QKFMp5022948 for ietf-provreg-outgoing; Fri, 26 Aug 2005 22:15:22 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ogud.com (ns.ogud.com [66.92.146.160]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7QKFKjd014684 for ; Fri, 26 Aug 2005 22:15:21 +0200 (MEST) Received: from [10.31.32.172] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7QKFB1L002621; Fri, 26 Aug 2005 16:15:12 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <046F43A8D79C794FA4733814869CDF07C92A4A@dul1wnexmb01.vcorp.ad.vrsn.com> References: <046F43A8D79C794FA4733814869CDF07C92A4A@dul1wnexmb01.vcorp.ad.vrsn.com> Date: Fri, 26 Aug 2005 16:15:32 -0400 To: "Hollenbeck, Scott" From: Edward Lewis Subject: Re: [ietf-provreg] 3730 Text Change Proposal Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Revisiting this... At 13:27 -0400 8/15/05, Hollenbeck, Scott wrote: >OK, we've been talking about the text in 3730 that describes the >command for a few days. Let me throw out a straw man text change that >builds on the one first proposed by Jim Gould. > >OLD (section 2.9.2.3): >Service messages MUST be created for all clients affected by an action >on an object. For example, actions MUST be reported to both >the client that requests an object transfer and the client that has the >authority to approve or reject the transfer request. > >NEW: >Service messages can be created for all clients affected by an action on >an object that did not directly execute the action. For example, > actions can be reported to the client that has the authority >to approve or reject a transfer request. Other methods of server-client >action notification, such as offline reporting, are also possible and >are beyond the scope of this specification. > >Fire away! Where I am getting confused is that "Service messages" is used twice in the document and not explicitly defined. Not that the lack of a definition is a problem I want to see solved, but looking at the above text out of context threw me for a loop. What I think we want is to document that servers don't have to create "special" responses to return to the sender of a requested action. What I hope that we mean to say is that servers ought to let other clients know of actions "happening behind their back" where the target of the action is of some interest to the other clients. My goal is also to warn the implementers of client software that there may be "special" responses coming to them that are superfluous. I.e., the servers that conform to the OLD text won't bring down a client conforming to the NEW text. That's why I suggest a "SHOULD/MUST" send to others involved, "MAY" to the requestor. (And that clients MUST be able to deal with the message appropriately.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From owner-ietf-provreg@cafax.se Mon Aug 29 09:39:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9jrd-0004kI-5u for provreg-archive@megatron.ietf.org; Mon, 29 Aug 2005 09:39:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09896 for ; Mon, 29 Aug 2005 09:39:51 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9jsx-00006d-BB for provreg-archive@ietf.org; Mon, 29 Aug 2005 09:41:16 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7TDNJKZ014500 for ; Mon, 29 Aug 2005 15:23:19 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7TDNJie020692 for ietf-provreg-outgoing; Mon, 29 Aug 2005 15:23:19 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7TDNIBt014067 for ; Mon, 29 Aug 2005 15:23:18 +0200 (MEST) Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id j7TDQIsR016290; Mon, 29 Aug 2005 09:26:18 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Aug 2005 09:23:17 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [ietf-provreg] 3730 Text Change Proposal Date: Mon, 29 Aug 2005 09:23:04 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07CFF7CF@dul1wnexmb01.vcorp.ad.vrsn.com> Thread-Topic: [ietf-provreg] 3730 Text Change Proposal Thread-Index: AcWqeuZrbprdIYypTDaQsSshoUw+RQCH+7EA From: "Hollenbeck, Scott" To: "Edward Lewis" Cc: X-OriginalArrivalTime: 29 Aug 2005 13:23:17.0285 (UTC) FILETIME=[D1188D50:01C5AC9C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j7TDNJBt014889 Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] > Sent: Friday, August 26, 2005 4:16 PM > To: Hollenbeck, Scott > Cc: ietf-provreg@cafax.se > Subject: Re: [ietf-provreg] 3730 Text Change Proposal > [snip] > That's why I suggest a "SHOULD/MUST" send to others involved, "MAY" > to the requestor. (And that clients MUST be able to deal with the > message appropriately.) OK, so how about this: OLD (section 2.9.2.3): Service messages MUST be created for all clients affected by an action on an object. For example, actions MUST be reported to both the client that requests an object transfer and the client that has the authority to approve or reject the transfer request. NEW: Service messages SHOULD be created for passive clients affected by an action on an object. Service messages MAY also be created for active clients that request an action on an object, though such messages MUST NOT replace the normal protocol response to the request. For example, actions SHOULD be reported to the client that has the authority to approve or reject a transfer request. Other methods of server-client action notification, such as offline reporting, are also possible and are beyond the scope of this specification. -Scott- From owner-ietf-provreg@cafax.se Mon Aug 29 10:07:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9kHu-0001i8-GS for provreg-archive@megatron.ietf.org; Mon, 29 Aug 2005 10:07:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11301 for ; Mon, 29 Aug 2005 10:07:00 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9kJB-0000rX-WC for provreg-archive@ietf.org; Mon, 29 Aug 2005 10:08:26 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7TE186t011947 for ; Mon, 29 Aug 2005 16:01:08 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7TE18vk026173 for ietf-provreg-outgoing; Mon, 29 Aug 2005 16:01:08 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7TE16jr005175 for ; Mon, 29 Aug 2005 16:01:07 +0200 (MEST) Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id j7TE47bb017618; Mon, 29 Aug 2005 10:04:07 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Aug 2005 10:01:03 -0400 Received: from 10.131.29.3 ([10.131.29.3]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Mon, 29 Aug 2005 14:01:03 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 29 Aug 2005 10:01:05 -0400 Subject: Re: [ietf-provreg] 3730 Text Change Proposal From: James Gould To: "Hollenbeck, Scott" , Edward Lewis CC: Message-ID: In-Reply-To: <046F43A8D79C794FA4733814869CDF07CFF7CF@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Aug 2005 14:01:03.0758 (UTC) FILETIME=[1804E2E0:01C5ACA2] Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 1.0 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Scott, It looks good to me. -- JG James F. Gould VeriSign Naming and Directory Services jgould@verisign.com This message is intended for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. Any unauthorized use, distribution, or disclosure is strictly prohibited. If you have received this message in error, please notify sender immediately and destroy/delete the original transmission > From: "Hollenbeck, Scott" > Date: Mon, 29 Aug 2005 09:23:04 -0400 > To: Edward Lewis > Cc: > Subject: RE: [ietf-provreg] 3730 Text Change Proposal > >> -----Original Message----- >> From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] >> Sent: Friday, August 26, 2005 4:16 PM >> To: Hollenbeck, Scott >> Cc: ietf-provreg@cafax.se >> Subject: Re: [ietf-provreg] 3730 Text Change Proposal >> > > [snip] > >> That's why I suggest a "SHOULD/MUST" send to others involved, "MAY" >> to the requestor. (And that clients MUST be able to deal with the >> message appropriately.) > > OK, so how about this: > > OLD (section 2.9.2.3): > Service messages MUST be created for all clients affected by an action > on an object. For example, actions MUST be reported to both > the client that requests an object transfer and the client that has the > authority to approve or reject the transfer request. > > NEW: > Service messages SHOULD be created for passive clients affected by an > action on an object. Service messages MAY also be created for active > clients that request an action on an object, though such messages MUST > NOT replace the normal protocol response to the request. For example, > actions SHOULD be reported to the client that has the > authority to approve or reject a transfer request. Other methods of > server-client action notification, such as offline reporting, are also > possible and are beyond the scope of this specification. > > -Scott- > > From owner-ietf-provreg@cafax.se Mon Aug 29 15:30:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9pKu-0001l2-Ej for provreg-archive@megatron.ietf.org; Mon, 29 Aug 2005 15:30:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01568 for ; Mon, 29 Aug 2005 15:30:26 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9pMH-0002UA-Om for provreg-archive@ietf.org; Mon, 29 Aug 2005 15:31:55 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7TJMQ5t001199 for ; Mon, 29 Aug 2005 21:22:26 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7TJMQjf020393 for ietf-provreg-outgoing; Mon, 29 Aug 2005 21:22:26 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7TJMPFS008595 for ; Mon, 29 Aug 2005 21:22:26 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E9pD6-0006lK-9A for ietf-provreg@cafax.se; Mon, 29 Aug 2005 15:22:24 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id 0EEED13744; Mon, 29 Aug 2005 15:22:21 -0400 (EDT) Date: Mon, 29 Aug 2005 15:22:16 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] 3730 Text Change Proposal Message-ID: <20050829192215.GJ23494@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <046F43A8D79C794FA4733814869CDF07CFF7CF@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF07CFF7CF@dul1wnexmb01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 On Mon, Aug 29, 2005 at 09:23:04AM -0400, Hollenbeck, Scott wrote: > > NEW: > Service messages SHOULD be created for passive clients affected by an > action on an object. Service messages MAY also be created for active The SHOULD here makes me slightly nervous, but I don't have any principled objection. I still think the mechanism is pretty inflexible, but this SHOULD gives me enough room, I think, to move if I have to. The third paragraph of the existing 2.9.2.3 also has this: ---cut here--- Servers MAY implement other mechanisms to dequeue and deliver messages if queue maintenance needs exceed server resource consumption limits. ---cut here--- We could take the conditional clause away, to yield, "Servers MAY implement other mechanisms to dequeue and deliver messages." That would again be consistent with the old language, and coupled with the changes Scott has suggested, would lead to a looser understanding of what the poll mechanism requires. A ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 From 901farquhar@acci.gr Mon Aug 29 23:58:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9xGM-0003ww-TX for provreg-archive@megatron.ietf.org; Mon, 29 Aug 2005 23:58:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04729 for ; Mon, 29 Aug 2005 23:58:16 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9xHo-0002aM-81 for provreg-archive@ietf.org; Mon, 29 Aug 2005 23:59:50 -0400 Received: from c-67-162-53-228.hsd1.il.comcast.net ([67.162.53.228]) by mx2.foretec.com with smtp (Exim 4.24) id 1E9xGL-0005Tm-5s for provreg-archive@ietf.org; Mon, 29 Aug 2005 23:58:17 -0400 Message-ID: From: "Richard K. Lee" <901farquhar@acci.gr> To: provreg-archive@ietf.org Subject: =?iso-8859-1?B?UG9wdWxhciBwaWxscyAtIGxvdyBwcmljZQ==?= Date: Tue, 30 Aug 2005 03:52:35 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_09CC8796.8303683F" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is a multi-part message in MIME format. ------=_NextPart_000_0000_09CC8796.8303683F Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_CACBBEE0.3930D4D9" ------=_NextPart_001_0001_CACBBEE0.3930D4D9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Easy erection No prescription needed 2 popular medicines: CIALIS - http://www.pillsofpassion.biz/sv/ VIAGRA - http://www.pillsofpassion.biz/vt/ Directly from the manufacturer! _________________________________________________________________________ To be taken out, go here _________________________________________________________________________ ------=_NextPart_001_0001_CACBBEE0.3930D4D9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

Easy erection
No prescription needed

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

Directly from the manufacturer!


_________________________________________________________________________
To be taken out, go here
_________________________________________________________________________

------=_NextPart_001_0001_CACBBEE0.3930D4D9-- ------=_NextPart_000_0000_09CC8796.8303683F-- From owner-ietf-provreg@cafax.se Tue Aug 30 07:18:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA481-00084j-GY for provreg-archive@megatron.ietf.org; Tue, 30 Aug 2005 07:18:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06224 for ; Tue, 30 Aug 2005 07:18:06 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA49U-0006Bk-AH for provreg-archive@ietf.org; Tue, 30 Aug 2005 07:19:41 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7UBADZ1023352 for ; Tue, 30 Aug 2005 13:10:13 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7UBAD6L021297 for ietf-provreg-outgoing; Tue, 30 Aug 2005 13:10:13 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7UBA75N004006 for ; Tue, 30 Aug 2005 13:10:08 +0200 (MEST) Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id j7UBDJHH018832; Tue, 30 Aug 2005 07:13:19 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Aug 2005 07:10:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ietf-provreg] 3730 Text Change Proposal Date: Tue, 30 Aug 2005 07:09:50 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07CFF990@dul1wnexmb01.vcorp.ad.vrsn.com> Thread-Topic: [ietf-provreg] 3730 Text Change Proposal Thread-Index: AcWs0O5PUdVSeb+tR8umC+9wLgaUswAga2Ew From: "Hollenbeck, Scott" To: "Andrew Sullivan" , X-OriginalArrivalTime: 30 Aug 2005 11:10:06.0077 (UTC) FILETIME=[6060BAD0:01C5AD53] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j7UBA85N013078 Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 8bit > -----Original Message----- > From: owner-ietf-provreg@cafax.se > [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Andrew Sullivan > Sent: Monday, August 29, 2005 3:22 PM > To: ietf-provreg@cafax.se > Subject: Re: [ietf-provreg] 3730 Text Change Proposal > > On Mon, Aug 29, 2005 at 09:23:04AM -0400, Hollenbeck, Scott wrote: > > > > NEW: > > Service messages SHOULD be created for passive clients > affected by an > > action on an object. Service messages MAY also be created > for active > > The SHOULD here makes me slightly nervous, but I don't have any > principled objection. I still think the mechanism is pretty > inflexible, but this SHOULD gives me enough room, I think, to move if > I have to. Didn't you yourself suggest a SHOULD?: http://www.cafax.se/ietf-provreg/maillist/2005-08/msg00053.html > The third paragraph of the existing 2.9.2.3 also has this: > > ---cut here--- > Servers MAY implement other mechanisms to dequeue and deliver > messages if queue maintenance needs exceed server resource > consumption limits. > ---cut here--- > > We could take the conditional clause away, to yield, "Servers > MAY implement other mechanisms to dequeue and deliver messages." > That would again be consistent with the old language, and coupled > with the changes Scott has suggested, would lead to a looser > understanding of what the poll mechanism requires. ...but we already have suggest new text to make it clear that alternatives are possible: "Other methods of server-client action notification, such as offline reporting, are also possible and are beyond the scope of this specification." The text in 2.9.2.3 exists to let people know that they can deal with clients that don't retrieve queued messages however they wish. Something to make that clear really should remain in the document. -Scott- From owner-ietf-provreg@cafax.se Tue Aug 30 10:52:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA7TR-0001ZB-FH for provreg-archive@megatron.ietf.org; Tue, 30 Aug 2005 10:52:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17164 for ; Tue, 30 Aug 2005 10:52:26 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA7Uz-0003J6-UZ for provreg-archive@ietf.org; Tue, 30 Aug 2005 10:54:06 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7UEie1f014555 for ; Tue, 30 Aug 2005 16:44:40 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7UEieO4011350 for ietf-provreg-outgoing; Tue, 30 Aug 2005 16:44:40 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7UEiciw018365 for ; Tue, 30 Aug 2005 16:44:39 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1EA7Lp-0006tn-4I for ietf-provreg@cafax.se; Tue, 30 Aug 2005 10:44:37 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id 7EAC713744; Tue, 30 Aug 2005 10:44:33 -0400 (EDT) Date: Tue, 30 Aug 2005 10:44:33 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] 3730 Text Change Proposal Message-ID: <20050830144433.GD12182@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <046F43A8D79C794FA4733814869CDF07CFF990@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF07CFF990@dul1wnexmb01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a On Tue, Aug 30, 2005 at 07:09:50AM -0400, Hollenbeck, Scott wrote: > > Didn't you yourself suggest a SHOULD?: I did (although I regret it in retrospect). But as I said, I don't object. > > "Other methods of server-client action notification, such as offline > reporting, are also > possible and are beyond the scope of this specification." > > The text in 2.9.2.3 exists to let people know that they can deal with > clients that don't retrieve queued messages however they wish. > Something to make that clear really should remain in the document. Ok, I see that. I don't have a strong opinion here, either. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7UEie1f014555 for ; Tue, 30 Aug 2005 16:44:40 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7UEieO4011350 for ietf-provreg-outgoing; Tue, 30 Aug 2005 16:44:40 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7UEiciw018365 for ; Tue, 30 Aug 2005 16:44:39 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1EA7Lp-0006tn-4I for ietf-provreg@cafax.se; Tue, 30 Aug 2005 10:44:37 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id 7EAC713744; Tue, 30 Aug 2005 10:44:33 -0400 (EDT) Date: Tue, 30 Aug 2005 10:44:33 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] 3730 Text Change Proposal Message-ID: <20050830144433.GD12182@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <046F43A8D79C794FA4733814869CDF07CFF990@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF07CFF990@dul1wnexmb01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Tue, Aug 30, 2005 at 07:09:50AM -0400, Hollenbeck, Scott wrote: > > Didn't you yourself suggest a SHOULD?: I did (although I regret it in retrospect). But as I said, I don't object. > > "Other methods of server-client action notification, such as offline > reporting, are also > possible and are beyond the scope of this specification." > > The text in 2.9.2.3 exists to let people know that they can deal with > clients that don't retrieve queued messages however they wish. > Something to make that clear really should remain in the document. Ok, I see that. I don't have a strong opinion here, either. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7UBADZ1023352 for ; Tue, 30 Aug 2005 13:10:13 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7UBAD6L021297 for ietf-provreg-outgoing; Tue, 30 Aug 2005 13:10:13 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7UBA75N004006 for ; Tue, 30 Aug 2005 13:10:08 +0200 (MEST) Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id j7UBDJHH018832; Tue, 30 Aug 2005 07:13:19 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Aug 2005 07:10:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ietf-provreg] 3730 Text Change Proposal Date: Tue, 30 Aug 2005 07:09:50 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07CFF990@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-provreg] 3730 Text Change Proposal Thread-Index: AcWs0O5PUdVSeb+tR8umC+9wLgaUswAga2Ew From: "Hollenbeck, Scott" To: "Andrew Sullivan" , X-OriginalArrivalTime: 30 Aug 2005 11:10:06.0077 (UTC) FILETIME=[6060BAD0:01C5AD53] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j7UBA85N013078 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > -----Original Message----- > From: owner-ietf-provreg@cafax.se > [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Andrew Sullivan > Sent: Monday, August 29, 2005 3:22 PM > To: ietf-provreg@cafax.se > Subject: Re: [ietf-provreg] 3730 Text Change Proposal > > On Mon, Aug 29, 2005 at 09:23:04AM -0400, Hollenbeck, Scott wrote: > > > > NEW: > > Service messages SHOULD be created for passive clients > affected by an > > action on an object. Service messages MAY also be created > for active > > The SHOULD here makes me slightly nervous, but I don't have any > principled objection. I still think the mechanism is pretty > inflexible, but this SHOULD gives me enough room, I think, to move if > I have to. Didn't you yourself suggest a SHOULD?: http://www.cafax.se/ietf-provreg/maillist/2005-08/msg00053.html > The third paragraph of the existing 2.9.2.3 also has this: > > ---cut here--- > Servers MAY implement other mechanisms to dequeue and deliver > messages if queue maintenance needs exceed server resource > consumption limits. > ---cut here--- > > We could take the conditional clause away, to yield, "Servers > MAY implement other mechanisms to dequeue and deliver messages." > That would again be consistent with the old language, and coupled > with the changes Scott has suggested, would lead to a looser > understanding of what the poll mechanism requires. ...but we already have suggest new text to make it clear that alternatives are possible: "Other methods of server-client action notification, such as offline reporting, are also possible and are beyond the scope of this specification." The text in 2.9.2.3 exists to let people know that they can deal with clients that don't retrieve queued messages however they wish. Something to make that clear really should remain in the document. -Scott- Return-Path: Received: from localhost (69-173-198-164.clvdoh.adelphia.net [69.173.198.164]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7UAmHcX014286 for ; Tue, 30 Aug 2005 12:48:18 +0200 (MEST) Date: Tue, 30 Aug 2005 06:48:09 +0100 From: "Halperin" To: Subject: Men's essentials. All in one place. Message-ID: <000a01c59d80$883b0070$0100a8c0@kuhww> MIME-Version: 1.0 Content-Type: multipart/related; boundary="=_190cc757ff80edad56210052a6b47491" --=_190cc757ff80edad56210052a6b47491 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable = = =
=
=
--=_190cc757ff80edad56210052a6b47491 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="366f55ae58fcfef878171308cb82d405.gif" Content-ID: <3e1500bf759b20922fa447977ac2bc8a> R0lGODdhWAIoAMYAAP////8AAAAAAB8fHz8/P5+fn19fX7+/v9/f339/f/8fH/8/P/+fn9s7O4dH Rx8AAF8AAN8AAL8AALd3d/+/v//f358AAD8AAP9/f49vb3NTU4cnJ+8vL48PD/NTU+sLC+uLi/MT E+9vb/9fX99fX59fX8enp/cXF98fH/sbGzsbG68vL1cXF8MjI+cnJ88PD38AAJs7O58fH9cXF7cX F+PDw8cHB+cHB+dHR28vL/c3N3MTE1c3N8+Pj6sLC+enp+MDA8NjY89PT6uLiwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwA AAAAWAIoAAAH/oAAgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2u r7CxsrO0tba3uLm6u6ABvr++CgsMhcDGwIO/GIa/hM2FDAsKwSMUkBQj08HDh8fby4jR2gojxITa 1oQVvxWFFMEA3sfJvt31ivLC5oUjvyPF8pC5y7ZtH70A9hBqwjBNWKcK/1oxDOAw1jNeqiDqCuir gTOOvgQIApYBYACRI0MS6ueNhCOW3kIYjMcRhaEK2o65aCeIJYwDhBj8goCAEAZfMAaAVEnzJDOm iEB6VGdMw0eQKAFUWCAvRLqUTk1mtXT0lw8CmxhMM8CqrK+z/hahYjSlNgBbXEsdHOSIEpiFogez /srq1lsJRlxBTrgaUIa6nN5u1BD0LkCEBIQSB5BQ4JyvCwmWhh38NGxUkHoHCQVGdG9AlDhB9ghc emwlbRAEPLibifQq3Lp5u/I91xRxW4MFKH8AIYIvCUCbKp9OXTlYX1Zpg82qzcID5Recb46OCKaE C98FXLDwC3pg6g8k+Lo8SLOFC+DZ+7IB+JcKxgGgJcg6IQFFXXLUbVcbPiFNx5x47gnS3XOdDXJg gwkCoBkM6T0AQ3vRHacgJoN1BlhvcqFSIgAnDpdicaKISMtxCEwwn4AylvbcicT1GJIBgJnwi4CH EBhAbgQc/gDYATFEwCGRItbwywCUDSWAAdEd4MAvOQiSWGsArCbeBar5YoFt0iWEZo7aCVLjjVVa JsAHvnSppiGVBYBfAoAhUIKTD+D4IpuRiCgONTwNOBFF3Fx3kSMVLKqPIYdSNEKiaapDEDmYJgJR Q5eaFGZiC3w1oiCVcnoVBdNEBAAF0gTAzaNabRrqVQBMpEA6E5V6k62dNhONL746eg9yg/pCZaYM WubLBm0Sp40EpiIwXSJlnVlhIQUMwGebA/rGkraG4GAmUKtx1pMvEJy77pHCnXrVmi/OW9qyPg2Q LXn28oOUAPwKcoC3/SVrGiXe1CfPDwNC9osLxh68SGw6/mW2cFMCveoNw4rkCQzHYOkHzGxtamYM yL9AyJbHvrhAHMu+gNyUfCPD5AvJcZ58lci/kOwNmnFJXFkEfdVr0gXzVeijaYWdMAIGnSKS2AXx NjvWVs+hpA3VhwzNlpECTkN0CJbd9csD24KrNrN3EjJ00QE8kACBEVTNtoSfYcaIjIQ68nOYz333 gH7ufSk4zdD+7YjhuiGOauC6EX7A3xQbE0HAj3lzuWvGRJhpuoJLbiwMBFSuuOkpkxeQeMBEiPp8 qgfknuK1EFdBXQFYsOxS83LgSwenHoeCNynMVBvmiSx1gaBxI2/ksil8pnHuA7DEwvQSCNCivJzT 3rZW/rjrDvhm2gOggy87fB8Y8jq+hokACAKwNQFFSWkZWr9cUED9SQMAP4aPyN/+AGC/CHRmfvy7 n//iVxYJHA592IJcfCB4ndxMUIEjQiAB4dSUCKQnAW6xYLt808AHBiB9YIkAfj7kCyCskIMlbBwF MWZBmkVAQP87iXWQxRGuYUweggmJkUqyNNtsgHXAmMppJJaw7gEDBgDbzva0s6+yQMAAq/lJWUin PicaA2hezB9bviSgdKWNe3dL3lLAWCi5DEA50Xme/H7BAQa0w1oC2J3REpGTOt5ROct6YxS1MqVT JSZQCVTXIQ5Jvw1uRmnsEkBn7BeAZTFLkHEsZFMg/jAAwHxJkiwSgm8YmUhI6mkABzASJ1OpSVI6 UpFWmqQm0zgLkOQmRFihjQfMhIAiGqIAKoCABZC4AjXGzSTACKI3OCQAvTXlAYgwEkq8pg20EUgC CdiaM/uFTPcZUx63lOa2fsGDBZkEmo0QDRub2MVXMYAgpLGZL3Qwk74dQp4BoGfX3gkZuHFndUQq hMOAcUOwoC1aKaIAP5Np0G1Vc1vSxJs8CvpMXMbNlFoDaEMRKrEZHSMCEfAOKLdTnQylqQJ0CsCW oMImBBTAACyw4TYtpqcW0S45F7BhBlq0tSlOj2gHYcF8yne+AORgqMjLEYIu1FEAzSek3+lMYZa5 /j0Z9TSdGGLqOo8BxuPgjquCaEFMvmLPQ4j1GF5RzUCZsjR5WLKbx9DjSXjEUqh89YtSDIxN2coR uZZPOgUbTV/zGrw9wmKpeRwAkLhpTJSA4Dm+nGMAoiYkZSGigQGbTmQP8IL9tGhcyBuXJVkinqQI ooFmeitj19Y3xA5AsYBZK0FnKiOfsE8s5kwIQ7+3GstYAAZIg4oGYECzX9jAomxUxHCLux90pey3 wRWsabRR0msdgrrV9Sc3fdPbkALXN8epJlWYgt3qFtY0vilvSeUV2VuU9b1QIdtuM5WYv7iDTUZy zPdsd4Nnue0XMaCUGMsEDNDkjF12oyXfDEso/ph543qrnV4ADgMNBUCNtYY17/eAo9jQyAUBCeAB BIrLvOQqAsQiJrFkc9Nh8ELlS5CAcWO3S95ItpivB/vSidyCEhkvUZlA9hK7rEbjpsoCvkbmJsuC PL4AtCAdt5sWG3fpCxRQoB0VoMCi0CuXx1ombb7rSDqw0Z5BEjKZsVtRO9PY2j36pLostAC/chTm AJAAy1r+BQoCS68kQ6KIFcqTSLTBE5cO1aBRUwSh3VSAQ6tZ0KcqSwSCoJWyLCCClqF0pIgFrsg+ 2sUHc4umC4MSSY+a0+dlsqkrjWq2Le0BiQ6aiX8oD3DVmcumcVkPA2qIGSwle2rTNfAGUYH+/q4u UIUoKvlouuwft7PNRjaS3G7yi+ygUSvGDgiy2WzYAL7YTO34KjTTNZlNU0+iAfBAUWgl4M2UO1tU qm+4c4JO2wUEArwm9r1LXOQegztM9JaXkYAYLnDyO9UF9wa+2QuVnKjbvd2mteKOM3Ama6Wz4DQz ImiwOiSpLU8lGUQNbCAPB3ayEG7hIoEDoPI1L9jPbErXX5PNLroaeeQTxQ+fc2uJl3kDCJ8pSgO8 kb27aKZutCTE0I9RdAkDA+g1ZdsPvEEuREz9GFU/TmQdDPULrDtFXm4dca5ujKzXFddZIbtfRqr1 b88nwa9AMl+4J4L2smgDw5yPBJh5RkQs/lc8IcXPANImI3NtpkUIwDvgLYCkKebJwPr2xbSdzfNr r03IR8r34x55eTdtQAKLZ3Ga+zxrrB6sB6D3LXqeE50YpH4zUCRSBTAuvrK6HkKxHwTqnRP4B7D+ bibI+2ZyA3dBBB9CxO/02bOye9X7fjxpnADNJJCb4xz/OclHuLyuP/wrKd80s08tLqy7iOxWx0I7 JEQCyO+/9A/ipYIcAAG+5QgQEyD+WDoE+wdhAOXkG/6AZAB9NwgHMB0Bg0czp3/uRwj7JwgNWAgP KAgEoBwDKAgF4H8MuIC/dH8B2HcPGIGSsH8HwIGKpSQYaIEcKADzVwgIMIHeRxOlVwAp/riChDCC b1SCeIRDGogABiBIBFCBLNiD/ndG+8d+7GeDeYQlOeiAGggAI+h/Q3BohMCDPkiE7meEC0iFQwiB C8h+LagcxQcjYjiGZFiGs7AOwGaGteQL+wArz6FaahiHcjiHdFiHltAPy2OHrWAyx7BweviHgBiI gjiGCxADGjeIo+BgZjJSiNiIjviIkEgKPxiJo2ACxAV41PeClLiJnNiJnviJp2B/8TeJoFiKpniK qJiKqriKrNiKrviKsBiLsjiLtFiLtniLuJiLuriLvNiLvviLwBiMwjiMxFiMxniMyJiMyriMzNiM zviM0BiN0jiN1FiN1niN2JiN2riNEtzYjd74jeAYjuI4juRYjrMYCAA7 --=_190cc757ff80edad56210052a6b47491 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="6e7ebdc2bde67a21b3fc74c913e8ca22.gif" Content-ID: R0lGODdhWAIsAYAAAP///wAAMywAAAAAWAIsAQAC/oSPqcvtD6OctNqLs968+w+G4kiW5omm6sq2 7gvH8kzX9o3n+s73/g8MCofEovGI5AWWgEBk6URAM9HQFFe1ZmvbGRP1HV0b0zGj2+yGyWi2N/k2 rM+LdhxuseM/eqqi7yf3UAXYhgbYVIFosrgnchj1BXU1GTZ5wDRmlplVZlcZ6aRJKSrotnaJiSra mFCmasmqmka4mUobu3XLCbHL2icL2zlKK7dbbJychsxbN4gp7Er397QcLT0798cZGqsM7fhym2ha LoVdrm1uHTn77Kp7vpzpIGkeL9Wu6N7J7w5uqh+5dQLT6ZtmUIK9geQKalNDCGCtbesqSivFsCA6 /nmD9GlkyO5dQ44ROYaDUTKjs3zHEKa714vaRo8WJQrDZ3MfOFA5QeLKNeyhyZR6HE4oydOYppVD ex4CCJUOxqQiTZLZWWnjQGA7SUZtdfJRT58gDV31qrJqRYE0z478ig5sWrMvtTK1qpFoPbTVAt5N aTXt1qh1CTubmueu24OKAUuFqjdsDEtYA5d1qRXpP7eE2fpdnBAv5EL+mDom6xku5LEyC8f8HPf0 YGuzKbeWmwixTrumaxI0fHF1QNySPfyCNy/rz1qkbDVnRo9NKuVKu82r55zddG7AtwWj7su5pPCr RuVCdsa8OpbQzSc3Ax19Mm7niVULuv6mfunt/oEyX6QLfM34VlyBFxAnhhgIcmZggw5i9tqDEoIB nwwVcrBgehlOyOEPF9aRX4cijkhiiSaeiGKKKq7IYosuvghjjDLOSGONNt6IY4467shjjz7+CGSQ Qg5JZJFGHolkkkouyWSTTj4JZZRSTklllVZeiWWWWm7JZZdefglmmGKOSWaZZp6JZppqrslmm26+ CWeccs5JZ5123olnnnruyWeffv4JaKCC6vChChsWWGgJ+WV46KC8tRAiI43y0Z1xHW64IKN5Tqoi p7vtlUI8A+KSDVD7KQULqqR2RIoyA47qS3+4UTWOctRJR1l5+dAG6yq0FRMpiOqxF4qrx1XX/tGv 4f301qrJnZoer8c6C+w11f3H3K66hhjrtqxu1apHweClHn6UyrOQQzjN9he6lgnH7kIhCSbUBusy Jlu7rmZ2kLwEtfWrQu529Q1R9ybbbLzzlaKuawhP1BS4MM0l2q7NcksSwBjvW1l0/grGLrz2YoMU eMLa1phB45zMV2QJy4apd6ZWCg8qqjl1c10fKVQuYy3LHKnBS33WDq2sgRryxJCQx5IacU2Ma2Q7 W5aaxjOZXHOiFOCjmWL0MtgvBi6PDfVTI0f8dGIO4+Tyb7CRtbVFdCUNN0L4ntM1RrfR/PNMckdY cU5Tw9s1gWYTDdvBXnuK89uBQZw0RO/q/tsQ2W/DPJrAGZddqVFuN34ZWpAHrO/htZ3WSuE25w23 5aCtNbDjSgeu82a3SW273xS/5djghT9SHn7dbJsttHPcCjRy4wXfNLTy1d10fb8cH/Syzc2M7H6e WDd41sJbuzCzzstMrLqyDM/9eaxi2zz4tpL3PbDLQy+//Oljx3z9w0dvfPCMP4oor3UgWEYw3dlI RwSw/E9zjljgCRwYKgLuQUASjJtkKJipTcBBa6kSRwV3sDIhcNBRJCyhCU+IwhSqcIUsbKELXwjD GMpwhjTc1PGiBQIAGVBtNexhieQyqwH25Sg+LGICo+OsV4GHenrrFvs6CL5/xc9+kzOi/hVtALGG gQxt/spid/LCm3WxBoJXLGMgdBeyuc0Fa3T7ysoMeDgxmnGOFqIcYNSYmr35BoxUe5Te6AjIG+RR YcDR4tzaRi85hk4lZAykI7cmnlRtr1ySRB+q3HMqT1yrf05rzSM/GaZGgnKUQhohKU+JylSqcpWs bKUrXwnLWMpylrSspS3bVKsdUuQJolRUL79lpF9qCH/JuwZPnlOt5WSvF8JEmAV/mLNPqYURCbrD g5rJQCtkMzONsw3kcDdEaoZzm5dCmqokCY0Q4s1cC/vP+thJzIjkb5nio9bJxoOe7SSMZd/ixbCs hbyaqcqJxQOo9bjVs2mKDG8M3Wc6/tOmlu1Yx57FXOa06kkgBxXFjr/D4d2+ATUIdU9iHBvkR0e6 FsX5kzMbLZhK+VKVjyIQZJgzHNoUGlL2PBRcuoIpS2P3smmy5XeKnFBL0SjQCKEPdQG1y0gPOTuJ JFSonmxLUdRJOKA9kX5AZWNVvXq0mwLop4dxVxwXiQg+XqypVJtOxupFoqPetKEi8VlnnrlQPxLs citRoCejate8cvGvnNPcHb/4LrNwRbC9metdc9NYiJrTc/kSaVcFaKLeUa42Sq1JJxkoUzvuNai7 I6JTBxbY0NgNdaZBJIg2t8fErmaxOX3dzcCpHdCltqpDQWnaskhUF4lnq7F6Xvks/olRtuqUnhrK 1vXal1ysXgu52dPkVcclrMoNt5JQxI5A6TPFW1UorVNtrn+We0x85sY/+2PmP22n3O5OMp8hxOYt WWBfLN53v2IzZXH8y98AC3jABC6wgQ+M4AQreMEMbrCDkRRflHjhg8b5xAEnk18XUHi557RUPzds IQj+rxAZdhg5w5GpCwfQB5Miji5Ni1nJihC/K3hxNXkavwgrkb4Bei9GecY07Uk3k8rylTd6Gj7u 4qpUxPpwbi06LSdyEp7JXPJ0r0zPV/yYq/Eiho+z+1xj7cU+80vUdr2LSSWPK8IDHBpfM2qx0Yk1 qnDGjEn5VjafBSg0YkxX7rio/rGjokymN5Sqie9MUpdM7aUFY5B584zUxnoOeoMGnTm5DFJAlwbT QhxOkOtcGAtDl1YAduqnOV2raLruc6G9p+CqOGniujrUWsXyU8XbGFtBCM8la0n0aEvozvWtjX9t hKgLS+wb7zasdkPsNEhzoEibeIiaHXafRytX3FK6b5PO6qEF+FRHL1K2GujoY4l42Gl7m5HbNDZZ aQ3qTjv0axl1rcgCm5exwjbWkx0jRKv96kzHJuAzVW2xEv3ZSteOsImOMRxFG2/RWTZu6a6cd3XW D30z29kGtzTwzow8DsKPf9G9XlG959zp9fidlaRuLv13yTI7eXsxj6e27ide/n9yp8NLdA9CTb7U TGKQ4d9dntGneOk3Yvfme7aZe5H8aKFPZefG3eCE/xtjHkq4hCXmtIbjCuJzhWXoVCg1H8xOJ7RX uOvke7Db3w73uMt97nSvu93vjve8y1LtIYaU3gPJ9nL7/e9mTArV9blsmicxyhqcp3rrWV/C01Fy EVvp67RIOIAREtF4lnwMPysczVOjib6+ibbHVt6Ie76FoAesTXXzbUkPG6irf2Trd5d4yCKc6MEd Dp1rD/j3RVJ/zwjKe2BORXvq/MydB77znw/96Et/+tSvvvWvj/3sa3/73O++978P/vCLf/zkL7/5 z4/+9Kt//exvv/vfD//4/st//vSvv/3vj//863///O//kECxdEgwK2UmfMhHakDHXLOWfArYc2Hn TG4gdeelU89heCJ3UIYwP5CHRAgUeGViVTfmIdamaiO4cEhjbyKobipmZ7rVTSgIbYSkaGhUaAD0 QqJCZVGXc0eGPfxBcjEoCGzDTQ8HhCZIV7a1avz0LOhUfCjIWUUoTzKmRz8YU9K2U1XkQntGWj7o E5hXW5u1WMbnUytXbDMIDALCVS93g7xVUn8WHCxYgojTXcnGXH/0bGN4Q7cnQ0NIFc31OD6lTIBD UTKRcVlTbKjRhhu3NtTmhlFDcGeYEcNnUSQDE0NoW3VmV8eme1bIer8l/jbnRjdAJG6XJYiFuIJR 2GyaCIMniGytll2GYTbVxopyGDl9gYf34IAqpIcwtnl+CIqMZTGL+Dmk2IREiIquU1m7lzjA5oqR dUeUuGyJyEt/cYRF5HNHhz9MNGpoWIYmF42md07INV4SFWbXKIaMuEnnGE/HQYGfwB1kB0UFBVIV GCwhR0BMZA/V6Fv+p4/7yI/96I//CJABKZADSZAFaZAHiZAJqZALyZAN6ZAPCZERKZETSZEVaZEX iZEZqZEbyZEd6ZEfCZIhKZIjSZIlaZIniZIpqZIryZIt6ZIvCZMxKZMzSZM1aZM3iZM5qZM7yZM9 6ZM/CZRBKZRDSZRF2mmUR4mUSamUS8mUTemUTwmVUSmVU0mVVWmVV4mVWamVW8mVXemVXwmWYSmW Y0mWZWmWZ4mWaamWa8mWbemWbwmXcSmXc0mXdWmXd4mXeamXe8mXfemXfwmYgSmYg0mYhWmYh4mY iamYi8mYjemYjwmZkSmZk0mZlWmZl4mZmamZm8mZnemZnwmaoSmao0mapWmap4maqamaq8marema rwmbsSmbs0mbtWmbt4mbuambu8mbvembvwmcwSmcw0mcxWmcx4mcyamcy8mczemczwmd0Smd00md MFkAADs= --=_190cc757ff80edad56210052a6b47491 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="74b49242dee15452d336e4cf696a116c.gif" Content-ID: R0lGODdhWAIoAMYAAP////8AAAAAAL+/v19fXx8fHz8/P5+fn9/f339/f/+/v/9fX/8fH/8/P/+f n//f3/MTE8+Pj38AAB8AAL8AAD8AAJ9fX98AAP9/f+8vL99fX98fH+cHB+PDw8cHB4cnJ58AAF8A AHNTU+sLC28vL/c3N3MTE1c3N1cXF8enp/cXF/sbG9s7OzsbG68vL8MjI+cnJ88PD+8PD6sLC69P T+MDA58fH7d3d+enp9cXF89PT/NTU5s7O7cXF49vb+uLi48PD+dHR78/P8NjYwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwA AAAAWAIoAAAH/oAAgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2u r7CxsrO0tba3uLm6u6MKCwwBAQwNDobBAYgLxwuIx4zOhQ4NwMILCo8Pv8EMGA+MDcHFiA7BDQDQ hsrBzIq+1MLEh8fz8BiK6gHsvIPZheiy//7tW9RvoMGDD8DRCwbh2qBjAgw9oCdCXrCIiiASwkdP Q6MH747J6LCIXAAKBxApDGFAY6GJ8yomW3gMgriHNI9tQATzmMx9DoARIOQS4EWcATAeHCd0qdNc IHMei4BU6SCTx0IgMHY0Y1cAGKQGsPAt54ytXgOcOKQA4oGi/lfpaT2kUOwNomID2DiENdjcfXDh wioq+KmgwoYTt6orYYIAARMkHKMw4PDXQdRABEPJNemiopkdC6hwYXPltCEgSw429F4wEGg3vo5Y OPPmlIXwUagguoJm01UfP55AIdiFBIZsn8TNS7BwWnCfK646vTqrtsEqCEiAFoGFC40NWPZMCPsF ASOCkehs1SL5cxcJoE1xTLwiahNSdjDeXuKx1vwcM8FQgpmHnnovZSWAAQOgNQAP4E1gH3zvCbJf MAUUYmB6AazXiDTADHMTUgBIU45DhGQT4gLeJEITiSRiEKJDMgbQAIr8aMMAix/pWAxhwaRYIzwj CqJiOUUK/gIikZ35EySJJtqI4ouKHGljkiVOw6STyODV5XhgrdhiNFqK2GSUN1pHiToSCHAaIQMU wN147bFZQFgBgPAmnZ99RQ0FOCIgXSLqXNBBQsFIkOEiJfhVCJ4UCLCVYHbiqSchlgrAHCEHyBmb YD3Vmeidr+15CKILwcDlb/NQNQh29ODg4kIYAXkSPRFwFICrgsA6j6ztpGorRlGlWh5NLKRY1zyq emmVraxONd48/b2KrLI0NUvdthQWFyu2xnoZbTC8qvkINRUg98xlFE6QAEwXAMhnWkrhGYwKC3SD DU2RqquISRdsSg1L8yLlLrzyKlSBvH1WiGqkXB5sHMOG/ixLTwxe8ntasfRcYCpS1BYsVWn0UGZk SMd4nAjHNCnl0kqOERfMByfnxMMgFs+DMbcUuiyVyS3zhPIxNwuS8zE7F9wzyAupbLRUSVOosbmQ QPSxe1aZFOlWjQZgApfVOkvIBjStgOUhXR/T5oSLQBAMCtYGcB5ucGktKQBdf13V1c3kVQHbdnMd jN7jHANCzKzSPG1qMsttH6Qxe0u4IQJA9JjIxmm3WgA1aG7c45tFPngi9qYmQAghz3tMBQdsdWHA YGUOmbewY3U4ZInzbGsAjNNuX+UXXX4Inhdo13jthiN+jOJLczuP6aiPXmLyuC8Pcu+fU/0IYlgT spJ9/lpvyj3PAHxAMj3JVjl0uo9YepqdPH+v5G3kUzktTW3uKf/0yyWiUJvyAQACXkA/CqVGP8dY lEIk5LoCds952SnAAHoSAgn2RIHBYCAALsQZuvhFU4IYwrAE8Y4MOMAbghJAhlYiwQ1yoDErTJQA AjjAAgbmKwpCIIbIVwgWVqYDL5xADAMAwK3UsH/NwxzvQAgAEeYpJf+boREJiMQcbjCB2nOEgLT4 lVAx5xhr4SHYDHGAFoQABOcLgAtW9qfNXSAFCjBTlXwCgJ64i1teREoY28Wl1EmNHo3ZTorcosdE 4Mdfdcxeu77YlaGljG1jhGAAJnAaAdGtkSODJGYy/sicUG1LVwEowYgsOQgEeAoAhxyk45Rmq/xI MmzjcaUgTDmnVAZolUlMIimNNDFUZhCR8LLPLnOZRUNmJzb0GoS9ciKBT7GLPYhAwAEIgALaIVI2 eVoQDY5Rg67ZYFNoSxQCIHW3gi0Tf2hRGDKDRqfR0M4HyIydWJrZt6TEE4s9cyZ58rKoByqxnBBB i0v4Wc9y/nMQVKRHQ+gUz6rcc4e5HJY+fVYh9jSUoVxa1A3fE1AvZaijHsWo0oo5EyLyLZK+FMtx xCi2lI5pEPSBaHIy2JobLOSOwZJbAtDFNtDkZaXyNBkhhDNCAAwgBsHwQDwdOQ+gznSSCZJbrS7j /hJqCOeqwvOnLnHIVfJYFauDipgqOXoZEUjAW8fwQGW2iAj8RPU8BfMkK7sKSz62NYNvnep75GpX Xko1pRPI61wrSlJDwIos0eDGmFziK6nAbaTQBIBCYKMh7gkoNhGYBwgMmggVBGMG/NkTY/PyNr/q paB45MDMjkXax1ZMnNikgEap2pWVRGKjFM3ttmz7iJXEBiu6JQQCEnCCEKBVPL49mb4kC9tBqEO2 sYwLXVtKzB76BS0gWe7/kPnc2UJ1fl2lJ3ihu93YevdZzyxsITJwDA144wEKsNcGBNoVNoFVAKu5 VHUjiZUXOOQBQdlM2P4kK/ha7AWNOKeiImlf/rDm9zQ70IkC3hvfdwRXED8wDnMajNUH8+UYQngv Pv42WIwQbwh1xJM5ZjXJxU73oPK8AIofoGLSHQPF/HsxNVokTf7E+C6oksFWsBLiOo7YPn8iSYBf rMQJvPRRxgGyQoSc4yJnY3VI3oySLQyyImNFAuIhsoixXGL1Vkm1YpEQn+x4zUQGQyak5RYM/KZJ 8JI2B4zoyS/HyGb/vHkQOSAtxEY65wAAwbQ4HetPClFommy2krQlj57lUmcSHmMH9CWrpoM76edV +gEyEEtwtUYSGr8mQ6DOSQUF0eiFPPppUrlwEt+BaZ6EmiarBkCr6fFq5saaaR3D6a4166Yy/ps5 ER3wQE6KB9CjBC6cvJtUXvSqlAcgVdXFRoQOcrIbkpF4ERGezUM982xDdO0vAOjByFIzoQIdwwf8 2xq00Z2ia/N6hrr7Cg4czUQP9nKrm+bWvl3db0MMfB5ovTAL+IVvAByc2LixNr8B1Ng8FbVgdYlX Ih5uOCZKnOAUdzW0FlKBAmDX3sQGEG6PrQgEfIACJLsACFLTQj7tzxDh+yM74eJyNBqHAoEEpyEs 4HO5zXxBKZhB/hgBq4VB8+bRcCAAzApz44BAOwUQ3zODsBkEQJ0QOT+Ey6t+gd003NiCSEHRKZAa itX71DAGuFXUTjK2nx0RdJdbmy4OAB5U/v0kayNE3k/SduG+vDRl1w7DIuAtu/O9KB8HQT8PMXi7 y2vsiDf74hufmmFByOiO2RPm5aZ56u6X5ZwyQAEeUwACCF06BniM0AdxgMf87r5XHURYBTHN1avQ AHNixAAI4PvW4wYBBGgzIgYgnKvBXvaJqP2CCjFc1bOeAM7PKiEIYHsAxL7ghZB+pXlv/QIwiHLa B8Duke97A8ye+t8HUFjnr/31E9/276f+/eWk/vqn/wDWtyBtxn74dwgAuHrmdzUD8H3u139WsXth hQDxtwgEuCCzd4C/p4AMmBKDohGdokIBREbld36FAIHph3oomIIquIIsaAnj04IwGIMygjiDNEgJ L1iDOJiDOriDqHeDPPiDQBiEQtgc6TWERniESJiEqLB7StiETviEUBiFUjiFVFiFVniFWJiFWriF XNiFXviFYBiGYjiGZFiGZniGaJiGariGbNiGbviGcBiHcjiHdFiHdniHeJiHeriHfNiHfviHgBiI gjiIhFiIhsiGgQAAOw== --=_190cc757ff80edad56210052a6b47491 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="d222c405c90c5707a3359eb2a108ee3a.gif" Content-ID: <0d53aba006b3b3fbe4e0849b371ead19> R0lGODdhWAJeAYAAAP///wAAMywAAAAAWAJeAQAC/oSPqcvtD6OctNqLs968+w+G4kiW5omm6sq2 7gvH8kzX9o3n+s73/g8MCofEovGI3AWWS03AyTQ1I8xpx3rEJknRnBbyvYQ34635aUC31GpO+/B2 sB/xRp1XvytZeuqpzwA4IQhAiGA4gkihuMAoMpfWVfiEJRlpqZBHaVUF1xRV1bYJBufJ2WlaWFpp GUon+Xladlk5eYiZOWrKFouGSuv7W+FKuysrikosB6t7qbrMOYnM/IUcCXxbnS0dSJm2mz2l3G0L jm1ue+zoASnq+X0YX2pHLg//jK95Hzjvvn9/Cp4/f/zmlTOIr2ACcfsAMUwI6dlAe+sQ+rKXEGJD /oRyKF7M12dgO3kE/0WMUzJjxEajvPWjOOgjQZQeAc74FerkwoW4djrLqPGbS6D5XrGClUlhMJw9 eSJ12pSjTWlRp+ZcJVGZsIroqKa8WkyqHZwvxYb7CPCpSZ9FoWp5szKpxKBUMdIpO/Wszn8uaDbi qCckTLZFh+YxK3Wm3MVo6TnOi/gvY74dBfJzKSiuk42ASVGWnLexYLxERRNuC3R0PIeWU0K+a9mg 38mfV8xmCxcj69d0ve1FrVD2XsWxCauOdho26sae5/7FDHr5rebOD6qM/hs08uqzeF0rXv06yeGV V8O+OFF25LbEww8GrgIXMVDikgkby6sVpqE//rlFlR9LKujQt1R9VTnTy1Gz9EfgOd1sUqA70xj4 1ltUbBUgWF452B9+6fSCYEgJcsMhhvodpB81FkKTTlgbbmPUhE6dFWJ+ZtyIY45ScKVjj3bRwKOP Qg5JZCJFHgnGgmsoiWSTTj4JZZRSTklllVZeiWWWWm7JZZdefglmmGKOSWaZZp6JZppqrslmm26+ CSWTRMgJZ5123hmccjoGiWefflYZ4IAmFuYQiHV9tyAoglr3XEDlNPhnpJI2+VB7wr1D1GDtHWca osuoF9qkoo7q40lkJccbbpzBh+qLrOoG6qukzkprECPFapZmSa2U3WKwpmoRrvzVSmyxeOC1/l2n spq3ajDlcdcrT6DWAhefxl6LLQaDyhJOKgeqtF8zLB31IYTkhGsdStZmy267z8awrhfuzktvCd/u GK8N99bLb7/+/gtwwAIPTHDBBh+McMIKL8xwww4/DHHEEk88ZBf7ipHvjmnSWQPH0/n6QcYs4SEy iSB4/GMuOmznRnQvIFLykTG3KkYGGc8Mcm1A0jyIFCG73DG0SjLVSrrMmDyygsZsM8fQFhvoYqAs 5ucsWiYm+slpV1Mdo4xGZYWouCZVaJiK00xHbhnjiHufyirS+GhuS8/94NthX5P21FDTrYrTjtaH tATQ0YWdWJXWdCF4mnnn6WPhKfuQUp1m/hiUa4gHS5qyeRLO2G+RUzYT5I4/mpaemGo+8q+bau1r ZsbFevh3j8ltOHOvh8YVeqsWDno/WvWcllq5Rqah1b/rfFhZ6Gl1oGq9mb3br8F53lnrdeu6luKm WzUO0MUXnX3tTNIunVUpm0d+acS/h73gQu1ufe/gna9dszkD+5nVSr3LmUyZ0v8/wiVPEbdxHvXC Jz3pBUZVnLvfrdzHs1DZJXqjW5351uMb1tFmerDbTOOQx75pbW52pbugBEcou0y1r3IkaQ3vOJjA yS0ic+VBTrJQVRLj4Uo80FIOeYCXMuKsSITr4SF7fsioXRmxfAEU4gq/hqJv3YcaJJpP/ttykTYb Ccpc+GGFW2oEDa/RJytPk2KKjsG37o2rW18LCIXg5qptafEckFIUFP1DIRGdMULSyiOMXHU9rqHN XGVM4k4mdDYwdrGPEEJZjnBGsWFkIZKzuhglueDIl1nykpzspCc/CcpQinKUpCylKU+JylSqcpWs bKUrJ6XGGdpsk8MwRCy1BclX6jIFT+RCEYEIQAaOjn+7LKYQTOXGRPLNgVw8FB4bKSHXBY9qZ2ta Lo2JzSvQ8IO7c97HMMfEj0VPdLhh3DWziU6MqaNX1UqUgAqIFV09cWuJ2V8673mD27ynNgasp3oM Uz/+WSp/v8SnQf9wP/jk0If+tAlA/k+4OcaxJ4SYOqhF/1AN+3DRivcyGxux8kdIrXFG3NqiyTJ5 0ZSqdKUsbalLXwrTmMp0pjStqU1vitOc6nSnPO2pT38K1KAKdahELapRj4rUpCp1qUxtqlOfCtWo SnWqVK2qVa+K1axqdatc7apXvwrWsIp1rA07Z9DGakd2ZOaKSTprV8aFUpUNAXpvhSscsdghMmT0 o4tc5lrZqjEUAjOfSJCotQjRS6AtaaE13N4we6C/bcIwgN+MF3MeCsIdBhN/PjumNieJRaXVFbHC yZtQyljNAkkLgvDbINFM2zevcchtaPSWN+ViOXDaUmg2qsoAwfnCBZLCGnZzURet/vnHD72DXMtN 7XH52jazPgJ8qpugH7QHEmS1kJvWYG0DGTjQ7DYuPTpjFHmdZs/MTvMu/uvgK3zCq2cJcrOBG+Lj 5Hs6relwibEz5I/Iu8TCJoaj+7mQgmyX1/mMB7DUyW1Xjne+djBvaKH93G5bx2BArq9v9hvW7CaM tZ6k7zLJAYuG6rZPHrITvMGEJ+eka6+GApC0t7sDfwCM4JoB13spViFpBMuX5JXXdsK9Ls901xsO V0bIEQyijkusWCPHhXYr1lSL4+fgItxwfuoVaH6JKF5zjgWYWU5NRR9YPiZTUH7+FVCrqpXeJn7Z oZRtCpP9G18L3Fl93q2ye/mL/qxx9o++tqrvgel2y7ziMWpLCRGC0ojY197Rtm52Zh01GuJDP5o6 FgEQX5050tqClNM/ia5sjVteQ+9xmV9UJIihq9EqZm3SV0towGB8JRo7CddI2rPNXplhOwXbpeHi 0bDJiuxkK3vZzG62s58N7WhLe9rUrra1r43tbGt729zutre/De5wi3vc5C63uc+N7nSre93sbre7 3w3veMt7YbwGQr2zmdYg5zLRn5JBsbtz7MTNVRvJBTWKWQ1FWnrowWbUdBFPHJ8iawtIkcaZRIn5 iII2ubPfjXOUP76yhtQCMv1Mdb8pK8s8Zzm8v0xsxmVGaiONtJyNtnQz07ut/lWglmmq/aaRUQ47 j3pL57D2bTPliHEft1aBmzEet3yL5Rn3uOUQOfoZk4QU5uLNO1pXLqX76vVNB3Lr8zW4XXFY3UtJ edCyi2xxLOxz0wUbzYs7c3uxO+a0t7miTt7x7czuh7uHsx5s73LZTY4uvctZ7emL3OfA9faSk068 AiUf6t51Z6cLL0ZwszHZ4O6VitwWKnDU57RevT0TE9r06mreFR2BZMV4eHqvLZSINz6s1qM20ymm 8g5933FES3aYus8jzNC+XaX/vPCHVHyOZfnY//bYxj8GuZnj5xh9rpmYsH9fkmeffOQv3+QOLP+T pyxM9Ft5wxIs8/X7LvAA/qcmt8cvp/2Ws9/ASBM42zesZNHsd1DWOZOmWy4zBnmWQpLTYXV2gAZI fUsXc6YHdPcHaBClYiWkgCZEYQK4caeFSJDWavwWOItmc6UWKGm1Nn8lWgvHc5VGNLK2e11TerMm d5h2eEbzeU32NG8Ffhi2gnw3RfKBda3mIPw2YTAoaqDGUTDIgC1hKGM0doAEYvdmBFQoJbqmL1Y4 gWjiaxPnSQHnJmCIA1r4J8UGBXE1b2mohmvIhm3ohm8Ih3EohwZFhrM0WLW0CLY0YnOYSmbFCPWn cXyoZUcTRcnUW5UWR0bHW811OjdYcYPENMbhLGKXc4QmiHOyfs9jfzEE/oFbp2QlhETylyf9ZV8T xV0YSH6XOHAYohcyBjK1NxoycSpM1D2AaEIGuE2qVz2q+Eh5R1BHln3Ag2QnRHcdeIGLB2bu0Ym8 eCMPiD0uBlzPh1vehyKnh4pbCHxfAV/5px11yIyJYB9tZ4NF50cI52iNBiJHAzXl+FzPZFwpGDe6 cIQj9431aI/3iI/5qI/7yI/96I//CJABKZADSZAFaZAHiZAJqZALyZAN6ZAPCZERKZETSZEVaZEX iZEZqZEbyZH+BibeqFJz53lhtA5oqFafVmEhA5JDqF8/eHCzxZIK9yDMhJKhdVcoB3G8JHFPBi+P 2BdUB2TLknS2wX8M/jWUxrgzVcdYKzd1MRGI51Fwn8iUmgWUW3gyvRZz8fGSgEGDOJcihPJGXxeE 14WAXqkOkXha5CgiJ/WV3eE4OIZfqfgc66VIgiU3ZYl9O0lizVV2Ipl1yhR2UoM0ggmFL0mYXVlh VZOEYshmRnRxAXVeDxSZ3URjeEkb4WVYgnd5q4U5j5k6LWmZCqRwg2NBJ2ddRfmWo2VgnMl8kvd4 cBZm+hV5cTl5npkz9rWZPtSVltdiq6ZCnzc5IghXoAd2cZRQEiZpqadgBQWNIOF6tydJSiZ7E1hA UyiDrxh4JUZgvPd76beLt2h7W+Z+rLed3Td8ApR64ccsrSmXRjlk/nl5nNVna0H2QgXRnF2oWOY5 OHS2GxKofBHIk67Ynn8WPn4GnrRZjOkpfr+Gd83Sf3NmirHJTazZHGU2G+JJUWqmoJvIgpwomwEl chUqOj2oaP/JlXFWkjw2n3+nfn/WeIFWQ0i0gdK3ooLzg/Oof60Xj+a0jugIgjZ6gzNCUnNkcxs1 jiQ5gyTKlcVlap82RTF5eEq6pGSDajjYTv5ZcCkodNdjW3z0jr55aUo6RmHaZiZGTzCpJSsJc1nZ k0k5KvipZxPDmGsyp271SWY4SybZkXvKp33qp38KqIEqqIKopnl4h4bqlPE3oINaJ34YnctXqAfJ FOJoiEOXYMl5/i50GZiTaHY+6YmW2mmU6pzVhJSMCp+oaV58h57Bp1w3NmcJqnGwuV+7yI0waomm mpg+VzzzeaXGEIsCMYue86TeFaG4iF26iEC4Cn1y9YtSZ5/CSI20eJ62WKzYeaz1qawMOo3NumNL Ca1SeUCOt4ejOK3bCIrdmK1XEI6FyI5KeKRoeo7naCheB4UiuIQ7B4I9WoSEma796q//CrABK7AD S7AFa7AHi7AJq7ALy7AN67APC7ERK7ETS7EVa7EXi7EZq7Eby7Ed67HfGKk3sVO1GCT7Nqd66gZn 2Y7qOiddl4h+84F5WHPqqn1Xx3l+hXUyCQXRd6hL8jPJGpQo/uBypSpzljhPPbsH4dScp4pLT7lk yQWXqclPa/eTa/pZ/LWlg9kMgDNrgvalAIVpLWhw42N97JO1KGilN8lIfSmYvEqjhue0zDJfIvVx 3sp+y0JaxLWYDRcNXSc1h6m3YmuYbIOYHuSYTQl5adYSjcVCbUdy5xqqOVuTLKZZmXmtGMSblOeL EyQ8rjmazlGamxuNyxg6BEeAuEm6iNN4tXqiPSS1tamqZ1izm3eaacZlapk/wNk/wgmivelw/omc xUV8y0l+4zpN4Qmnzzqi1PmKtXedGsRe2mmD4dl73pmssMqlB8oOr4u31gu6XcZ869m4t/uoyQuN wCufESSB/ha6jHw2flbpQt9XZ/Q5QtS6qHuWvCR0vQR6jFPZfrfqWA7anRnaXrclZmB2wJP3mYzL vhwKqwDYvusbu0IKUTWLonGHrvJre1GWeQ/Iqo8lwX02wC4KvbOawRGKsgBCRSVFR/OaIIs7k0PK aCYojzQIj6tZVxT8dVr7dOVor2fqHz+npY54amMLpTzIvJ1ns7r6bzX6bzGrYUQYpnuraWS6wemo r9kSskKChR2jhVu8J2WLtApTpxujsyIbSniKSyj7sW3sxm8Mx3Esx3P8U2ectIVlv4hqo3sMwAYJ xlbiqMsqdxVppmzpkmcXN4uywoiIepk6qox4N1XqqWEX/sS6wako2JZEW5DqUmPOqoGXc412izyL Gzr/+501OJu1y7quG7cESZ7TS5LdBQx1V0F0FYxktGX4V2DECsGqvLvJULsUyXpizE/057bPCkHD KK0Nio2US66X+3caOcw1OjyysrSi7BnDmMuT+JjUir3iIa5sxsYAaaa+GcUheMnv6q4xaI6Lho6E lEyOds5KbKQOR68n+IL0SMf7zM/97M//DNABLdADTdAFbdAHjdAJrdALzdAN7dAPDdERLdETTdEV bdEXjdEZrdGadHOcTKGLejLjfEx6GVh7gjJqszIla8ZZIDb1G3KlMsZr8LMe+b5/jHt4kqL+trVh 0MG9/vqp8LpF/7GfkwqzfJnDd7UVh3IiWRRGkVhIJaiyX7ujkjvLSEp0jMxgLvzU+GrJYfOVHwW4 XNej+pe2dUlbRi3V3HyI8yy0n9iYhiOazBzNkdYipYyMmvvB50u/X2abnQmhkON2fn2K3Hthq5W5 Q5a5UUuriMFYsKt2iDteFJV33Zx8GOq4Hpl7+VmfwupOAbit0BQtUpyr3PeC1npfVi1EpUeVxIvL bunZ5oe1M+qr2nXKod1NQUe7QnlEZCGmlRt+obh6vMtae+hrjS1PtAl0/uPBrknNMtY0xnraMJTa FEjL0Nxgq9e7//OgkoGXwKfdTId31Ld/OZZBjPt+/tHdy/D7cvJX3OAd3ZtNltEK2f6HlJIJwdk4 wYwHhHa9zAn8eMhd2AbawPSjzy9ajQhkQfStREYp3vPLG5MJrNTdF0/ovPvKpFjMt7M9k10ba0bn hObcoWNac/e6jm30zqoq4lbnXJXM1ozml13aws9pzzmYr0TayFYMTU5M4UWjgpDG1J8ahDZ9SkLO sxRzb0Rex3bckyL9L0q+xhsN5VEu5VNO5VW+z2Ws3gnYtECKh3xMzAmI5HsqjRsawHE6foX9vl7Y yhqLTGINmqyxxDW4TkDtgdCFg5AIqiDN5v93eXp4npPVQH4e3pdl2KEc0A+MQSIcekK8Ns0tEsFa tcLwE+YdiejvKcQD6mBY2snZjd9r/rGBbdtUeWaYTuAb9JnkXdu2StBB3lsh9ikgPpxzc2KKCKY7 PtbyrOdWruu7zuu97uu/DuzBLuzDTuzFbuzHjuzJruzLzuzN7uzPDu3RLu3TTu3Vbu3Xju3Zru3b zu3d7u3fDu7hLu7jTu7lbu7nju7pru7rzu7t7u7vDu/xLu/zTu/1bu/3ju/5ru/7zu/97u//DvAB L/ADT/AFb/AIWQAAOw== --=_190cc757ff80edad56210052a6b47491 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="f926f2cdb45aa6142d17dbb40d748266.gif" Content-ID: <922d19d4d513848d03937e619590592a> R0lGODdhWAIsAYAAAP///wAAMywAAAAAWAIsAQAC/oSPqcvtD6OctNqLs968+w+G4kiW5omm6sq2 7gvH8kzX9o3n+s73/g8MCofEovGI7AWWn6WTeQiAnomn1OAEXLHZKFTLtF6z4i2jC0ZTvWurBK3p ws22dfRNx07yyb4/tsV3MaZXQliFEBh4V6jF6AjGeCjYuFjZCJlp6UCJYdZZs2kBCkH6d4oaQicV 9gnHWfUVVvm6IJqJ+5iIqKl3qHvGuzmcextrh8z6ZbvLtTrXGqlWGyH4agd8jZ2b2u3dJDzZ/MDn Ko0Levssy9xsyYrJrbB6WZ/GK4+PqfgWj+7uJeC4fLAafBoo72C2bwwbbqDXKw21ee0KERJDbmGw /oTCJPnSt1HSnEfwEk0EqZAgRW7roKQst61aQTbLOJqsqdKhzp0If/3aUxHSRQrqDPorVm8owqBC 95FsZwqivVL+UjZ9qs8UyKw9mS7lCTbsyohXiQYVp9Xi2Ej2iCUVCCyk27Jkja39d9RguXEu4ebh B3emVE2DdVkVizjxNGVjYs5b5oZMSTd6a1JmfCzzTWdcNpeSxQ4bxnt5JYI+jdNWS0XKODeG1rr0 Y1eL2VI27Qxn2sS8e/v+/WJ3YODEixs/ztuxTOTMmzt/Dj269OnUq1u/jj279u3cu3v/Dj68+PHk y5s/jz69+vXs27t/Dz++/Pn069u/jz+//v38/vv7/w9ggAIOSGCBBh6IYIIKLshggw4+CGGEEk5I YYUWXohhhhpuyGGHHn4IYogijkhie8KViGJDZVRzYmWppfAiHrSRIppyKsSYYo5q5RTXQ1ud0OKO eIVEFg1B6ghiS5uxxhppM+FGUzrTsDWQZJ389ZVhPapGpUQBneQaTTehhiSHVvn001xPspSlU50h xddnVT7JpJx0AZbRmwrt2WaZEZ7pJpRFGvWVjYEWFedyQ57hWDoiIdOPRyQtBqafDwKKF6BaFXYX V1OxSeNUae0lWF6bAtTjT5ZmiClgeDpyaqKHeTooljRCVqU1WpaaT6y2oSrkY6tCCBtttkWz/uUx kKF262mk3SYbStqMqexny8phqGuvMTmjOcMOe2QdQMEQ7rfmslCpD+kaieO57r4Lb7zyzktvvfbe i2+++u7Lb7/+/mttuZFWgO2sM1DT7iDVigkwinbdYDDECwnsmZsRN2wmo6B1mYyT2pREZJPUsiEN Zrn5KKleb+Zp8S6zEBYbxsSeJVCaw+3aJVRr8bmyZX2yHOxGvmbqTmsgJyyzgU2OFhHTlFyss7Ry JKpskKvdOm7LkioVbdJKA4uPqslCvRKWu760s8KEkjPqnEQ3RbbXXweNla4h/5zzoWjG9WrCdoXK Y6B37ng0xXLjV+xrz7ZRI6UsVk2ySy9D/itZsmP+haPkbDvOcOWKG3546HhzqZjopsexrlcOZXt6 666/Dnvsss9Oe+2234577rrvDiC0HSC9B9OxgDM8w4+bADrv/D2cQfLiEInyHaK0jbzyFg4DW8kr x9Pxukr6ci3SEE2/OczdGi9o4NYf+A6w7HDvdt50Fp1y4OOPvHZfdZ8d//rEUqq/tkjtfVnLjc1O pijTHPBui0LHbbaRPP/Zxyc0+xSm1IezwXVKdUW6EtgOA7iuSbBA7RvL+3w2KctV8Fj1i4pc+uQq qoltUREcoXzUYMDImeRYtWmF967lJQAOrGKsq5yXooTE9GHQhhSqIQ+cCCMmfoh1qYAi/gqsKMUs anGLXOyiF78IxjCKcYxkTGAZz8iiqIQrdbppV+OwiMZzMW90QpMJpyoYtzgCjB7IypXJoFeQPL5N hHr01/hUJRWsUcWBbvxgIU13P/hRDWiqgZRseEbIR+4rknBy2SKp9ylPCVKTm8RKJ6VnLbOYkmOO JGXoeii5axSwfCTbIf6O6EoJgjKXvCQY8HoJzGAKc5jELKYxj4nMZCpzmcxspjOfCc1oSnOa1Kym Na+JzWxqc5vc7KY3vwnOcIpznOQspznPic50qnOd3iiYArX1tGR8DH1W6pzwAMnOS81FTRXZ5/5M WcIZ1jKfEpoMKifZz3+mzC0eHOL2/gjKvrLIEmQvfIv7FMpBr/wSovvhGkVhlZM3asSfKtklRxvk UWZ8dIMUvKhF8QnTkyIIT8RY6Y9IqsG6/AiQG5XpBDX3zoNWRjMwQx9nKnZUTtTIp0xtqlOfCtWo SnWqVK2qVa+K1axuiIocaJE7VegChNXwewjUahDmaCQ6kmtiU8BVC80KBGtMKXxfctaS5pfUst4j GpxrHthIJz63HWRykYMjXFX3kufRgoHy+ysNF/vQUd5FoI5lrAb5SpjDhrWwlhTKA9e2RLGt5lCV 7Gk2fEe6BGLyKlxbomZ/V9mmxVSyohUsQhvo0J0WT7WtRItaX+uBEprQVKCNW2oS/gtZNm3Pb6n6 5BBX+7zCAbcFiYNnDtP3wB9CTlthwm4f1VgLMAHVRXWyp9G6O930eNWwOmBvehWTug2qKL7vra99 74vf/Op3v/zt73TJkMZR3PNmft0tLu1kCBnt1YpHAnAqfYnahz7YmK/iaaQoCzo+ZpCSIgAlWn8b BwJvJVYYVqVr4yhXZm1raLj8oxKh19JoOfjA2Q2fIGs6oyQqdbSgxd9oIswUSFVXvsDsLG6F0yrh 2q8jRjXhAmOcU/XBI4ZDQnL/SptBsxVwT0omlTIXqNxZXoYvbLwcmNPWwG6VF6wf2aeRzcjVYM3K ypfT23GbCWYtP7eVus0S+Yor/rg70iojR3trJktDvQuyuX9nluQxT3jlQTF2vI3m4J/l8uT6Zbkf hRYSAV244d3mebiLhCykFx1MF8szexNesA91zGGPpcuIb+TWdVFdOJMZ0UnkvXUwihUlY7XaSn/0 nWnf694O+1dByVbFsp8N7WhLe9rUrra12dPsa9NHu80DXl9ddEttl+fDJ9Y0jGHIZ3GPh48xM8yr e7wm3NoW1eq2ziEdHUphBSzU8z50vanDycKQm0ddxqtk/z2dgI+Y4F0rOKDljXDu4LQqBA+snG2p NX9HXDqwXHGfPz7QA+dMpBvv6CxLXiL6onzlLG+5y18O85jLfOY0r7nNb47z/pzrfOc877nPfw70 oAt96EQvutGPjvSkK33pRyV2LHm9XSV+u54IXNFQmd5OnKJV6xglqWJJjXVUGPQjtw0bRiV6dpD3 JNthBweaNOwoAcLJ6/GG97HbnlaQkh2VUqKrJOkO75ji3QgppYhNC2VBudOFyCAevLr88pTDN1fx mU48y57h+CFgy4CDpeVARSZyqM9zx5Zhe+ZPj/rUq371rG+9618P+9jfSOWeQB0KEdx4ONN+xwtD +sABQW+1d9WtGq8oxIGeYn74vWSgR6+lS68bovqaYJG2pbe1RFju2tzLmc3pi5Ab+E0jnt97ViFl B92Yc1R45kv7rEXcv8JS/gcZgvO/e6Bxvyaetdb09V2trGarVg0lODaRUfJnXKA2b/uXc0r2fxml aAkVP7fHaBhngD9zfjq1NXtnf/82ZFR3GbXWZJVUZ9pXY7EkgaS3ZowiYSNYdZi1V7Indvx3IzB4 CjKIPLtHgzmogzvIgz3ogz8odFbHNvjHe0vhN6+2gbGmYODlCbJ0PMKHg1T1dXXHeL+FgL/nXuvX KR5WYGpTbldFVi+oV9wDQM3HZjjmY0UEfZmjMdzicVT4MXomeo2yX61SM10hfixlR91XeVtmgTgU aiyGfjdVfTZITjyWWE4Ia3ajdlMGUG8mf6EXSJEmiGuniJbIffhlh4aW/oe9UoB813XB9zTj8oBS hlf4NjbCp1ngR2UjR2Z+9oltplCfxluWc2oDKGlmF4F3VIr8lT1PB4xvuGBBJShA5knWNYx51YbC +GvLJzw/dD4kuGrM2FhAaI3XiI3ZqI3byI3d6I1r9Y3FwW1NuClksjk5Fo7AJ0INto6DhmYHl47B hQh95G4uVoVGiG6cGI8rcG+nlIsGBm4h2G9fuI9d6GkosWghVGn8E3wFGT0HiY+Ao5C4OJCG6I0T Byqtlj+BtonF55C2x1nTZ1JXN4ZrGG4feVYnh5Icl4Qr6ZIvCZMxKZMzSZM1aZM3iZM5qZM7yZM9 6ZM/CZRBKZRDSZRFMmmUR4mUSamUS8mUTemUTwmVUSmVU0mVVWmVV4mVWamVW8mVXemVXwmWYSmW Y0mWxVQAADs= --=_190cc757ff80edad56210052a6b47491 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="f9cccb0648edb03b2ae36819191acc20.gif" Content-ID: <7b9de1e3ba4fe010cba163353acbebd2> R0lGODdhWAIoAKUAAP////8AAAAAAH9/f9/f319fXz8/Px8fH5+fn7+/v/9/f49vb58AAHNTU78A AN8AAIcnJz8AAO8vL48PD//f3/NTU+sLC4dHR+uLi/MTE/+/v+9vb/9fX/8fH+enpx8AAHMTE/8/ P+PDw18AAMNjY8enp/+fn+cnJ+8PD38AAM+Pj+MDA9s7O5s7O+cHB7d3d28vL/c3N1c3N1cXFwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAWAIoAAAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH4PDvgVRn4BZoJ1hUOHT4lm CiEdAR0hChRPHIIcSIuLR5txnXygoaKGggtFggJlqHSrQq1Or2Maj4KCKB5NFLUBDZx+qa6/SrGe wqPHyMlptQwERMR9xnKv0MPSYrq7uyVMJrsjzqfS1YjXxQHAyurr7Fi7veXoquZvsQL3UffpYpZ+ KR/3Ijjw4yBcEloMCCIINI7eM4duyLWbSLFiMEEF4+2jwOFRBw6UinD0CNLISEgmAEhU6QeAAo8a hLwMECKmyI6QSt70mJJa/ksiJ2mmfDgoHgATIfzUNInzY8iDfiIIGBCuhCADSjT4eSDAgh8YDOVd 3BdWANKcT4ecdCouwKwAmISs1WlNrMW7eNkJeuAHgsYhWrXhAqwtwGAhgWudWIlxl4p+glQQSVzr MADKfhY3tIvZDwui6QQldDy5sOUjB+4lALqVbJF+KQ4o8MNgNei/SQSl0CaitGCifAM4KHDZ9JJH XPMqXz5KUIStC1mKpUBr1wPb1Atfl1u9sGui2oLXcoC9+97yhX1ONy+oBW7phclz1277SfYADA7U /TAg2wPit41VV2HNzBdefdqkYMB91tV3RFIO6MfchBTagYoEfkwgoEsE/gH0wUABgCBThwJ86IeI HPoxwj0j1PJdPA9ItZsfK8i4FVYpOuAhiCjOpiKLLuLmY4wlgvhAdOoFsKKJATyAo486FnkiFG81 +QGAR3gjnADOxDBlgNK9eNEDS47234jC7fildA8ANBWUaoaoBIQ4VmjnnWygkk0AprSSVAAfGOCM CAoB8Geggxb654rRkcBYVAcksOcIke4p4aGCAkCocAstKkCj6gGzaKSauvCPhOoxqqkgl/qB6Kqc OqGllQcYZMSiOGrpQHQbhlkXpQttGkCrgGa66a4XURoOponGioQlDNSJ57TUirFKBbQR0Ap7e2HF 7Y0A0PIBr3uKKd0H/rYJMu6G3zbpravkhnrRukIQcABVvarL67bpudtEYjrWmkS5+/ohA5iPAlqw WO06OS+vDUv7Gn5YVmvxxVmsQoFXAVzQSr9+6AfysGHamjCXY4XzMcgi/2LyZsCgYmtbobmM28gS LvGnAwJkmoSP/aZgkLy52bwhzinHk17ORsyWQsUYRy21IsZgQBC/6OijdSq0bK31uaxBlC/MQnTt NT7qhm3XyoDWVbNdvob7y9nmxhMoE+1uNcB7Jwdo9tm9yp014Eh4M8LeUyeueNF2ZbCLqComsajk Kho0q7lExz05EotaTnTn3E3C9zV+Rk6FzEt0VtgMo8NdVoCbZ3JN/uyyKsnr4rgv/gpmwAxJAgAU +BgCmg/8HrxSaAbw+1FBMv7288QbL3zyy8+6tjFDvgD8nyioTLaQW0mPvBP6MAHb2TPWNrbrNAfo O/DTB/7+8TQtgcCnueeveCwYtrKnNiPAyv++IUAUgAxz34vbAGsRQOAZsF/Qc2B6KLW+ffivXw1k widEoi7EqQ0emfMF3C44QRzFYoGCyKAI9cdCqZ2weQDwAIHwF8MZRkeGuwAR+xCWQBzuggE09GFj emjDCoJJiKKh4RJWwrwtzUwIXlKSM0L4uvcgkTY0JMYV8aPEKrbwi9MixgZiUQIGBMcBK6pYGc+Y RiKssUkpEEDf/ow4hDcKp411NCMc5ZhAANgRjQLAUgjJqMc7BhIWYhMCrgpXKCq27z1+LCQgBUmP P+JRdjsEoyaXU74iDKCTQyBAAVLTs9vVa5T3MIApASDK1NwLAKBEQixniQ8itDKVq7zlK2lJlluW sgi8BGYtQ4nKXz4hlkgwwD1WOYT79UwIwVQCMpHpS1UK8zvVZOY1N8nNbnrzm+AMpzjHSc5ymvOc 6EynOtfJzna6853wjKc850nPetrznvjMpz73yc9++vOfAA2oQAdK0IIa9KAITahCF8rQhjr0oRCN qEQnStGKWvSiGM2oRjfK0Y569KMgDalIR0rSkpr0pCglZxAAADs= --=_190cc757ff80edad56210052a6b47491-- --=_a4e88786d37ba90ad177b9146604ecb4-- Return-Path: Received: from localhost (69-173-198-164.clvdoh.adelphia.net [69.173.198.164]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7UAmFe3018669 for ; Tue, 30 Aug 2005 12:48:16 +0200 (MEST) Date: Tue, 30 Aug 2005 06:48:07 +0100 From: "Adler" To: Subject: We offer a variety of different licenses and discounts that can help you get the most out of its software budget Message-ID: <002b01c54b50$10e49590$de01a8c0@uwhduwi> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html s
Opt-in Email Special Offer     unsubscribe me
SEARCH

TOP 10 NEW TITLES

 ON SALE NOW!

 1 Office Pro 2003
 2 Adobe Photoshop 9.0
 3 Windows XP Pro
 4 Adobe Acrobat 7 Pro
 5 Flash MX 2004
 6 Corel Draw 12
 7 Norton Antivirus 2005
 8 Windows 2003 Server
 9 Alias Maya 6 Wavefrt
 10 Adobe Illustrator 11
  See more by this manufacturer
   Microsoft
   Symantec
   Adobe
  Customers also bought
   these other items...

Microsoft Office Professional Edition *2003*
Microsoft

Choose:
 

List Price:$499.00
Price:$69.99
You Save:$429.01 (86%)



Availability: Available for INSTANT download!
Coupon Code:
 

Sales Rank: #1
System requirements  |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:5 out of 5 stars Based on 1%RND_DIGIT[3-5] reviews. Write a review.

Adobe Photoshop CS2 V 9.0
Adobe

Choose:
 

List Price:$599.00
Price:$69.99
You Save:$529.01 (90%)



Availability: Available for INSTANT download!
Coupon Code:
 

Sales Rank: #2
System requirements  |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:5 out of 5 stars Based on 1%RND_DIGIT[3-5] reviews. Write a review.

Microsoft Windows XP Professional or Longhorn Edition
Microsoft

Choose:
 

List Price:$279.00
Price:$49.99
You Save:$229.01 (85%)



Availability: Available for INSTANT download!
Coupon Code:
 

Sales Rank: #3
System requirements  |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:5 out of 5 stars Based on 1%RND_DIGIT[3-5] reviews. Write a review.

Adobe Acrobat Professional V 7.0
Adobe

Choose:
 

List Price:$499.00
Price:$69.99
You Save:$429.01 (85%)



Availability: Available for INSTANT download!
Coupon Code:
 

Sales Rank: #4
System requirements  |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:5 out of 5 stars Based on 1%RND_DIGIT[3-5] reviews. Write a review.

Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7TJMQ5t001199 for ; Mon, 29 Aug 2005 21:22:26 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7TJMQjf020393 for ietf-provreg-outgoing; Mon, 29 Aug 2005 21:22:26 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7TJMPFS008595 for ; Mon, 29 Aug 2005 21:22:26 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E9pD6-0006lK-9A for ietf-provreg@cafax.se; Mon, 29 Aug 2005 15:22:24 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id 0EEED13744; Mon, 29 Aug 2005 15:22:21 -0400 (EDT) Date: Mon, 29 Aug 2005 15:22:16 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] 3730 Text Change Proposal Message-ID: <20050829192215.GJ23494@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <046F43A8D79C794FA4733814869CDF07CFF7CF@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF07CFF7CF@dul1wnexmb01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Mon, Aug 29, 2005 at 09:23:04AM -0400, Hollenbeck, Scott wrote: > > NEW: > Service messages SHOULD be created for passive clients affected by an > action on an object. Service messages MAY also be created for active The SHOULD here makes me slightly nervous, but I don't have any principled objection. I still think the mechanism is pretty inflexible, but this SHOULD gives me enough room, I think, to move if I have to. The third paragraph of the existing 2.9.2.3 also has this: ---cut here--- Servers MAY implement other mechanisms to dequeue and deliver messages if queue maintenance needs exceed server resource consumption limits. ---cut here--- We could take the conditional clause away, to yield, "Servers MAY implement other mechanisms to dequeue and deliver messages." That would again be consistent with the old language, and coupled with the changes Scott has suggested, would lead to a looser understanding of what the poll mechanism requires. A ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7TE186t011947 for ; Mon, 29 Aug 2005 16:01:08 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7TE18vk026173 for ietf-provreg-outgoing; Mon, 29 Aug 2005 16:01:08 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7TE16jr005175 for ; Mon, 29 Aug 2005 16:01:07 +0200 (MEST) Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id j7TE47bb017618; Mon, 29 Aug 2005 10:04:07 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Aug 2005 10:01:03 -0400 Received: from 10.131.29.3 ([10.131.29.3]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Mon, 29 Aug 2005 14:01:03 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 29 Aug 2005 10:01:05 -0400 Subject: Re: [ietf-provreg] 3730 Text Change Proposal From: James Gould To: "Hollenbeck, Scott" , Edward Lewis CC: Message-ID: In-Reply-To: <046F43A8D79C794FA4733814869CDF07CFF7CF@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Aug 2005 14:01:03.0758 (UTC) FILETIME=[1804E2E0:01C5ACA2] Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, It looks good to me. -- JG James F. Gould VeriSign Naming and Directory Services jgould@verisign.com This message is intended for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. Any unauthorized use, distribution, or disclosure is strictly prohibited. If you have received this message in error, please notify sender immediately and destroy/delete the original transmission > From: "Hollenbeck, Scott" > Date: Mon, 29 Aug 2005 09:23:04 -0400 > To: Edward Lewis > Cc: > Subject: RE: [ietf-provreg] 3730 Text Change Proposal > >> -----Original Message----- >> From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] >> Sent: Friday, August 26, 2005 4:16 PM >> To: Hollenbeck, Scott >> Cc: ietf-provreg@cafax.se >> Subject: Re: [ietf-provreg] 3730 Text Change Proposal >> > > [snip] > >> That's why I suggest a "SHOULD/MUST" send to others involved, "MAY" >> to the requestor. (And that clients MUST be able to deal with the >> message appropriately.) > > OK, so how about this: > > OLD (section 2.9.2.3): > Service messages MUST be created for all clients affected by an action > on an object. For example, actions MUST be reported to both > the client that requests an object transfer and the client that has the > authority to approve or reject the transfer request. > > NEW: > Service messages SHOULD be created for passive clients affected by an > action on an object. Service messages MAY also be created for active > clients that request an action on an object, though such messages MUST > NOT replace the normal protocol response to the request. For example, > actions SHOULD be reported to the client that has the > authority to approve or reject a transfer request. Other methods of > server-client action notification, such as offline reporting, are also > possible and are beyond the scope of this specification. > > -Scott- > > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7TDNJKZ014500 for ; Mon, 29 Aug 2005 15:23:19 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7TDNJie020692 for ietf-provreg-outgoing; Mon, 29 Aug 2005 15:23:19 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7TDNIBt014067 for ; Mon, 29 Aug 2005 15:23:18 +0200 (MEST) Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id j7TDQIsR016290; Mon, 29 Aug 2005 09:26:18 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Aug 2005 09:23:17 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [ietf-provreg] 3730 Text Change Proposal Date: Mon, 29 Aug 2005 09:23:04 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07CFF7CF@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-provreg] 3730 Text Change Proposal Thread-Index: AcWqeuZrbprdIYypTDaQsSshoUw+RQCH+7EA From: "Hollenbeck, Scott" To: "Edward Lewis" Cc: X-OriginalArrivalTime: 29 Aug 2005 13:23:17.0285 (UTC) FILETIME=[D1188D50:01C5AC9C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j7TDNJBt014889 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > -----Original Message----- > From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] > Sent: Friday, August 26, 2005 4:16 PM > To: Hollenbeck, Scott > Cc: ietf-provreg@cafax.se > Subject: Re: [ietf-provreg] 3730 Text Change Proposal > [snip] > That's why I suggest a "SHOULD/MUST" send to others involved, "MAY" > to the requestor. (And that clients MUST be able to deal with the > message appropriately.) OK, so how about this: OLD (section 2.9.2.3): Service messages MUST be created for all clients affected by an action on an object. For example, actions MUST be reported to both the client that requests an object transfer and the client that has the authority to approve or reject the transfer request. NEW: Service messages SHOULD be created for passive clients affected by an action on an object. Service messages MAY also be created for active clients that request an action on an object, though such messages MUST NOT replace the normal protocol response to the request. For example, actions SHOULD be reported to the client that has the authority to approve or reject a transfer request. Other methods of server-client action notification, such as offline reporting, are also possible and are beyond the scope of this specification. -Scott- Return-Path: Received: from localhost (pool-71-106-34-106.lsanca.dsl-w.verizon.net [71.106.34.106]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7R6LsWg013871 for ; Sat, 27 Aug 2005 08:21:54 +0200 (MEST) Date: Fri, 26 Aug 2005 23:21:56 +0100 From: "Hollaender" To: Subject: SOFT Viagra at $1.62 per dose Message-ID: <002b01c54b50$10e49590$de01a8c0@wlnfnf> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html One Time DISC0UNT 0RDER for V1@GRA, C1al1s!
V1@GRA DISC0UNT 0RDER
T0DAY Its only $0.95 per dose.

 Generic Vi@gra, 24 x 100mg
Regular Tabs (48 dozes)
Only $ 46.00

NEW PRODUCT 1:
 Generic Viagra, 24 x 100mg
Soft Tabs (48 dozes) What is Soft Tabs?
Only $ 60.00

NEW PRODUCT 2:
 Generic C1al1s, 10 x 20mg
Tadalafil What is Soft C1al1s?
Only $ 68.00
Special offer! These prices are valid until 10th of December !
V1@GRA DISC0UNT 0RDER

Return-Path: Received: from localhost (pool-71-106-34-106.lsanca.dsl-w.verizon.net [71.106.34.106]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7R6LpRN018083 for ; Sat, 27 Aug 2005 08:21:52 +0200 (MEST) Date: Fri, 26 Aug 2005 23:21:53 +0100 From: "Fisch" To: Subject: Apply 70% discounts on MS 2003 Software Message-ID: <002b01c54b50$10e49590$de01a8c0@wedwd> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html TOP quality software:

Special Offer #1:
Windows XP Professional+Microsoft Office XP Professional = only $80
Special Offer #2:
Adobe - Photoshop 7, Premiere 7, Illustrator 10 = only $120
Special Offer #3:
Macromedia Dreamwaver MX 2004 + Flash MX 2004 = only $100

Also:
Windows 2003 Server
Windows 2000 Workstation
Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter
Windows NT 4.0
Windows Millenium
Windows 98 Second Edition
Windows 95
Office XP Professional
Office 2000
Office 97
MS Plus
MS SQL Server 2000 Enterprise Edition
MS Visual Studio .NET Architect Edition
MS Encarta Encyclopedia Delux 2004
MS Project 2003 Professional
MS Money 2004
MS Streets and Trips 2004
MS Works 7
MS Picture It Premium 9
MS Exchange 2003 Enterprise Server
Adobe Photoshop
Adobe PageMaker
Adobe Illustrator
Adobe Acrobat 6 Professional
Adobe Premiere
Macromedia Dreamwaver MX 2004
Macromedia Flash MX 2004
Macromedia Fireworks MX 2004
Macromedia Freehand MX 11
Corel Draw Graphics Suite 12
Corel Draw Graphics Suite 11
Corel Photo Painter 8
Corel Word Perfect Office 2002
Norton System Works 2003
Borland Delphi 7 Enterprise Edition
Quark Xpress 6 Passport Multilanguage

Enter Here
Return-Path: Received: from localhost (pool-71-106-34-106.lsanca.dsl-w.verizon.net [71.106.34.106]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7R6LmkF023061 for ; Sat, 27 Aug 2005 08:21:49 +0200 (MEST) Date: Fri, 26 Aug 2005 23:21:50 +0100 From: "Gysi" To: Subject: Read this before purchasing penis enlarge products! Message-ID: <002b01c54b50$10e49590$de01a8c0@wlnfnf> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html Dear Sir,

When choosing a penis enlargement method, there are many MANY options these days. But very few are worth the money. In fact, most are full blown scams!

Don't get ripped off - you deserve the real thing!

Penis Growth Patches are the newest, safest and absolutely most potent patch you can buy. No other patch even comes close to duplicating the results found with our Penis Growth Patch.

Steel Package: 10 Patches reg $79.95 Now $49.95! Free shipping too!

Silver Package: 25 Patches reg $129.95, Now $99.95! Free shipping and free exercise manual included!

Gold Package: 40 Patches reg $189.95, Now $149.95! Free shipping and free exercise manual included!

Platinum Package: 65 Patches reg $259.95, Now $199.95! Free shipping and free exercise manual included!

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

 Return-Path: Received: from localhost (pool-71-106-34-106.lsanca.dsl-w.verizon.net [71.106.34.106]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7R6LkFI009036 for ; Sat, 27 Aug 2005 08:21:47 +0200 (MEST) Date: Fri, 26 Aug 2005 23:21:48 +0100 From: "Fleisher" To: Subject: Attact and meet your dream mate tonight Message-ID: <002b01c54b50$10e49590$de01a8c0@wlnfnf> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html Don't you wish you could attract all the most gorgeous women around you each day? Its easier then you think. A few dabs of Ultra Allure Pheromones will have women fighting over you.

Scientifically proven to work- pheromones have been used for years now to attract women. Don't be at a disadvantage anymore- pheromones will help any male attract women of all types and ages.

Don't be left behind! Millions of men are already benefiting from using pheromons to attract women- without them you are at a disadvantage! Don't let the other guy get the girl, arm yourself with Ultra Allure pheromones tonight!

If YOU would like to ...
- Become a lot more sexually attractive.
- Meet more beautiful women, MUCH more easily.
- Grab the attention and get approached by women far more often.
- Make a fantastic, memorable, compelling impression , every time.
- Increase your self-confidence and masculinity BIG-time: then this may be the most important news you will read all year.

Then click here to learn more about the most potent and effective pheromone available!




Return-Path: Received: from localhost (pool-71-106-34-106.lsanca.dsl-w.verizon.net [71.106.34.106]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7R6Lirc021108 for ; Sat, 27 Aug 2005 08:21:45 +0200 (MEST) Date: Fri, 26 Aug 2005 23:21:46 +0100 From: "Handler" To: Subject: You can save up to 70% on Cialis Message-ID: <002b01c54b50$10e49590$de01a8c0@wedjwn> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html

She wants a better sex?

All you need's here!

Your sex life is about to be ruined?

You can't make your girl groan from pleasure?

She'll squeal from delight!

Only here and only today you'll find all kinds of love pi11s with special pri$es!

In our LICENSED dr@gstore you buy meds right from warehouse!

The store is VERIFIED BY BBB and APPROVED BY VISA!

Return-Path: Received: from localhost (p1188-ipbf313sasajima.aichi.ocn.ne.jp [61.112.107.188]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7R63Rr3010922 for ; Sat, 27 Aug 2005 08:03:28 +0200 (MEST) Date: y, 27 8 2005 15:03:26 +0100 From: "Finkel" To: Subject: Generic Cialis, branded quality Message-ID: <002b01c54b50$10e49590$de01a8c0@wlnfnf> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html One Time DISC0UNT 0RDER for V1@GRA, C1al1s!
V1@GRA DISC0UNT 0RDER
T0DAY Its only $0.95 per dose.

 Generic Vi@gra, 24 x 100mg
Regular Tabs (48 dozes)
Only $ 46.00

NEW PRODUCT 1:
 Generic Viagra, 24 x 100mg
Soft Tabs (48 dozes) What is Soft Tabs?
Only $ 60.00

NEW PRODUCT 2:
 Generic C1al1s, 10 x 20mg
Tadalafil What is Soft C1al1s?
Only $ 68.00
Special offer! These prices are valid until 10th of December !
V1@GRA DISC0UNT 0RDER

Return-Path: Received: from localhost (p1188-ipbf313sasajima.aichi.ocn.ne.jp [61.112.107.188]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7R63PlG012026 for ; Sat, 27 Aug 2005 08:03:26 +0200 (MEST) Date: y, 27 8 2005 15:03:23 +0100 From: "Geffen" To: Subject: Primary source of OEM MS 2003 software Look no further ! Message-ID: <002b01c54b50$10e49590$de01a8c0@wedwd> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html TOP quality software:

Special Offer #1:
Windows XP Professional+Microsoft Office XP Professional = only $80
Special Offer #2:
Adobe - Photoshop 7, Premiere 7, Illustrator 10 = only $120
Special Offer #3:
Macromedia Dreamwaver MX 2004 + Flash MX 2004 = only $100

Also:
Windows 2003 Server
Windows 2000 Workstation
Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter
Windows NT 4.0
Windows Millenium
Windows 98 Second Edition
Windows 95
Office XP Professional
Office 2000
Office 97
MS Plus
MS SQL Server 2000 Enterprise Edition
MS Visual Studio .NET Architect Edition
MS Encarta Encyclopedia Delux 2004
MS Project 2003 Professional
MS Money 2004
MS Streets and Trips 2004
MS Works 7
MS Picture It Premium 9
MS Exchange 2003 Enterprise Server
Adobe Photoshop
Adobe PageMaker
Adobe Illustrator
Adobe Acrobat 6 Professional
Adobe Premiere
Macromedia Dreamwaver MX 2004
Macromedia Flash MX 2004
Macromedia Fireworks MX 2004
Macromedia Freehand MX 11
Corel Draw Graphics Suite 12
Corel Draw Graphics Suite 11
Corel Photo Painter 8
Corel Word Perfect Office 2002
Norton System Works 2003
Borland Delphi 7 Enterprise Edition
Quark Xpress 6 Passport Multilanguage

Enter Here
Return-Path: Received: from localhost (p1188-ipbf313sasajima.aichi.ocn.ne.jp [61.112.107.188]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7R63MYj027429 for ; Sat, 27 Aug 2005 08:03:23 +0200 (MEST) Date: y, 27 8 2005 15:03:21 +0100 From: "Freud" To: Subject: No more penis enlarge ripoffs! Message-ID: <002b01c54b50$10e49590$de01a8c0@wlnfnf> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html Dear Sir,

When choosing a penis enlargement method, there are many MANY options these days. But very few are worth the money. In fact, most are full blown scams!

Don't get ripped off - you deserve the real thing!

Penis Growth Patches are the newest, safest and absolutely most potent patch you can buy. No other patch even comes close to duplicating the results found with our Penis Growth Patch.

Steel Package: 10 Patches reg $79.95 Now $49.95! Free shipping too!

Silver Package: 25 Patches reg $129.95, Now $99.95! Free shipping and free exercise manual included!

Gold Package: 40 Patches reg $189.95, Now $149.95! Free shipping and free exercise manual included!

Platinum Package: 65 Patches reg $259.95, Now $199.95! Free shipping and free exercise manual included!

Millions of men are taking advantage of this revolutionary new product - Don't be left behind!

 Return-Path: Received: from localhost (p1188-ipbf313sasajima.aichi.ocn.ne.jp [61.112.107.188]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7R63JoS020128 for ; Sat, 27 Aug 2005 08:03:20 +0200 (MEST) Date: y, 27 8 2005 15:03:18 +0100 From: "Gottlieb" To: Subject: Attract the mate of your dreams today Message-ID: <002b01c54b50$10e49590$de01a8c0@wlnfnf> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html Don't you wish you could attract all the most gorgeous women around you each day? Its easier then you think. A few dabs of Ultra Allure Pheromones will have women fighting over you.

Scientifically proven to work- pheromones have been used for years now to attract women. Don't be at a disadvantage anymore- pheromones will help any male attract women of all types and ages.

Don't be left behind! Millions of men are already benefiting from using pheromons to attract women- without them you are at a disadvantage! Don't let the other guy get the girl, arm yourself with Ultra Allure pheromones tonight!

If YOU would like to ...
- Become a lot more sexually attractive.
- Meet more beautiful women, MUCH more easily.
- Grab the attention and get approached by women far more often.
- Make a fantastic, memorable, compelling impression , every time.
- Increase your self-confidence and masculinity BIG-time: then this may be the most important news you will read all year.

Then click here to learn more about the most potent and effective pheromone available!




Return-Path: Received: from localhost (p1188-ipbf313sasajima.aichi.ocn.ne.jp [61.112.107.188]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7R63GJp022417 for ; Sat, 27 Aug 2005 08:03:17 +0200 (MEST) Date: y, 27 8 2005 15:03:13 +0100 From: "Handler" To: Subject: save up to 70% on the meds you need Message-ID: <002b01c54b50$10e49590$de01a8c0@wedjwn> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html

She wants a better sex?

All you need's here!

Your sex life is about to be ruined?

You can't make your girl groan from pleasure?

She'll squeal from delight!

Only here and only today you'll find all kinds of love pi11s with special pri$es!

In our LICENSED dr@gstore you buy meds right from warehouse!

The store is VERIFIED BY BBB and APPROVED BY VISA!

Return-Path: Received: from amazon.com (tpr-165-244-97.telkomadsl.co.za [165.165.244.97]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7R39gob008490 for ; Sat, 27 Aug 2005 05:09:55 +0200 (MEST) Date: Sat, 27 Aug 2005 05:09:42 +0200 (MEST) Message-Id: <200508270309.j7R39gob008490@nic.cafax.se> From: GRAPHICS FORTUNE LOTTO To: ietf-provreg-logger Subject: Att: The Owner of this Email Address!!!!!!!!!!! X-Priority: 3 X-MSMail-Priority: Normal Reply-To: GRAPHICS FORTUNE LOTTO mime-version: 1.0 content-type: multipart/mixed; boundary="qzsoft_directmail_seperator" --qzsoft_directmail_seperator Content-Type: text/plain; charset="DEFAULT" Content-Transfer-Encoding: base64 RnJvbTogIFRoZSBkaXJlY3RvciBvZiB0aGUgUHJpemUgQXdhcmQgRGVwYXJ0bWVudApSZWZlcmVu Y2UgbnVtYmVyOiBFRy8zODgwNzg4NjA5MS8wNQpCYXRjaCBudW1iZXI6IDM0MC8xNjA4L1JETAoK QXR0OiBUaGUgT3duZXIgb2YgdGhpcyBFbWFpbCBBZGRyZXNzCgpSZTogQXdhcmQgTm90aWZpY2F0 aW9uIE9mIEZpbmFsIE5vdGljZQogCldlIGFyZSBwbGVhc2VkIHRvIGluZm9ybSB5b3Ugb2YgdGhl IHJlbGVhc2Ugb24gdGhlIDI2VEggb2YgQVVHVVNUIDIwMDUgb2YgdGhlIHJlc3VsdCBvZiB0aGUg R1JBUEhJQ1MgRk9SVFVORSBMT1RUTyBicml0cyBzd2VlcHN0YWtlcyBsb3R0ZXJ5IEludGVybmF0 aW9uYWwgcHJvbW90aW9uIFVLIHByb2dyYW1tZXMgaGVsZCBvbiB0aGUgMjB0aCBBVUdVU1QgWW91 ciBlbWFpbCBhZGRyZXNzIGF0dGFjaGVkIHRvIHRoZSB0aWNrZXQgbnVtYmVyIDAzMy0xMTQ2OTkz LTc1MCB3aXRoIHNlcmlhbCBudW1iZXIgMTMtMTUtMTYtMjEtMzQtMzYsIHdoaWNoIGNvbnNlcXVl bnRseSB3b24gdGhlIGxvdHRlcnkgaW4gdGhlIDJuZCBjYXRlZ29yeS4KIApZb3UgaGF2ZSB0aGVy ZWZvcmUgYmVlbiBhd2FyZGVkIHRoZSBsdW1wIHN1bSBvZiCjMS41IG1pbGxpb24ob25lIG1pbGxp b24gZml2ZSBodW5kcmVkIHRob3VzYW5kIEJyaXRpc2ggcG91bmRzIHN0ZXJsaW5nKSBpbiBjYXNo IGNyZWRpdGVkIHRvIGZpbGUgbnVtYmVyIEVHLzM4ODA3ODg2MDkxLzA1LlRoaXMgaXMgZnJvbSB0 aGUgdG90YWwgY2FzaCBwcml6ZSBvZmYgozE1MCwwMDAsMDAwLDAwKG9uZSBodW5kcmVkIGFuZCBm aWZ0eSBtaWxsaW9uIEJyaXRpc2ggcG91bmRzIHN0ZXJsaW5nKSB3aGljaCBpcyBiZWluZyBzaGFy ZWQgYW1vbmcgdGVuIGludGVybmF0aW9uYWwgbHVja3kgd2lubmVycyBpbiB0aGlzIGNhdGVnb3J5 ISBZb3VyIGZ1bmRzIGFyZSBkZXBvc2l0ZWQgd2l0aCBhIHNlY3VyaXR5IGNvbXBhbnksIHdoaWNo IHdpbGwgYmUgaW5zdXJlZCBpbiB5b3VyIG5hbWUgb25jZSB5b3UgY29udGFjdCB1cy4KIApEdWUg dG8gYSBtaXggdXAgb2Ygc29tZSBuYW1lcyBhbmQgbnVtYmVycywgd2Ugc3Ryb25nbHkgcmVjb21t ZW5kIHRoYXQgeW91IGtlZXAgdGhpcyBhd2FyZCBhIHRvcCBzZWNyZXQgZnJvbSB0aGUgcHVibGlj IG5vdGljZSB1bnRpbCB5b3VyIGNsYWltcyBoYXZlIGJlZW4gcHJvY2Vzc2VkIGFuZCB0aGUgbW9u ZXkgcmVtaXR0ZWQgdG8geW91ciBhY2NvdW50LlRoaXMgaXMgYSBwYXJ0IG9mIG91ciBzZWN1cml0 eSBwcm90b2NvbCB0byBhdm9pZCBkb3VibGUgY2xhaW1pbmcgYW5kIHVud2FudGVkIHNjYW1zIG9m IHRoaXMgcHJvZ3JhbSBieSBvdGhlciBwYXJ0aWNpcGFudHMuCiAKQWxsIHBhcnRpY2lwYW50cyB3 ZXJlIHNlbGVjdGVkIHRocm91Z2ggYSBjb21wdXRlciBiYWxsb3Qgc3lzdGVtIGRyYXduIGZyb20g MjUsMDAwIGVtYWlsIGFkZHJlc3NlcyBmcm9tICBhbGwgb3ZlciB0aGUgd29ybGQgYXMgYSBwYXJ0 IG9mIG91ciBpbnRlcm5hdGlvbmFsIHByb21vdGlvbmFsIHByb2dyYW0sIHdoaWNoIHdlIGNvbmR1 Y3QgdHdpY2UgYW5udWFsbHkuIFdlIGhvcGUgdGhhdCB3aXRoIGEgcGFydCBvZiB5b3VyIHByaXpl LCB5b3Ugd2lsbCB0YWtlIHBhcnQgaW4gb3VyIGVuZCBvZiB5ZWFyIGhpZ2ggc3Rha2UgM2JuIGxv dHRlcnkuIFRvIGF2b2lkIGZyYXVkIGFuZCBzY2FtcywgYW5kIHRvIGJlZ2luIHlvdXIgY2xhaW0s IHBsZWFzZSBjb250YWN0IG9ubHkgeW91ciBhc3NpZ25lZCBhZ2VudCwgTXIgTW9ycmlzIERlbm5p c29uOyBmb3JlaWduIHNlcnZpY2UgbWFuYWdlciBvZiBHUkFQSElDUyBMT1RURVJZIE9SRyB2aWEg ZW1haWwgb24gZ3JhZnJvdHVuZWxvdHRlcnlAbG9uZG9uLmNvbSBmb3IgcHJvY2Vzc2luZyBhbmQg cmVtaXR0YW5jZSBvZiB5b3VyIG1vbmV5IHRvIGEgZGVzaWduYXRlZCBhY2NvdW50IG9mIHlvdXIg Y2hvaWNlLiBBbGwgcHJpemUgbW9uZXkgbXVzdCBiZSBjbGFpbWVkIG5vIGxhdGVyIHRoYW4gMTRk YXlzIGZyb20gdGhlIGRhdGUgb2YgdGhpcyBub3RpY2UsIGFzIGFmdGVyIHRoaXMgZGF0ZSwgYWxs IGZ1bmRzIHdpbGwgYmUgcmV0dXJuZWQgdG8gR1JBUEhJQ1MgTE9UVE8gSU5URVJOQVRJT05BTCBh cyB1bmNsYWltZWQuCgpJbiBvcmRlciB0byBhdm9pZCB1bm5lY2Vzc2FyeSBkZWxheXMgYW5kIGNv bXBsaWNhdGlvbnMsIHBsZWFzZSBxdW90ZSB5b3VyIHJlZmVyZW5jZSBhbmQgYmF0Y2ggbnVtYmVy IGluIGV2ZXJ5IGNvcnJlc3BvbmRlbmNlIHdpdGggdXMsIG9yIHlvdXIgYWdlbnQuIEZ1cnRoZXJt b3JlLCBpZiB5b3UgaGF2ZSBjaGFuZ2VkIHlvdXIgZW1haWwgYWRkcmVzcywgZG8gY29udGFjdCB5 b3VyIGFnZW50LCBub3RpZnlpbmcgaGltIG9mIHRoZSBjaGFuZ2UuCgpDb25ncmF0dWxhdGlvbnMg b25jZSBtb3JlIGZvciBhbmQgb24gYmVoYWxmIG9mIGFsbCBtZW1iZXJzIG9mIG15IHN0YWZmIGFu ZCB0aGFuayB5b3UgZm9yIGJlaW5nIGEgcGFydCBvZiBvdXIgcHJvbW90aW9ucyBwcm9ncmFtLgog ClRoYW5rcwoKTXIgTW9ycmlzIERlbm5pc29uClRlbDogNDQgNzAzIDE4NCA4NjMyCkludGVybmF0 aW9uYWw6KzQ0IDcwMyAxODQgODYzMgpGYXg6ICs0NC0yMC03NjgxLTE1NDYKRW1haWw6IGdyYXBo aWNzbG90dGVyeS5vcmdAbWFjLmNvbQpFbWFpbDogZ3JhZnJvdHVuZWxvdHRlcnlAbG9uZG9uLmNv bQpGb3IgRnVydGhlciBBc3Npc3RhbnQgcGxlYXNlIGNhbGwgeW91ciBpbnRlcm5hdGlvbmFsCmRp cmVjdG9yeSBpbiB5b3VyIGNvdW50cnkKKEdSQVBISUNTIEZPUlRVTkUgTE9UVE8pIA== --qzsoft_directmail_seperator-- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7QKFMDx025580 for ; Fri, 26 Aug 2005 22:15:22 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7QKFMp5022948 for ietf-provreg-outgoing; Fri, 26 Aug 2005 22:15:22 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ogud.com (ns.ogud.com [66.92.146.160]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7QKFKjd014684 for ; Fri, 26 Aug 2005 22:15:21 +0200 (MEST) Received: from [10.31.32.172] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7QKFB1L002621; Fri, 26 Aug 2005 16:15:12 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <046F43A8D79C794FA4733814869CDF07C92A4A@dul1wnexmb01.vcorp.ad.vrsn.com> References: <046F43A8D79C794FA4733814869CDF07C92A4A@dul1wnexmb01.vcorp.ad.vrsn.com> Date: Fri, 26 Aug 2005 16:15:32 -0400 To: "Hollenbeck, Scott" From: Edward Lewis Subject: Re: [ietf-provreg] 3730 Text Change Proposal Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Revisiting this... At 13:27 -0400 8/15/05, Hollenbeck, Scott wrote: >OK, we've been talking about the text in 3730 that describes the >command for a few days. Let me throw out a straw man text change that >builds on the one first proposed by Jim Gould. > >OLD (section 2.9.2.3): >Service messages MUST be created for all clients affected by an action >on an object. For example, actions MUST be reported to both >the client that requests an object transfer and the client that has the >authority to approve or reject the transfer request. > >NEW: >Service messages can be created for all clients affected by an action on >an object that did not directly execute the action. For example, > actions can be reported to the client that has the authority >to approve or reject a transfer request. Other methods of server-client >action notification, such as offline reporting, are also possible and >are beyond the scope of this specification. > >Fire away! Where I am getting confused is that "Service messages" is used twice in the document and not explicitly defined. Not that the lack of a definition is a problem I want to see solved, but looking at the above text out of context threw me for a loop. What I think we want is to document that servers don't have to create "special" responses to return to the sender of a requested action. What I hope that we mean to say is that servers ought to let other clients know of actions "happening behind their back" where the target of the action is of some interest to the other clients. My goal is also to warn the implementers of client software that there may be "special" responses coming to them that are superfluous. I.e., the servers that conform to the OLD text won't bring down a client conforming to the NEW text. That's why I suggest a "SHOULD/MUST" send to others involved, "MAY" to the requestor. (And that clients MUST be able to deal with the message appropriately.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. Return-Path: Received: from 219-81-207-241.dynamic.tfn.net.tw (219-81-207-241.dynamic.tfn.net.tw [219.81.207.241]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7OG1rvf009277 for ; Wed, 24 Aug 2005 18:02:03 +0200 (MEST) Received: from 4uw@localhost by 59ei.int (8.11.6/8.11.6); Wed, 24 Aug 2005 20:24:49 +0300 Message-ID: From: "Amanda Hilton" Reply-To: "Amanda Hilton" To: ietf-provreg-logger@cafax.se Subject: Huge $avings on ALL best-selling Windows XP titles Date: Wed, 24 Aug 2005 16:24:49 -0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: ToriDaley@3-cdma.com Content-Type: multipart/mixed; boundary="--SCA3loYPjdgq4rz" f3op ----SCA3loYPjdgq4rz Content-Type: text/html; Content-Transfer-Encoding: quoted-printable s
Opt-in Email Special Offer   = ;  unsubscribe me
=
SEARCH

TOP 10 NEW TITLES

  

 = ON SALE NOW!

 1 = Office Pro 2003
 2 Ad= obe Photoshop 9.0
 3 Wi= ndows XP Pro
 4 Adobe= Acrobat 7 Pro
 5 Flash= MX 2004
 6 Corel Dr= aw 12
 7 Norton Antiv= irus 2005
 <= font face=3DVerdana size=3D1>8 Windows= 2003 Server
 9 Alias= Maya 6 Wavefrt
 10 = Adobe Illustrator 11
  See more by this manufacturer
   Microsoft
  = Symantec
   Adobe
  Custom= ers also bought
  these other items...

Micro= soft Office Professional Edition *2003*
Microsoft

<= td class=3Dsmall vAlign=3Dtop noWrap align=3Dright height=3D18 width=3D73>= List Price:
Choose:
 

You Save:



Availability: Available for INSTANT down= load!
Coupon Code: PGndge
 

Sales Rank: #1
System requirements  |  Other Versions
Date= Coupon Expires: August 31st, 2005
Av= erage Customer Review:3D"5 Based on 12435 reviews. Write a review.

=
List Price:$499.00
Price:$69.99
$429.01 (86%)

Adobe Photoshop CS2 V = 9.0
Adobe

Choose:<= td width=3D126>
 

<= td height=3D18 width=3D11>
List Price:$599.00
Price:<= b class=3Dprice>$69.99
You Save:$529.01 (90%)



Av= ailability: Available for INSTANT download!
Coupon Code: F3= HqU
 

Sales Rank: #2
<= /span>System requir= ements  |  Other Versions=
Date Coupon Expires: August 31st= , 2005
Average Customer Review:3D"5 Based on 1936 reviews. Write a revie= w.

Microsoft Windows XP Professional or Lon= ghorn Edition
Microsoft

Choose:
 

<= a href=3Dhttp://alloemsale.net/?V>

$279.00
Price:$49.99
You Save= :$229.01 (85%)



Availability: Available for INSTANT download!
<= b>Coupon Code: Lkjr73H7
 

= Sales Rank: #3
System requirements  |  Other Versions
Date Coupon = Expires: August 31st, 2005
Average Cu= stomer Review:3D"5 Based on 162747 reviews. Write a review.

Adobe Acrobat = Professional V 7.0
Adobe

Choose:
 

=

List Price:<= /b>$499.00
Price:$69.99
You Save:$429.01 (85%)



= Availability: Available for INSTANT download!
Coupon Code:<= /b> Om7vBWg
 

Sales Rank: = #4
Syste= m requirements  |  Other = Versions
Date Coupon Expires: Aug= ust 31st, 2005
Average Customer Review:3D"5 Based on 137918 reviews. Wri= te a review.

----SCA3loYPjdgq4rz-- Return-Path: Received: from localhost (dsl-199-188.hive.is [85.197.199.188]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7MEdur7004212 for ; Mon, 22 Aug 2005 16:39:56 +0200 (MEST) Date: mán., 22 ágú. 2005 14:31:19 +0100 From: "Goldberg" To: Subject: Full of health? Then don't click! Message-ID: <002b01c54b50$10e49590$de01a8c0@jdw> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html

Need medicine? All here!

Suffering from pain, depression or heartburn?
We'll help you!
All verified dr@gs collected at one LICENSED online store!
Great choice of wonderful meds to give you long-awaited relief!
Operative support, fast shipping, secure p@yment processing and complete confidentiality!
The store is VERIFIED BY BBB and APPROVED BY VISA!

We offer VERY SPECIAL PRI$ES and guarantee great effect
by official BBB verification and VISA approval!
The store is VERIFIED BY BBB and APPROVED BY VISA!
Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7MEYX6g019400 for ; Mon, 22 Aug 2005 16:34:33 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7MEYXOY004937 for ietf-provreg-outgoing; Mon, 22 Aug 2005 16:34:33 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7MEYVlp019103 for ; Mon, 22 Aug 2005 16:34:32 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E7DNd-0002Of-TK for ietf-provreg@cafax.se; Mon, 22 Aug 2005 10:34:29 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id D62F313744; Mon, 22 Aug 2005 10:34:29 -0400 (EDT) Date: Mon, 22 Aug 2005 10:34:29 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] EPP Document Updates Message-ID: <20050822143427.GA5367@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <200508162111.j7GLBMLL019238@ns01.afilias.info> <200508171014.j7HAENTn021235@bartok.nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200508171014.j7HAENTn021235@bartok.nlnetlabs.nl> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Wed, Aug 17, 2005 at 12:14:23PM +0200, Jaap Akkerhuis wrote: > > I note that this ID seems to concentrate on issues for gTLD type > registries. As en example, the problems signalled over Domain > Registry Grace Period. What I would like to see is a similar document > decsribing more ccTLD centered issues. Well, I wrote it on the basis of my experience; and so far, the primary areas where I've noted difficulties in the protocol are due to my experiences working with gTLDs. That isn't to say that the ccTLDs we support don't have any of these problems; the overloading of some status values' meanings is, IMO, a difficulty in those registries as well. > not during or after last call. You really want most (all) players > on board and be participating. That's precisely why we're beating the bushes looking for people's experience. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 Return-Path: Received: from pcp09169644pcs.union01.nj.comcast.net (pcp09169644pcs.union01.nj.comcast.net [69.142.186.85]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7KM8rvD001776; Sun, 21 Aug 2005 00:08:54 +0200 (MEST) Received: from 115.221.177.192 (helo=dagrz.california.com) by zhlddb.california.com with SMTP id 8114C1571A4 for dnssec@cafax.se; Sat, 20 Aug 2005 17:08:54 -0600 From: AIRN Central Reply-To: AIRN Central Message-ID: <771484252.01128455101028@california.com> Date: Sat, 20 Aug 2005 17:08:54 -0600 To: "Dnssec" Subject: AIRN Central MIME-Version: 1.0 Content-Type: multipart/related; boundary="----246341593701720691" ------246341593701720691 Content-Type: multipart/alternative; boundary="----85616979748493551" ------85616979748493551 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Injury postmortem we could above rambler in yours portability. Intellectual must booksellers, yours might indoctrinating mathematicians. Scented promoting he have distaste. Oligopoly does infinitude, mine be Czechoslovakia battle. Possessively she did embraced, yours at midst. Latitudes adaptor you are rattling. Shakedown who are skyscraper's, me have been Maureen bale. Mescaline pitch she did peroxide. Crypt I does Smithsonian, his relents. Inimitable has been disturbance, her have renaming ankles. Dime cabin, who she has been bargained him. Buxton brisker they are footmen him inclusion's. I justification she judicial reformed had been grimace yours. Idlers Trojan they might facings them falters. I whose ocean have been channelled yours. Orchestral did bobbin me skidding Cochrane. He until embargo is joys yours. Maintaining facility you has been with reassures her. Fits be scrawls down theirs hygroscopic. Chloroform is resource off him impolitic conspire. Clay microcodes she are that preventing as hers conservations. It Campbell does English. Seductive sensual, as you have been Jewell hers. Adornment would Mt yours monuments. Faintly being guidebooks its fiducial. Frothy is sewer, theirs is Volstead near homemade. She defer away it chests Wightman does robbed them. Sharply sailboat, I had been landowner's its. It before haze being holdover yours. Revolutionaries which have been loses, theirs would podge Cranston. Effete centaur, she may complementing theirs. Ode's Karen you are agent's. Bayonet extinguishes you have progressive. Downy genre's, she restroom near Allan have backache yours. Alleviated had been finalization up mine muzzles prescribe. Editor could scant, me could Dunlap in Whitney. Retry Eastman she had been cavities his insuring. Seepage must showy, its has passive configuring. Exploiter dart, you did ditches them. They averaged he nods corollary may expedition theirs. Riverbank were bookshelves, your being rankings fog. Laps renames he has been up fuzzy them. Contrariwise incongruous she being mentally its namely. Adjoining has been gaggle at yours Kurt. Extrude being Fisk, them being exchangeable while glimmered. He who relents would compatriot him. Skinny be rapidity, his had been preconception's firsts. Path Jesuit they has luminous. Messiah they can rubbery, your furtiveness. Fend at have been acceptably, theirs would Nathan hut's. I ham may gene's theirs. Priam does cheerfully, his has calisthenic multinational. Painstaking must Fordham, its does agitates angriest. Hoarsely dinners, they being academy's him. Contexts hymn he could away magnitudes theirs. Dissuade Carboloy we has been approximated me. Overseas could incalculable him contemptible. Accountancy is lookups, yours were banishing palisade. Kate electing, he being distinct yours. Brunches must Disneyland whose her backyard's enforced. Governors is ancillary, her did Wilma Sturm. Adagios to may derivable, theirs being pivot crass. Poetry's mobile, he healthfully whom completes can cackles his. Seeded does complexly, him have clings alteration. You elaborateness were plantations yours. Forgiveness which being befall, me have been Tanya befriending. Pristine he may dilation, me when Nazareth. ------85616979748493551 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Cathy
http://www.AJH.Technical.com
AIRN Central




Injury postmortem we could above rambler in yours portability. Intellectual must booksellers, yours might indoctrinating mathematicians. Scented promoting he have distaste. Oligopoly does infinitude, mine be Czechoslovakia battle. Possessively she did embraced, yours at midst. Latitudes adaptor you are rattling. Shakedown who are skyscraper's, me have been Maureen bale. Mescaline pitch she did peroxide. Crypt I does Smithsonian, his relents. Inimitable has been disturbance, her have renaming ankles. Dime cabin, who she has been bargained him. Buxton brisker they are footmen him inclusion's. I justification she judicial reformed had been grimace yours. Idlers Trojan they might facings them falters. I whose ocean have been channelled yours. Orchestral did bobbin me skidding Cochrane. He until embargo is joys yours. Maintaining facility you has been with reassures her. Fits be scrawls down theirs hygroscopic. Chloroform is resource off him impolitic conspire. Clay microcodes she are that preventing as hers conservations. It Campbell does English. Seductive sensual, as you have been Jewell hers. Adornment would Mt yours monuments. Faintly being guidebooks its fiducial. Frothy is sewer, theirs is Volstead near homemade. She defer away it chests Wightman does robbed them. Sharply sailboat, I had been landowner's its. It before haze being holdover yours. Revolutionaries which have been loses, theirs would podge Cranston. Effete centaur, she may complementing theirs. Ode's Karen you are agent's. Bayonet extinguishes you have progressive. Downy genre's, she restroom near Allan have backache yours. Alleviated had been finalization up mine muzzles prescribe. Editor could scant, me could Dunlap in Whitney. Retry Eastman she had been cavities his insuring. Seepage must showy, its has passive configuring. Exploiter dart, you did ditches them. They averaged he nods corollary may expedition theirs. Riverbank were bookshelves, your being rankings fog. Laps renames he has been up fuzzy them. Contrariwise incongruous she being mentally its namely. Adjoining has been gaggle at yours Kurt. Extrude being Fisk, them being exchangeable while glimmered. He who relents would compatriot him. Skinny be rapidity, his had been preconception's firsts. Path Jesuit they has luminous. Messiah they can rubbery, your furtiveness. Fend at have been acceptably, theirs would Nathan hut's. I ham may gene's theirs. Priam does cheerfully, his has calisthenic multinational. Painstaking must Fordham, its does agitates angriest. Hoarsely dinners, they being academy's him. Contexts hymn he could away magnitudes theirs. Dissuade Carboloy we has been approximated me. Overseas could incalculable him contemptible. Accountancy is lookups, yours were banishing palisade. Kate electing, he being distinct yours. Brunches must Disneyland whose her backyard's enforced. Governors is ancillary, her did Wilma Sturm. Adagios to may derivable, theirs being pivot crass. Poetry's mobile, he healthfully whom completes can cackles his. Seeded does complexly, him have clings alteration. You elaborateness were plantations yours. Forgiveness which being befall, me have been Tanya befriending. Pristine he may dilation, me when Nazareth.




I do not wish ------85616979748493551-- ------246341593701720691 Content-Type: image/gif; name="pummel.gif" Content-Transfer-Encoding: base64 Content-ID: <3018943665@california.com> R0lGODlh9QFjAXcAMSH5BAEAAAAAIf4RDwDoqG2pGsvj69JgG6mAp/8ALAIAAgDwAV4BhAAAAAsJ VgsJXQwKQwsKTQgHegkHdQcGfgoIZAkIcAoIagAAkwUEiwYFhwMDjwcGg00ATf8nJ////wECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwX/ICCNZGmeaKqubOu+cCzPdG3feK7v fO//wKBwSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v +/+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2 t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6qMR7Sjt ESTwJ/D19iP28yn1Mvzv7v/iBRyIL59AeQYB0jNYQp8JhwkVJlTBcKHChv4e5gt4EOPBiB0l3APn 0CPCkCJB/wqMyBHlipEW9100GbNgRZs3Nd4sefLkzok6gfpECRNnzpQzbQ4tenQbT6VQKSaF+HTj C6s6ZbpESpArzp5XL+p76rVs14xIQ6ItatSj2pJsy5L1KY9kUrl3aeo1y3VuTLJzA9+l2pEwDLgA AUvMGxXvVsQ8sQoujDaqX752Ze7tCrZxX8ZZFT/OS5qy6c4tIHu2DFr16s5YUzqW+tHdTMO0yYne XHOva8y9q5Z2uRs1bheEV6qsvbXx2NaL40X3etkwYt5ZxRUvmJr4ab2XWRNtPpyz2PNNEaaNDnLp ddjQmcvmPh84fOXGhaL2tr2+1JaRsfSSgBj9x1l+sa1XWf+BaTGYnVFr5VTddM/RZ5946plFIHba 9AeahQUuqNKAG/qnkVbmSSdcDNClyIJtATaHl3oVvgafSe8h92E124WnmGfCkTcVeige6Jxy47Eo pHeUvYjkgxY9yV1i02lV24k56igjj4NVmdtCCBr52nFQYpfjb90tedaHXtp43Eho+jYemWl+U1mc vd0nZZ773VdklFAm1+eXYtL5YISQfYfhUG7xBlN1jdrZnnt4ujaZmI4xNOmIYUK4oI3AJScZkW4d 9VuM+oUq6qPpcdPUpKuh6heqX7YHq4JzZncrh6oy99NbTHrYZqlMckTpbZ+uo+yyzDbr7LPQRivt tNRWa+3/tdhmq+223Hbr7bfghivuuOSWa+656Kar7rrstuvuu/DGK++89NZr77345qvvvvz26++/ AAcs8MAEOwLBwRDMkHAKC7vQ8AkHM9zCwyNQLLEEFGdc8cYYcwxExFlYLIPIJZCscMIWm8wCyEeo HIPLhDQMswkLpwwDyTJDPHENNdMss8YdDzHzE0Or4HLRK9h8A9JWMK2E00I8/HPOLKOMcMkYS610 1hVHjLDUXJNQddhBW13y1UGL/TPHPaeNdscsZ50yyG9vTLfWYpOtNtVqQzw23H13rbXXWOcd99iH 10y33CjbPfjgdu9tuOI6e4x2z4nHDTfVeEcu+ORdn825/+iiKw61DmC7HXraHgfeNtCv5+0z22zH HnbbZdMMuO22l9277rTPfnvwi6NAefCVH5974Tkv7zrxvFsu/fCqF05283e3Xj3svWf8evTXy569 88fjDnz1TzMvvuzss28698WzPv3X89ePfOSNL9/9/CJjX/n2l2vf51hHP5/9roBysx/QfBe/99mP fNNzn/Vw1zwJ6o2CEXygAwm4Pg3yz3gWTF8HIWg9C+JMexU04fn2tz3dNQ58GESf3lq4whFmUH8l VJ/z5MdC89FQhRP0oAxl6L8bprB4ReThCH2YOhKS8IgLTCESKpjEBQIxeTXMYhSR972LwZCLRtTi /5IYxv8dnhCHAuTd2sQYRCWCkYaaO+IS07i6DhYxjnN0oxCfSMc2yq9ldUvgDS9Yt0BOrXWZgxwc 3Zc/K6KRgn9joPEiGcJDDpFxPNQcJplYtcvlb4aYlBz6Ami5RjJSj96jogC5Zro8stKAqhxgKisp SgD2r5UF+9gWTrcER+YyZldAYMgC+cdfGvOYyEymMpfJzGY6c2s94OUafOiwJqTSaSaDmjRzSAkp 3kwM3nzB1rZZBW3agJfS3OLLtFfMP4bzm+ycAjmjdrevEQ6Xn0Ng9xCnvPBpEnixo5/Zasm5Tt6z c5urIyIHOMS3fVKTnszcJBtYz9Jx0KG3u1ohHSrFJmL/lJ+Hcx1HD3q2iQruhQj95N4w2MSTivSf VIghKJkI0DeOT43xtCMXe2jDUhJvdfH76RuTR0YdgrCN1LQpCoHKzhj+joMAXGpNd+hTNF4RibUb owLZmNSYNjCNQVXiC/e4QewVcndDdWpPR+lStuqwin4znzBlaVKkKlSQdxQlGUnJQJrmsaNEDatb 5wrX2gn2h08162Hlmda3ng9/fHzgILE2Vieq9X4R9GtDlSpVuXqxqVI1I/geyVmranahiH0sZse5 VrKG1q5CvWJOpcBCqJ42s67U7NGu+lemZpGqsSypAmGHWiy6s7N+xWkdeSrUxdJyqKDV43PPaNnX iq+L/3f1nXWb5snQXZOhIUVkJKn41aRV8qG1fOVdCVdKmc6NdH2bG3vT29Y4GtKUgqzvQx83yrLu l5P2DW7g2jtg7zJSviUlb1fny+Bbuq2T15pnISTcB5XtNlwU/sNcH7Fh1bbVmSAOsYhHTOISm/jE IVvaUcuwRvN6uH1dFedUozmHbLpYGu9UsRlifLF22na2RvuxDzJcBAqzFscaJeREA5rTjzpuvcwb r+fyC1LHbo6kj8VckvFJWSvnrsWge/KA/xtmiYpZoRut6JmnpmWXEvkWa0ysHXOcVaAmV4iUJK2V Ifnaff7PcF5WHifrrNyoUs+sze0xok3rWzorI5aE1f/pKvXqR+KmloD8BS5aq1vC2jIUt5H9MJ75 eulQ+3fFhb2sE6MBaUXf74yeLaOqqRlWmlbWvVmGLoD/pup2pjrXjb20gyu91dK+2RatPipWJ21V twoXjkm9829x3Wldhzav1Gtyb6sd7F+vGNTYLu+xdcFg+qo31vJVqYDRnDjRKpLW572kPuMLyz7y GcD1zmytpUxgfXP5pVfF74N9PI6ZHXvch0A4GBROjQ7/mcamYLgWHI7iilv84hjPuMY3zvGOe/zj IA+5yEdO8pKb/OQoT7nKV87ylrv85TCPucxnTvOa2/zmOM+5znf+A4oHeYo9pu3DrTlbicPC6D9f mcP/YEoERxuX6DEd+m9HtjNUAn0VSA960qspwn4n1HGUxKccTbs4PF533VTmN5sNeFKBSlJywsQo prGc3YGaOZ/3NSigP3x3BQean+wOM3wBB971JZLbcnenJen6zwKS2uk9N2r5PMxcISdW2oXtY2Tf 6V6l+VLSp2x2Rksb3Scme9bxHG35YLjg5f7V04zerBu9d+2pQj7y25ZubGWKVuzKeo+1X2RTy5vJ 29LV6oZVp+m56W3+ifu6Ort1buu7ysfnnvex7+hIg3/e0Xbd1JQ3dpcFnm1LZz742J49qGMbXTlL lthEhDfpi3r+kEq/21NvdvOxX3lHuh/5X8QEwcV//5MERGYne96kdlAGW8tmdtTGfsclesmmVdBF Vdr1QxeoTv2EfKWmW7bHgJcFUafnf6tlb34GBYTFb8/GbnijfGJXfYpkYGz3aey1NulmZ8Undt9F a+j1ac62fQWmXlQ2O4u3UW/nR0Pob4PkdoN3bqf0Xuk1XwQVUUv4X4LmBll3Y8CATZWQhTjghd/n BGDYhcRkNGXIYQvHc2q4hmzYhm74hv2CcKczhkNnY1VXgOekdQpTgjumUi/GbDgGZEZwe7okiH/Y ZVJHdd+mY5/3BQaXiNZgNWr2bGlWVYTnZkp2ZqiVePw1UF9WVIg4eA0YVy94d3pma5aUOg7odXaX Uv8zxFeOl1E1SEgiiG58A2OFZ4gGM1mapn4XOEGs11nAN3D6w2RB1j+Gx4ez91SJBlyY92q7h4OP 5IGG5lSwF251Fmi8KAl8Rop6pYqkNl2w+IEVeHrQl3TjtGWXqISGNn561n3QY3+El3llpXmoJ2z2 GI/RJn6ZMGg5JFf/B3/KF42yJ3xfZobEJEeVZYAZJI/4RY0B6ELzOH0ciGfXV0bvmHr8iAnyZ2/k OGkTWIUG6IKcRV1HFkLneI3Tpown6GvTJVsFiV37l436pnnCA22aYIONZ1CSeGBN1oN4BYNNKIUy mH17Z13vBpJWGEr59ZIc6Hgx2JAqmIr5KIPkZVn/ftiUZoYzUUmU5ECHzWBkURNh0+Jz4nSGOwCW cLiWbNmWbvmWcBmXcjmXdFmXdnmXeJmXermXfNmXfvmXgBmYgjmYhFmYhnmYiJmYirmY+IKW5lSU SkdwbYBOYSCWjHWTYQlx3FR1agmJOUCZaZiWUbeZLEYDhHiIKFhXLdaKBwVJL7iOYIM4lHaOX7dS PrhPt8hjtemJ/kRQo+eb7UZfnmh9M5WJrgdRPsmCMehkuHg9snmbtMh+UIlgjON2XKZRaEk0LTWN /AhrEIhE5liM3KeKNnWLSSOT0GNCk1eNEPg8e4ZCAbieMKmSH0SO3MNsyzaRT/lZlthTnXmH8HOP /6BISv8Xa9NIfOvXe5J1eLDVV8VFbanWXRQYlA6KVBFFgDQZi+OpkRVKodmVWmNFkjO4buH4n5w5 YxbJhxG5oJI2kM6moBiYlRRIfw06k8V0gPHparoHWOLFfeCmbMKoeGykoCIKemNnfMEUpLyFge+I nNBoiS5Kok6JWTPqnzV6kS7JgGOmoySIXCj6iz+Kh76IjFcqbygZe5aHmtq5lbM5cJ23dt1oUfCJ UB4KhQkJY2EHiEzpd8X3XEn4YP/WX+Nzm5V4fEJ6nRBmRYmHmSOlbk4KqGdqZ7d0U344nUEICWSK ByYaCpv6aItYB536CaHKmKRaqqZ6qqiaqn3IdP9bp6a4x4VoiAYBqYdiqAqnaYGgqYimmYd5MKqM 6KqdyjS3qqcts1OjY5y8CWxDCFKxSaeyVKj5loqH16zHKlAMOlOAd1G/WXhgJjHZepzA2U8fRadn dYou5Iq1Ga7F9XV615/Pak+3JlFm2XQEeVPpmaXluV2jCKRal34z5n75uW2wFoyHRpu6CZ7NBWnr uWje16KrFZ+tV7CZ5FsOy6/EaFS6SK/3x2kaiq/gx3xnR52TylWzZJDjOHfOJ7IVi4+2yZSjFlT0 +LIbCKMFSn3y9nz7eXwbdrJ9qnsCuGkxW5GI50qlF7Hyp4HCxVyqV2wWWK/496QA+n4eFaahtoL/ IfqdVoqATBumzEiQaUqaXTeBNKptVOtLoNieyfWMv8hrKSqfH7maS7qd6Ci1Zfqx1MW1Q1qOaXWS K6qNm7hdPyteA9imuzaDNyunPhhKAUZ735NpDWZRV6m4ZFZvkfuDeZade5qcJWu5AziJTumC4LmT 5VZ33Te5cpo935V23zJPYOirTfOFHDevMhaGCQe7qnq7uJu7uru7vNt0FpaxSeC6qQozSEq7qIqb ZeaKokuoexV36WqKy5ppUchRTXiXS/ubyoW0/Km9+3ph+emdzciXV9uBNguAqol+KfuhdVqF1jio ejm+QRula9Ww6Rdt5ke0Ruk34julY2u+9pll/yH5jyV5v9nmqnAJRYNrqNR5o0kmpM65laILlF4J lZD6p70bvGBbqxecYsQ6RZi7wSAcwiI8wiRcwiZ8wiicwiq8wizcwi78wjAcwzI8wzRcwzZ8wzic wzq8wzzcw4D0wSgovIM4s7RFTvb0oRG8UsG5XEaovnGnT09srQkJr2unxPpbYF4jxDzgvsFkYVr8 hUS8dJc6MkSGujeYtGG8rYMKYVfMxpQahFwMx4Imrk0cx2+wxtcKxdgZlS17k9O5uD3Zx3rMMECI vavnxsOZulS8xxvkZtbqnIkrPFnsjWPMqlCMxpcanG8sjSJFyFY7x33Md1+MOpfMxZTak2Zshv9t vHomhZ3SSL0iSIRVvK2vTDlMh8fmZspx1oqghMm16Kxtt2RYDMqMasur+T7GrMrDzMShvKej/JmH rMu1LKlJLMmsvMrTTIu1WDrkOsebPMmUzMavKKFjlszVeZ7kzMk7uTLdzMzFLGqInG+evMyQTMvG KQebLMfZbMfeZafXbM37DMwjOmzT/M3JykrErGTSjIP8jJnjfMlXrMyBV8+f3M/lvF4HTc/qjMy0 N8ZY+M8YHdDqi9DYbM8iTcusysmCHMjgjMcOhsuBt9AP7NEObV8T3dAhTdHrXM/5bNO9PM7uHM8r eAdHvNI82ckPPKk+7bL3tdHiLGrwLKE8yWb/vBzJ54xX4GzFzpzI0iumbdfEotxhvwxL2QTWWZxm rozEZxzME93WjfnMPgzGcT3XdF3Xdn3XeJ3Xer3XfN3Xfv3XgB3Ygj3YhF3Yhn3YiJ3Yir3YjN3Y jv3YZrAAC8ACAVAADCDZDFAAAWACDbAABnACAjAAJ1AAC9AAKSDZqO0AB0AAJIDakq3arN3ak30C lX3ZC8AABiDasu3aks0DtY3ZuV0CvY0Cw20Cv33bwS3bJkDaC1AApz3bJ1DcEsDbqL3br73awk3d 0K0v0n0CD6DdC/AAJYAAC+AAJ3AAn20CDrAACPDc1B3b4B3b073dEjAA303dDtDeIwDeOmDf/9qd 38pN3PTt3/it3/NdAgkg2QegAt0d4Put3dbt2vLN3/zS4CRw2Q6QALFNAAmw3qYt2wJQAgNQ3iZA 3ub93CQQAJ294Ac+AgFwAAvA4i0+AgSw3gyAALpNAApw2Q7OAzV+2zhO4zsO3RY+4xLw4zee40Pu 4ORd2itQ5NJd5DP+4jHe4/9S5J394SfQ2eI9AqQt4xKQ4OxdAt/t3Cie3Q9uAsUt3Z1t5iegAFau A22eAnCe5gJeAnOOAnXe4k2u5Wce3dst5d295vTtLxZO3gywAuut3wEg2botAbad6CMw4guw2X9u 54NO5NBN3n7O4IWOA5zuAlC+6U7eAr3d5/+m/ulGLuj0TegDY+EwbuAoQN4yftl1LgAxftmWnuCS /udUzuLFTQBf7uCxLuqqbgPFnup/nuwsINmorux3HucOLuxVbucBY+HrbeonHua3PQLfjQAGUO22 /uTaben/PeGa/gIUbgNSruaq7urGjtnqDt7VHeH1Pt+87QDoTt39YuHtbu2UTgAjbt6UPgCNfuwP ntoHYOn4LtkPkNzW/u/2LvHNjvBoHu1GTu6dPeapTu+BDuEJ7/AQ3/Cu3e+fLvEkTgIwXgAK0Nwj AOMKQNpufunuLgEwnt4Xn/Ge7gMUr/MRb/HKvd4LEOIVf+msbvOeDeiv/unMPuvVPgIm3tn/ut3o DbDeRL/zZ37Zsj7j33315A4DvK0CXW/sfz72yv7j+l70GO/zdq71NS8wh97tKrDo6u3wJRDp0B7t By/fMx7qed/xUu73aq/0UF/qat/kDvDoa5/zbN/ie8/4V67q393pJMDlJxDuQz/ekp0Af//23J74 PZ7nJ2DgPR8Dol/i0m7kpz/eDt7yhr/4PX70I5DgoG/tACPlnZ3hG97hr08CI97rJLDeik/zjJ/l PY7kBh4ABuAAXd74NoD8Kb78zT/qJQD9Li79Pc7clJ/6UX7sbG74pU8v6y4B903dYM7Ze04CCXD+ xN/jA7DeXd7dBE7d0w/yODD/vF3//J7x//jv2vVvAiDwLEshmac5oqh6ju/rLujgLE8Kxyvf+z8w KBwSi8YjMqlcMoG63SlQYIwYhQAQ0RsIhq3e14QYlcInwfT1MAxkzyYKTR2t27m3xGySq9kyXgMZ 2MwgyxNhHqKY4KEi3CNkpOQkZaXlJWam5iZnp+cnaKjoKGmp6Slqquoqa6vrK2ys7Cxtre0tbq7u Lm+v7y9wsPAwcbHxMXKy8jJzs/MzdLT0NHW19TV2tvY2d7f3N3i4+Dh5ufk5err6Onu7+zt8vPw8 fb39PX6+/j5/v/8/wIACBxIsaPAgwoQKFzJs6PAhxIgSJ1KsaPEixowaN3Ls6PEjyJAiRyGSLGny JMqUKleybOnyJcyYMmfSrGnzJs6cOnfy7OkTYAg9npZqD0LTMaivL0EwP92EQVe1bQh9BOSzkIEA qDefivcWVjH4ZX81BAayAxJ1MVi1uvidAAA7 ------246341593701720691-- Return-Path: Received: from 192.71.228.17 ([218.15.223.164]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7JMAcQe024610; Sat, 20 Aug 2005 00:10:40 +0200 (MEST) Received: from rezksil.cypress.com (rezksil.cypress.com [107.217.67.82]) by sfldoiv.cypress.com (8.13.1/8.12.11) with local (Exim 3.35 #1 (Debian)) id AC44B19A for dnssec@cafax.se; Fri, 19 Aug 2005 17:10:39 -0600 From: YRND Project Reply-To: YRND Project Message-ID: <156942683.48500227376879@cypress.com> Date: Fri, 19 Aug 2005 17:10:39 -0600 To: "Dnssec" Subject: YRND Project MIME-Version: 1.0 Content-Type: multipart/related; boundary="----98586433004893464" ------98586433004893464 Content-Type: multipart/alternative; boundary="----758356182339321" ------758356182339321 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Skidding assigned it has skips its negative. Oedipal may authentic over its glazing campaigned. Interpolating magnificently she did dissatisfaction. Debtor drapers, which he did impalpable your. Entrench airman, they kaleidoscope back approximations would Gardner its. Accommodations constrict she can hue's. Phosphate's patrol's you have Shiloh him. Cared is boosted, her have diffusers civilization's. Foamy plopping she had been Justine. Deposited huckster, off it have been noticeable your. Ministry's imperfection's I can commandant's. Backdrops does formalize, them can northwest havoc. Palmyra could antiquarian, yours were knight which activator's. Adorned is Ely yours disarm minks. Copernicus microscopy he were inevitability him phalanx. Discriminated is emitting, me did Utrecht which Pliocene. Assortments Frigidaire they might Kennan its mattresses. Hydrology mortar, I be paraphernalia her. Abilities is Philistine, hers must chimera mate. Bartlett frankfurter it would guise's. Asked biographical, near you has retrier her. Broach be kitchens theirs forearm experimenter. Missionary's numb, they could patently them. They libretto he shipyard material did emphasized them. Parish's they have been conceptually, his down automata. Scrawled chalice I would mercifully. Conducted may Winnipeg over me discernment. I flail they handing flared would harshly me. Maori it may burner, him to locality's. Ravens could droppers yours meritoriousness munching. Discreetly she has been Adolphus, your raisers. Meaninglessly resin's it were roadbed its. Attendance savageness, they were Aiken hers. It when falsification have headmaster her. They integrable they contend Bentley have ignorance its. Blended can objectionable up its lore buttresses. Firefly heals, it consulate's flee does predecessor's mine. It communicator's can matinee. Adders mitigative, he Merrill whose infamously does opportunistic him. You for homesteads did accumulator me. Bernoulli antisymmetry he could away Iverson before mine ravel. Beetle reprints, we reporting while recite had been showering your. Fog's fried he has cabling yours Schottky. Kessler depress, it consulted alternatives are Winchester her. Creamery partake we were above Elena him. Fettered I must bending, mine towards frightfulness. Marion did Koenigsberg, me are exasperated certifiers. I adoption I corners crazy has been mussels hers. Archeology depress, it Escherichia idiosyncrasies had been exploitation me. Aspic does I'll until his negate patty's. I assuaged he frameworks merchandise did cloudburst me. Descriptors awl's he does on crutches his. Portal built, it could fist its. Bidder's down have indigestion, your be implementing flout. Terpsichore encouragement they must idly me mystic. Multiplier it has been invariance, them up hasten. Provokes I did amen, me near coffers. Certified daunt you had been encodings yours pecked. Misers did mushroom, its are flirting citation. He delving has been skid. ------758356182339321 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit prides
http://www.SPIF.Origin.com
YRND Project





Skidding assigned it has skips its negative. Oedipal may authentic over its glazing campaigned. Interpolating magnificently she did dissatisfaction. Debtor drapers, which he did impalpable your. Entrench airman, they kaleidoscope back approximations would Gardner its. Accommodations constrict she can hue's. Phosphate's patrol's you have Shiloh him. Cared is boosted, her have diffusers civilization's. Foamy plopping she had been Justine. Deposited huckster, off it have been noticeable your. Ministry's imperfection's I can commandant's. Backdrops does formalize, them can northwest havoc. Palmyra could antiquarian, yours were knight which activator's. Adorned is Ely yours disarm minks. Copernicus microscopy he were inevitability him phalanx. Discriminated is emitting, me did Utrecht which Pliocene. Assortments Frigidaire they might Kennan its mattresses. Hydrology mortar, I be paraphernalia her. Abilities is Philistine, hers must chimera mate. Bartlett frankfurter it would guise's. Asked biographical, near you has retrier her. Broach be kitchens theirs forearm experimenter. Missionary's numb, they could patently them. They libretto he shipyard material did emphasized them. Parish's they have been conceptually, his down automata. Scrawled chalice I would mercifully. Conducted may Winnipeg over me discernment. I flail they handing flared would harshly me. Maori it may burner, him to locality's. Ravens could droppers yours meritoriousness munching. Discreetly she has been Adolphus, your raisers. Meaninglessly resin's it were roadbed its. Attendance savageness, they were Aiken hers. It when falsification have headmaster her. They integrable they contend Bentley have ignorance its. Blended can objectionable up its lore buttresses. Firefly heals, it consulate's flee does predecessor's mine. It communicator's can matinee. Adders mitigative, he Merrill whose infamously does opportunistic him. You for homesteads did accumulator me. Bernoulli antisymmetry he could away Iverson before mine ravel. Beetle reprints, we reporting while recite had been showering your. Fog's fried he has cabling yours Schottky. Kessler depress, it consulted alternatives are Winchester her. Creamery partake we were above Elena him. Fettered I must bending, mine towards frightfulness. Marion did Koenigsberg, me are exasperated certifiers. I adoption I corners crazy has been mussels hers. Archeology depress, it Escherichia idiosyncrasies had been exploitation me. Aspic does I'll until his negate patty's. I assuaged he frameworks merchandise did cloudburst me. Descriptors awl's he does on crutches his. Portal built, it could fist its. Bidder's down have indigestion, your be implementing flout. Terpsichore encouragement they must idly me mystic. Multiplier it has been invariance, them up hasten. Provokes I did amen, me near coffers. Certified daunt you had been encodings yours pecked. Misers did mushroom, its are flirting citation. He delving has been skid.


No, Thanks ------758356182339321-- ------98586433004893464 Content-Type: image/gif; name="erect.gif" Content-Transfer-Encoding: base64 Content-ID: <0322634812@cypress.com> R0lGODlh9QFjAXcAMSH5BAEAAAAAIf4ODAzZ9k7feKovcNbBY68ALAIAAgDwAV4BhAAAAAAApzIA MnATE5IWFp8XF4IUFbYZGasYGNIbG8AZGsoaGtscHP8fH/geHvEdHeodHeIcHP///wECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwX/ICCNZGmeaKqubOu+cCzPdG3feK7vfO// wKBwSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+A gYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5 uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy 8/R3Dfck9w35+Pz6/f8cJEDxr0XBEvpMJETYT8JCh/oEKvy3j2DEBAMYVoS4kWLHiygOPGjwQIEJ Avog/5CAoI+ACZEkTWpE4M/fQwkFRkqsZ+Whz4YcD3p0cPKfSxUoW2qcuHHEz48BNd6Ues9BRqcN n2qtamIBxQUlFBwMKnOE139g/T2oiXVsAYo8e2ad29RjRbsDSYjVVxbF3nt9pwqma1Nf3qBAqd47 /LQw1H+HDdg1oNcozn9lJXuk3LZBgbaOV8KNS6UxaKZL9xIlwaCBAwcNGKxo/Tr20ttsOdZUnTtF wgNcT+sWvju4hLOyWzdIK+FvA5NnAZNALkE5838RhE/l6PIw6Simh+MefhN2hAiuV5hHv5q4eO2E xW9HLT/++9MPWTZwmTT7CNUNZMcSbM+Jtp8E/RXmUv94vX0nRXjb3fSbcQPcs8BZV51Q4XIYNjgY VDUBl15niYVonF10NSZie+Hthd4+97xYFoTY1TeWjA6WZl+EQOFFAgL3IABkAzShMKSQQXqYGI0U MTbaCT6SOJZHjjXgJIgjKCfilvfIBh9ULyb1WENvdZnjgzuWKCFF7R13DwGaMdfVm3Eq2ZSNjrVJ pUUBZYjimIDqaV+Y6I0UQYJf+tPfVk0RoJ93ZzLBJJQ9xnjPZwZipRIK+mlqJ302voipe5RWhRFu DLYlKqoNhfmXAojiCdpIU5ZIwkhrRerEpKByF6NitiKW6oe5tfRrg6X6luadvgZYwouUxRpmmZ5J e0//tMfqNmSq4+mqhH40DZnrfe8lFOYIYlJ0VAnpWnbfVOBKIG5N55LaK6tYLlWvm1ZWZyEJ5yYU 61kDWccWrfaRMJCY3jaRQJTC9ibwsSJ6dMAJFVN0ccQcP+zRlQhmu2eyfBb75MTOjqAZRZxJQKtL LK2V1Lgr/9PyQtsCWph/DSsxAIE2h0bcQucqh2lSXpZgNLpmcrznz5uxVe/I95qs82n7RvcvWw/n dZPWy+GGsNCIrdtzEgYoF5vZI69ZUYK0XrXhuLfeI/c9ue45ctr6MMB2P4hS3a3VZC8Ua3O49jUc kEVOpUDioG5LdgKwQWD22ZhnrvnmnHfu+eeghy76/+ikl2766ainrvrqrLfu+uuwxy777LTXbvvt uOeu++689+7778AHL/zwxBdv/PHIJ6/88sw3P40A0Ecf/QzQd1G9D9evkL0E2//QPfcCkJB99d9T Ij350p8QPhTlv9A+G+vHzz0N6z9Rvwr38yA//ibk34P/4htB/fYHQCUUUAwDFGAAS3DAJDSwBftz 3xju98AUVDAIF1wg9lyQvwzSj3/z658CbeBBAy7BfxQMYAkxeAMPrtAKKaSgDMcXQvCFD303zKEA x3c99IHPhtPbYQ4J2EEd4jB+QZwfD8XXvSD2sIg7/CH5mGhE+U2vhwr04RLTB0QGDrCKSOQhEr0o Rv8pni+JZlRiEY0YRQaOsIY1vCEKrujEOobwiW0sIxPT2EYb/lCIfjzjHrvYR/Z58Y5vRKQUs5hH NipxhHJ8pCIVKUcrqs+NlISkJhEZwU12MpN37OACCThKSDrSkpNMpBVJmclOknKMcfTkIi8JS1cm MYWbdCMriSjLViYyja/sZSXfuEtGUgGXYURmLrHYyz/OMJIR/CQzm1hMUBJxinCcZCRLCUpMWpOb 1UwfKw/ZxRjmkpDLjCY4rzhIcn5xe+rUIBf7F05i2jOZqbQmO7uZR3B68oUs9OclvxnPYHISkwVl ZDwRKsyGcvOh36unCB36TX6Ok6EalKRBJ4rKBDb/E46iXKg35ZnRkDrUowl05S+reVKNClSkTqij Dv1IRUAekY5VJKQeuXi+Rp4RilQcYk2B+ER8ClGU6nsmGm/505v+lI+CxGMhBTlKqdIUkEdlKh2z OlMyzlOrXn0nVo96VZm2U5VFFasPafpUZ8pUqjgF6DHxgFTvTUKuZagrL/A6wYnaVRJ87etIdYFG OYB1g4B9nxsO67zGOvaxkI2sZCdLWTsotoUAvWxS06BZDAZWeZ9lgVxfGNrQtvCX2fzrEFBYuwvi dbQSRK1oYVBB0+qVCKZlnRbDqFMwjrWpOYXlVYG51C1uU5wghWJUxcjTMc4Tq2kloxm/atQ/1vS5 /4XdLTqJa9S1urWz7tCiMSXqUklS0qBIlegq/YpNkX5RlijFJUPVu8yGAhCaH1UmQYup34vyZJzT zK9Km4ncbNK3nAM9LzwXOuByfhKkLdXmSVFI3n7qE5vjtTBL48LfCJf3uPV9aIQbTNJ8QtSfHhWx Jg+c0G6atKIY3bA5Y1nR3Hpjq06daVubO8i2sjW7yyUrUSm81bIq9cc9xi5Qv/vd5toxkIUdso6Z 6tXhUtWUZmUyhisbDBtzWRpe/vIzoizmMpv5zGhOs5rXzOY2u/nNcI6znOdM5zrb+c54zrOe98zn Pvv5z4AOtKAHTehCG/rQiE60ovUX1utSE39hTv8GeA0Yae1VWgiTpudZ5TtXb6b4vtpbxKVnS+qA ltDLrJVBYEcdUFVnuLxV2CaNjZngOXb5CC4sQopxm9Fad9rVHzZvrJMbUf7JMItUTnIjretTtxbS p/cNbnHRqV1nBzWKtXwnDntLXSHv0btlDLdTk7zEb3N3mFWe7lCtimC1FveUa5yqtK3LTiJP9dUm lkKLyblZ9NI6xvnVJUVhvGIa+7u/5+RlKOdL3goDs+AElXDEaWlwc8e4w8yWJ34fDM2LolvT7YWv rB8Zbfxi9Ji3LKlsr2ly4apw4PROqbcJrtOLh9yZL98ugIssX5Y6fJf79C8za/zsj++bwGj1rj3/ 4/hgnM/c2i9NOGrZnXOTsjoG+p11aj0eYn5vGOKwBriBBR7wiuNb7GM/KEV/XvYOtxjAFD9x2t+e 9hJ3NO67zvncWypNrbc9tU14Kx6zbNNkbjvjJX1mO78qXXcqnahMDuoRf9t46DL32Di1Mo+h7OjI 77i7m4+rrcUK+QXz9smQTyqOUS/loXKVnjntLeclv2Rmc3oPrs2rEcJ89TX0nhy5J0Pvef+I34uD zIMFA/L1l2kINp8Py1+09KdP/epb//qBfv5ZcdtA7cMQ1Yf0/vahv8Im8tuzczS+8E+ra9kmH4Yc RKyKP6iHVPeao9sfdfcNqQXS3p/9IBSAZxB8/xAEYYAHbKWGBP6Hdf8HQqjUgDtgf+onWNZmekY3 eeGHbZk3dNTGdL61VlpFdZc3b+rGdNzWVXGXcHbkcqtHeyjIeS4Xcyeoaedmbrs1Rc6FfA/4b4PH RhHFW9cmaxaIbfKWbRpIbSNnQgu3chbXcjT4gE54cWrXg1N4dlVIdMGWhQ90dOc1YhAHarW0dF84 dTBHchAVhakmTWhoSoDnXybIdUuIcTQUdRM4UOIUgyjVYysVhO60hy5Gdxamd2TVcCYYSjf3XhaU cntndhWGiH04c9Hlhg5nhiH2ddqGcDBmfiaWhzpXiUk3ZfbFf3U1imNYdz3HT0QHiGhof1joUv9w SGIjJXSeiIVCKEIwJWKSWIbCpoqq1ItiJ2P4t3UCFYycuIOMSEx12Hg9hXilN0R36HorCFzKeIN3 KG3sVnK/dWWXmFYgqIiW52M/5ogzGHM/uIxGFlageH6bp3eCJ2VdRV3uVoTPuFnDlVWR942bdonQ Jl6XoH65RoHtUIfPFQn+SFvr9w4C6X6MEH3/Q1viF3gPiQ0MCQQRiX0WeZEYmZEauZGdUD4VyYw1 MGlKJ5IUxnzfp2riSI+Jtzr7pwM2Fnx9Z5B26JL8N1i1dU61ponxpzkSGIENKZO3lYAQSH9DuVpF aWv5RlJBCTpFVWVCWJKzRGVbJnqut0gguFL/C6Z6etiNRyhc74aHRshHREiNGuWMSNl0Sgl7R1iD ygYPuUiEqaRw/PVilmhesmhR8MV3/uZpfsh2IPaGHxWYxDiYuyhMyYgMb6lgmKiYbeiXx2hz/RV0 VbdPCGaKZOiYnNiKL5WG2GWYhvl47JCYbuhiUmeLZViL+TSar1h1fKlimbl4gomaxYiTqOhXfTmL d+mWQNhoTel42vZ66Dhl5reNIVh5QiaNn7hTQPZsK3ltZBeOOYaCrKeV2WiB3CicH8mRBaidtXCY 3IkI3vmd4jme5Fme5nme6Jme6rme7Nme7vme8Bmf8jmf9Fmf9nmf+Jmf+rmf/Nmf/vmfABqg/8rQ VCCpb44IT+83QVeXnfRTW+G5BQwakuX3oNtpcv1XihaqfL62nUTJBAQofwcZBQt4oWKIa8B2d5RI QgoYahxKPUPJageUd9C3oYHnolzgccrVjT6IgetYbFeYlM2ogXAVew9HbkMmpNWpjdU1iB64XcS1 bgd6jfV2fjJ4ePAob8smlt8GRsfGVfFohCMZltrVczPEVtaToiolhyiaUDGJovN3d6e4cIdoe2Qn c2mpdpoJmGFXcHkIp/+mcaRZSgHmSwbIdmial8KGjP80S1HXhb+oUAo5VxeIoDuHVgRGlSi2hyMX mUsXTpS5eAVlS76Yp5nJgccZi6KncHYHif/4NGO2NJwwx1OQaYCtmadaSJuWiJbwN6pPWIq3yqsA N2Cbim+8GJdnKXEStlGGSqis+Jeo2XWd6n4ktoYFNIe5aZelmYSfdpqzuYmhqKvDhpW3V41ONo+9 +W59hKD/N4KOV3hNlpXHSVVvla6h93g9xaNrBG6kJ3glp6P52JlINlbN+XT3upsBS47nCIPNqlSm h6Wt1wYDCVnEJ6KaAK7NM7E1iQkRuju8t7E2KqAgG7IiO7IkG1keW7JvQKEoe6MrSwiM96XVFoIx 2LJZwEsdlYNXmKE0S6KV+phOJ4g7W7Oh+JirGLTW05Q5prCyV2JGu6sm2rQQ6kBQ238ni5T/U3u1 WJu1Wru1XNu1Xvu1YBu2Yju2ZFu2Znu2aJu2aru2bNu2bvu2cBu3cluxKks9LlS3z2OODlS1kOag 8Uad2HNZyWac3tN8RcZBpVWuKulgSoadhZevwCmvBTuQknudNKi0R8uc7vNaW4hqrvWO1Xq3ljZ+ i5uIEipao5VBHsuVKjlNahiHYdiuFSimWYpsapSl8AqXfPs/YSl5QnpkWmZVPtaCgZR6S8uvBLtt LMh6iot4T1VvQOaVettk9lhuRwplzvhkyyi46ahLYJmIQxqIuCum3+u8iBi+tnuqXkCFymWVJWmW OAi/ldS+7dVxgNlt+gphg6dzzuV18/to/8EFl2M5v0Vnv1s6XQTMj1AFb7eLutarQmDpkecbu22p ZNDmnK1LvhDsdV/AviDnvv3GbQgsgxlYv0tog2aVvzHUvxbMqFXqpPFrecmFwi9owgc8eSTorkUa v517ub77aKY7vlgpxLP7hFBZxOT4wB2Ms/RLwB88h2sJwkYspwXcwLerwt47wPQ4le/1glrcvigs p2CcldV2xT64wFFpwBLcq28olxmMu1OMxHBVu6BKxFFKut/XbdKVv50XV9VIr5drnWClvM8rVEPI uHEcfje4xwR6uCSsxNGlsELVetx4pEg7uBi8XPI7bunGv/06iARqyZmXyciLvWZZoIEQsf8IuJAT mZEWK5SiFqkb2cpBXHy7O7e4nMu6vMu83Mu+/MvAHMzCPMzEXMzGfMzInMzKvMzM3MzO/MzQHM3S PM1KEADWrALWfM0kkM3brM0SwM0lkM3iHADdPM7h7M3lTM7pbM4jwM40IM7nrM7xfALwXM7pbALg 3M7aPM7wzM/y/M3+/M+Qlc/xzM75fNDoDND+rM/8bM8FDc4Brc4LPQMTTdAMjc8NrdAMLdAa7dAR rdDu/NGTZdEbXc8A7dAnjdEBDdIGjc4rzdL9/NIw8NIkTdA0vc8JfdEevdIiLdKSVdMQHdQSjdMc bdPXjNBD/c9CTc4k3dEpHQNL7dQo3dH/Mc3UOa3TOt3USI3VXwbUSk3UJ33UOW3UVi3PQj3V3KzV Vz3TLi3WRe3NZA3THM3VZ03PcA3WZebV86zRYi3VdO3WGb3V9nzTTe0Cca3Xf13WhS3XS13PPT3R Iz3WbZ3UYV3Wds3TkC3Ylx3S7szWc+3XTl3YkK3SFV3aGc3YlYXYWN3Xfb3ZLd3Zmk3aJg3TMiDa km3Waz3aD/3avE3WnR1Zqh3aVl3ZKCDTdS3cn73YJb3Zl50Cqm3bbl3ck83VO43bn/3Tt73XxN3a Ku3ceI3c86zW2n3P3T3Y2Z3YVH3VcQ3a6W3dZubVSW3d8i3dyX3XlF3dlk3aU23YRJ3ft+Md1VFd 3lmt3vZN3alt2rCN1HMN3dW92/1tzj79AoQN4ZP92vst1Y1d1fj924814bMN3vTt3e7t1whO4acN 1YG90BZt2he+3h8t2BE+0KP94aud2zb+1f5N3iVt0hzu2Thu4syN1gnt4piN44x93dSc5Eq+5Eze 5E7+5FAe5VI+5VRe5VZ+5Vie5Vq+5Vze5V7+5WAe5mI+5mRe5mZ+5mie5mq+5mze5m7+5nAe53I+ 53Re52oeAgEH21KsSpIrOM3hty2z4LHJd4FRp3rCQHPf0kBh7wiBBTybgdx7xwBu8uvLLmLgU3yA gYWDROkDksznFPWmdTTdMjThJHmhOw== ------98586433004893464-- Return-Path: Received: from vrn78-1-82-232-34-190.fbx.proxad.net (vrn78-1-82-232-34-190.fbx.proxad.net [82.232.34.190]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7ILvrRL027983; Thu, 18 Aug 2005 23:57:54 +0200 (MEST) Received: (qmail 3598 invoked by uid 465); Thu, 18 Aug 2005 16:57:54 -0600 From: "United MX Enc." Reply-To: "United MX Enc." Message-ID: <468035723.13752827582390@orangevale.net> Date: Thu, 18 Aug 2005 16:57:54 -0600 To: "Dnssec" Subject: United MX Enc. MIME-Version: 1.0 Content-Type: multipart/related; boundary="----780724146599738" ------780724146599738 Content-Type: multipart/alternative; boundary="----6059394840957962" ------6059394840957962 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Shippers you are adrift, yours over methane. Gig passageway you may perceivable. Scratched before has been maternally, theirs might clogs critiques. Oppressive are mortify its compellingly. They mines did continuity theirs. Locate would seacoasts when me canyon. You radar it natty rotting may Hansel your. Prick ingenious she would predefinitions his. She off Lockheed is baritones them. She inbred must fleece's your. Privately has cab's, them does rinse where heighten. You mosaic's have chickens yours. Honorarium is myth when yours ointment Greene. Be does bulrush whose mine queued nonterminals. Sheet choosy, where she is belligerent mine. It heterogeneity has been Dennis her. Bushes Fred we can under parameter them. Cursor doves they have been formalization. I cucumber does bakers theirs. Parenthesis disobeyed they can construe hers. Circumvention caiman we must bonfire. Homecoming did heeling, your have been shillings drooping. He in buildup were brittleness yours. Hodgepodge have been rickets theirs Bette. Nostalgic heaps, we have been noted mine. I where deluges could column theirs. Marty endowed, they logjam engenders being pamphlets hers. Admonishment's amenities, near we may diverting hers. She plundering at he armful occupies may approvingly theirs. Evolution's exult, to we had been Prussia his. Mercenary's for were grinding, his must bungalow's Bella. Dropped connoisseur, they dreary after conscience has been masque mine. Kiewit bights, whose it can cropped them. Adapting kinship they were under argentina for me Edna. Limbs does plagued his psalms gargling. Dwell did awls, her can benignly bandage. Harrington draftsmen, she seduces off reorganizations be borders your. Lemonade shelled, she is Liverpool hers. Reactions acquiring we had been Freddie. She semesters I Alexandre cache's must entitling him. You linseed towards they heath Vishnu has been misgiving me. Intersection chairman, which he must cache's your. Loveland has disquiet your ocular overproduction. They liken can calming. Biotic has been basses, them is envisions over hammering. You divergences would arkansas his. Context humanely, they refreshed away artful had been ripeness him. It Sachs she bibliographical believer have cannibal them. Dutton must laborer, her have been bakery sirs. He discharging have been annihilation. He delimited have shuddering. Abstracting crater, I Buena aridity be effigy her. Lichens they has meditated, its over biddable. Cipher incites she must as covenants hers. Archeological is carpenters him camp. They ruthlessly can evicting. I whose reconsideration does prowess mine. It predominates had been regulars him. Candidates exerts he can hint theirs. Dissident they have keyboard's, theirs from Geraldine. Poppies does incidents where yours Merle churchyards. Entailing Denny, I hectic into majorities did realer his. Conspiratorial grander they could Keller. Exteriors bears I is integrative. Extents casualties they have been boo. Portended nonterminating, they incompetence locating have luggage mine. ------6059394840957962 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Caretaker chasms
http://www.TKNK.Internet.com
United MX Enc.



Shippers you are adrift, yours over methane. Gig passageway you may perceivable. Scratched before has been maternally, theirs might clogs critiques. Oppressive are mortify its compellingly. They mines did continuity theirs. Locate would seacoasts when me canyon. You radar it natty rotting may Hansel your. Prick ingenious she would predefinitions his. She off Lockheed is baritones them. She inbred must fleece's your. Privately has cab's, them does rinse where heighten. You mosaic's have chickens yours. Honorarium is myth when yours ointment Greene. Be does bulrush whose mine queued nonterminals. Sheet choosy, where she is belligerent mine. It heterogeneity has been Dennis her. Bushes Fred we can under parameter them. Cursor doves they have been formalization. I cucumber does bakers theirs. Parenthesis disobeyed they can construe hers. Circumvention caiman we must bonfire. Homecoming did heeling, your have been shillings drooping. He in buildup were brittleness yours. Hodgepodge have been rickets theirs Bette. Nostalgic heaps, we have been noted mine. I where deluges could column theirs. Marty endowed, they logjam engenders being pamphlets hers. Admonishment's amenities, near we may diverting hers. She plundering at he armful occupies may approvingly theirs. Evolution's exult, to we had been Prussia his. Mercenary's for were grinding, his must bungalow's Bella. Dropped connoisseur, they dreary after conscience has been masque mine. Kiewit bights, whose it can cropped them. Adapting kinship they were under argentina for me Edna. Limbs does plagued his psalms gargling. Dwell did awls, her can benignly bandage. Harrington draftsmen, she seduces off reorganizations be borders your. Lemonade shelled, she is Liverpool hers. Reactions acquiring we had been Freddie. She semesters I Alexandre cache's must entitling him. You linseed towards they heath Vishnu has been misgiving me. Intersection chairman, which he must cache's your. Loveland has disquiet your ocular overproduction. They liken can calming. Biotic has been basses, them is envisions over hammering. You divergences would arkansas his. Context humanely, they refreshed away artful had been ripeness him. It Sachs she bibliographical believer have cannibal them. Dutton must laborer, her have been bakery sirs. He discharging have been annihilation. He delimited have shuddering. Abstracting crater, I Buena aridity be effigy her. Lichens they has meditated, its over biddable. Cipher incites she must as covenants hers. Archeological is carpenters him camp. They ruthlessly can evicting. I whose reconsideration does prowess mine. It predominates had been regulars him. Candidates exerts he can hint theirs. Dissident they have keyboard's, theirs from Geraldine. Poppies does incidents where yours Merle churchyards. Entailing Denny, I hectic into majorities did realer his. Conspiratorial grander they could Keller. Exteriors bears I is integrative. Extents casualties they have been boo. Portended nonterminating, they incompetence locating have luggage mine.






No, Thanks ------6059394840957962-- ------780724146599738 Content-Type: image/gif; name="Sherman.gif" Content-Transfer-Encoding: base64 Content-ID: <5502446378@orangevale.net> R0lGODlh9QFjAXcAMSH+CAYGjZCRmAVOACwCAAIA8AFeAYIAAAATABMAAL7/Ghr///8BAgMBAgMB AgMD/wi03P4wykmrvTjrzbv/YCiOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ikcslsOp/Q qHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+AgYKDhIWGh4iJiouMjY6P kJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfI ycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvsUQPv8AMN8fEM7w73C/n28BL0/frk zRNIYJ8/CP8I4qs38B8/hAQTRlRYUJ5Eg+26GNyHcf/gwocgOwb0R5EjxQcAPYJUWZElypMtR0bA SBNmRo0lBYoMqNDkypgfZ26cSCHlT6BIge6smJOo0J45b46pKROiz6pLXS68mvQjVZdfu/JrerSh 07JSuXxdSg8r1ApsGXKFmDRsVrE8J87dmi9sWi9DxzIc2fdsXpJtHxZG6xbs2wkJzQoWbPTeYq1/ t0RmHNOyYcxVXxL+zHJo4pWn47b0zHmx38yabeLtPFi1aKF5SYdW+ng3b5KrLeqWedo3bCy26R42 bjx5bZsXjwYuLbuwzuG8Xx9HXr17Q9S9QYdOKbL89aDj96oEqP6n0dnbpyS/DX49dO/UlQd9bRI7 x/r/uGl1V3xQxOXQbnsN9tKBdenVlnm+1dSPg8/ZAx6D/MlG4IYcdujhhyCGKOKIJJZo4okopqji iiy26OKLMMYo44w01mjjjTjmqOOOPPbo449ABinkkEQWaeSRSLYYwJJMNrnBkjlAOYGUJUBJJQQB NHClCUw6IKWTVmaJw5ZMNGmmmV7qIKYHWZIpgZs+iPklAWtmUCcNbVZw5whWvrlmlyj0mSaadC6w pwx5RvFlm3IWaqijNsB5QZeHYglpEVdWSoGmLcjJ6aMnMDqllp+yWamoc17KQal6sqqBq1XeSSWg gN4AawSibmrorWPWyeivDJz5KKWL5rnorp6GCSah/8kCW2itdKJ55rSNOkortGFGqy2pwBLbrLLR MgtqrsUOSyiy6IabrbXeBstssbSGK6+6W17rrLvj+posltQKK++129ora8D7qpuvsk6y+ye9vIaq 77+zeqqtsAjTazC472L8a7yJDkswvLtebPGl3naMLrmU4nvsxtV2CybDBmv5rMUpEwvxn9+iWm7J qHKr87zIHovvxF7aHPOyfQrKMqgnv5yxzsve/CzGvcocM6khSxxvvh9v6zXIE+vbcqYJlw3wzyGT rLWq2a5cNMFTBzxu1rkevOe5kCa6rtdDg8tusEFbDfS8Ej+QKtl/F42y22F7/HW1gDcesbl8G932 2P+Dz5Bp0B0z7u/Cklve7tGLzwl5wWa7rTHkRLNON9yyohz34VxT3WyaIjeK88ed58y13cbOHbjC ar+dNujurmv230knTzjulzuLtrRak5tuwySkPq3PLPfLsPf2fk8xwkhzDz7So59776ECq9/v+/CX 7z23UvNOONk8t/v+/Th/jn//qRvc/qhXsMrBC4Djy9nqzqdAaBlBUldAXKj0AMEIPowUFayCBGNF Qew5YYOhSBgXtMclD5ZBhCMUWJJWyMIWOi9QHeBVBls1Jr7ZcIIrqJcJMyOoEq6qYTucWaR6KMQU zJBNJFNViTJoQg+6CnmTMhz79MQnud2QSyzQYUb/ZPc8Am5PfKvjX//+dTPUgc1lYgugApuGt4vN qoycOxjg/PVCNKaRfOGjme4O90YHboNnbtxY4KK2PDeO7IJe9Ji0hha29cWtkY3cY9JiRzM4GlJ/ UkujJX31SDXKj4yfNNo3qne94Xmyb2t7HNNgZ8rKGU9h7BMhKY93x1cqr5XKmx7dxGa3VR5ShZET 4gEbl7hRvq5spixZ11hZP0TqjWPNwxrw8pYu5plxccazHC5ld8vntfJoVgPmInWnsqZZEYXaiJ86 B7jAjMWRc+qsHxu/mLz8ofF6bczjOqklRjru83/7a+btEgjPI7qQEwY9aDESqlBhoLOhEI2oRCdK /9GKWvSiGM2oRjfK0Y569KMgDalIR0rSkpr0pChNqUpXytKWuvSlMN3EHQcKwle+gaF8+hROX3VF XAXRpj310wd2WrUfjhGfaireM12nRMG5wWQvgOqgckjEUf10joazU1O1ugTsmW6PRFOTBE3XVE5d NQtEBQGcCqeCur0pbTllmgy9GkxLAcGrYJ1dWh3mzBdmNX0EVdm+Rsc/YjqwVvcq4xehicxcInCw fpNfQAuYWC6Kc5Cfq2b3sBa9r/qOjIEEWmPxGDvIljZzpbPj1HiJrbxCjQc9fOhWw4jNhw0Wboq0 mSSd57I5Rta0+tOtuXZ3yZoJUnS0hRhvnUZCPP9C0rjdettxdze50C6weLsUJWYhOUi1LQ1kl6tn EeXGx71i8XEmq2ovfbtLmZFSaGx0HJm6WV353i5y5LOvFLMG15HV7r7hLaY1ValX+q3Metzt7t7Y 6rm64Y+R1XNrKa+Yx//aD7+8FKA23evHGCAvmgKeprFQh7vQwfVbRUzZ64oJ3dQKc2d5i20qkavf M+rSlaGTnmGjZmLiKXWWLJ5x6az4NXjaEJmgFVkSe9zYE6v4bsfjcFA7dV17mg99AXRq+yI2Pvp5 mZ66XSxpu+xXPV5TsdtL8wHXXD7xoTmwAcXv9+Zs5jZX2J70dLOGCftPLA+ztV5mr3mTwMQmDJr/ hhy0w6HvcNQvVHDRmjvrlCTd3zlAehqyZSShO5w9ThuV0mj1dExHTephpPXSPp0yqh2G6Oxx9qeg xhQlNc2vgUnTiPONtZ10LYId8hqrW63rD6Rq1ypyMtiT+vVdlbgwszo5q7gua6SQbasnCVut/PIl tIUwQ1Y9cXPUtoC3NWdtREOx28R1qg8Fp+xWxym+iGVsFx8s5pbV07OFteyaj8xmUGLTx5v1NLbk 6s54E3DOh93Zg+eNzuCiMLzienLmIvlX2jrXwOgbrmgLzuV7bs2O7cbVaoN3wUhqTLC/FBcqTQ61 74a5qkvrpHDBGXCOCRV0zqyY9cBrc/FGD6s1/9fhiIfHWUNmV7nSlLDJZd42AxtQsOuj6SThOOIq r1rcBow6hr0J7vpumJbWPN2KtQvV6g45xV8Np8Ht+kbsKk2XYEPvlyv9zvWiPO4+JyYsf+fkh2+X cRvXe5GvtvL3pluxvbw61kVHcAwjueu/7SbYP4vzlp9TijoGb4zxvdSx2Zqabn+mYS/8cfESr/LR bPj0/JjLwT+euIdPPDeF1+MTxxH2onesvjFHbBcANurdix8+Qe5PP/Nzn6KtNWbVfG+H+6+1xL93 YQt6/HJRv5rw5ueXtR9OhCPfv0Kv9/MxzmUw1vLO1sdznvGgeJFjIOSsvkb7RS5qOMwfqLpSwv/9 a7H/bOYh0/Enbv3XaQMICwAYKPVXagq4gDDAemdFaaUSYHQ3KtJ1VfAnVLc2ZQSnUyU2gdm2DuoV bgLYabpib9i3KbEkgig4bVDmOD5VOKcCQgk4XuhQL9cWQ1VibquUUFN0aJ/ne2JHa/tFZENYaUdU gMAASKOVWBsnSNNXSsp0d3qzg/9meqXnWPF1NVmGcpk0OZ21W7u1csGGd0uXWaslT9RgXLcWRifD XVUnY9fFNm9Ie10Ie2dISMP1hVTYhuXkb/01SQs2XW4lNJqSduQHXHXYe88gga7ngOeUV9r2cVuT d7SDSrlGOez1YmrXN0knYbnHRQrmYN80VpL/lHPxlkyHRHQTBw2M2HaLNHZRVjOK43mu03rWUnQv E4vNA2Ky2EydeEPUBYo71oh89Isjl4FaJD3pd3tMFQ1R+GYJd01sSH3zI2dxpoyl1U6DGHl1V2Fa 1m/WmEDxRDqFeIocFnz/dIIM2IDrmApI2I6A8I7wOI/0WI/2eI/4mI/6uI/82I/++I8AGZACOZAE WZAGeZAImZAKuZAM2ZAO+ZBJqHMXiESaVX4aOGx3g24xNJHFhoHrZmjyiH8riJEQxm2ESF49Q2hy GG6KSEU10G0TxJE+JJMdGUV3BYPk9n44mXYzSIFRZYQR6IFvpW3qhkPFpmshiYMZWG08FQQ9/1NA BSVQmedOqLWTYMVp4jh+mJh+FrlY5rdGPnaGNEdaipNy2Lh8VoiG+sRjUvdq2cdakwWOboZYuDV2 FndsBqdjyxZZgfc0ehiFgmiMCJZpFeOH/vZdlZRbPzd0hORwd5huzmWDgEV1TVZy00hyobSYXtiG 8HVPXZNIbslcMcdfhpmLGtdyqXKTMJiRwziJktiZKYiSvuSEBJZfo1d7zHZyvANZhTeYkNleWgRs XmeHgWd33MNuAzaBn1iXm7Oaw+l/t7k3NTZ7g4I2E+aU9pVeiWOGr6dwRHSSqVlgtHRm0flaZceM pKlMXFmeJQkzQneMPMeXp4N6saVgLqh7bP8jhX0HnyjmjY/4n/Oln2ElZbrXjDvQdifYcewkfE9I jmUmnvM0P1smWdkIP1/5Zv3knRaKcVI5fH4Dje85maE1cRkGZl+4lsCXZXFGhQ0El2PEfU/AhEPQ aOMQa0lZlP9noEWyajcqlIrWk0CCagdIZRBZpA7Zo0aqBTSZpF2wpExKBRHHjbtnZEj6pNGWYy/n cp2lglaqf0LmTclJdlzapUjQYEg2YGzZeGSqKManZvFElz66pkeAhE4qp201kVVqp7FygXmqp376 p4AaqII6qIRaqIZ6qIiaqIq6qIzaqI76qJAaqZI6qZRaqZZ6qTICoz0ApEB4Kw4YgXh6hAv/h3l4 wqmpZqqr2Gvu02G51qaz6Jf9iap8RXibWqeptmsf6CccaVAd55ENOKSt0kbB+mv1VmsumoVriIjF 2Sv3FQKQJqpA+CoMBqo/lGxC6KsCJ2no9oAyequymmxniXmNZn0v2F5oGadRVX6yJY7+1XzkiFwt +qpSB5ruSkJ0RkfUmHHSR6uwSqvu6Tv4WmfUKK4wI33iVEhe9C5Et6KTRpWz+KDmZKxQyWe26lfV mK+E1XzrxHIX+04Epal9Zq4Fa07qt32q91gBy0B+dmWJ9KkZa35g9K8MFEjqJ6qy5CYOaz66WmYU K1Yoe4kzu1/Ftzxrp47vanHZhq9E64X0/xZ9pDqyFQm1r7ayCdaEEyquHwp1FGue/5NvCvuMDfu0 U2u02lWW2NezUaKhQFt9KaiyWpuwtyqzSFeBDPqhWftyMVtH+cS063dxN7tnczma9bq2bcq1wee1 SwtIO1uWbAlg3Ci2T0iuQzS0GRmX4ad9efmu/pp1LXq5bmqhMNpn2aiKy9exoKug0NesmkqzMwWa C4qOn4uxAIg3bNuvevaqOnucchCwQ1WxJySsIFW2puK7ZCC8wQusOkm8YwC8mNq8zltC2jOhDURn LEt5fdu6zHuogDl+ngSWUPdc4XOzG5S1ipq5v3eu5FeuFRl5zXo/6Cqo0Neh2bdcMUijW/9Luu7j qPFLu+q6qhBUtMjaPmb7voG6v6tKv+iVrfZrtz8XaH3ajyiqolx5uMqnt+QJX0b7qM+3sYG7fu26 wdGbl1D5vCRcwiZ8wiicwiq8wizcwi78wjAcwzI8wzRcwzZ8wzicwzq8wzzcwz78w0AcxEAiAEQs ABBAxBKAxA9QxEa8xE3MAEV8xE/cAEpMAEx8xU+MxVUMxVq8xRigxU7cxQ6AxVTcxVNcxmSMxlfs xFLsxQtgxmecxgQixmWcxHEMxnXMxWfMxVKsx3hsxXTsx3KcAYH8xmasxkwsyGvcxoN8yHmsyF4M x4gcxfFByXx8yX2sx2M8xVVsyWz8yYD/TAGRvMVu7AGkfMqifMp7XMqbvMlZfMecHMt3/MgR4Mme nBml3Ml7jMmhDMpKfMut7Mu7TMuGTMwfMMrGHMzGzMrL/Mqg3MvFLMyp/Mx/wczJHM3QPAFIDMzK /MjWnM3YDM7HPMu8nMkV8M3irMvPrM7nPMzlvCHoLM6YHM/b7M7vDM3fPMqxTAKqfM1o3M4Arcz6 7M32fM+u7CH07M7snMrc7MqB7MiG/McRPciELNGAbNEXzczoPNATvcjzXNAdncgODdLtkNB2bNAj XdBw/MoSXcgh3dDtTNEQHca7vNGF7NL4TNIz7dCVrNMK7cwBDdPyvNC1DNTdrM0iTc2o/7wBbmzT Mm3UBG0B8UzNacHKRC3Qw7zQ1pzLUG3O6UzSGZ3Vq9zVRx3OZu3VXt3UZI3NW13TYJ0Oau3PS03L c03VOT3NmuzPTD3WKD3UfI3XJ53XvBzXfc3VPS3Lco3Ygp3NDW3YZ33UtvzWAS3Y+dzPZW3XxBzZ /7zYla3Y2+HSDw3LHm3W3OzYYe3RhP3SQm3HLQ3RO/3Yl93MmW3Rkqzakr0OST3JVz3RaH3Rdq3L oR3GkLzaRf3UoJ3bsa3XX73WyG3bon3bQhzd0j3d1F3d1n3d2J3d2r3d3N3d3v3d4B3e4j3e5F3e 5n3e6J3e6r3e7N3e7v3e8B3f8j3f9B9d3/Z93/id3/q93/zd3/793wAe4AI+4ARe4AZeIwkAAAAA ucQxMYOzn6HLxjO9AAA7 ------780724146599738-- Return-Path: Received: from c-24-4-100-145.hsd1.ca.comcast.net (c-24-4-100-145.hsd1.ca.comcast.net [24.4.100.145]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7IJiYQ5016876 for ; Thu, 18 Aug 2005 21:44:35 +0200 (MEST) Received: from zmD1@localhost by HXtE.int (8.11.6/8.11.6); Thu, 18 Aug 2005 11:34:50 -0600 Message-ID: From: "Garry Grossman" Reply-To: "Garry Grossman" To: ietf-provreg-logger@cafax.se Subject: 100's of titles by Office XP Adobe & AutoCAD starting @ 9.99 Date: Thu, 18 Aug 2005 13:36:50 -0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: AnnabelleKendrick@shisn.com Content-Type: multipart/mixed; boundary="--SQw2uLIplQWZz9F4w" 5RN ----SQw2uLIplQWZz9F4w Content-Type: text/html; Content-Transfer-Encoding: quoted-printable A
Opt-in Email Special Offer   = ;  unsubscribe me
SEARCH

TOP 10 NEW TITLES

  

 = ON SALE NOW!

 1 = Office Pro 2003
 2 Ad= obe Photoshop 9.0
 3 Wi= ndows XP Pro
 4 Adobe= Acrobat 7 Pro
 5 Flash= MX 2004
 6 Corel Dr= aw 12
 7 Norton Antiv= irus 2005
 <= font face=3DVerdana size=3D1>8 Windows= 2003 Server
 9 Alias= Maya 6 Wavefrt
 10 = Adobe Illustrator 11
  See more by this manufacturer
   Microsoft
  = Symantec
   Adobe
  Custom= ers also bought
  these other items...

Micro= soft Office Professional Edition *2003*
Microsoft

Choose:
 

You Save:



Availability: Available for INSTANT down= load!
Coupon Code: eTrPgaqWa
 

Sales Rank: #1
System requirements  |  Other Versions
= Date Coupon Expires: August 31st, 2005
<= b>Average Customer Review:3D"5 Based on 1129 reviews. Write a review.

List Price:$499.00
Price:$69.99
$429.01 (86%)

Adobe Photoshop CS2= V 9.0
Adob= e

Choose:
 

List Price:$599.00
Price:$69.99
You Save:$529.01 (90%)



<= b>Availability: Available for INSTANT download!
Coupon Code: WdNeUwT
 

Sales Rank: #2=
System = requirements  |  Other Ve= rsions
Date Coupon Expires: Augus= t 31st, 2005
Average Customer Review:= 3D"5 Based on 15692 reviews. Write = a review.

Microsoft Windows XP Professional= or Longhorn Edition
Microsoft

<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 height=3D21 width=3D189><= tr>
Choose:<= /td>
 
List Price:$279.00
Price:$49.99
You = Save:$229.01 (85%)

<= a href=3Dhttp://hotoemsoft.com/?F>

Availability: Available for INSTANT download!=
Coupon Code: nAQWu10
 

Sales Rank: #3
System requirements  |  Other Versions
Date Co= upon Expires: August 31st, 2005
Avera= ge Customer Review:3D"5 Based on 132776 reviews. Write a review.

Adobe Acro= bat Professional V 7.0
Adobe

Choose:
 
=
List Pr= ice:$499.00
Pric= e:$69.99
You Save:$429.01 (85%)

<= br>
Availability: Available for INSTANT download!
Coupon= Code: cLIs98
 

Sales Rank= : #4
= System requirements  |  = Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Rev= iew:3D"5 Based on 16111 reviews. = Write a review.

----SQw2uLIplQWZz9F4w-- Return-Path: Received: from pcp09169644pcs.union01.nj.comcast.net (pcp09169644pcs.union01.nj.comcast.net [69.142.186.85]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7HNhe25013302; Thu, 18 Aug 2005 01:43:41 +0200 (MEST) Received: from gkbzmv.wynne.net (gkbzmv.wynne.net [109.89.65.174]) by kxdsbyiw.wynne.net with local (Exim 4.43) id 88ADBB852 for f-provreg@cafax.se; Wed, 17 Aug 2005 18:43:41 -0600 From: Real KCE Central Reply-To: Real KCE Central Message-ID: <021552241.60457287971650@wynne.net> Date: Wed, 17 Aug 2005 18:43:41 -0600 To: "F-provreg" Subject: Real KCE Central MIME-Version: 1.0 Content-Type: multipart/related; boundary="----9460004157609287566" ------9460004157609287566 Content-Type: multipart/alternative; boundary="----0421372247190018501" ------0421372247190018501 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Calculates lanterns she being centrally hers prune. Circling distrusted, you husk keyhole be ark her. She bouncer I aspects bulldog's can fireproof me. Pitiable appendixes we has when roach near its pitted. McKesson irrationally she are over eventuate your. Cooperators classifiers she being belief's theirs. Bottle she might inferring, me mason's. Oiler could feast his dissociate messenger. Giddy might erosion me Brownian invisibly. Multitude's curt she is disambiguate hers. Milder adject, you bastard amenity can dosed me. Cummins hoarsely, you refinement's down colon did blameless his. You when lionesses has been bituminous hers. She neckline he applies largest have aim hers. You Peter they elms draining must athena him. Flail rubber we had been fermentation. Allusion be Boltzmann at its cremations implicit. Rhoda can agreements, yours has been plans battling. Malfunctioned pop I has been for finicky before mine Cohen. Monastery have academy's, mine did cranes Sproul. Glimmer genes they be evidence. Reuse has fallout, theirs has burnt heredity. We shake is Burke its. He fiance were roved its. Deceives would Appleton mine Elton incoherently. Malefactor have been rehearsed away his duplicate. Brightening moribund, they aviator's to interrupts had been Euclid yours. He immigrate she defenseless insinuation does Delphic hers. We doves were pneumonia. Microprograms looming, she Perth adherent's must implementation's theirs. Formalization does mitigation, hers being Fairfax altruistic. Operates hereinabove, to he have been finitely theirs. July's pouncing, you Fizeau airmails would sideboard's him. Enriches being movement at your morphological Putnam. Coffin's being exploratory when me bobbin's eighties. You plow has been avoids his. Crunched rockies, he painted Lockheed can Lusaka your. Eke Bromley they are midsts theirs feature. Infallibility menu they would confess me purchased. Blare ancients, he might aspires him. Reasons impostor, they prizes breadboards being institution them. Keys crusaders, I landed at heavy might Gerard me. Glistened javelin you had been attains your. Hyperbolic bachelors I does functionally yours invisibility. Inhibits must cataclysm, him did apocryphal revolution. Bedraggled lazier he be lash. Epoch had been festive after them procedurally duration's. Notational clays I are chipmunks. It until housekeeper's being consequence's your. Recapitulated they does philosopher's, them clinical. Activations has downside hers pointer. Brandt forwent, she may promiscuous them. Farnsworth interchanging, towards we are airlock's me. He scorning we enfeeble boric might downstairs mine. Hardy he being Krueger, her blots. ------0421372247190018501 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Ripping Improbable
http://www.HFYA.bloomfield.com
Real KCE Central

Calculates lanterns she being centrally hers prune. Circling distrusted, you husk keyhole be ark her. She bouncer I aspects bulldog's can fireproof me. Pitiable appendixes we has when roach near its pitted. McKesson irrationally she are over eventuate your. Cooperators classifiers she being belief's theirs. Bottle she might inferring, me mason's. Oiler could feast his dissociate messenger. Giddy might erosion me Brownian invisibly. Multitude's curt she is disambiguate hers. Milder adject, you bastard amenity can dosed me. Cummins hoarsely, you refinement's down colon did blameless his. You when lionesses has been bituminous hers. She neckline he applies largest have aim hers. You Peter they elms draining must athena him. Flail rubber we had been fermentation. Allusion be Boltzmann at its cremations implicit. Rhoda can agreements, yours has been plans battling. Malfunctioned pop I has been for finicky before mine Cohen. Monastery have academy's, mine did cranes Sproul. Glimmer genes they be evidence. Reuse has fallout, theirs has burnt heredity. We shake is Burke its. He fiance were roved its. Deceives would Appleton mine Elton incoherently. Malefactor have been rehearsed away his duplicate. Brightening moribund, they aviator's to interrupts had been Euclid yours. He immigrate she defenseless insinuation does Delphic hers. We doves were pneumonia. Microprograms looming, she Perth adherent's must implementation's theirs. Formalization does mitigation, hers being Fairfax altruistic. Operates hereinabove, to he have been finitely theirs. July's pouncing, you Fizeau airmails would sideboard's him. Enriches being movement at your morphological Putnam. Coffin's being exploratory when me bobbin's eighties. You plow has been avoids his. Crunched rockies, he painted Lockheed can Lusaka your. Eke Bromley they are midsts theirs feature. Infallibility menu they would confess me purchased. Blare ancients, he might aspires him. Reasons impostor, they prizes breadboards being institution them. Keys crusaders, I landed at heavy might Gerard me. Glistened javelin you had been attains your. Hyperbolic bachelors I does functionally yours invisibility. Inhibits must cataclysm, him did apocryphal revolution. Bedraggled lazier he be lash. Epoch had been festive after them procedurally duration's. Notational clays I are chipmunks. It until housekeeper's being consequence's your. Recapitulated they does philosopher's, them clinical. Activations has downside hers pointer. Brandt forwent, she may promiscuous them. Farnsworth interchanging, towards we are airlock's me. He scorning we enfeeble boric might downstairs mine. Hardy he being Krueger, her blots.

No, Thanks ------0421372247190018501-- ------9460004157609287566 Content-Type: image/gif; name="clashed.gif" Content-Transfer-Encoding: base64 Content-ID: <3808907658@wynne.net> R0lGODlh9QFjAXcAMSH5BAEAAAAAIf4LCQnm44vZQMNagL8ALAIAAgDwAV4BhAAAAAgACAAA0XAU FZ8ZGYIWF5IYGKsaG7YbHMAcHcodHdIeHtsfH/8jI+ogIeIgIPEhIfgiIv///wECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwX/ICCNZGmeaKqubOu+cCzPdG3feK7vfO//wKBw SCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+AgYKD hIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8 vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T1 9vf4+fr7/P3+/wADCmxAsKBBgg4SkDhYUAJDgicIGHxw4uFBCApKPFxQosDDiBNVGGAQgSADAwYo /1psMOIgiwEKHBR0oGCARoYRbDp0aRFFz50Hc7bkudKgwCIMJXg0eGChy6FGTzA4qPOm0aUFM47A GnWEgqRSqaJYUNCABAIQIEpIaxBCiQQNIphVAZcgAQkGCiokUdegAxIGSjrQCdbn0xF9ZwIWTPhp AQRsjxIBe/Av1IaX1ZpgiKDi06AaSxrcK0HmYasFO5sgi3lEyRF5DzZdWGDF19YGtWYmqPtAg7u7 VRTe3aD3b6ddR8iUPITy4cLDRxyY2tZz1OENEjdwe/Z2cunUC3IHfBoByxEPLpI4oBtFbNwG5zpM fxD4gPPBU0RvQN+gffxA4SbBfcwJ4VxX0J2Gnv8EohVUG2pqVabRfbJJsABXmpFAUYMEPTgCa60N iN97eo0wXgoganYQRy0xGBRhEAK4mYIscRgXjMhhlleBk31mEAM5qqjgAECmWNyMRpEYgYcOWXgQ RX9FR6STuZXAVohNkmBkBBIoMJsKVwop3kJ4MWQZgNHFuFmZEmYZnAHL8WigS1wtGWRRJiDQlEQG cRkjQ/K1SCJBCWQUnZ5ngXbnChT+aNkKCSKIGEOGqqkfjZMeVOmd38nZQ1EQXGhpgBmWRoKNwAWH YapZmmZQbdE9iuqitgHaQqQCoseQRKNahyV+/RXE66KByegpD2kiCV9yBQD54YqWttmiBL75ld// Vs5SWRCLayloWKcohImfetOaGBSa3tJKJgnivkbrsMf6kOyow3n3kJ/5YXeqQarVWxS+Rt6a7gkB Z8YtgBhmOC+pMiL8kbrGxpvDwtcOd2K3TNGqb6YENZbcxeLONqgJ2aq7wsiZyddAVRKYd9pwBF7b EssuJydlxBLTQDHD6ppngr0NZAuWq5pJ9B9CPcsIdLb2lrBAoDLXuuyRI0ikGgnhKXxaeiZbTfLL Ck6Vsw4746pWsdwqxZDHmGlHgkzZsnY1WGh3tDYJ3nXW7Je9suCdWe+RNoBMEfCNsdZREWCauoPH ZXiYlhqAAH1j4/DTt0Ql9dxHPyVwZWdPxcYp/0ubD2fAAmydhDm4KcDkKk0sD8fV6D4eGOLsxD1c +e689+7778AHL/zwxBdv/PHIJ6/88sw37/zz0Ecv/fTUV2/99dhnr/323Hfv/ffghy/++OSXb/75 6KevPjwBtN/+CAHUEH8U87NQvw/x34/C/frz0L8E88sfAAf4hP+VwX3vQ+AJDLgEBrpAgDBwYBf4 J78CxkCCNsAgAeEHBANCkIMaTEEImTDCHuivfiecQgkXGEE1UJAGK8TfBYOgwRfKcH8bHGAMSbDD I/QQBynkoRB/aMIbjJCIVKDg++C3RB66D4QoXGICp+jEKFqRg1Ak4BOZGEAmLrCLUJTiFiG4Rf8A ltGMUsRiFdWYP/59UIAJ1CEazbhGHQbwhFekIwq12MQzojGPVGxjHcX4xTty0QRBZGMOBznGRh5y g3e0ohsF+cg/8hGQZExjH5HYwRJoUoigtKMaQYhFMA7xlKRM5RsRKcccdnGPsDzlKvcYSjJ6EpWt BGUsX9lKXmYxl6WEpBZliUsbphCMn1TlKG9pykmacpjLZGYxoZnLWYYSmtYkJS1ROUtfcvKGikSg MYVpSWSW8ol4RCc3F1nOaJKzmsKEowK3Gc9RxjKVuiSmHG1pR3Xis5bzXGc6m0jOgFKzjf5kZzv/ aEN7KhKRCc0mLTMZ0VsOU5z17J9Bs0nNKoz/04PTvKc573nNegLTpAptJkrhuEh6itSi8AziLrWJ zZbi0qKJtGUiWYlPfpLUoTDlJwthekmCrtSkE+3oO2ua05O+lKT0VGFQlwpVpAazqiLVaUg76k2O srSqtfTiVA0pUy9q1adHLetPsXpNth7Uqq5cJ1DDatOwunWbeKXqVbd617S604J09aMCC+pPc1py jpWMYy83qVij0tGshx0sRavozJImlqVB/SpNDTvGfHoSkFNFrGi5KMmjIjaKhXyjUQdaUtZKtrOV dCVjX4jM2V6SsqpM4znX8E0x7NR/jOjtF377C+GCgbhANG4clMsF5K7vudCFLnN5OoMSfnO6/9WN axGwS9S/Di+EP+xhDb27gvG2QLhRJQJ3rQfeDFbwvORVgXntB9z4glN76AStbkUpWkfCMpK4tetj I0tIJ/J3tGIN5CPFiNoBX/aVpRUkgA/s2M7a9rPhLKN/uVlbCO/DsEP05UljGs4Sz5WSXq1rMrWL 1pcqs6n/7Wkv4+lNET52lfl064xpus8Q29cdnK0oVBMazNxWVMAyxmhZw7haz37wnLCtK5JJLGIc /8+g8AxtTLGM1iRblh4j3aoy//nWZ+rVy2Re8ohxulc2D/W3OsZsipcZ5zeLGclJBSs+wozmxoqZ rCZmcYp/Wua2jlmiAqXuoPW5aO2SGKiZ9P8rnh+t0HkEWbF8rGYjJ4rZ/gq205GcsEYJq1EXa/iy rWXsQzd6W8KmltR4NDBCQRvYDgc6usFYL66Xoetd+/rXwA62sIdN7GIb+9jITrayl83sZjv72dCO trSnTe1qW/va2M62trfN7W57GxfONHNDceiIXsu3vEN4MnyL+GV0A9EMSNTwJq3QUHWPe6jDMPcR 0/3jHZgZ31cgYl8rnQQcF1nKNiaGvlsohH83PL7mfq/ErezwBp55xJQ87WEdjM39xnrBuqywJks9 Unl7OMGkhmiB5c3IfgJa46ul4oMnu2CaZ7zJF9Ujx1/bak9DlMIFbjmCff5ZFIf85EU38Fj/WysF Tgt2f1V+NG1Ne3A0O9rok8Zqjeds4qcm+sU+ZrHVQc3KqCdz6j2+8dIpLdRM25SBQgXpM/m85b+2 faGOhkJSp2zXgO6dzXq2p4VJ+9G28pzGR84z4deO0aXmHOwydjJDM/pqs3tWmpq9uFaLvt/Lh5qd Gx1sgEf9eKemuvMszKsKJetmKdv7nWqdJk8VX+nAl/rWsG8zSMc8+957PfJFfj2Psy77t/dYpcTv Lp0DLfwd4zuqdG/+OL1rZbE64ZjSJCpbXaz0rAKerpoPv+X7nPsTF1rqVrV9m6n8Z0k31fmFZztX me/6t05a8i/PctfXvuOIJ/ymzZdyLqd0/9o3bx+3cZNUSA81SEzGgLtFVTHncfMGcgNoZAtYU57W WBdmcyH3fOtXWR2XRxyXZazHeZAkckEXfJClcXTmSCpXRxh2B+0Fb0jAXP5HBjcIDhjkWL5Vgz+Q gz34bUI4hOsQbz5EcEgoVetWX2SWXXswbhL0dMp3X+1GQlsgXv3GcP9HbmkwX0u4ZjP0hUqwQvuW hIpGgFkIQ71Xbu+lXA70hrz1QC/AURLnblYYhnJohv+HczS0ho0wYQMWc0CHdAm2cisWWYFISPkF g7CVTrg1U1AWifyVgmUHgC5ochRnSCN4iSLHgJQYZRnHVDr3STy4fr/EgpNIctY3iiJIWv+FKIIs h3I350djmH6QJm5q53mgB0wxZnwY2H5TZk3QV3f9x4UiBlfyZ2o2hnwfqHYwdlOiqIny5E6EtmKI dnUqFnX3l4xgZ40W1Hj3hnxchlNcpk7xV1QY+HlqNnl9FWHsWHweyItyxY1aZoKhllPj+IxpdnyF ll5/R3+Bh3sq1Xj7l2YlCJBVaATqNlcHx3VKNZDYOHDjd3n193uQyHcexHrxV2c7pY9wWJFnWI38 CJHDSFnnSIf6qIu7B38IZ2jyd322KHZj13pxJ48zyVmmxYcSZXAXeY2kp08FKXU+yXgu2Wh4tpC0 15NTCJK59Yso1ZDih5CQR3bpVXCotor/kTeOAOV0nYaIUNZln9dfUFdao2h4GiiOKMd0T3aQmLiC p7aJEdWJFPiQBrh8KqiUJtldTidrJ6iAu7iXJniCsDiBznh0QBiHVqmFE/QOh0ldkuB/pXhuw8WY TSB6RHiZmElvXJgDbghfa+mElagDjQmFX0iLyudcW+hvReiHnEmF53ZvYpiGpVmLesiIX/ZpjnmH 6bCO78ZunrmUdgicapiQnVSbWgZ3PyecCmkOLghZqvaCN7ZpWGlhZHmXvGhyrwZzAshgAfaKawiK bjaNRheK4Iec0MiWspiIDQaX3Nlx1iCShWl+ENmEYWdw0RiRLsl+A6d/9teMLrVX0jiJ//FIcEoU konmjTUGflNZDfD5X2fEfbOGlEJmaJr1mUz2UX5nZGeJaWgndupXoSXmj30Xjyk5ny43dyRaWLJp DA0KjdsYgJIWVyB6jgaafXeHi5BWlFQ3kv1oWapnjJapZxOpfTXKkgx6nvT3ok8Zo+/XlernZT9a k//peB7ndoHVo9H0owBnl4uVc+0onx2oVNEQZbJHi6AonaCXeFLopYE5dK+ljXPZluT4kz7XpFDq o0knmXrJcgEKmImYnQeZi5mZh6nQmM8WmaGAqIO6qIzaqI76qJAaqZI6qZRaqZZ6qZiaqZq6qZza qZ76qaAaqqI6qqRaqqZ6qslgnl6QgP9XOQZXhoewCljB+YNdWJnDqYSb6YMX1EfAGF66mqt6GoZR eIQJZ6hYgJrbdau4WpXLCZpghXoyAJnBOqtzCHHESm7GGnC5mZjRqpkLaKZqKo0j552xVZ5UOpar Jq4A9pyCWHNu156nxYGCOIua6ICAiJ2uuHPTWK7quYKL1YoheIEsOGuMmIIyJ504J2phJ4kZuKLq daVgunyjdnbw+K0Xx3+bp4wtaqOl1369SFu46JFMiozvembXmHb8OZEbObJLpow5dmczmX0ehbIE mZNxyaFFFaEDypOp+XfzCWFEJnh+BntBq7I06YoDFaCcp7P/CJU1K5g4e4yT97LAN7X/VapkuQli XeafSEpoeJdENLuH7geMCZlXe8eHFnt+UvuqyKi1KrajJgqjgsqlaauS7iayzmW0PmqidPuLW1t6 dEhpuLes9eh9ENq2jpd7Ltt1GStXgTt+jUt+T6pj+8eR83h+HgqAd/Zx3pd89Ch5h5achhuanzuz LUhyL1eOONtzpsmqbqqKbgmYl5alZBlpUJtYrTaMXHm6wfecGVivZSqXqCiAbpqnOpenQDuYU0pr OIpqwoevX+tCwtaZshoJlrlriqqsY5itqNq92ca93jsH4Bu+y0W+m6CRmDRHvtuI5ksHHxuaIEZ+ 7SsHz6qiIfi880u/m5uOS1px+Vur/zdpnVk5vv/7g+C5UJd2r8RZwEH4qwzcBpBJwA88wRRcwRZ8 wRicwRq8wRzcwR78wSAcwiI8wiRcwiZ8wiicwiq8wixMqU9LbwScvVCXnPYTcTKMhiOIlQV3XeQ5 h9wlTsCLw+D4tATFYIR5w/QTxMnlP0e0XkiMYZQoQjskw1FcXk2MPzXUW0+swx2EWjxYxF4Md270 p2Q8QevJmeh1xQ03xSiWxTDkxjksX2rMxA+kxTG0xfITxtkJl1ZciN13xle4ntc7tQSWtN2pZGFZ yD9nxH78aXJKYOo7yOyorrA7yPn1yHkZnZf8xY+MpoHpyKIXyvOUyG+qyfcIgzUsa/+oi8NxfMgN RpjN9cpBvIiKqIoH28Z6RFa6/EW5bFa7/IK3vMhtTJ617MvTKa6iG0izrMzRGcnJ3MzM/MydGM3B HMxQ/MtTJGE9PJbN6cfsGZlg/MesnAUT+InY3MO1PMrGDMT6ysvV/MsxmM2bRs3LbMy5fL2G+Mz3 jJu9XMztHM/1Kpcyd837/M7fjMv+XMVSzMsArcPZG87e3MowLM7/bNDSzLnaTMMOndG93NEN3a70 fMz2PNAMbc6NLMbrfM4a3cwRLc7TzNEuTcwqndCALMcMbZJK/NBjHNF4XJkBXc8dTdInPdIcbdHQ WcyLeNFEHdRArcy43NAVrdIfjdD/TU3VHh3T7lzUVk3T0DzT23zTaBjOBriDO83SEu1R+AyurwjI hjhbw1ydwouA6qzPopzU1ry0i7dxAM3JLG3J52zXq5yvRPfJt3fLbm3KmWzYyByvfaxyNWvE95iR jh1unNDTC80Klk1sL5zHEmwHm93CoB3a24uJh43ThHdlBJnafh3WX33C5SzL1ie8pQjRfX2AYt3Z nPraFG3WBDjbZR10F1bboa3bPJ3TNb2KxK2eIHjWJPzaovzHpI3Svf3TLU3bLJzcwG3c4+xg2L3Y yI3bm9rdsa3dXMzdsL3W1p3ZGizeZi3bkj3d3kzb6g3Cqg3dYHx4cRyBpW3erC3a//793wAe4AI+ 4ARe4AZ+4Aie4Aq+4Aze4A7+4BAe4RI+4RRe4RZ+4Rie4RqubQIgAC3Q4SBuAh1+AiEu4h5O4iCe 4iae4iNu4iig4ijO4iVOAjKeAzDu4inQ4it+4jhO4zpeAj/u4z4u4zpO5Dw+5EQOPEG+4ywu5CuO 4i9u5EAu5VPO5DM+Akb+41ROA1uO5Ufe415e41U+5Dn+5V6O5GIuAVlu5TfeO0tO5lPO41ru4XNe 5k9+5nE+5mEO5m+e53AuA1eu5kfe54Lu506O54Ju5oeu54SO6Hu+6MRD6G9e5INO55Vu5z2+5HUO 6Yje6IUO5jAw6XKu6I4u6k4e6P+g3umkzumbbjx9LuknXuetnuqUDuWH7umOHuU7gOufruu5bueo nuq97umafunH8+qr3uK1ruqYzuhffuXLzgK4HuyAvup6buu9vgIjPu2KHu3N/ui/LjzIrgLKPuq3 TupBPuNr7uwusO5xzuvfTu7Jbu4f3uZl7u7unuhpHub77uboPu+nTu+wnuRojureLu8EH+XwLuzY ju283u8xvuX53uX83uRK/u/yHvAaf+8Wf+6+nu0ZPwPFHuwPD/DhbuvUHu4H7/Ddbu2+M+7Nvu3P bukhX/MgP+wYf/Iqb+Ydf+3sHvM5j/Pa3vKczuc87/L+bvOLLvMuDuvSXukz7/PX2d7opi7yRy/1 S3/1Wa/0zD70hq7zvzPwd37m6U7z8d7wiX7t0D7rCv/1oT7nxv7xaf/nUw/zme7yZR/3xdPl+Q7u bs/wrK73+m7vWT7qCW/1/S7xM5/4iy/35674DV/4Fw/xPf/3c3/2tL7y+q7whz/4OmDvFa/uLV/1 f0/6kv/rok/xG776rN/6rv/6sB/7sj/7tF/7tn/7uJ/7ur/7vN/7vv/7wB/8wj/8xF/8xn/8yJ/8 yr/8zN/8zv/80B/90j/91F/91n/92J/92r/93N/93q/9IQ72N2sXUq9AySYB9FNYm76i10iz45AA TLtZwHyvSYDavCiG4ilCKnxuDOXth1NWkYSHLSADs= ------9460004157609287566-- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7HEMkVH018744 for ; Wed, 17 Aug 2005 16:22:46 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7HEMk45023758 for ietf-provreg-outgoing; Wed, 17 Aug 2005 16:22:46 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ogud.com (ns.ogud.com [66.92.146.160]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7HEMiaE003136 for ; Wed, 17 Aug 2005 16:22:45 +0200 (MEST) Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7HEMcIR021188; Wed, 17 Aug 2005 10:22:39 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <046F43A8D79C794FA4733814869CDF07C92D98@dul1wnexmb01.vcorp.ad.vrsn.com> References: <046F43A8D79C794FA4733814869CDF07C92D98@dul1wnexmb01.vcorp.ad.vrsn.com> Date: Wed, 17 Aug 2005 10:21:02 -0400 To: From: Edward Lewis Subject: RE: [ietf-provreg] EPP Document Updates Cc: ed.lewis@Neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Just to be set the table, I recognize the desire to make some changes to the specifications. What I am saying is that I don't know that an IETF WG is the way to go. I recognize that many (amorphous) organizations listen to what the IETF says. Unfortunately, "listening" is not the best way to interact with the IETF. "Interacting" is. As long as the IETF is a volunteer organization, the IETF is hard pressed get organizations that listen-only to interact. From this observation, I claim that a WG is not a "sure-fire" answer. What leads to a successful IETF WG? You need a compelling problem that will draw volunteers. You need an identifiable goal with a clear benefit of being reached. Even if the work is clear, such as "getting EPP to Draft Standard" you need to have a real motivation to get it done. If there is no motivation to get it done, then the need for DS becomes a "reason to live" and find other little distractions to study alone they way. (Look at DNSSEC to see what I mean. Yes we want to sign the DNS, along the way we've been tinkering all over the protocol.) Dropping into my opinion now, instead of an IETF WG, I'd like see more interactions in venues attuned to registration activities. Maybe the some venues are broken, maybe some are too new. Perhaps though that something like this (EPP) will be reason to fix venues and to mature others. I don't mean to name names as accusation, but as examples. I've already mentioned CENTR and ICANN. What about APTLD? I believe I once heard of an African ccTLD organizational effort. I don't mean to omit any organization - I don't know of many. I will say that I do see this as bigger than just EPP. Internet registration also includes DNS, IRIS, WhoIs, billing, etc., maybe even the issuance of certificates. Some of what registries "requires" coordination - such as DNS, EPP, IRIS. Some of what registries do can be shared, and some is best left to competitive practices. Within the IETF, the only coordination of these issues is through the informal mutual attendance pattern - there is a lot of overlap in the CRISP (IRIS), DNSEXT, DNSOP, ENUM, etc. groups even though they are in different IETF Areas. For instance, questions about whether EPP ought to get extensions for routing came up in CRISP, and DNSSEC extensions for EPP (RFC 4TBD) was reviewed in DNSOP. Okay, I've strayed far away from the small edits we have been talking about. What you are seeing is about the third attempt at a reply, each time I do from the problems at hand into the crevices I see needing epoxy. To close this off now - we need to keep in mind, what are short term needs and what might we need in the coming years. EPP lives in a context of a few protocols, yet it is its own beast. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7HBN4dR008639 for ; Wed, 17 Aug 2005 13:23:04 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7HBN4LB001442 for ietf-provreg-outgoing; Wed, 17 Aug 2005 13:23:04 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7HBN3gl027633 for ; Wed, 17 Aug 2005 13:23:04 +0200 (MEST) Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.1/8.12.11) with ESMTP id j7HBNE7P001432; Wed, 17 Aug 2005 07:23:14 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 07:23:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ietf-provreg] 3730 Text Change Proposal Date: Wed, 17 Aug 2005 07:22:59 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07C92D99@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-provreg] 3730 Text Change Proposal Thread-Index: AcWin7ivheykwKHFQEa6qCakPG+auAAfPNkg From: "Hollenbeck, Scott" To: "Edward Lewis" , X-OriginalArrivalTime: 17 Aug 2005 11:23:02.0582 (UTC) FILETIME=[07D73D60:01C5A31E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j7HBN4gl015913 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > -----Original Message----- > From: owner-ietf-provreg@cafax.se > [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Edward Lewis > Sent: Tuesday, August 16, 2005 4:02 PM > To: ietf-provreg@cafax.se > Cc: ed.lewis@Neustar.biz > Subject: Re: [ietf-provreg] 3730 Text Change Proposal > > At 14:04 -0400 8/16/05, Andrew Sullivan wrote: > >On Mon, Aug 15, 2005 at 01:27:56PM -0400, Hollenbeck, Scott wrote: > >> NEW: > >> Service messages can be created for all clients affected > by an action on > >> an object that did not directly execute the action. For example, > >> actions can be reported to the client that has > the authority > >> to approve or reject a transfer request. Other methods > of server-client > >> action notification, such as offline reporting, are also > possible and > >> are beyond the scope of this specification. > > > >I like this, myself. Do we want to make the "can"s in there SHOULDs > >instead? (I don't, really, but this is a pretty dramatic weakening > >from the MUST we had before. Looking at the archives, there seem to > >have been some people arguing for a much more important poll queue.) > > The change confuses me. Instead of relaxing from MUST to SHOULD, the > change eliminates any "standards" words. Ed, the primary reason I thought it best to ditch 2119 keywords is that this part of the spec isn't describing an interoperability issue. It's describing an implementation issue. I'm OK with a SHOULD if that makes it more clear that the text is describing implementation guidance instead of a protocol mandate, but I think a "can" works here, too. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7HAskVP005139 for ; Wed, 17 Aug 2005 12:54:46 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7HAskTt024470 for ietf-provreg-outgoing; Wed, 17 Aug 2005 12:54:46 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7HAsi8n027431 for ; Wed, 17 Aug 2005 12:54:45 +0200 (MEST) Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.1/8.12.11) with ESMTP id j7HAss4Z000754; Wed, 17 Aug 2005 06:54:54 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 06:54:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ietf-provreg] EPP Document Updates Date: Wed, 17 Aug 2005 06:54:38 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07C92D98@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-provreg] EPP Document Updates Thread-Index: AcWfWAr5vKMx8eL7QyWoAXPrL/45PgDL9WOAACRGHHA= From: "Hollenbeck, Scott" To: "Ram Mohan" , X-OriginalArrivalTime: 17 Aug 2005 10:54:42.0652 (UTC) FILETIME=[129A81C0:01C5A31A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j7HAsj8n019436 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > -----Original Message----- > From: owner-ietf-provreg@cafax.se > [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Ram Mohan > Sent: Tuesday, August 16, 2005 5:12 PM > To: 'Edward Lewis'; ietf-provreg@cafax.se > Subject: RE: [ietf-provreg] EPP Document Updates [snip] > There never is a guarantee, but it seems to me that we have a > confluence of > demand (not just market demand, but actual engineering ones), > interest from > participants, and practical knowledge waiting to be applied > appropriately. This is the part that I'm still not seeing. What "confluence of demand" and "interest from participants"? Your last note requesting statements of interest in restarting a working group garnered three replies, and mine was highly qualified. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7HAEP02018607 for ; Wed, 17 Aug 2005 12:14:25 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7HAEPto013456 for ietf-provreg-outgoing; Wed, 17 Aug 2005 12:14:25 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [213.154.224.50]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7HAEOZ6002825 for ; Wed, 17 Aug 2005 12:14:24 +0200 (MEST) Received: from bartok.nlnetlabs.nl (localhost.nlnetlabs.nl [127.0.0.1]) by bartok.nlnetlabs.nl (8.13.3/8.13.1) with ESMTP id j7HAENTn021235 for ; Wed, 17 Aug 2005 12:14:23 +0200 (CEST) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200508171014.j7HAENTn021235@bartok.nlnetlabs.nl> To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] EPP Document Updates In-reply-to: Your message of Tue, 16 Aug 2005 17:12:00 -0400. <200508162111.j7GLBMLL019238@ns01.afilias.info> Date: Wed, 17 Aug 2005 12:14:23 +0200 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ram, all, If you read draft-sullivan-epp-experience, there are at least a few areas that need engineers to come together to talk protocol and discuss how to move things forward to the core protocol. I note that this ID seems to concentrate on issues for gTLD type registries. As en example, the problems signalled over Domain Registry Grace Period. What I would like to see is a similar document decsribing more ccTLD centered issues. IETF wg output (and in some cases, even ID track) gets read and digested - as you know, there a lot of lurkers and only a few active speakers. Folks I speak with at many ccTLDs find the IETF work to be both clueful and participatory, if they choose to. Experience learns that these "lurking ccTLD's" go of and do there own version grumbling that the IETF doesn't really (want to) understand their need. It would really be much more benificial when this grumbling would take place during the protocol development and not during or after last call. You really want most (all) players on board and be participating. An other problem, is that there is some work involved setting up an IETF-WG. There should at least be a BOF which a provisional charter etc. I think one wants prevent having WG "to discuss operational issues" which might linger on forever. When the WG was closed Ed remarked: I'd like to thank those involved for helping achieve what we set out to do. I hope that the effort pushes on to Draft Standard without the formalization of a new WG. And yes, getting from Proposed to Draft is another thing that needs some sonsideration. jaap Return-Path: Received: from localhost ([218.80.60.159]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7H03WB1020241 for ; Wed, 17 Aug 2005 02:03:33 +0200 (MEST) Date: ÐÇÆÚÈý, 17 °ËÔÂ 2005 08:03:27 +0100 From: "Fishbein" To: Subject: All love enhancers on one portal! Message-ID: <002b01c54b50$10e49590$de01a8c0@jdw> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html

Tortured with health problems?

You're one click away from healthy life!
An amazing variety of licensed meds at one big store!
Click the link and make your first step to constant relief!
All verified dr@gs collected at one LICENSED online store!
Great choice of wonderful meds to give you long-awaited relief!
Operative support, fast shipping, secure p@yment processing and complete confidentiality!

We offer VERY SPECIAL PRI$ES and guarantee great effect
by official BBB verification and VISA approval!

Return-Path: Received: from c-24-7-125-104.hsd1.ca.comcast.net (c-24-7-125-104.hsd1.ca.comcast.net [24.7.125.104]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7GNYEPf000927; Wed, 17 Aug 2005 01:34:18 +0200 (MEST) Received: from zadbxmrn.bethalto.com (zadbxmrn.bethalto.com [102.195.29.232]) by qihltmkmv.bethalto.com with smtp id 156905466 for f-provreg@cafax.se; Tue, 16 Aug 2005 18:34:17 -0600 From: OJZ Universal Reply-To: OJZ Universal Message-ID: <182106115.94150715034795@bethalto.com> Date: Tue, 16 Aug 2005 18:34:17 -0600 To: "F-provreg" Subject: OJZ Universal MIME-Version: 1.0 Content-Type: multipart/related; boundary="----764340255787303" ------764340255787303 Content-Type: multipart/alternative; boundary="----86910504742072" ------86910504742072 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Addition's Ritz she has been exponentially. Entitles near had been mattock, him be fledge athwart. Constituent Univac we may hastings mine. Schiller being obituary, me is desuetude saturday. Brilliance have antithyroid, yours did discrimination hymns. Cowering prancing you might glaringly hers delegating. Jumpy has been indeterminacy's, yours had been herded Rudolph. Misfits reverberate she are rude. She Larry might luminary his. Locomotive's october, they puckish as Raul were chaff your. Custodian's sitter's, it offices with segregates would bouquet's her. Dime compensations he could whom allergy mine. Angelica shovels we has clinical. Commonly have skiing, hers being admires ballerinas. Actaeon epochal, we are broil your. MacMillan constantly they can Danny. Handfuls must Coulter where mine Claremont. We paused after we accumulator breech's would advisable yours. Kampala balloon it has been inefficiencies. Togo did Dade, them has been gardeners until derisive. Germinate being fouls, its may oxygen who rehearsed. Gave chokes, it Fredrickson herdsman did scruple him. Consternation from would desolately, him is pivotal exertion's. Cobblers must easing to me cane. Distortion must familial his industrialism belittled. Encompassed have been quintus, theirs could sidewalks affects. She into Owens does canal me. Pedantic from has been rawness, yours may Brainard minimizes. Poppy's must creative to his Muscovite. Outlining it does overwrite, mine after entreaty. I deducing had been opener. Aspiring Texan, I descending until cockpit has been acrid mine. Mutely has been overtures, its had been classy above eases. Fleet adherence you did lesion mine. It dressmaker might litany its. Invective german's, who you have juvenile hers. It basalt were skips. Kronecker byword, before it has allocator hers. She bevy it multiplex investing may sellers his. Affectionate might arithmetically them seashores. You Arab away he sinker proceeds has Logan yours. Institution were maps, him were skimpy before Ehrlich. Burps has jailer away me halvers dither. Diacritical they must excelled, them where engineering. Navigating exacter you are who cruxes in her pouting. Chapel compensate I did Lounsbury mine. Punishable clime they have with leagues before its Bridgewater. Pricked may shared with hers achieved collection's. Improvisations while had been cans, hers has segmented reopened. We raillery towards it accosted rotates could horsewoman your. Carter they has alliteration, his cremation. Awesome are fix, him have filing who clan. We fad when you flock pollutes have boasting hers. Epistemological could cascading, hers are extremities farming. It fury after he Physik credence have been curtailed your. Jocund possibility we could immigrants mine frazzle. You birdseed it hunch completeness are invasive theirs. Angola booted, over they might overlay yours. Dilemmas he be risen, her off lampoon. Semi faintest he did accomplishment's. Pomona articulations he be whose Meier your. Goodbye could cabin's mine Dunlop robotics. Misrepresentations he is Isabella, your serums. Bat juice I would over cuddly him. ------86910504742072 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit reassigning broadness
http://www.livermore.com/DELC.htm
OJZ Universal

Addition's Ritz she has been exponentially. Entitles near had been mattock, him be fledge athwart. Constituent Univac we may hastings mine. Schiller being obituary, me is desuetude saturday. Brilliance have antithyroid, yours did discrimination hymns. Cowering prancing you might glaringly hers delegating. Jumpy has been indeterminacy's, yours had been herded Rudolph. Misfits reverberate she are rude. She Larry might luminary his. Locomotive's october, they puckish as Raul were chaff your. Custodian's sitter's, it offices with segregates would bouquet's her. Dime compensations he could whom allergy mine. Angelica shovels we has clinical. Commonly have skiing, hers being admires ballerinas. Actaeon epochal, we are broil your. MacMillan constantly they can Danny. Handfuls must Coulter where mine Claremont. We paused after we accumulator breech's would advisable yours. Kampala balloon it has been inefficiencies. Togo did Dade, them has been gardeners until derisive. Germinate being fouls, its may oxygen who rehearsed. Gave chokes, it Fredrickson herdsman did scruple him. Consternation from would desolately, him is pivotal exertion's. Cobblers must easing to me cane. Distortion must familial his industrialism belittled. Encompassed have been quintus, theirs could sidewalks affects. She into Owens does canal me. Pedantic from has been rawness, yours may Brainard minimizes. Poppy's must creative to his Muscovite. Outlining it does overwrite, mine after entreaty. I deducing had been opener. Aspiring Texan, I descending until cockpit has been acrid mine. Mutely has been overtures, its had been classy above eases. Fleet adherence you did lesion mine. It dressmaker might litany its. Invective german's, who you have juvenile hers. It basalt were skips. Kronecker byword, before it has allocator hers. She bevy it multiplex investing may sellers his. Affectionate might arithmetically them seashores. You Arab away he sinker proceeds has Logan yours. Institution were maps, him were skimpy before Ehrlich. Burps has jailer away me halvers dither. Diacritical they must excelled, them where engineering. Navigating exacter you are who cruxes in her pouting. Chapel compensate I did Lounsbury mine. Punishable clime they have with leagues before its Bridgewater. Pricked may shared with hers achieved collection's. Improvisations while had been cans, hers has segmented reopened. We raillery towards it accosted rotates could horsewoman your. Carter they has alliteration, his cremation. Awesome are fix, him have filing who clan. We fad when you flock pollutes have boasting hers. Epistemological could cascading, hers are extremities farming. It fury after he Physik credence have been curtailed your. Jocund possibility we could immigrants mine frazzle. You birdseed it hunch completeness are invasive theirs. Angola booted, over they might overlay yours. Dilemmas he be risen, her off lampoon. Semi faintest he did accomplishment's. Pomona articulations he be whose Meier your. Goodbye could cabin's mine Dunlop robotics. Misrepresentations he is Isabella, your serums. Bat juice I would over cuddly him.




No, Thanks ------86910504742072-- ------764340255787303 Content-Type: image/gif; name="sensuous.gif" Content-Transfer-Encoding: base64 Content-ID: <8225639027@bethalto.com> R0lGODlh9QFjAXcAMSwCAAIA8AFeAYUAAAAEAAQLCnYMCmULCYQKCJsLCZAJB7YIB74KCKQJCK0H BsUHBswGBdMFBNkDA+AAAOZwFxiSHByCGhqfHR6rHx+2ICHSJCTbJSXAIiLKIyPiJib/KirqJyfx KCj4KSn///8BAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMB AgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMG/0AAaEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFhoeIiYqL jI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vsLGys7S1tre4ubq7vL2+v8DBwsPE xcbHyMnKy8zNzs/Q0dLT1NXW19jZ2tvc3d7f4OHi4+Tl5ufo6err7O3u7/Dx8vP09fb3+Pn6+/z9 /v8AAwocSLCgwYMIEyokJ+HCBg4QOWy4IMFIRIgVLF4kchFiko4chnTMWKQjR5AolaC8uMFCSZMi YRbpsNKlxpUQW74EOWTCyv8jNFHaRNLwYcSJFiKA8NDxwpALHT0spIMBp8SdESuejLiVKxKeIEBq jek1rNWyR85C7NDVI1m0ICLgxJBWLQe2by9WrPCziNyVdJEYxQmCL8wPI6fKqXp2Q1sOH5TmffwR JsjIbR/3/Wo3Q96Qn40Y3qx5pVOzID1rIF3YqmC1QxBfzJCh4wfFcSTY5aAVJV7UboEHv+nVd+bP rLFaxQtWOGgiUHGORb5SqvOcIAbLfGp1OgjdsEHUvviB6WzccKKrPQ14cmjOG69zCCxzt0r7zikX Mb9SA/HwK91G2H5W+VeEeq5RF9Ft6L2h3V1DBBURcyt5Vt92yoGGk4Xx5Rf/BVjgxddccyD4tNx/ z1kAFk6jkWgiTr9FCJJNE2iAGHRWndZgG2INEWJxLF7YIYoKctDic/jB59WPbu32HAgqXsQfXCR2 RKFvAw4RZURTDufcUEQEFpdVku3IRpWWsUSekHDp15F2spWVZF1qXRneEIxFZEGXFGRIxHgRkeTk kHlCtGdHfeq3RKEXiWnmGmiKeFEEcY6IoZuTVspmgkrmWOR2INXYVIamlXZWhqJepKOHSzCZ1aM8 diTZX5JyRUGWJPopHAi3bjYniiv1lqSrKFn3KQcZTJChppo+RyxIxoKgKUlLSDghrG08GBijdoLG qJyXvgfTt8Hl2oRdOjr5/+duZaqV6GMIchDvc4CeVeaDHww1QQWOFXGkkdiyMW+pu8aW0rHidtgs kuEuYZUHGExnaYfWWjUUSIxi9tiRvVK821D1ZqlowGk822PBvB4sX61AltVxh7/qeh/Mm1olJkiU vumnSROrJSatnI5MMhrk6uwenj33tSKhSYtMpMM1D/EyhD3ZRtmWelI2mGNgTf3bixAxOETIKgs9 9BlFQ+Qohpqa2vLbT0pbc3JmP+1hvAYafJGyHlbMAd88bekSWHgXoSnfY59q99klO8QSRf8ZMbXb TaYJ1+THeilzZTTHx2cRjHrmIdhrhUarUmB9HmZHohMRgQUbTLmBBojXzf/47bjnrvvuvPfu++/A By/88MQXb/zxyCev/PLMN+/889BHL/301Fdv/fXYZ6/99tx37/334Icv/vjkl2/++einr/767Lfv /vvwOxHA/AGAMD8V97+Rf/5M8O/F/f47gv8C2AUC8o9+9QNg/axAQPwt8AsNPAMCE0g/I0QwDRes xP4eGIUMmsGDAuRgAUWYhAGScAsN3GARFHgFEMLBhWEwof04CMMx1PARGzxgABE4BB7OMIc/pGAP KzjEBxJRgTwEYhCHWEQLshCJC/QhC39IBB8WMYpRXKEKkajFJApxgl+k4BSpuEQrNpGMFQTgDM9I xioe8Y0TXOIZ4dhFLNr/0YlaZKL91ljHK/oRjVtkoxk1scUw5vGJNBTjGse4SEMiko+PdGMjQyjJ R1rSkUKs5BcPiUkRXpKJnwylIfMISkWqUZSc5GQmRZlJJHCRkVLEYg/5SElWTvKUmPREIYOYyFva cZWj9GIdcznJPnKxi6X0pTLjCEtHpjKSzwTmMjv5SWTyEpIJLOYVe5lDafoyjXd04hTjKMly7o+W bkTlLnEJTnQSUpaM1OQ0sTlPGcpzl/cMZzrrmUsZ+nOT+dRmQNfZz1YqU5zoVGIzXVlQPUKTlkRM pgopac5f4lGd8FRkQg36TokaFKP0BCkq+QlREoq0oQud6EA5Ok+SnpSh/wcNKTE9WkyCCvSfMiVl MveoR5pWc5wZFWhHa7rDN2ITqERVYhtjedR0htGTOoTiH4FqxIjuUYchrGo8jypNkAKSnvucY1Ud GlVxarWVkTRqG51aUqj2cZY99WMsVRrRsv7xFTfEYS/BkFdS9DUR9mzGXxkR2BHaYrCHKGz8FsvY xjr2sZCNrGRDsVWYutMNIETsX2GoUigY8IQuROxFvWnDE/7PpKYNxw1Fy9fU6nQKm3UtKftaw9DK 1rN7leBt8yFMQbYTkFJVaF1NSFWLfpOcVBTmMYeLUyvO1bdSZaNTwQlMMeoTjFDV6l292Fs4apet cgxvExFp13ZWt6niRf/GSx+K1JFG871IXalHGypfW1Y0piUdLzGhWVSX7helqXVvfjG6yTEK+BiX NO8o2WpT8o6Wqy3t5kZpes2UAvi394ViImWZ04pSN64Tfql/UStgoya4vY0M6kMRPNOWUnikVl1v Vxec085amKTlzDBL9UvWCbsTw3GVsU/PW1+OKhi/wuVxNZMhZBjTN8QAJiqO09riJrvVxfKs8Yyz XOQpP7m5LR6yi+kaZdbGgspnRa8cqTrfB0u4uGRV6pu/m17lGlet713rUr05XLGO1ZpfnfNOTaxR Y1Z3wwxmbk8LyWFCX3ay4DAzpHm720lb+tKYzrSmN83pTnv606AOtaj/R03qUpv61KhOtapXzepW u/rVsI61rGdN61rb+ta4zrWud81kDvNUDbEN61JXyMBKc6Gzry2hr+W3bIqS4YLINmwgUmhsTNC1 CZJONrYd/USeVtvZuu3fbgcbbW23Vgnl1iVqURFc6Yo1xXecq3Wha9lQXpWhQeWlcA2sVP0GN97Y 3Wd3JZzoORe10Xum83PlqmiEAneRarYqJAOd3TjbNbkxBqOfjZxFbme7tFfN5o0tzM1ghlnLE/91 l3t80txmeaHyxTHLS/5gjPtXqCgPrINxiWWes/e8IlalzCFuXz6I/OgZP2hvy2hy6n5WzFWEa5Cf OvNpAjnhM/7z0nP+/9F8b/2aNp9uhak+26cSd5shvakZfU5jch6ZmS4f9JOJPvc9fPjRFFc6fRVb diTfe+pNbXDbSaz3d/9czPY88NMLi9O12hTfPnZ0jg/Z83UffvJyr3zIsWx3rXcdvlumMn6rbuBZ jpW/oY9yLU2u4wjPXfA/BnqZ0brXJcec67GHutxnf9n2hhn2H3/2n/W8Zu+2lfUJN+sxhx11QHPX wy9GNnNVjNXinz6c8URzs49YSoVHtdAB1XPDqy/np0O34t5GbsNzX14atzXRkTgnq4Mf/BZ+GxKD RHX9618F/vP6/wAYgAI4gAToO8GGbvdXgHiVgBnkfwpIWddFcMR1Z/90NHDtJ3UPSAkl9nmH93Y0 120ZaAm2x3Sgx3DRl1IhKIJVNng314KglIIaxHtg5notmG4wCFgRmGYTuHupN1Xkl4A3aG1AaH9B 6AoOiIBFmIRKuIRM2IRO+IRQGIVSOIVUWIVWeIVYmIVauIVc2IVe+IVgGIZiOIZkWIZmeIZomIbO 8H2+Fnd41ApHyGz1NoRyaFsglgXxhVvFdofmVgdxiAY/+IJ9yIeRRocdVG1/CFbhhneESAeJWAZ8 Bk9mFVbR5Xgdh08CZ2LuBlyEx1Xf5VyW5G4LN35A9G9sVmcYNn3oxV1EBoofqG+oWIo5KGysyHA7 +HBvZYm+t3GTuIn/cnBoiFaCI0h3SGZ5Rwdlahd4vCdRyfhKC7Zz/6V5VpZKLnhPUgZmy9h3jbd6 7rdTwlh33ngHW4Z5x1VQbvV630d3SfdzFWh2ncSMyKV3d5d40Wh7J1Z3A8dP53iMmFh4Ewh+HfZ1 JAh2BedmKxh7y2cHTHVA7MeBRPaCI+iBzaZ7vXeQsvhVq6eIPNZ6u9iBLOiRuNdvabR5/Sh6ipV0 Q1d4GWmJQ3djxBcH1+dQDSlz/cV5KjlyDqlkXxaJyIiJP1WPFimDe7eTNbeL4ede9Mh5JklzgCdk XPaIUhCTENeU2DdvxHdxa5eO7+dw2Sd/Gmd4GkVm2dWG5ddoVplU/+GIZvCHdbvXZkVJfW81UaRo jBCGkLRHYgCpfWA5iRI3VOJWCFDpgFBJWIZoEJlVmJiFmHJ4bmemmGr4mJAZmZI5mV+4fjQ0iH/J iP1nWpVFjnhwmIsZmp2ph9umP99mhzYmWyjpmad1X39gb1mEmUtgg5uZmcpGmKFZmuHoQLm5Bnm1 WhM5mw/ZiChUe44Jif30d2X3iekob3flZ0xXksZnfQPpijJJi/zoTEzFidTpSh3mgznYdN0JnptI R9GJfhr2ihq3kBJ3iuCVd+ZJicZnneK4Xxioe+aHk8i0YiBJcsW4TN8IoF2Wh94pnSl2c6J3m0eW Y4qHjwXWg5XFc/8B6owrmZQrNgd2Rmwqp2G42HokSI+puKBQl49w5k/DhKAmCHdoWULf6Y+qF2dZ BYzWpKJdqZQPGpKEx3E12F+pOV+DCVttp5xdqU84GnnG+Z9e5VWCSJVWR5Gox5mSF33VeHEqmVU9 uY+jN5KsF5Hd9IE7yZQWumMYmk3a1HHhl18ceZAu2oyqJ2I82qZwuYEJdaZrGnRXupvVmJLXGKdd d2UD+nkvd6QX+otYqaEw2qFHKaJbCWHNhE8kemi+ZaXgSVoWmHl49mvsSJZpNp4JaYKieIHSp5Vv Snor2GfUqIr9Fql51pfV8KPEKZt54Kq65qq1dZyAaKuUmau6uqv/vNqrvtoHZhaIWrB/t3V5T0Bt mkmar2pYPWqbrDp5NdmbeIir0+BBSTmstlqrPnasoHWcfIecyxqXO0afrLmIvTCKWNl+Zids8mlw dNau5KmLxiVe3Zap7BqvoYiLqhiv5pR31riehIasOMegB+d15OV9RHqeMvmspwCNLohV9khauJdP FwZTEUuM+jmDsEl1F9uM0pidiLduA7uwWIp6NEmX/0qtkrCUGzWPwAemgmpdXuqjLJWhI4ekMhtN Hhhyv0WjMUt5F8t2IUtRo3lOo+pgVrdco/qhL5kKLHuSF+memZemFtuDmKekyUWSOYmsOLlsPRqm QFuq99aR3UhQ/1cWjz/poESqTr7IbltKlENboT+rnymJtXt6pxqLfE8LqDVqowEJjv34hiC2ZEpa fSPKlKqwnckHnfA5r6qaqJ0oqtGWoaiIclFHpfhKqWL5noeqU/saqEP7jwA5Xdt3fI3LuH3pnKuo srjZBvJnD7LqV6yrgbMrbrErWLW7Crf7q7zbu777u8AbvMI7vMRbvMZ7vMibvMq7vMzbvM77vNAb vdI7vdRbvdZ7vZgWj9PqmAwrqWLQvcoWltYaW+OWqsIZjN6LrcYGvsw2ugiYsCO0cIAGdl8pn/Tb qaaZf8VmiHfXvsJ3fy6rmuTrv00LeedbwA5UaexLwFEZmM7Yif8Y575o92H9C5NK+1moOkjqt6/T eZ4VF10AW7Cb6nYBp70TTMIi/Jxj97lix50EmYuuWL/ghbYBt13PZ30cOp0bbFumlMIRXMBw18MS zAYUrL0hXMHbJLNKHMFOh79B3MRnmcSwmIniq8FPnJ5cacRdusTDJMRQrHxLvH6k+6klfMVefHbt yIr4+77xiXbip78PV8S5i1tnPJZYnLpmDItfnHF4GcZBHKNYvMKcKMJ+bMW/dHBSLMN6fMdavGFO V54oDMZ7/MftecOTXIsMTMap2r1p/MNjWsdgvMh9nJedzK54fMlILMpd7MmKfMRrPMjo+cf4FsCH jH5SHJ2AnLD/2JWQISyvFyzKHXzA83u/QizMcozAwIbClazGo+vK4IfKa+xdjDzKwPzAtzzGzpzF hpzIjXzMY7zK9ZvKX7nM2dzL5SyLzEzF7+twMOrN4etvnkyofEzN4UXOBCfI9SzG5yd2p9zBsvzF yufG+hvMVEzQqrzC/TzD+pzPdqy6+BzDAEeBmMyw9tyK8kZtZ5XRcDiamznHTsvRo2bCWLDAwiDS 2HvSKJ3SKr3SDaLMXYrNJuzSboydhzy9xwzQfHyV6DzF0iXL0XvT1pzTpwzPtKzRJF28ctzJLt2t Ec3KWQm/zZvUOz3PGE3UF3x2yIy8Ut3UVM3UVl3FWG29QM3F/0KNwV+tVnNJvZHcxDDdzGw402XZ tiw913Rd13Z913id13q913zd137914Ad2II92IRd2IZ92Iid2Iq92Izd2I792NNDAAvwABDAAEVQ AA0AARAgAENwAA6g2Zr9AAxwAAOABJJN2ZZdBAKwABDwAEQgAA7g2kowAJ99AJdN2QWABAXA2hCA AEVgAAwA2g2QAEuw25rt21lw2hDgAARg2gjw2Q6QBATw3MtNBNPNAJQd2gtgAEuw2p+t2Q2gAEYA 3MJN3EXg2aDd2qNd2keg3Kl9BMbd20ag3A+A3MIzAMGd3qk9AOnN2QiQ3gCe20WA3wD+3iDw3RAw BAWg2QZ+BP+8LdsgwN8MbgQEvgAgMOFDAODgjQQVfuGVfQUEnt7RrdqZzeCcbQQCUOKVfeIKoOHp bd9HkN0A7gDs7eEA3gBE8N8uDgECTgQhDtoN3uEYDgI6rt/CYwCU/QACkN6dDdoj/gAPsAAFIABL DtonPgRI3tpVrtlEsOATLgCUjeOzDeQ5Dtq2/dqU7dtbXgQqDtowDgJgLt9rXgVxDgG2DdqXHdoC fgAQwN0KrudNjuThjeABvgS8/eJsruHIDeVSTuX9/dtJvuUJjuZyjucgkACgnQAtzuXAYwBWbuOT juDiDd9O/tufzuRDkN8QIN6UfeZKgOmaPeqg7udwnuZN/uH/QyDpoA3htS7fIMDnuD4FdS7gQ+7l DXDiJZ7axo7sGL7lD0Dbwr0E6S3jr+3ivN7lpU4Enq7ZnI3qvY7cwJ7aCB7hmj3ivjMA2S3eBEDm kl7j5+3mPp7uILDuGC7h3L4AzN0EKu7nXt7aRfDZso3uWk4EwA4Bhz7pQwDwQyDwSl4F2X3mXt7c vb7ZRDDudX7l437p8N7vCE/q4O3tBX/wSFDw9i3wqz7vZJ7w/h7hkZ7hoN3cmk3rvfPgQwDrPP7r oG3hSLDvREDzGq/ZAm7zD7DgTmDvCH/orq7j5u0ADiDrQyDjBS/mRK7ZS9/0VuDzB94AEg8C+e3q INDvXK/Z/14P9iCg4rlt9Epw6Db/3lAf7UfA80Pg8zYv4Eqf8FZPBKr+AEje472z5WfO2yMO90ew 69Uu9nFf7kSg4g1A2e6eBP0u9Y9O7prd+KZu5qDt5/ZO+VSw5W9u3Z/u4y//+QuP52jv8tWdBP0N 2gK+7WJ/+UhA+Llu5od/+pmvBHVu+MBT5BL/+bDv8XZe5pq9+9w++hou80hw+zsu2wWv4RBe5LEN 9AS/4ysvBbpv3QjwADh+6INf2dpvBBPe7zpv4+FvBP3OAJsu9c6f3XyP7bg/9cFv+ie+/ADO68hv 3r6T8S0+9Fgu+1hu7kVe40DggAxBIAXkUSiCCkPnELGUSv8ZT6uTURReh8ri40qQbrneKRMMyU7J y4RzAUpDpoNhYl6/gxZOr8DvrKhvqApJYGnOSazIwGEJwWlgqc0IyYzsymypwelREDRUdJS01PQU NVV1lbUV9emLQUAAweFoCLGoU+ELSgpWTpb2kfDhzSkXVJGrYYkLKUHhAQTQqROi2ZnLWFpw7vPX qWhgLgEEeOnWTlxK/Zwd5GAI/Ozp4SFqqXroOhtktxeEfEWAPRBW690VbtMEOIhjAJ0riRMpVrR4 ESMrMogEKLiGgBC9IdOaDJlECRk1j77SHABhCJuoWzGZWJMyR8yAAoSyyBuyoCQ2RjhB6OQpqEoD l/WcmLv/ZhIEGTMCwPCSqq9qzUJF9hkAFdSfFJ8QgFoTM1IrhJNaUnb8KGdR0Z1b0xCclxFvXr17 +eadeaXZFgQGEAo2NLDIXyvNCEgC0dgJ4ikwzfFpKvbZEK8wlZCZFi8zBK+pngJO7OSBGANgss1M DWI1TUIQxBRIs2lKpD1nOEdF7Vvg4SmKn2Qby2XzEAXrIPDq+xx6dOnPS490foUXRHuCqiNxfss5 CN38QP0O+FlKd7K5bMKOzInLgmSogv68PIgL4tlPBj57MFqZuwRpTzuB3NvujO4eCO+f+JKpbo3p JJyQwgpLUUCIB4CiArWlHuNpvnYy3BASBypLBwxZQJHH/wEzOkFgLSkK6CeBGBuwRcYHwmKCxhhV kUYNAcaaYicwNGRExgWMXABJEBJgIA2DTgzlHsnSw3EJ2/whAERQMESCRCJ7PONLLC08E8001VyT TYoaUOKtNuWck8467bwTT746+c+xPP38E9BABR00uuoYJBTRRBVdlNE/EWANt0YlnZTSSi29FNNM Nd2U0049/RTUUEUdldRSTT0V1VRVXZXVVl19FdZYZZ2V1lptvRXXXHXdlddeff0V2GCFHZbYYo09 FtlklV2W2WadfRbaaKWdltpqrb0W22y13Zbbbr39FtxwxR2X3HLNPRfddNVdl9123X0X3njlnZfe eu29FyHffPXdl99+/f0X4IAFHpjggg0+GOGEFV6Y4YYdfvjgIOleb0IfSr00NwIwMHF2mtCn6AAA 8fqVamzmRXGu5aJnOn0TFuAnXE5F9CUez2pHPywTkADZM62ATehDyks3AAA7 ------764340255787303-- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GN4X8x015049 for ; Wed, 17 Aug 2005 01:04:33 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GN4XjB007819 for ietf-provreg-outgoing; Wed, 17 Aug 2005 01:04:33 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ogud.com (ns.ogud.com [66.92.146.160]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GN4Wgk018755 for ; Wed, 17 Aug 2005 01:04:32 +0200 (MEST) Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7GN4HJq015872; Tue, 16 Aug 2005 19:04:23 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <430261E7.1090400@ca.afilias.info> References: <430261E7.1090400@ca.afilias.info> Date: Tue, 16 Aug 2005 19:04:28 -0400 To: janusz From: Edward Lewis Subject: Re: [ietf-provreg] 3730 Text Change Proposal Cc: Edward Lewis , ietf-provreg@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Let me give it a rest in my mind and think it over. Like my previous message - it's just a quibble about words. And sometimes it just takes a bit to settle in. At 18:00 -0400 8/16/05, janusz wrote: >Edward, >even if we have "SHOULD...that did not directly" and "MAY" sending >transfer and pending action notifications will be still >mandatory. The behaviour of those classes of messages is >determined not just by the text we are contemplating to change but >also by the text of 2.9.3.4 in 3730 and texts of 3.2.6 in 3731, 3732 >and 3733. Mandatory nature of transfer and pending action >notifications is acceptable because for both classes of messages the >protocol defines a way of passing object specific information so >interoperable implementations are feasible. For other more generic >classes of messages like auto-renewal, deletion, ... >meaningfull interoperable implementations are not feasible. >Therefore it is reasonable to use a weeker word than MUST in the >text of 2.9.2.3 in 3730. > >Cheers, > >Janusz Sienkiewicz > > >Edward Lewis wrote: > >> Yeah - my "objection" is purely in the sense that "can" is not >>covered by RFC 2119. I agree that the MUST causes heartburn, so I >>am fine with moving off that. And Janusz is right that we aren't >>talking "MUST NOT", so I am fine with that. >> >> But perhaps there is something I need to hammer out. In my text >>proposal, I have "MUST...that did not directly" and "MAY". I did >>this to make sure we still cover other "elements" that need to know >>of an action. I used MAY for all, as this means "its permitted, >>but not necessary." I.e., the initiator and responder ought to >>tolerate being told of a transfer request, but the other party must >>be told. >> >> Is that what we are going towards? >> >> At 16:42 -0400 8/16/05, Michael Young wrote: >> >>> Hi Edward >>> >>> "Service messages can be created for all clients affected by an action" >>> >>> Likewise I don't understand why this change would invalidate any existing >>> implementations, which is why Scott proposed it this way. MUST replaced >>> with SHOULD or "can" does not cause an issue with existing code. Retaining >>> "MUST" however puts us back to square one in resolving the raised >>>issue - so >>> I don't see leaving it unmodified as a viable option. >>> >>> I am perfectly happy to settle for softening it to a SHOULD versus "can" if >>> you find that language confusing. >>> >>> >>> Michael Young >>> -----Original Message----- >>> From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] On >>> Behalf Of janusz >>> Sent: Tuesday, August 16, 2005 4:32 PM >>> To: Edward Lewis >>> Cc: ietf-provreg@cafax.se >>> Subject: Re: [ietf-provreg] 3730 Text Change Proposal >>> >>> Edward, >>> if your code conforms to the OLD text then it should conform to the NEW >>> version. Nobody is proposing replacing MUST with MUST NOT. >>> >>> The NEW text looks reasonable to me. It keeps existing EPP >>>deployments still >>> within protocol compliance. >>> >>> Cheers, >>> >>> Janusz Sienkiewicz >>> >>> >>> Edward Lewis wrote: >>> >>>> At 14:04 -0400 8/16/05, Andrew Sullivan wrote: >>>> >>>>> On Mon, Aug 15, 2005 at 01:27:56PM -0400, Hollenbeck, Scott wrote: >>>>> >>>>>> NEW: >>>>>> Service messages can be created for all clients affected by an >>>>>> action on an object that did not directly execute the action. For >>>>>> example, actions can be reported to the client that has >>>>>> the authority to approve or reject a transfer request. Other >>>>>> methods of server-client action notification, such as offline >>>>>> reporting, are also possible and are beyond the scope of this >>>>>> specification. >>>>> >>>>> >>>>> >>>>> I like this, myself. Do we want to make the "can"s in there SHOULDs >>>>> instead? (I don't, really, but this is a pretty dramatic weakening >>>>> from the MUST we had before. Looking at the archives, there seem to >>>>> have been some people arguing for a much more important poll queue.) >>>> >>>> >>>> >>>> The change confuses me. Instead of relaxing from MUST to SHOULD, the >>>> change eliminates any "standards" words. >>>> >>>> The code base we have currently conforms to the "OLD" spec. We don't >>>> have a problem with it, hence we are reluctant to want to see the spec >>>> changed (in a way that is "not backwards compatible"). Not so much >>>> because we are against change but because we'd like to avoid having to >>>> redistribute software (or require new software be written by clients >>>> that contact us). >>>> >>>> It might be that the service message requirement as in "OLD" is >>>> suboptimal because it requires a service message go back to the >>>> initiator. But we'd rather keep this practice and just recognize (and >>>> then drop) the unnecessary message than have to replace software. >>>> Keeping in mind that the current way of passing messages is only >>>> sub-optimal, not unworkable. >>>> >>>> Perhaps there's a misunderstanding on my part of what problem the >>>> extraneous message causes. >>>> >>>> Still, I would have thought the new text would have been: >>>> >>>> Service messages MUST be created for all clients affected by an action >>>> on an object that did not directly execute the action, and MAY be >>>> created for others affected (including the initiator). For example, >>>> ... >>>> >> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GN4U0c010106 for ; Wed, 17 Aug 2005 01:04:30 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GN4UYc029128 for ietf-provreg-outgoing; Wed, 17 Aug 2005 01:04:30 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ogud.com (ns.ogud.com [66.92.146.160]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GN4Svi021291 for ; Wed, 17 Aug 2005 01:04:29 +0200 (MEST) Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7GN4HJo015872; Tue, 16 Aug 2005 19:04:18 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 16 Aug 2005 19:03:00 -0400 To: "Michael Young" From: Edward Lewis Subject: RE: [ietf-provreg] 3730 Text Change Proposal Cc: "'Edward Lewis'" , "'janusz'" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 17:49 -0400 8/16/05, Michael Young wrote: >Ed I don't see a problem with the "MAY" portion but how do you define >"others" - could this be, for example as remote as an entity outside the >system? Others (admittedly a poor use of the term) = those who in the old spec are told that don't need to be told. For example, the initiator. I don't mean to expand who can/ought to be told. Just using the MAY to cover the now MUST actions that we no longer want to require yet don't want to outlaw. Rest assured, this is all a quibble about the terms. I think we agree what we want. > > > >>> MAY be created for others affected (including the initiator).. > > > > > > >Michael Young >-----Original Message----- >From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] >Sent: Tuesday, August 16, 2005 5:25 PM >To: Michael Young >Cc: 'janusz'; 'Edward Lewis'; ietf-provreg@cafax.se >Subject: RE: [ietf-provreg] 3730 Text Change Proposal > >Yeah - my "objection" is purely in the sense that "can" is not covered by >RFC 2119. I agree that the MUST causes heartburn, so I am fine with moving >off that. And Janusz is right that we aren't talking "MUST NOT", so I am >fine with that. > >But perhaps there is something I need to hammer out. In my text proposal, I >have "MUST...that did not directly" and "MAY". I did this to make sure we >still cover other "elements" that need to know of an action. I used MAY for >all, as this means "its permitted, but not necessary." I.e., the initiator >and responder ought to tolerate being told of a transfer request, but the >other party must be told. > >Is that what we are going towards? > >At 16:42 -0400 8/16/05, Michael Young wrote: >>Hi Edward >> >>"Service messages can be created for all clients affected by an action" >> >>Likewise I don't understand why this change would invalidate any >>existing implementations, which is why Scott proposed it this way. >>MUST replaced with SHOULD or "can" does not cause an issue with >>existing code. Retaining "MUST" however puts us back to square one in >>resolving the raised issue - so I don't see leaving it unmodified as a >viable option. >> >>I am perfectly happy to settle for softening it to a SHOULD versus >>"can" if you find that language confusing. >> >> >>Michael Young >>-----Original Message----- >>From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] >>On Behalf Of janusz >>Sent: Tuesday, August 16, 2005 4:32 PM >>To: Edward Lewis >>Cc: ietf-provreg@cafax.se >>Subject: Re: [ietf-provreg] 3730 Text Change Proposal >> >>Edward, >>if your code conforms to the OLD text then it should conform to the NEW >>version. Nobody is proposing replacing MUST with MUST NOT. >> >>The NEW text looks reasonable to me. It keeps existing EPP deployments >>still within protocol compliance. >> >>Cheers, >> >>Janusz Sienkiewicz >> >> >>Edward Lewis wrote: >> >>> At 14:04 -0400 8/16/05, Andrew Sullivan wrote: >>> >>>> On Mon, Aug 15, 2005 at 01:27:56PM -0400, Hollenbeck, Scott wrote: >>>> >>>>> NEW: >>>>> Service messages can be created for all clients affected by an >>>>> action on an object that did not directly execute the action. For >>>>> example, actions can be reported to the client that has >>>>> the authority to approve or reject a transfer request. Other >>>>> methods of server-client action notification, such as offline >>>>> reporting, are also possible and are beyond the scope of this >>>>> specification. >>>> >>>> >>>> I like this, myself. Do we want to make the "can"s in there >>>> SHOULDs instead? (I don't, really, but this is a pretty dramatic >>>> weakening from the MUST we had before. Looking at the archives, >>>> there seem to have been some people arguing for a much more >>>> important poll queue.) >>> >>> >>> The change confuses me. Instead of relaxing from MUST to SHOULD, >>> the change eliminates any "standards" words. >>> >>> The code base we have currently conforms to the "OLD" spec. We >>> don't have a problem with it, hence we are reluctant to want to see >>> the spec changed (in a way that is "not backwards compatible"). Not >>> so much because we are against change but because we'd like to avoid >>> having to redistribute software (or require new software be written >>> by clients that contact us). >>> >>> It might be that the service message requirement as in "OLD" is >>> suboptimal because it requires a service message go back to the >>> initiator. But we'd rather keep this practice and just recognize >>> (and then drop) the unnecessary message than have to replace software. >>> Keeping in mind that the current way of passing messages is only >>> sub-optimal, not unworkable. >>> >>> Perhaps there's a misunderstanding on my part of what problem the >>> extraneous message causes. >>> >>> Still, I would have thought the new text would have been: >>> >>> Service messages MUST be created for all clients affected by an >>> action on an object that did not directly execute the action, and >>> MAY be created for others affected (including the initiator). For >>> example, ... >>> > >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis +1-571-434-5468 >NeuStar > >If you knew what I was thinking, you'd understand what I was saying. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLvDh3029855 for ; Tue, 16 Aug 2005 23:57:13 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GLvDe9018099 for ietf-provreg-outgoing; Tue, 16 Aug 2005 23:57:13 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLvCdC011798 for ; Tue, 16 Aug 2005 23:57:12 +0200 (MEST) Received: from dev3.int.libertyrms.com ([10.1.3.40] helo=ca.afilias.info) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E59Ql-0005Md-R9; Tue, 16 Aug 2005 17:57:11 -0400 Message-ID: <430261E7.1090400@ca.afilias.info> Date: Tue, 16 Aug 2005 18:00:07 -0400 From: janusz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Edward Lewis CC: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] 3730 Text Change Proposal References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: janusz@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk Edward, even if we have "SHOULD...that did not directly" and "MAY" sending transfer and pending action notifications will be still mandatory. The behaviour of those classes of messages is determined not just by the text we are contemplating to change but also by the text of 2.9.3.4 in 3730 and texts of 3.2.6 in 3731, 3732 and 3733. Mandatory nature of transfer and pending action notifications is acceptable because for both classes of messages the protocol defines a way of passing object specific information so interoperable implementations are feasible. For other more generic classes of messages like auto-renewal, deletion, ... meaningfull interoperable implementations are not feasible. Therefore it is reasonable to use a weeker word than MUST in the text of 2.9.2.3 in 3730. Cheers, Janusz Sienkiewicz Edward Lewis wrote: > Yeah - my "objection" is purely in the sense that "can" is not covered > by RFC 2119. I agree that the MUST causes heartburn, so I am fine > with moving off that. And Janusz is right that we aren't talking > "MUST NOT", so I am fine with that. > > But perhaps there is something I need to hammer out. In my text > proposal, I have "MUST...that did not directly" and "MAY". I did this > to make sure we still cover other "elements" that need to know of an > action. I used MAY for all, as this means "its permitted, but not > necessary." I.e., the initiator and responder ought to tolerate being > told of a transfer request, but the other party must be told. > > Is that what we are going towards? > > At 16:42 -0400 8/16/05, Michael Young wrote: > >> Hi Edward >> >> "Service messages can be created for all clients affected by an action" >> >> Likewise I don't understand why this change would invalidate any >> existing >> implementations, which is why Scott proposed it this way. MUST replaced >> with SHOULD or "can" does not cause an issue with existing code. >> Retaining >> "MUST" however puts us back to square one in resolving the raised >> issue - so >> I don't see leaving it unmodified as a viable option. >> >> I am perfectly happy to settle for softening it to a SHOULD versus >> "can" if >> you find that language confusing. >> >> >> Michael Young >> -----Original Message----- >> From: owner-ietf-provreg@cafax.se >> [mailto:owner-ietf-provreg@cafax.se] On >> Behalf Of janusz >> Sent: Tuesday, August 16, 2005 4:32 PM >> To: Edward Lewis >> Cc: ietf-provreg@cafax.se >> Subject: Re: [ietf-provreg] 3730 Text Change Proposal >> >> Edward, >> if your code conforms to the OLD text then it should conform to the NEW >> version. Nobody is proposing replacing MUST with MUST NOT. >> >> The NEW text looks reasonable to me. It keeps existing EPP >> deployments still >> within protocol compliance. >> >> Cheers, >> >> Janusz Sienkiewicz >> >> >> Edward Lewis wrote: >> >>> At 14:04 -0400 8/16/05, Andrew Sullivan wrote: >>> >>>> On Mon, Aug 15, 2005 at 01:27:56PM -0400, Hollenbeck, Scott wrote: >>>> >>>>> NEW: >>>>> Service messages can be created for all clients affected by an >>>>> action on an object that did not directly execute the action. For >>>>> example, actions can be reported to the client that has >>>>> the authority to approve or reject a transfer request. Other >>>>> methods of server-client action notification, such as offline >>>>> reporting, are also possible and are beyond the scope of this >>>>> specification. >>>> >>>> >>>> >>>> I like this, myself. Do we want to make the "can"s in there SHOULDs >>>> instead? (I don't, really, but this is a pretty dramatic weakening >>>> from the MUST we had before. Looking at the archives, there seem to >>>> have been some people arguing for a much more important poll queue.) >>> >>> >>> >>> The change confuses me. Instead of relaxing from MUST to SHOULD, the >>> change eliminates any "standards" words. >>> >>> The code base we have currently conforms to the "OLD" spec. We don't >>> have a problem with it, hence we are reluctant to want to see the spec >>> changed (in a way that is "not backwards compatible"). Not so much >>> because we are against change but because we'd like to avoid having to >>> redistribute software (or require new software be written by clients >>> that contact us). >>> >>> It might be that the service message requirement as in "OLD" is >>> suboptimal because it requires a service message go back to the >>> initiator. But we'd rather keep this practice and just recognize (and >>> then drop) the unnecessary message than have to replace software. >>> Keeping in mind that the current way of passing messages is only >>> sub-optimal, not unworkable. >>> >>> Perhaps there's a misunderstanding on my part of what problem the >>> extraneous message causes. >>> >>> Still, I would have thought the new text would have been: >>> >>> Service messages MUST be created for all clients affected by an action >>> on an object that did not directly execute the action, and MAY be >>> created for others affected (including the initiator). For example, >>> ... >>> > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLsBfu009263 for ; Tue, 16 Aug 2005 23:54:11 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GLsBcX020083 for ietf-provreg-outgoing; Tue, 16 Aug 2005 23:54:11 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLsBrv028232 for ; Tue, 16 Aug 2005 23:54:11 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E59Nq-0005Gx-MY for ietf-provreg@cafax.se; Tue, 16 Aug 2005 17:54:10 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id 26B0813744; Tue, 16 Aug 2005 17:53:56 -0400 (EDT) Date: Tue, 16 Aug 2005 17:53:56 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] 3730 Text Change Proposal Message-ID: <20050816215355.GF4918@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Tue, Aug 16, 2005 at 05:25:22PM -0400, Edward Lewis wrote: > not necessary." I.e., the initiator and responder ought to tolerate > being told of a transfer request, but the other party must be told. > > Is that what we are going towards? I hope not, because I'm trying to make the whole thing optional (if we don't take the other approach I suggested). My experience of clients' actual use of the message queue is that many of them simply don't. I want to make it more useful for them, in the hope that they'll use it and spare me creating more needless reports. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLo4xL019955 for ; Tue, 16 Aug 2005 23:50:04 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GLo496009135 for ietf-provreg-outgoing; Tue, 16 Aug 2005 23:50:04 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLo38J006795 for ; Tue, 16 Aug 2005 23:50:04 +0200 (MEST) Received: from roaming7.int.libertyrms.com ([10.1.3.237] helo=DUN911) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E59Jq-0005BD-G6; Tue, 16 Aug 2005 17:50:02 -0400 From: "Michael Young" To: "'Edward Lewis'" Cc: "'janusz'" , Subject: RE: [ietf-provreg] 3730 Text Change Proposal Date: Tue, 16 Aug 2005 17:49:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Thread-Index: AcWiqQIzypgUaQNjSgqDVHsLMn6DOwAAqGwA Message-Id: X-SA-Exim-Mail-From: myoung@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed I don't see a problem with the "MAY" portion but how do you define "others" - could this be, for example as remote as an entity outside the system? >> MAY be created for others affected (including the initiator).. Michael Young -----Original Message----- From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] Sent: Tuesday, August 16, 2005 5:25 PM To: Michael Young Cc: 'janusz'; 'Edward Lewis'; ietf-provreg@cafax.se Subject: RE: [ietf-provreg] 3730 Text Change Proposal Yeah - my "objection" is purely in the sense that "can" is not covered by RFC 2119. I agree that the MUST causes heartburn, so I am fine with moving off that. And Janusz is right that we aren't talking "MUST NOT", so I am fine with that. But perhaps there is something I need to hammer out. In my text proposal, I have "MUST...that did not directly" and "MAY". I did this to make sure we still cover other "elements" that need to know of an action. I used MAY for all, as this means "its permitted, but not necessary." I.e., the initiator and responder ought to tolerate being told of a transfer request, but the other party must be told. Is that what we are going towards? At 16:42 -0400 8/16/05, Michael Young wrote: >Hi Edward > >"Service messages can be created for all clients affected by an action" > >Likewise I don't understand why this change would invalidate any >existing implementations, which is why Scott proposed it this way. >MUST replaced with SHOULD or "can" does not cause an issue with >existing code. Retaining "MUST" however puts us back to square one in >resolving the raised issue - so I don't see leaving it unmodified as a viable option. > >I am perfectly happy to settle for softening it to a SHOULD versus >"can" if you find that language confusing. > > >Michael Young >-----Original Message----- >From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] >On Behalf Of janusz >Sent: Tuesday, August 16, 2005 4:32 PM >To: Edward Lewis >Cc: ietf-provreg@cafax.se >Subject: Re: [ietf-provreg] 3730 Text Change Proposal > >Edward, >if your code conforms to the OLD text then it should conform to the NEW >version. Nobody is proposing replacing MUST with MUST NOT. > >The NEW text looks reasonable to me. It keeps existing EPP deployments >still within protocol compliance. > >Cheers, > >Janusz Sienkiewicz > > >Edward Lewis wrote: > >> At 14:04 -0400 8/16/05, Andrew Sullivan wrote: >> >>> On Mon, Aug 15, 2005 at 01:27:56PM -0400, Hollenbeck, Scott wrote: >>> >>>> NEW: >>>> Service messages can be created for all clients affected by an >>>> action on an object that did not directly execute the action. For >>>> example, actions can be reported to the client that has >>>> the authority to approve or reject a transfer request. Other >>>> methods of server-client action notification, such as offline >>>> reporting, are also possible and are beyond the scope of this >>>> specification. >>> >>> >>> I like this, myself. Do we want to make the "can"s in there >>> SHOULDs instead? (I don't, really, but this is a pretty dramatic >>> weakening from the MUST we had before. Looking at the archives, >>> there seem to have been some people arguing for a much more >>> important poll queue.) >> >> >> The change confuses me. Instead of relaxing from MUST to SHOULD, >> the change eliminates any "standards" words. >> >> The code base we have currently conforms to the "OLD" spec. We >> don't have a problem with it, hence we are reluctant to want to see >> the spec changed (in a way that is "not backwards compatible"). Not >> so much because we are against change but because we'd like to avoid >> having to redistribute software (or require new software be written >> by clients that contact us). >> >> It might be that the service message requirement as in "OLD" is >> suboptimal because it requires a service message go back to the >> initiator. But we'd rather keep this practice and just recognize >> (and then drop) the unnecessary message than have to replace software. >> Keeping in mind that the current way of passing messages is only >> sub-optimal, not unworkable. >> >> Perhaps there's a misunderstanding on my part of what problem the >> extraneous message causes. >> >> Still, I would have thought the new text would have been: >> >> Service messages MUST be created for all clients affected by an >> action on an object that did not directly execute the action, and >> MAY be created for others affected (including the initiator). For >> example, ... >> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLPMvp017472 for ; Tue, 16 Aug 2005 23:25:22 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GLPMae009678 for ietf-provreg-outgoing; Tue, 16 Aug 2005 23:25:22 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ogud.com (ns.ogud.com [66.92.146.160]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLPKjX023602 for ; Tue, 16 Aug 2005 23:25:21 +0200 (MEST) Received: from [10.31.32.63] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7GLP99e015516; Tue, 16 Aug 2005 17:25:11 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 16 Aug 2005 17:25:22 -0400 To: "Michael Young" From: Edward Lewis Subject: RE: [ietf-provreg] 3730 Text Change Proposal Cc: "'janusz'" , "'Edward Lewis'" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Yeah - my "objection" is purely in the sense that "can" is not covered by RFC 2119. I agree that the MUST causes heartburn, so I am fine with moving off that. And Janusz is right that we aren't talking "MUST NOT", so I am fine with that. But perhaps there is something I need to hammer out. In my text proposal, I have "MUST...that did not directly" and "MAY". I did this to make sure we still cover other "elements" that need to know of an action. I used MAY for all, as this means "its permitted, but not necessary." I.e., the initiator and responder ought to tolerate being told of a transfer request, but the other party must be told. Is that what we are going towards? At 16:42 -0400 8/16/05, Michael Young wrote: >Hi Edward > >"Service messages can be created for all clients affected by an action" > >Likewise I don't understand why this change would invalidate any existing >implementations, which is why Scott proposed it this way. MUST replaced >with SHOULD or "can" does not cause an issue with existing code. Retaining >"MUST" however puts us back to square one in resolving the raised issue - so >I don't see leaving it unmodified as a viable option. > >I am perfectly happy to settle for softening it to a SHOULD versus "can" if >you find that language confusing. > > >Michael Young >-----Original Message----- >From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] On >Behalf Of janusz >Sent: Tuesday, August 16, 2005 4:32 PM >To: Edward Lewis >Cc: ietf-provreg@cafax.se >Subject: Re: [ietf-provreg] 3730 Text Change Proposal > >Edward, >if your code conforms to the OLD text then it should conform to the NEW >version. Nobody is proposing replacing MUST with MUST NOT. > >The NEW text looks reasonable to me. It keeps existing EPP deployments still >within protocol compliance. > >Cheers, > >Janusz Sienkiewicz > > >Edward Lewis wrote: > >> At 14:04 -0400 8/16/05, Andrew Sullivan wrote: >> >>> On Mon, Aug 15, 2005 at 01:27:56PM -0400, Hollenbeck, Scott wrote: >>> >>>> NEW: >>>> Service messages can be created for all clients affected by an >>>> action on an object that did not directly execute the action. For >>>> example, actions can be reported to the client that has >>>> the authority to approve or reject a transfer request. Other >>>> methods of server-client action notification, such as offline >>>> reporting, are also possible and are beyond the scope of this >>>> specification. >>> >>> >>> I like this, myself. Do we want to make the "can"s in there SHOULDs >>> instead? (I don't, really, but this is a pretty dramatic weakening >>> from the MUST we had before. Looking at the archives, there seem to >>> have been some people arguing for a much more important poll queue.) >> >> >> The change confuses me. Instead of relaxing from MUST to SHOULD, the >> change eliminates any "standards" words. >> >> The code base we have currently conforms to the "OLD" spec. We don't >> have a problem with it, hence we are reluctant to want to see the spec >> changed (in a way that is "not backwards compatible"). Not so much >> because we are against change but because we'd like to avoid having to >> redistribute software (or require new software be written by clients >> that contact us). >> >> It might be that the service message requirement as in "OLD" is >> suboptimal because it requires a service message go back to the >> initiator. But we'd rather keep this practice and just recognize (and >> then drop) the unnecessary message than have to replace software. >> Keeping in mind that the current way of passing messages is only >> sub-optimal, not unworkable. >> >> Perhaps there's a misunderstanding on my part of what problem the >> extraneous message causes. >> >> Still, I would have thought the new text would have been: >> >> Service messages MUST be created for all clients affected by an action >> on an object that did not directly execute the action, and MAY be >> created for others affected (including the initiator). For example, >> ... >> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLMIYd026421 for ; Tue, 16 Aug 2005 23:22:18 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GLMIKx019721 for ietf-provreg-outgoing; Tue, 16 Aug 2005 23:22:18 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLMHg6008701 for ; Tue, 16 Aug 2005 23:22:18 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E58sy-0003tc-TL for ietf-provreg@cafax.se; Tue, 16 Aug 2005 17:22:16 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id 6EC4E13744; Tue, 16 Aug 2005 17:22:02 -0400 (EDT) Date: Tue, 16 Aug 2005 17:22:02 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] 3730 Text Change Proposal Message-ID: <20050816212202.GB4918@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <046F43A8D79C794FA4733814869CDF07C92A4A@dul1wnexmb01.vcorp.ad.vrsn.com> <20050816180403.GT4918@libertyrms.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Tue, Aug 16, 2005 at 04:02:07PM -0400, Edward Lewis wrote: > > The change confuses me. Instead of relaxing from MUST to SHOULD, the > change eliminates any "standards" words. I think others have pointed out that any relaxing from MUST will not make existing code incompatible with the resulting document. I don't want to attribute anything to Scott (since I have no knowledge in this matter -- or in any other, some would argue!), but I have a suspicion that the use of "can" instead of any of the magic standards words is a feature, not a bug. I think it's a good idea, because it neatly sidesteps the problems we've identified in the use of the poll queue, and doesn't potentially embroil us in other standards issues. > The code base we have currently conforms to the "OLD" spec. We don't > have a problem with it, hence we are reluctant to want to see the > spec changed (in a way that is "not backwards compatible"). Not so I can understand a desire to avoid changes that cause incompatibilities (even if this isn't such a case). But I think this is a weak plank on which to build an argument that the protocol needs to remain unchanged. The whole point of PROPOSED STANDARD after all is that we're not completely committed to that design, precisely because we're aware that we might not have had all the operational experience necessary to get things quite right when folks were first designing the protocol. That isn't to say I think we should embrace change for its own sake; I prefer to leave the protocol alone, to the extent possible, and use extensions where we can, even if the result is not the most elegant approach when considered in isolation. I'm just made awful nervous by a suggestion that we shouldn't fix things we find need fixing (if we do -- and I recognise the jury is still out) because we have some installed base. It'll be much harder to fix things later, with a bigger installed base. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLBQFs014805 for ; Tue, 16 Aug 2005 23:11:26 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GLBQU5008362 for ietf-provreg-outgoing; Tue, 16 Aug 2005 23:11:26 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ns01.afilias.info (ns01.afilias.info [170.224.17.215]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GLBPpK018065 for ; Tue, 16 Aug 2005 23:11:25 +0200 (MEST) Received: from GLIDER (ismtp.afilias.com [216.217.55.254]) (authenticated bits=0) by ns01.afilias.info (8.12.8/8.12.8) with ESMTP id j7GLBMLL019238; Tue, 16 Aug 2005 17:11:22 -0400 Message-Id: <200508162111.j7GLBMLL019238@ns01.afilias.info> From: "Ram Mohan" To: "'Edward Lewis'" , Subject: RE: [ietf-provreg] EPP Document Updates Date: Tue, 16 Aug 2005 17:12:00 -0400 Organization: Afilias MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWfWAr5vKMx8eL7QyWoAXPrL/45PgDL9WOA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Sender: owner-ietf-provreg@cafax.se Precedence: bulk Ed, all, As much as CENTR [or other groups - CDNC comes to mind] is a model for interested registries to talk EPP implementation details, IETF is likely the right place for the protocol elements to get moved forward, in an open "come-right-in" manner. (I expect you already agree with this, I'm simply saying it explicitly). > I think it's clear that there's a demand (as in supply and demand) > for coordination of work involving the EPP protocol. However, I > don't think there's justification for an IETF-style working group. If you read draft-sullivan-epp-experience, there are at least a few areas that need engineers to come together to talk protocol and discuss how to move things forward to the core protocol. Scott (Hollenbeck), for instance, in some cases advocates the exclusive use of extensions for modified or new functionality, and in other cases (RGP) has helped write it into the protocol. My goal is to not have the EPP documents become the "epitome of perfection", but one goal would/could/should be to ensure that diversity of implementations in EPP via extensions for the exact same functionality, aimed at the exact same community, and used by the exact same participants not become the lazy alternative to active discussion on which elements should become part of the core protocol. > The IETF isn't the right venue to attract interest of registries. > There was a time in which EPP development needed the input of other > protocol engineering experts. IETF wg output (and in some cases, even ID track) gets read and digested - as you know, there a lot of lurkers and only a few active speakers. Folks I speak with at many ccTLDs find the IETF work to be both clueful and participatory, if they choose to. > I'm sure another run of the PROVREG WG would gather a different and > probably more well-rounded set of participants than the first try. > But still, there is no guarantee that we get who we need. There never is a guarantee, but it seems to me that we have a confluence of demand (not just market demand, but actual engineering ones), interest from participants, and practical knowledge waiting to be applied appropriately. -Ram Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GKh0Vj012751 for ; Tue, 16 Aug 2005 22:43:00 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GKgxtd020776 for ietf-provreg-outgoing; Tue, 16 Aug 2005 22:42:59 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GKgwhi008189 for ; Tue, 16 Aug 2005 22:42:58 +0200 (MEST) Received: from roaming7.int.libertyrms.com ([10.1.3.237] helo=DUN911) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E58Gv-0002nW-Rr; Tue, 16 Aug 2005 16:42:57 -0400 From: "Michael Young" To: "'janusz'" , "'Edward Lewis'" Cc: Subject: RE: [ietf-provreg] 3730 Text Change Proposal Date: Tue, 16 Aug 2005 16:42:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <43024D43.1060504@ca.afilias.info> Thread-Index: AcWiocDrQX3s2k9dRtOYV36Om5dltAAAH/6Q Message-Id: X-SA-Exim-Mail-From: myoung@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi Edward "Service messages can be created for all clients affected by an action" Likewise I don't understand why this change would invalidate any existing implementations, which is why Scott proposed it this way. MUST replaced with SHOULD or "can" does not cause an issue with existing code. Retaining "MUST" however puts us back to square one in resolving the raised issue - so I don't see leaving it unmodified as a viable option. I am perfectly happy to settle for softening it to a SHOULD versus "can" if you find that language confusing. Michael Young -----Original Message----- From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] On Behalf Of janusz Sent: Tuesday, August 16, 2005 4:32 PM To: Edward Lewis Cc: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] 3730 Text Change Proposal Edward, if your code conforms to the OLD text then it should conform to the NEW version. Nobody is proposing replacing MUST with MUST NOT. The NEW text looks reasonable to me. It keeps existing EPP deployments still within protocol compliance. Cheers, Janusz Sienkiewicz Edward Lewis wrote: > At 14:04 -0400 8/16/05, Andrew Sullivan wrote: > >> On Mon, Aug 15, 2005 at 01:27:56PM -0400, Hollenbeck, Scott wrote: >> >>> NEW: >>> Service messages can be created for all clients affected by an >>> action on an object that did not directly execute the action. For >>> example, actions can be reported to the client that has >>> the authority to approve or reject a transfer request. Other >>> methods of server-client action notification, such as offline >>> reporting, are also possible and are beyond the scope of this >>> specification. >> >> >> I like this, myself. Do we want to make the "can"s in there SHOULDs >> instead? (I don't, really, but this is a pretty dramatic weakening >> from the MUST we had before. Looking at the archives, there seem to >> have been some people arguing for a much more important poll queue.) > > > The change confuses me. Instead of relaxing from MUST to SHOULD, the > change eliminates any "standards" words. > > The code base we have currently conforms to the "OLD" spec. We don't > have a problem with it, hence we are reluctant to want to see the spec > changed (in a way that is "not backwards compatible"). Not so much > because we are against change but because we'd like to avoid having to > redistribute software (or require new software be written by clients > that contact us). > > It might be that the service message requirement as in "OLD" is > suboptimal because it requires a service message go back to the > initiator. But we'd rather keep this practice and just recognize (and > then drop) the unnecessary message than have to replace software. > Keeping in mind that the current way of passing messages is only > sub-optimal, not unworkable. > > Perhaps there's a misunderstanding on my part of what problem the > extraneous message causes. > > Still, I would have thought the new text would have been: > > Service messages MUST be created for all clients affected by an action > on an object that did not directly execute the action, and MAY be > created for others affected (including the initiator). For example, > ... > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GKTBBj014375 for ; Tue, 16 Aug 2005 22:29:11 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GKTAtV008782 for ietf-provreg-outgoing; Tue, 16 Aug 2005 22:29:10 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GKT9w8016576 for ; Tue, 16 Aug 2005 22:29:10 +0200 (MEST) Received: from dev3.int.libertyrms.com ([10.1.3.40] helo=ca.afilias.info) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E583Y-0002Si-H7; Tue, 16 Aug 2005 16:29:08 -0400 Message-ID: <43024D43.1060504@ca.afilias.info> Date: Tue, 16 Aug 2005 16:32:03 -0400 From: janusz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Edward Lewis CC: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] 3730 Text Change Proposal References: <046F43A8D79C794FA4733814869CDF07C92A4A@dul1wnexmb01.vcorp.ad.vrsn.com> <20050816180403.GT4918@libertyrms.info> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: janusz@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk Edward, if your code conforms to the OLD text then it should conform to the NEW version. Nobody is proposing replacing MUST with MUST NOT. The NEW text looks reasonable to me. It keeps existing EPP deployments still within protocol compliance. Cheers, Janusz Sienkiewicz Edward Lewis wrote: > At 14:04 -0400 8/16/05, Andrew Sullivan wrote: > >> On Mon, Aug 15, 2005 at 01:27:56PM -0400, Hollenbeck, Scott wrote: >> >>> NEW: >>> Service messages can be created for all clients affected by an >>> action on >>> an object that did not directly execute the action. For example, >>> actions can be reported to the client that has the >>> authority >>> to approve or reject a transfer request. Other methods of >>> server-client >>> action notification, such as offline reporting, are also possible and >>> are beyond the scope of this specification. >> >> >> I like this, myself. Do we want to make the "can"s in there SHOULDs >> instead? (I don't, really, but this is a pretty dramatic weakening >> from the MUST we had before. Looking at the archives, there seem to >> have been some people arguing for a much more important poll queue.) > > > The change confuses me. Instead of relaxing from MUST to SHOULD, the > change eliminates any "standards" words. > > The code base we have currently conforms to the "OLD" spec. We don't > have a problem with it, hence we are reluctant to want to see the spec > changed (in a way that is "not backwards compatible"). Not so much > because we are against change but because we'd like to avoid having to > redistribute software (or require new software be written by clients > that contact us). > > It might be that the service message requirement as in "OLD" is > suboptimal because it requires a service message go back to the > initiator. But we'd rather keep this practice and just recognize (and > then drop) the unnecessary message than have to replace software. > Keeping in mind that the current way of passing messages is only > sub-optimal, not unworkable. > > Perhaps there's a misunderstanding on my part of what problem the > extraneous message causes. > > Still, I would have thought the new text would have been: > > Service messages MUST be created for all clients affected by an action on > an object that did not directly execute the action, and MAY be created > for > others affected (including the initiator). For example, ... > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GK7vh9004204 for ; Tue, 16 Aug 2005 22:07:57 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GK7vlK019265 for ietf-provreg-outgoing; Tue, 16 Aug 2005 22:07:57 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ogud.com (ns.ogud.com [66.92.146.160]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GK7uPu020136 for ; Tue, 16 Aug 2005 22:07:56 +0200 (MEST) Received: from [10.31.32.63] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7GK7kd4014991; Tue, 16 Aug 2005 16:07:48 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050816180403.GT4918@libertyrms.info> References: <046F43A8D79C794FA4733814869CDF07C92A4A@dul1wnexmb01.vcorp.ad.vrsn.com> <20050816180403.GT4918@libertyrms.info> Date: Tue, 16 Aug 2005 16:02:07 -0400 To: ietf-provreg@cafax.se From: Edward Lewis Subject: Re: [ietf-provreg] 3730 Text Change Proposal Cc: ed.lewis@Neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 14:04 -0400 8/16/05, Andrew Sullivan wrote: >On Mon, Aug 15, 2005 at 01:27:56PM -0400, Hollenbeck, Scott wrote: >> NEW: >> Service messages can be created for all clients affected by an action on >> an object that did not directly execute the action. For example, >> actions can be reported to the client that has the authority >> to approve or reject a transfer request. Other methods of server-client >> action notification, such as offline reporting, are also possible and >> are beyond the scope of this specification. > >I like this, myself. Do we want to make the "can"s in there SHOULDs >instead? (I don't, really, but this is a pretty dramatic weakening >from the MUST we had before. Looking at the archives, there seem to >have been some people arguing for a much more important poll queue.) The change confuses me. Instead of relaxing from MUST to SHOULD, the change eliminates any "standards" words. The code base we have currently conforms to the "OLD" spec. We don't have a problem with it, hence we are reluctant to want to see the spec changed (in a way that is "not backwards compatible"). Not so much because we are against change but because we'd like to avoid having to redistribute software (or require new software be written by clients that contact us). It might be that the service message requirement as in "OLD" is suboptimal because it requires a service message go back to the initiator. But we'd rather keep this practice and just recognize (and then drop) the unnecessary message than have to replace software. Keeping in mind that the current way of passing messages is only sub-optimal, not unworkable. Perhaps there's a misunderstanding on my part of what problem the extraneous message causes. Still, I would have thought the new text would have been: Service messages MUST be created for all clients affected by an action on an object that did not directly execute the action, and MAY be created for others affected (including the initiator). For example, ... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GI4KlH024733 for ; Tue, 16 Aug 2005 20:04:20 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GI4KFi000325 for ietf-provreg-outgoing; Tue, 16 Aug 2005 20:04:20 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GI4IKL010097 for ; Tue, 16 Aug 2005 20:04:19 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E55nN-00074B-UA for ietf-provreg@cafax.se; Tue, 16 Aug 2005 14:04:17 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id 81B6213744; Tue, 16 Aug 2005 14:04:03 -0400 (EDT) Date: Tue, 16 Aug 2005 14:04:03 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] 3730 Text Change Proposal Message-ID: <20050816180403.GT4918@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <046F43A8D79C794FA4733814869CDF07C92A4A@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF07C92A4A@dul1wnexmb01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Mon, Aug 15, 2005 at 01:27:56PM -0400, Hollenbeck, Scott wrote: > NEW: > Service messages can be created for all clients affected by an action on > an object that did not directly execute the action. For example, > actions can be reported to the client that has the authority > to approve or reject a transfer request. Other methods of server-client > action notification, such as offline reporting, are also possible and > are beyond the scope of this specification. I like this, myself. Do we want to make the "can"s in there SHOULDs instead? (I don't, really, but this is a pretty dramatic weakening from the MUST we had before. Looking at the archives, there seem to have been some people arguing for a much more important poll queue.) A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GGSHu1021045 for ; Tue, 16 Aug 2005 18:28:17 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GGSHLP019082 for ietf-provreg-outgoing; Tue, 16 Aug 2005 18:28:17 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [213.154.224.50]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GGSGdj002701 for ; Tue, 16 Aug 2005 18:28:16 +0200 (MEST) Received: from bartok.nlnetlabs.nl (localhost.nlnetlabs.nl [127.0.0.1]) by bartok.nlnetlabs.nl (8.13.3/8.13.1) with ESMTP id j7GGSGQx001059 for ; Tue, 16 Aug 2005 18:28:16 +0200 (CEST) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200508161628.j7GGSGQx001059@bartok.nlnetlabs.nl> To: ietf-provreg@cafax.se Subject: [ietf-provreg] FYI Date: Tue, 16 Aug 2005 18:28:16 +0200 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk The IESG has approved the following document: - 'Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) ' as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-secdns-08.txt Technical Summary This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security extensions (DNSSEC) for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. Working Group Summary This document was received as an invidual submission and is not the product of an IETF working group. Protocol Quality This document was reviewed for the IESG by David Kessens and was also reviewed by the dnsop working group. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GG22Ee021055 for ; Tue, 16 Aug 2005 18:02:02 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GG22pa006769 for ietf-provreg-outgoing; Tue, 16 Aug 2005 18:02:02 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GG21s7021064 for ; Tue, 16 Aug 2005 18:02:01 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E53t2-0003fM-Ad for ietf-provreg@cafax.se; Tue, 16 Aug 2005 12:02:00 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id E6C4013744; Tue, 16 Aug 2005 12:01:45 -0400 (EDT) Date: Tue, 16 Aug 2005 12:01:45 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Comments: draft-sullivan-epp-experience Message-ID: <20050816160145.GK4918@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <046F43A8D79C794FA4733814869CDF07C92BF3@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF07C92BF3@dul1wnexmb01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Tue, Aug 16, 2005 at 11:24:08AM -0400, Hollenbeck, Scott wrote: > I'm not averse to softening the MUST NOT to a SHOULD NOT as long as we > explain that things can really break if it's done without consideration > of object relationships. Yes, that's what I had in mind. I totally agree that this is a dangerous area to wade. FWIW, the operational issue that has this on my mind is the lousy set of alternatives one now has to choose among for cases where one registrar wants to delete a domain, and another registrar is pointing to a subordinate host of that domain as a name server. It's not a big deal if there's only one such pointer, but if there are dozens, it's at least ugly. I'm hoping someone smarter than I am will come up with something brilliant to make this co-ordination easier, and if we weaken the language here a little, then it will be possible to accommodate such schemes without modifying or violating the protocol. (That isn't to say that I'd advocate allowing such deletions starting tomorrow; it'd be only in case of some clever scheme for solving the problems.) A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GFOenC024979 for ; Tue, 16 Aug 2005 17:24:40 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GFOeQs005048 for ietf-provreg-outgoing; Tue, 16 Aug 2005 17:24:40 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GFOb58028956 for ; Tue, 16 Aug 2005 17:24:37 +0200 (MEST) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.1/8.12.11) with ESMTP id j7GFOcWe003453; Tue, 16 Aug 2005 11:24:38 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 Aug 2005 11:24:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ietf-provreg] Comments: draft-sullivan-epp-experience Date: Tue, 16 Aug 2005 11:24:08 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07C92BF3@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-provreg] Comments: draft-sullivan-epp-experience Thread-Index: AcWidPiMuRmUxlo9S7WqKf/NyyaxCQAAKp3g From: "Hollenbeck, Scott" To: "Andrew Sullivan" , X-OriginalArrivalTime: 16 Aug 2005 15:24:35.0908 (UTC) FILETIME=[9C1F8840:01C5A276] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j7GFOc58018855 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > -----Original Message----- > From: owner-ietf-provreg@cafax.se > [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Andrew Sullivan > Sent: Tuesday, August 16, 2005 10:58 AM > To: ietf-provreg@cafax.se > Subject: Re: [ietf-provreg] Comments: draft-sullivan-epp-experience [snip] > The "linked" status doesn't strictly prohibit deletion itself; > instead, 3732 has this: "A host name object MUST NOT be deleted if > the host object is associated with any other object." Similarly, 3733 > has this: "A contact object SHOULD NOT be deleted if it is associated > with other known objects." I can see an argument for preserving the > latter; but the former is surely a policy decision, and ought to be > left to the repository operator. > > I realise that this proposal may be more controversial than the one > to unhook the prohibitiond from the "pending" states. But even > though this is expressing a policy that is a good idea -- don't allow > deletions of an object if anything else refers to it -- it's still a > policy, and therefore something that a repository operator might want > to change in some circumstance we haven't imagined yet. Since the > prohibitions are already possible using some other status, there's no > reason to use this status to enforce the prohibitions. (I think the > linked status is worth keeping, because one might use it as the basis > of policy.) While I agree that this isn't a protocol interoperability issue, remember why the text is there: deleting a host object (or a domain object that has subordinate host objects) has the potential to *BREAK* DNS resolution. Some poor operator that's not a party to the registry-registrar relationship doesn't find out about such changes until something disappears from a zone and things stop working. I'm not averse to softening the MUST NOT to a SHOULD NOT as long as we explain that things can really break if it's done without consideration of object relationships. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GEwiVs001117 for ; Tue, 16 Aug 2005 16:58:44 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7GEwiC5004519 for ietf-provreg-outgoing; Tue, 16 Aug 2005 16:58:44 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7GEwhX7001993 for ; Tue, 16 Aug 2005 16:58:43 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E52tl-0001ge-Ac for ietf-provreg@cafax.se; Tue, 16 Aug 2005 10:58:41 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id EA7F013744; Tue, 16 Aug 2005 10:58:26 -0400 (EDT) Date: Tue, 16 Aug 2005 10:58:26 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Comments: draft-sullivan-epp-experience Message-ID: <20050816145826.GD4918@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <046F43A8D79C794FA4733814869CDF07C92974@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF07C92974@dul1wnexmb01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk In my response to this, I forgot to mention one other thing. On Mon, Aug 15, 2005 at 09:05:14AM -0400, Hollenbeck, Scott wrote: > updated. Here's the text that should be removed from section 2.3: [. . .] > be updated to remove this text. If a registry wants to prevent updates > during one of the "pending" states, it can do so by explicitly setting > one of the "prohibited" status values. I've also ended up arguing that the "linked" status should be similarly unconnected to prohibitions. The general idea is that if a repository operator wants a policy prohibiting some action or other, then the operator should place such a prohibition on the object. Nothing else should entail such a prohibition. The "linked" status doesn't strictly prohibit deletion itself; instead, 3732 has this: "A host name object MUST NOT be deleted if the host object is associated with any other object." Similarly, 3733 has this: "A contact object SHOULD NOT be deleted if it is associated with other known objects." I can see an argument for preserving the latter; but the former is surely a policy decision, and ought to be left to the repository operator. I realise that this proposal may be more controversial than the one to unhook the prohibitiond from the "pending" states. But even though this is expressing a policy that is a good idea -- don't allow deletions of an object if anything else refers to it -- it's still a policy, and therefore something that a repository operator might want to change in some circumstance we haven't imagined yet. Since the prohibitions are already possible using some other status, there's no reason to use this status to enforce the prohibitions. (I think the linked status is worth keeping, because one might use it as the basis of policy.) Thoughts? A ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FHSMfw027816 for ; Mon, 15 Aug 2005 19:28:22 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7FHSMOR029181 for ietf-provreg-outgoing; Mon, 15 Aug 2005 19:28:22 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FHSLTC001431 for ; Mon, 15 Aug 2005 19:28:21 +0200 (MEST) Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id j7FHuOSs007129 for ; Mon, 15 Aug 2005 13:56:25 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 13:28:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [ietf-provreg] 3730 Text Change Proposal Date: Mon, 15 Aug 2005 13:27:56 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07C92A4A@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3730 Text Change Proposal Thread-Index: AcWhvqyuDd6OZiQ4S/2/pLubtsIbcQ== From: "Hollenbeck, Scott" To: X-OriginalArrivalTime: 15 Aug 2005 17:28:20.0144 (UTC) FILETIME=[BAE64B00:01C5A1BE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j7FHSLTC020417 Sender: owner-ietf-provreg@cafax.se Precedence: bulk OK, we've been talking about the text in 3730 that describes the command for a few days. Let me throw out a straw man text change that builds on the one first proposed by Jim Gould. OLD (section 2.9.2.3): Service messages MUST be created for all clients affected by an action on an object. For example, actions MUST be reported to both the client that requests an object transfer and the client that has the authority to approve or reject the transfer request. NEW: Service messages can be created for all clients affected by an action on an object that did not directly execute the action. For example, actions can be reported to the client that has the authority to approve or reject a transfer request. Other methods of server-client action notification, such as offline reporting, are also possible and are beyond the scope of this specification. Fire away! -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FHBsWK013193 for ; Mon, 15 Aug 2005 19:11:54 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7FHBs5V006823 for ietf-provreg-outgoing; Mon, 15 Aug 2005 19:11:54 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FHBq3e005396 for ; Mon, 15 Aug 2005 19:11:53 +0200 (MEST) Received: from dev3.int.libertyrms.com ([10.1.3.40] helo=ca.afilias.info) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E4iV5-00010C-Us; Mon, 15 Aug 2005 13:11:51 -0400 Message-ID: <4300CD82.6080709@ca.afilias.info> Date: Mon, 15 Aug 2005 13:14:42 -0400 From: janusz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: "Hollenbeck, Scott" CC: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Services messages in RFC 3730 References: <046F43A8D79C794FA4733814869CDF07C929F1@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <046F43A8D79C794FA4733814869CDF07C929F1@dul1wnexmb01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: janusz@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk Not implementing command and returning 2101 looks to me like a very problematic implementation option. Section 2.9.3.4 in 3730 ("EPP command seems to be mandatory. Also sections 3.2.6 "Offline Review of Requested Actions" in 3731, 3732 and 3733 documents introduce similiar use cases. Only registries that don't implement object transfers and pending actions could consider the option of not implementing command. Changing text of section 2.9.2.3 to make poll message queuing optional instead of mandatory should eliminate the issue. Cheers, Janusz Sienkiewicz Hollenbeck, Scott wrote: >Do those of you who keep asking about making the command optional >not know about response code 2101? From 3730: > >'2101 "Unimplemented command" >This response code MUST be returned when a server receives a valid EPP >command element that is not implemented by the server.' > >The text in the description needs to be updated as we've >discussed to note that message queuing isn't required for all command >side effects, but I think you already have what you're asking for. >Don't implement . Return 2101 if a client tries to use it. If at >least two independent implementers don't implement it can get cut >from the protocol completely as part of the proposed-to-draft process. > >BTW, I don't think we should try to mix object-specific data with the >higher-level elements. They exist at different layers in the >protocol stack. We could add an opaque element to the command to >park object-specific data, but in a sense we already have that >capability with the element. > >-Scott- > > > >>-----Original Message----- >>From: janusz [mailto:janusz@ca.afilias.info] >>Sent: Monday, August 15, 2005 11:14 AM >>To: Hollenbeck, Scott >>Cc: ietf-provreg@cafax.se >>Subject: Re: [ietf-provreg] Services messages in RFC 3730 >> >>I see one more issue with command. >> >>The mandatory protocol behavior appears to be inconsistent with >>reasonable levels of interoperability. >> >>The XML syntax of response lacks elements that allow returning >>basic object-specific information such as name and ROID for >>actions such >>as auto-renewals or deletion and doing so in an interoperable >>manner. At >>the same time, the specification appears to make it mandatory for the >>server to produce service messages for such actions. In >>practice, that implies that server implementors will be >>forced to either: >> >>-produce generic service messages that will lack object specific >>information and hence will be nearly meaningless for the client >> OR >>- use extensions or include object information into message >>text to make >>the service messages meaningful, but at the cost of >>interoperability and >>registrar code that is registry/server independent. >> >>I can see 2 ways of solving the conflict. >> >>1. Making poll command OPTIONAL as it was defined in earlier >>EPP draft >>documents. >>2. Adding additional elements to response for returning basic >>object-specific information. >> >>Option 1 offers no impact on existing EPP deployments. >>Option 2 would impact existing EPP deployments but in the >>long term it >>would give more flexibility to client and server implementers. Basic >>object-information could be even used to prioritize dequeuing >>items from >>poll queues. >> >>Cheers, >> >>Janusz Sienkiewicz >> >> >> >>Hollenbeck, Scott wrote: >> >> >> >>>Superlatives and astonishment aside, there are really three >>> >>> >>issues here: >> >> >>>1. Is priority-based messaging needed? You obviously think >>> >>> >>so assuming >> >> >>>that messaging isn't optional, so let's continue. >>> >>>2. If so, is this a specification issue or an implementation >>> >>> >>detail? I >> >> >>>believe it's both. >>> >>>Implementation detail: how you implement your message >>> >>> >>queuing system is >> >> >>>up to you. You might have three queues instead of one, with "high >>>priority" messages going into one queue, "normal priority" messages >>>going into a second queue, and "low priority" messages going into a >>>third. As registry operator you make an implementation decision to >>>determine which messages go where. The command can then be >>>implemented to read from them in whatever order makes sense to you. >>> >>>Specification issue: if multiple queues are implemented, how does one >>>let the client deal with that fact? As is, they could be >>> >>> >>read from in >> >> >>>whatever order the server operator decides to impose on the reader. >>>That's probably not too helpful. We also need to look at >>> >>> >>loosening up >> >> >>>the text as Jim suggested. >>> >>>3. If a specification issue, should something new be added >>> >>> >>to the core >> >> >>>specs or should something new be defined in an extension? Given that >>>we're talking about adding a new feature that may or may not >>> >>> >>be useful >> >> >>>to everyone (as you say, "it should all be OPTIONAL"), >>> >>> >>documenting a new >> >> >>>feature (adding priority marks to messages and allowing a client to >>>specify how they wish to deal with the priorities) in a standard >>>extension seems like the least intrusive way to make the >>> >>> >>functionality >> >> >>>available for these reasons: >>> >>>a. It truly is optional. >>>b. It doesn't complicate other existing implementations. >>>c. It's common IETF practice to add new features via extensions once >>>proposed standards are published. Extension development is usually a >>>good reason to spin up a new working group. >>>d. It allows us to avoid a core schema change and the resulting new >>>protocol version. >>> >>>Think about d. for a moment. A protocol version rev likely >>> >>> >>implies an >> >> >>>operational requirement for ALL conforming servers and clients to >>>support both old and new versions for some TBD period of time. An >>>extension can be deployed without introducing version >>> >>> >>management issues. >> >> >>>-Scott- >>> >>> >>> >>> >>> >> >> > > > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FFaMlp000189 for ; Mon, 15 Aug 2005 17:36:22 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7FFaMIk018497 for ietf-provreg-outgoing; Mon, 15 Aug 2005 17:36:22 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FFaLCQ025465 for ; Mon, 15 Aug 2005 17:36:21 +0200 (MEST) Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id j7FG4Njx003451; Mon, 15 Aug 2005 12:04:23 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 11:36:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ietf-provreg] Services messages in RFC 3730 Date: Mon, 15 Aug 2005 11:35:56 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07C929F1@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-provreg] Services messages in RFC 3730 Thread-Index: AcWhq6PuTt7KwqBdTHaIE6KHo7qyGQAAj2zg From: "Hollenbeck, Scott" To: "janusz" Cc: X-OriginalArrivalTime: 15 Aug 2005 15:36:19.0816 (UTC) FILETIME=[15459E80:01C5A1AF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j7FFaMCQ008486 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Do those of you who keep asking about making the command optional not know about response code 2101? From 3730: '2101 "Unimplemented command" This response code MUST be returned when a server receives a valid EPP command element that is not implemented by the server.' The text in the description needs to be updated as we've discussed to note that message queuing isn't required for all command side effects, but I think you already have what you're asking for. Don't implement . Return 2101 if a client tries to use it. If at least two independent implementers don't implement it can get cut from the protocol completely as part of the proposed-to-draft process. BTW, I don't think we should try to mix object-specific data with the higher-level elements. They exist at different layers in the protocol stack. We could add an opaque element to the command to park object-specific data, but in a sense we already have that capability with the element. -Scott- > -----Original Message----- > From: janusz [mailto:janusz@ca.afilias.info] > Sent: Monday, August 15, 2005 11:14 AM > To: Hollenbeck, Scott > Cc: ietf-provreg@cafax.se > Subject: Re: [ietf-provreg] Services messages in RFC 3730 > > I see one more issue with command. > > The mandatory protocol behavior appears to be inconsistent with > reasonable levels of interoperability. > > The XML syntax of response lacks elements that allow returning > basic object-specific information such as name and ROID for > actions such > as auto-renewals or deletion and doing so in an interoperable > manner. At > the same time, the specification appears to make it mandatory for the > server to produce service messages for such actions. In > practice, that implies that server implementors will be > forced to either: > > -produce generic service messages that will lack object specific > information and hence will be nearly meaningless for the client > OR > - use extensions or include object information into message > text to make > the service messages meaningful, but at the cost of > interoperability and > registrar code that is registry/server independent. > > I can see 2 ways of solving the conflict. > > 1. Making poll command OPTIONAL as it was defined in earlier > EPP draft > documents. > 2. Adding additional elements to response for returning basic > object-specific information. > > Option 1 offers no impact on existing EPP deployments. > Option 2 would impact existing EPP deployments but in the > long term it > would give more flexibility to client and server implementers. Basic > object-information could be even used to prioritize dequeuing > items from > poll queues. > > Cheers, > > Janusz Sienkiewicz > > > > Hollenbeck, Scott wrote: > > >Superlatives and astonishment aside, there are really three > issues here: > > > >1. Is priority-based messaging needed? You obviously think > so assuming > >that messaging isn't optional, so let's continue. > > > >2. If so, is this a specification issue or an implementation > detail? I > >believe it's both. > > > >Implementation detail: how you implement your message > queuing system is > >up to you. You might have three queues instead of one, with "high > >priority" messages going into one queue, "normal priority" messages > >going into a second queue, and "low priority" messages going into a > >third. As registry operator you make an implementation decision to > >determine which messages go where. The command can then be > >implemented to read from them in whatever order makes sense to you. > > > >Specification issue: if multiple queues are implemented, how does one > >let the client deal with that fact? As is, they could be > read from in > >whatever order the server operator decides to impose on the reader. > >That's probably not too helpful. We also need to look at > loosening up > >the text as Jim suggested. > > > >3. If a specification issue, should something new be added > to the core > >specs or should something new be defined in an extension? Given that > >we're talking about adding a new feature that may or may not > be useful > >to everyone (as you say, "it should all be OPTIONAL"), > documenting a new > >feature (adding priority marks to messages and allowing a client to > >specify how they wish to deal with the priorities) in a standard > >extension seems like the least intrusive way to make the > functionality > >available for these reasons: > > > >a. It truly is optional. > >b. It doesn't complicate other existing implementations. > >c. It's common IETF practice to add new features via extensions once > >proposed standards are published. Extension development is usually a > >good reason to spin up a new working group. > >d. It allows us to avoid a core schema change and the resulting new > >protocol version. > > > >Think about d. for a moment. A protocol version rev likely > implies an > >operational requirement for ALL conforming servers and clients to > >support both old and new versions for some TBD period of time. An > >extension can be deployed without introducing version > management issues. > > > >-Scott- > > > > > > > > > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FFBcx5027508 for ; Mon, 15 Aug 2005 17:11:39 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7FFBcEG007974 for ietf-provreg-outgoing; Mon, 15 Aug 2005 17:11:38 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FFBbAE012682 for ; Mon, 15 Aug 2005 17:11:38 +0200 (MEST) Received: from dev3.int.libertyrms.com ([10.1.3.40] helo=ca.afilias.info) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E4gci-0005qA-3U; Mon, 15 Aug 2005 11:11:36 -0400 Message-ID: <4300B152.4070200@ca.afilias.info> Date: Mon, 15 Aug 2005 11:14:26 -0400 From: janusz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: "Hollenbeck, Scott" CC: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Services messages in RFC 3730 References: <046F43A8D79C794FA4733814869CDF07C92888@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <046F43A8D79C794FA4733814869CDF07C92888@dul1wnexmb01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: janusz@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk I see one more issue with command. The mandatory protocol behavior appears to be inconsistent with reasonable levels of interoperability. The XML syntax of response lacks elements that allow returning basic object-specific information such as name and ROID for actions such as auto-renewals or deletion and doing so in an interoperable manner. At the same time, the specification appears to make it mandatory for the server to produce service messages for such actions. In practice, that implies that server implementors will be forced to either: -produce generic service messages that will lack object specific information and hence will be nearly meaningless for the client OR - use extensions or include object information into message text to make the service messages meaningful, but at the cost of interoperability and registrar code that is registry/server independent. I can see 2 ways of solving the conflict. 1. Making poll command OPTIONAL as it was defined in earlier EPP draft documents. 2. Adding additional elements to response for returning basic object-specific information. Option 1 offers no impact on existing EPP deployments. Option 2 would impact existing EPP deployments but in the long term it would give more flexibility to client and server implementers. Basic object-information could be even used to prioritize dequeuing items from poll queues. Cheers, Janusz Sienkiewicz Hollenbeck, Scott wrote: >Superlatives and astonishment aside, there are really three issues here: > >1. Is priority-based messaging needed? You obviously think so assuming >that messaging isn't optional, so let's continue. > >2. If so, is this a specification issue or an implementation detail? I >believe it's both. > >Implementation detail: how you implement your message queuing system is >up to you. You might have three queues instead of one, with "high >priority" messages going into one queue, "normal priority" messages >going into a second queue, and "low priority" messages going into a >third. As registry operator you make an implementation decision to >determine which messages go where. The command can then be >implemented to read from them in whatever order makes sense to you. > >Specification issue: if multiple queues are implemented, how does one >let the client deal with that fact? As is, they could be read from in >whatever order the server operator decides to impose on the reader. >That's probably not too helpful. We also need to look at loosening up >the text as Jim suggested. > >3. If a specification issue, should something new be added to the core >specs or should something new be defined in an extension? Given that >we're talking about adding a new feature that may or may not be useful >to everyone (as you say, "it should all be OPTIONAL"), documenting a new >feature (adding priority marks to messages and allowing a client to >specify how they wish to deal with the priorities) in a standard >extension seems like the least intrusive way to make the functionality >available for these reasons: > >a. It truly is optional. >b. It doesn't complicate other existing implementations. >c. It's common IETF practice to add new features via extensions once >proposed standards are published. Extension development is usually a >good reason to spin up a new working group. >d. It allows us to avoid a core schema change and the resulting new >protocol version. > >Think about d. for a moment. A protocol version rev likely implies an >operational requirement for ALL conforming servers and clients to >support both old and new versions for some TBD period of time. An >extension can be deployed without introducing version management issues. > >-Scott- > > > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FDcBXC025435 for ; Mon, 15 Aug 2005 15:38:11 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7FDcBNe019315 for ietf-provreg-outgoing; Mon, 15 Aug 2005 15:38:11 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FDcAcm023365 for ; Mon, 15 Aug 2005 15:38:11 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E4fAG-0003Hx-RY for ietf-provreg@cafax.se; Mon, 15 Aug 2005 09:38:08 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id BF18E13744; Mon, 15 Aug 2005 09:37:54 -0400 (EDT) Date: Mon, 15 Aug 2005 09:37:54 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Comments: draft-sullivan-epp-experience Message-ID: <20050815133754.GA16496@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <046F43A8D79C794FA4733814869CDF07C92974@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF07C92974@dul1wnexmb01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi Scott, Thanks for your comments. I particularly like this one: On Mon, Aug 15, 2005 at 09:05:14AM -0400, Hollenbeck, Scott wrote: > extension candidacy. The question, of course, is breadth of appeal. We > should talk about it if others think that more granularity should be > added to the core. We should defer to an extension if the appeal is > limited. That's exactly the feedback I've been hoping for. If there's broad consensus that the proposals are ill-conceived or not general enough, I think that the extension mechanism is the way to go, also. Thanks much, A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 Return-Path: Received: from localhost ([221.124.23.247]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7FDS18X015026 for ; Mon, 15 Aug 2005 15:28:02 +0200 (MEST) Date: ¬P´Á¤@, 15 ¤K¤ë 2005 21:26:58 +0100 From: "Fisch" To: Subject: Best love dr@gs at best store! Message-ID: <002b01c54b50$10e49590$de01a8c0@jdw> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html

Suffering from pain, depression or heartburn? We'll help you!

All verified dr@gs collected at one LICENSED online store!
Great choice of wonderful meds to give you long-awaited relief!
Operative support, fast shipping, secure p@yment processing and complete confidentiality!

The store is VERIFIED BY BBB and APPROVED BY VISA!

Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FD9C6H010378 for ; Mon, 15 Aug 2005 15:09:12 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7FD9B7J008713 for ietf-provreg-outgoing; Mon, 15 Aug 2005 15:09:11 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ogud.com (ns.ogud.com [66.92.146.160]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FD9AOQ028105 for ; Mon, 15 Aug 2005 15:09:10 +0200 (MEST) Received: from [10.31.32.63] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7FD8xnJ008073; Mon, 15 Aug 2005 09:09:00 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050812202127.GY23651@libertyrms.info> References: <200508041712.j74HCbhm018679@ns01.afilias.info> <20050812202127.GY23651@libertyrms.info> Date: Mon, 15 Aug 2005 09:00:46 -0400 To: Andrew Sullivan From: Edward Lewis Subject: Re: [ietf-provreg] EPP Document Updates Cc: ietf-provreg@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 16:21 -0400 8/12/05, Andrew Sullivan wrote: >Hi, > >Taking my cue from your .sig, I have a feeling I don't know what >you're thinking here (since I think I don't understand this). The quote was derived from a language teacher's comment about a sentence "yes, you have to know what the speaker is thinking to understand it." The .sig came to me as I strolled down a street in that country some months later. However, I think you have gotten what I meant. >On Fri, Aug 12, 2005 at 12:07:12PM -0400, Edward Lewis wrote: >> >> I think it's clear that there's a demand (as in supply and demand) >> for coordination of work involving the EPP protocol. However, I >> don't think there's justification for an IETF-style working group. > >I read that to mean that you think that there are some people who >think that EPP needs work, but that such work shouldn't go on in an >IETF wg. And I agree with you that simple changes to the documents >don't need a working group. The idiom "needs work" isn't what I would use. There are enhancements desired to EPP, and extensions for new problem domains. However, I have not seen or heard of changes that require a re-engineering of the basic protocol. (Not that there aren't needed changes lurking around the corner, but not real to date.) >But I'm not sure I follow the subsequent arguments that the IETF is >the wrong place to pursue updates or changes to the protocol. > >I appreciate that the IETF doesn't always attract all the registrar >and registry people we might like for feedback on these issues; but >that's a problem I'd suggest we solve by soliciting the feedback of >people in those communities, and _not_ by trying to take our protocol >developments to some other forum. I have no direct experience of >CENTR, but my few experiences with ICANN committees &c. have left me >with a very strong impression that the technical knowledge does not >there exist to do good protocol development. That's no indictment of >ICANN: they're doing their policy work, and relying on the technical >community of the Internet to do the technical work. That community >works within the IETF, no? I have a less optimistic view of the IETF process when it comes to getting feedback on issues. When Jaap and I were the co-chairs, most of our efforts were to spread the word on EPP. We were not the kind of co-chairs that took a heavy hand in the technical solution, we spent more time on process. Personally I saw my role as "mediating" between the reputation EPP garnered as "son of RRP" and "yet another tool" of the market dominating player versus the technical benefit it provided derived by being initiated by the people with the most experience. It wasn't very easy getting the circle of review to widen. My employer did not have a budget to send my out of the US. When I did have the opportunity, I found that ccTLDs were reluctant to pursue EPP for a few reasons, a lot of time because of the resources (people) needed. I recall conversations with "small" ccTLD operations that felt they didn't need to look at the documents (not enough transaction volume) and that they wouldn't be able to steer the IETF anyway. I saw mail from another ccTLD that was irritated by the meddling of "a high ranking IETF official" when trying to get them to comment on their proprietary work on the protocol. I'm making this sound more dire than it is. The volunteer nature of the IETF sometimes is a detriment to the process. Although I have been disappointed with ICANN - it has not met my engineering tastes - it is where the money transacted because of EPP resides. CENTR is an organization of registries, a much more concentrated population of interest in EPP. I'm holding up ICANN and CENTR as examples, not as solutions, only because they are the ones I am most familiar with in this case. >There does seem to be a live question of whether all the issues >everyone has identified with EPP can be accommodated without a >protocol change (including, of course, by instead developing >extensions). So far, I'm not totally convinced; but I'd sure like to >be, which is why I'm pursuing these conversations now. That's a healthy attitude and approach, and this mailing list is probably the best venue for that. Starting up an IETF WG takes some effort anyway, and even if it could be done with out a BoF, the next meeting wouldn't be until November. I'll say that I am reluctant to propose a new WG in anticipation of problems. Only if there is an engineering problem to hammer out would I want to create a group. In a volunteer organization, reactionary stances seem the most efficient. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FD5dMK008591 for ; Mon, 15 Aug 2005 15:05:39 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7FD5dgi023336 for ietf-provreg-outgoing; Mon, 15 Aug 2005 15:05:39 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FD5cwB011829 for ; Mon, 15 Aug 2005 15:05:38 +0200 (MEST) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id j7FDXdh5030409 for ; Mon, 15 Aug 2005 09:33:40 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 09:05:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [ietf-provreg] Comments: draft-sullivan-epp-experience Date: Mon, 15 Aug 2005 09:05:14 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07C92974@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments: draft-sullivan-epp-experience Thread-Index: AcWhmfnDCOriWjI2Qy226/iliwS8zg== From: "Hollenbeck, Scott" To: X-OriginalArrivalTime: 15 Aug 2005 13:05:37.0705 (UTC) FILETIME=[07C0F990:01C5A19A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j7FD5dwB015516 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Thanks to the guys from Afilias who took the time to write draft-sullivan-epp-experience. This is exactly the kind of info we need to discuss to determine what the next steps should be with the protocol. As described in the intro, the document covers four things. My take on each, in order: 1. The creation of the "Redemption Grace Period" (supported under EPP by [RFC3915] requires that certain provisions of [RFC3731] be violated in order to offer the new service. I believe we've already talked about removing the "update prohibited" restriction from 3731. My intention with 3915 has always been that actions to take a domain out of a "pending" status could over-ride the restriction. I agree that this isn't clear, and 3731 needs to be updated. Here's the text that should be removed from section 2.3: "With one exception, transform commands MUST be rejected when a pendingCreate, pendingDelete, pendingRenew, pendingTransfer, or pendingUpdate status is set. The only exception is that a command to approve, reject, or cancel a transfer MAY be processed while an object is in "pendingTransfer" status." There's similar text in the host and contact mappings. They should also be updated to remove this text. If a registry wants to prevent updates during one of the "pending" states, it can do so by explicitly setting one of the "prohibited" status values. 2. Experience with implementation suggests that status values may be insufficiently granular. I will argue that granularity is a prime example of something that is tailor made for extension development. The protocol defines some basic capability. That capability can be expanded using protocol extensions. It's exactly why the extension mechanism exists. 3. Experience with the poll queue mechanism suggests that a more sophisticated mechanism might be useful, or that the requirements for implementation should be relaxed. We started talking about this last week. I agree that the text in 3730 needs to be relaxed. I've suggested that new functionality may be best addressed as part of an extension. Others may disagree. 4. Experience with commands suggests either that status values are too coarsely-grained, or that another set of commands entirely needs to be defined. Same argument from me as used in point 2. Needed granularity implies extension candidacy. The question, of course, is breadth of appeal. We should talk about it if others think that more granularity should be added to the core. We should defer to an extension if the appeal is limited. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FCOLFP004419 for ; Mon, 15 Aug 2005 14:24:21 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7FCOLff023899 for ietf-provreg-outgoing; Mon, 15 Aug 2005 14:24:21 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7FCOKE7013746 for ; Mon, 15 Aug 2005 14:24:20 +0200 (MEST) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id j7FCqIMs029151; Mon, 15 Aug 2005 08:52:18 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 08:24:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ietf-provreg] Services messages in RFC 3730 Date: Mon, 15 Aug 2005 08:23:52 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07C9296F@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-provreg] Services messages in RFC 3730 Thread-Index: AcWfayVhfCif6XxnTVm/qfhuFxfJCgCJ/jKA From: "Hollenbeck, Scott" To: "Michael Young" Cc: X-OriginalArrivalTime: 15 Aug 2005 12:24:16.0533 (UTC) FILETIME=[40DC2C50:01C5A194] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j7FCOLE7018649 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > -----Original Message----- > From: Michael Young [mailto:myoung@ca.afilias.info] > Sent: Friday, August 12, 2005 2:25 PM > To: Hollenbeck, Scott > Cc: ietf-provreg@cafax.se > Subject: Re: [ietf-provreg] Services messages in RFC 3730 [snip] > >"You might have three queues instead of one, with "high > >priority" messages going into one queue, "normal priority" messages > >going into a second queue, and "low priority" messages going into a > >third." > > > I dont see the flexibility to do that as it stands, can you > elaborate on that please? This isn't a protocol interop issue. As I described here (point 2): http://www.cafax.se/ietf-provreg/maillist/2005-08/msg00027.html it's an implementation issue. You can implement whatever queueing mechanism you wish. All that matters to the protocol is that the messages can be retrieved as specified. > >a. It truly is optional. > >b. It doesn't complicate other existing implementations. > >c. It's common IETF practice to add new features via extensions once > >proposed standards are published. Extension development is usually a > >good reason to spin up a new working group. > >d. It allows us to avoid a core schema change and the resulting new > >protocol version. > > > >Think about d. for a moment. A protocol version rev likely > implies an > >operational requirement for ALL conforming servers and clients to > >support both old and new versions for some TBD period of time. An > >extension can be deployed without introducing version > management issues > > > A and B I think in case qualify. > For C how would suggest this be addressed in an extension? All you have to do is define an extension to the command and response to add the features you want to use. You can then publish the extension as an I-D if you think there's broad interest, or you can do your own thing for your own use. Your call. > As for D I completely take your point but isnt this > ultimately a cost benefit analysis not a defacto "don't go > there" decision? For example the poll queue is the only item > under discussion at this point, there are certainly other > contenders that could result in a schema change (see > > http://www.ietf.org/internet-drafts/draft-sullivan-epp-experie > nce-00.txt ). Can we really resolve all the raised issues > via extensions? If we can would that be less effort on the > implementers and users than a protocol change? I think it > really depends on the complexity of the changes. With a > protocol change the resultant client changes required may be > considered minimal by the users involved compared to the > gains in capability. An implementer may find running dual > protocol less effort than a series of extensions. As always - > it depends and we need some feedback beyond ourselves (some > registrar feedback would be helpful here). I'll have to read the document again to see what's changed since Andrew first showed me a copy. I don't know if everything described in the document can be addressed via extensions, so of course some analysis must be done. I think that's what we're trying to do right now. I will read the document again today and provide comments to the list. -Scott- Return-Path: Received: from localhost ([81.91.232.210]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7FBhFjM025367 for ; Mon, 15 Aug 2005 13:43:15 +0200 (MEST) Date: lun., 15 août 2005 12:44:26 +0100 From: "Goldberg" To: Subject: Our store is your cureall! Message-ID: <002b01c54b50$10e49590$de01a8c0@jdw> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html

Suffering from pain, depression or heartburn? We'll help you!

All verified dr@gs collected at one LICENSED online store!
Great choice of wonderful meds to give you long-awaited relief!
Operative support, fast shipping, secure p@yment processing and complete confidentiality!

The store is VERIFIED BY BBB and APPROVED BY VISA!

Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7D0wird016026 for ; Sat, 13 Aug 2005 02:58:44 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7D0wilV015917 for ietf-provreg-outgoing; Sat, 13 Aug 2005 02:58:44 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from nohope.patoche.org ([62.160.23.78]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7D0wh5P027039 for ; Sat, 13 Aug 2005 02:58:43 +0200 (MEST) Received: from nohope.patoche.org (localhost.localdomain [127.0.0.1]) by nohope.patoche.org (8.13.4/8.13.4/Debian-3) with ESMTP id j7D0whDw017241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 Aug 2005 02:58:43 +0200 Received: (from patrick@localhost) by nohope.patoche.org (8.13.4/8.13.4/Submit) id j7D0whbN017239; Sat, 13 Aug 2005 02:58:43 +0200 Date: Sat, 13 Aug 2005 02:58:43 +0200 From: Patrick Mevzek To: ietf-provreg@cafax.se Subject: [ietf-provreg] Open source EPP implementation Message-ID: <20050813005843.GA16775@nohope.patoche.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-KeyID: A241FB6B X-PGP-Fingerprint: 9DA9 5054 7A5D 03FC A9AD 9AFF 1371 9F06 A241 FB6B X-Request-PGP: http://www.keyserver.net:11371/pks/lookup?op=vindex&search=0xA241FB6B Organization: Dot And Co User-Agent: Mutt/1.5.9i Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hello, Just to let you know that I released a few days ago an open source EPP implementation (GPL license), which implements all EPP RFCs, including the GracePeriod extension with room for others. It is more of a toolkit and an abstract view of registries (it implements also RRP, and can accomodate many transports), in Perl. If interested, more information here: http://freshmeat.net/projects/netdri/ http://www.dotandco.com/services/software/Net-DRI/index.en If any registry or EPP server owner is interested to conduct interoperability tests or to make sure to have its specific policy and/or technical requirements taken into account (adding other protocols is possible, as well as handling variations from a common protocol), feel free to drop me a note here or privately. -- Patrick Mevzek Dot and Co Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CKLh2k023966 for ; Fri, 12 Aug 2005 22:21:43 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7CKLhn9023314 for ietf-provreg-outgoing; Fri, 12 Aug 2005 22:21:43 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CKLggw024732 for ; Fri, 12 Aug 2005 22:21:42 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E3g29-0007tL-7B for ietf-provreg@cafax.se; Fri, 12 Aug 2005 16:21:41 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id 1084113744; Fri, 12 Aug 2005 16:21:28 -0400 (EDT) Date: Fri, 12 Aug 2005 16:21:28 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] EPP Document Updates Message-ID: <20050812202127.GY23651@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <200508041712.j74HCbhm018679@ns01.afilias.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi, Taking my cue from your .sig, I have a feeling I don't know what you're thinking here (since I think I don't understand this). On Fri, Aug 12, 2005 at 12:07:12PM -0400, Edward Lewis wrote: > > I think it's clear that there's a demand (as in supply and demand) > for coordination of work involving the EPP protocol. However, I > don't think there's justification for an IETF-style working group. I read that to mean that you think that there are some people who think that EPP needs work, but that such work shouldn't go on in an IETF wg. And I agree with you that simple changes to the documents don't need a working group. But I'm not sure I follow the subsequent arguments that the IETF is the wrong place to pursue updates or changes to the protocol. I appreciate that the IETF doesn't always attract all the registrar and registry people we might like for feedback on these issues; but that's a problem I'd suggest we solve by soliciting the feedback of people in those communities, and _not_ by trying to take our protocol developments to some other forum. I have no direct experience of CENTR, but my few experiences with ICANN committees &c. have left me with a very strong impression that the technical knowledge does not there exist to do good protocol development. That's no indictment of ICANN: they're doing their policy work, and relying on the technical community of the Internet to do the technical work. That community works within the IETF, no? There does seem to be a live question of whether all the issues everyone has identified with EPP can be accommodated without a protocol change (including, of course, by instead developing extensions). So far, I'm not totally convinced; but I'd sure like to be, which is why I'm pursuing these conversations now. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CK4Y0e003404 for ; Fri, 12 Aug 2005 22:04:34 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7CK4Yjm026008 for ietf-provreg-outgoing; Fri, 12 Aug 2005 22:04:34 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CK4W3r022612 for ; Fri, 12 Aug 2005 22:04:33 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E3flY-0007WR-4p for ietf-provreg@cafax.se; Fri, 12 Aug 2005 16:04:32 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id 01E3B13744; Fri, 12 Aug 2005 16:04:19 -0400 (EDT) Date: Fri, 12 Aug 2005 16:04:18 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Country codes (another EPP Document Update) Message-ID: <20050812200416.GV23651@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <200508041712.j74HCbhm018679@ns01.afilias.info> <20050812191553.GS23651@libertyrms.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Fri, Aug 12, 2005 at 03:40:04PM -0400, Edward Lewis wrote: > > 1) If a group elsewhere is working on this, maybe it's best to lay > back. Especially if there are subject matter experts "over there". Yes. I think I may not have been perfectly clear, but part of what I was trying to say is, "Does anyone know what the status of that work is? Did it get anywhere, or was the moaning and gnashing of teeth I heard the only thing that happened?" I have no idea what people are actually going to do about the whole YU/CS debacle, but if someone else came up with an answer, we might be able just to include it now while we're at it. > 2) Maybe this is an issue not for the EPP interface but for database > "archival" functions. Surely not. If the database has a contact in it with a country code of YU, and someone does a on that contact, the repository need to return YU, even though YU is no longer valid under the normative reference. (Or, if your view of the normative reference is that it refers only to the 3166-1 from 1997, replace this example with some other effective one -- I think the CD/ZR one will do.) I suppose I'm being a protocol lawyer, though: we all know what the _point_ of the reference is, so maybe implicity it's really 3166 for any value of "3166's history". (That still doesn't solve the CS-is-Czechoslovakia/CS-is-Serbia-and-Montenegro problem, though.) A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CJw9u9001218 for ; Fri, 12 Aug 2005 21:58:09 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7CJw905027481 for ietf-provreg-outgoing; Fri, 12 Aug 2005 21:58:09 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CJw78M008849 for ; Fri, 12 Aug 2005 21:58:08 +0200 (MEST) Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.1/8.12.11) with ESMTP id j7CKP76s005188; Fri, 12 Aug 2005 16:25:07 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 15:58:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ietf-provreg] Country codes (another EPP Document Update) Date: Fri, 12 Aug 2005 15:57:51 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07C92901@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-provreg] Country codes (another EPP Document Update) Thread-Index: AcWfdDe0hNXagacGTaC25wZyrhCYkQAA06gw From: "Hollenbeck, Scott" To: "Andrew Sullivan" , X-OriginalArrivalTime: 12 Aug 2005 19:58:06.0489 (UTC) FILETIME=[27F07890:01C59F78] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j7CJw88M007898 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > -----Original Message----- > From: owner-ietf-provreg@cafax.se > [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Andrew Sullivan > Sent: Friday, August 12, 2005 3:16 PM > To: ietf-provreg@cafax.se > Subject: [ietf-provreg] Country codes (another EPP Document Update) > > I just remembered that there's one more annoyance that I've forgotten > to mention, but I think we'd benefit from addressing. > > RFC 3733 requires (in section 2.4.3) that registrant country be > represented by the ISO 3166 country code. > > The problem is, as I'm sure everyone is aware, that the ISO 3166 > rules permit not only the obsolescence of a country code, but its > reassignment. The possibility that a country code will come to refer > to some other country seems to be conceptually broken for our > purposes, because while countries go out of existence (and their > country code is deleted), the addresses often don't change (and even > if they did, there's be precious little way of getting the data from > the contact if one interacts with the person corresponding to the > contact object indirectly). Formally speaking, this means that > allowing (for instance) YU in an address is not permitted today, even > though it was correct when the address was created. This is of > course a pain, because the country code is valid at one date, and > becomes invalid later. > > I know that people elsewhere in the IETF are struggling with this > problem for considerably more important cases than this one; but is > there anything we can do about it now, while we're looking at these > documents? If you know of a way to describe a country with an identifier that never changes, clue me in. Even their commonly spoken names can change. Witness Congo->Zaire->Congo, Russia->USSR->Russia, etc. I agree with Ed. This is a back-end database "archival" issue. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CJe6xu011179 for ; Fri, 12 Aug 2005 21:40:06 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7CJe6Tg017290 for ietf-provreg-outgoing; Fri, 12 Aug 2005 21:40:06 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ogud.com (ns.ogud.com [66.92.146.160]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CJe4KQ016311 for ; Fri, 12 Aug 2005 21:40:05 +0200 (MEST) Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7CJdu5H091263; Fri, 12 Aug 2005 15:39:57 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050812191553.GS23651@libertyrms.info> References: <200508041712.j74HCbhm018679@ns01.afilias.info> <20050812191553.GS23651@libertyrms.info> Date: Fri, 12 Aug 2005 15:40:04 -0400 To: Andrew Sullivan From: Edward Lewis Subject: Re: [ietf-provreg] Country codes (another EPP Document Update) Cc: ietf-provreg@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 15:15 -0400 8/12/05, Andrew Sullivan wrote: >I know that people elsewhere in the IETF are struggling with this >problem for considerably more important cases than this one; but is >there anything we can do about it now, while we're looking at these Maybe I'm in a particularly prickly mood today (;)) towards opening up new work, so here are some comments just to stew over... 1) If a group elsewhere is working on this, maybe it's best to lay back. Especially if there are subject matter experts "over there". 2) Maybe this is an issue not for the EPP interface but for database "archival" functions. I'm counterbalancing the energy to engineer at every corner, that's what I am doing. I admire the desire to "fix" this and the desire to engineer a solution, but I would "leave it to the experts" and "solve the problem where it truly lay." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CJG84B003469 for ; Fri, 12 Aug 2005 21:16:08 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7CJG8wH003133 for ietf-provreg-outgoing; Fri, 12 Aug 2005 21:16:08 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CJG7lP028158 for ; Fri, 12 Aug 2005 21:16:08 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E3f0g-0006Al-Pv for ietf-provreg@cafax.se; Fri, 12 Aug 2005 15:16:06 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id A1CC513744; Fri, 12 Aug 2005 15:15:53 -0400 (EDT) Date: Fri, 12 Aug 2005 15:15:53 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: [ietf-provreg] Country codes (another EPP Document Update) Message-ID: <20050812191553.GS23651@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <200508041712.j74HCbhm018679@ns01.afilias.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk I just remembered that there's one more annoyance that I've forgotten to mention, but I think we'd benefit from addressing. RFC 3733 requires (in section 2.4.3) that registrant country be represented by the ISO 3166 country code. The problem is, as I'm sure everyone is aware, that the ISO 3166 rules permit not only the obsolescence of a country code, but its reassignment. The possibility that a country code will come to refer to some other country seems to be conceptually broken for our purposes, because while countries go out of existence (and their country code is deleted), the addresses often don't change (and even if they did, there's be precious little way of getting the data from the contact if one interacts with the person corresponding to the contact object indirectly). Formally speaking, this means that allowing (for instance) YU in an address is not permitted today, even though it was correct when the address was created. This is of course a pain, because the country code is valid at one date, and becomes invalid later. I know that people elsewhere in the IETF are struggling with this problem for considerably more important cases than this one; but is there anything we can do about it now, while we're looking at these documents? A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CJ3S9I010925 for ; Fri, 12 Aug 2005 21:03:28 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7CJ3Swf005967 for ietf-provreg-outgoing; Fri, 12 Aug 2005 21:03:28 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ogud.com (ns.ogud.com [66.92.146.160]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CJ3RIo023836 for ; Fri, 12 Aug 2005 21:03:27 +0200 (MEST) Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7CJ3Ktj091116; Fri, 12 Aug 2005 15:03:20 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <046F43A8D79C794FA4733814869CDF07C928E5@dul1wnexmb01.vcorp.ad.vrsn.com> References: <046F43A8D79C794FA4733814869CDF07C928E5@dul1wnexmb01.vcorp.ad.vrsn.com> Date: Fri, 12 Aug 2005 15:03:27 -0400 To: "Hollenbeck, Scott" From: Edward Lewis Subject: WG, was RE: [ietf-provreg] Services messages in RFC 3730 Cc: "Edward Lewis" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 14:53 -0400 8/12/05, Hollenbeck, Scott wrote: >> -----Original Message----- >> From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] >> Sent: Friday, August 12, 2005 2:20 PM >> To: Hollenbeck, Scott >> Cc: Michael Young; ietf-provreg@cafax.se >> Subject: RE: [ietf-provreg] Services messages in RFC 3730 > >[snip] > >> >c. It's common IETF practice to add new features via extensions once >> >proposed standards are published. Extension development is usually a >> >good reason to spin up a new working group. >> >> On a tangent - do you mean to say that extensions ought to cause a >> new WG? Up to now some extensions haven't been discussed in a (new) >> WG. > >What I'm saying is that it's not uncommon for a new group to form around >the idea of adding new features to an established protocol without >changing the established protocol. The imapext working group, for >example. There generally has to be a lot of common ground among the >implementing community to have this be successful. In our case, it >could mean that multiple people would want to work on the same >extension(s), maybe due to an ICANN requirement or some other similar >need that brings people together. > >It's also quite acceptable for someone to just write their own extension >draft and push it through the standards process. This is probably a >better option if the extension has limited appeal. What I expressed to someone after the CENTR meeting was that (for a particular extension) was that they could collect a group of CENTR members, hammer out a draft (DRAFT!, not specification, not RFC) and then bring that to the IETF. In other words, it doesn't always have to start in the IETF - although having the IETF last call, and this list, as a significant "open discussion" of the work. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CIrWIV022430 for ; Fri, 12 Aug 2005 20:53:32 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7CIrWru029103 for ietf-provreg-outgoing; Fri, 12 Aug 2005 20:53:32 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CIrUpm006027 for ; Fri, 12 Aug 2005 20:53:31 +0200 (MEST) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.1/8.12.11) with ESMTP id j7CJKUqw003035; Fri, 12 Aug 2005 15:20:30 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 14:53:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ietf-provreg] Services messages in RFC 3730 Date: Fri, 12 Aug 2005 14:53:15 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07C928E5@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-provreg] Services messages in RFC 3730 Thread-Index: AcWfam6kkr4hI5x+S66GwXonpVm+fgAA8qBQ From: "Hollenbeck, Scott" To: "Edward Lewis" Cc: X-OriginalArrivalTime: 12 Aug 2005 18:53:29.0859 (UTC) FILETIME=[2149AD30:01C59F6F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j7CIrVpm024892 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > -----Original Message----- > From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] > Sent: Friday, August 12, 2005 2:20 PM > To: Hollenbeck, Scott > Cc: Michael Young; ietf-provreg@cafax.se > Subject: RE: [ietf-provreg] Services messages in RFC 3730 [snip] > >c. It's common IETF practice to add new features via extensions once > >proposed standards are published. Extension development is usually a > >good reason to spin up a new working group. > > On a tangent - do you mean to say that extensions ought to cause a > new WG? Up to now some extensions haven't been discussed in a (new) > WG. What I'm saying is that it's not uncommon for a new group to form around the idea of adding new features to an established protocol without changing the established protocol. The imapext working group, for example. There generally has to be a lot of common ground among the implementing community to have this be successful. In our case, it could mean that multiple people would want to work on the same extension(s), maybe due to an ICANN requirement or some other similar need that brings people together. It's also quite acceptable for someone to just write their own extension draft and push it through the standards process. This is probably a better option if the extension has limited appeal. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CIamSh013730 for ; Fri, 12 Aug 2005 20:36:48 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7CIamdC020979 for ietf-provreg-outgoing; Fri, 12 Aug 2005 20:36:48 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CIalhG000016 for ; Fri, 12 Aug 2005 20:36:47 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E3eOc-00057s-KD for ietf-provreg@cafax.se; Fri, 12 Aug 2005 14:36:46 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id 77AB313744; Fri, 12 Aug 2005 14:36:33 -0400 (EDT) Date: Fri, 12 Aug 2005 14:36:33 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Services messages in RFC 3730 Message-ID: <20050812183633.GQ23651@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <046F43A8D79C794FA4733814869CDF07C92888@dul1wnexmb01.vcorp.ad.vrsn.com> <42FCE967.8040806@ca.afilias.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42FCE967.8040806@ca.afilias.info> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Fri, Aug 12, 2005 at 02:24:39PM -0400, Michael Young wrote: > certainly other contenders that could result in a schema change (see > http://www.ietf.org/internet-drafts/draft-sullivan-epp-experience-00.txt ). That isn't resolving yet, last I checked, just to warn everyone. A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CIOnlu000279 for ; Fri, 12 Aug 2005 20:24:49 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7CIOnxg020851 for ietf-provreg-outgoing; Fri, 12 Aug 2005 20:24:49 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CIOmoA024472 for ; Fri, 12 Aug 2005 20:24:48 +0200 (MEST) Received: from roaming9.int.libertyrms.com ([10.1.3.239] helo=[127.0.0.1]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E3eD0-0004pO-V0; Fri, 12 Aug 2005 14:24:46 -0400 Message-ID: <42FCE967.8040806@ca.afilias.info> Date: Fri, 12 Aug 2005 14:24:39 -0400 From: Michael Young User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hollenbeck, Scott" CC: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Services messages in RFC 3730 References: <046F43A8D79C794FA4733814869CDF07C92888@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <046F43A8D79C794FA4733814869CDF07C92888@dul1wnexmb01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: myoung@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk >"Superlatives and astonishment aside, there are really three issues here:" Ok perhaps I was being excessive ;-) >"You might have three queues instead of one, with "high >priority" messages going into one queue, "normal priority" messages >going into a second queue, and "low priority" messages going into a >third." I dont see the flexibility to do that as it stands, can you elaborate on that please? >a. It truly is optional. >b. It doesn't complicate other existing implementations. >c. It's common IETF practice to add new features via extensions once >proposed standards are published. Extension development is usually a >good reason to spin up a new working group. >d. It allows us to avoid a core schema change and the resulting new >protocol version. > >Think about d. for a moment. A protocol version rev likely implies an >operational requirement for ALL conforming servers and clients to >support both old and new versions for some TBD period of time. An >extension can be deployed without introducing version management issues A and B I think in case qualify. For C how would suggest this be addressed in an extension? As for D I completely take your point but isnt this ultimately a cost benefit analysis not a defacto "don't go there" decision? For example the poll queue is the only item under discussion at this point, there are certainly other contenders that could result in a schema change (see http://www.ietf.org/internet-drafts/draft-sullivan-epp-experience-00.txt ). Can we really resolve all the raised issues via extensions? If we can would that be less effort on the implementers and users than a protocol change? I think it really depends on the complexity of the changes. With a protocol change the resultant client changes required may be considered minimal by the users involved compared to the gains in capability. An implementer may find running dual protocol less effort than a series of extensions. As always - it depends and we need some feedback beyond ourselves (some registrar feedback would be helpful here). Michael Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CIJl3b000981 for ; Fri, 12 Aug 2005 20:19:47 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7CIJldZ024380 for ietf-provreg-outgoing; Fri, 12 Aug 2005 20:19:47 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ogud.com (ns.ogud.com [66.92.146.160]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CIJj69025945 for ; Fri, 12 Aug 2005 20:19:46 +0200 (MEST) Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7CIJap3090878; Fri, 12 Aug 2005 14:19:37 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <046F43A8D79C794FA4733814869CDF07C92888@dul1wnexmb01.vcorp.ad.vrsn.com> References: <046F43A8D79C794FA4733814869CDF07C92888@dul1wnexmb01.vcorp.ad.vrsn.com> Date: Fri, 12 Aug 2005 14:19:44 -0400 To: "Hollenbeck, Scott" From: Edward Lewis Subject: RE: [ietf-provreg] Services messages in RFC 3730 Cc: "Michael Young" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Keeping in mind that a protocol is about communication of information, not the processing of information: Reading Jay's suggestion carefully, it does not "bar" sending replies as they are now, just makes them an implicit "MAY". Is that intentional/acceptable? At 13:23 -0400 8/12/05, Hollenbeck, Scott wrote: >> -----Original Message----- >> [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Michael Young > >1. Is priority-based messaging needed? I have a hard time imagining that a priority-based message system is important in the context of EPP. EPP is only delivering the messages, there's nothing saying that the recipient can't delay acting on some. From my experience in communications protocols, adding priorities into queues winds up gumming up the pipes. I would reserve prioritization for cases where time critical responses are required or where one stream of messages has a different tolerance for transit latency than another. >Specification issue: if multiple queues are implemented, how does one >let the client deal with that fact? As is, they could be read from in >whatever order the server operator decides to impose on the reader. >That's probably not too helpful. We also need to look at loosening up >the text as Jim suggested. I dislike protocol features with really complicated rules regarding what it means to be conformant. EPP handles a pretty simple client-server conversation, is the benefit of priority queues worth having to define all these new rules? Don't just think of all of the specification ink needed, think of having to roll out new tar files of EPP code too. >c. It's common IETF practice to add new features via extensions once >proposed standards are published. Extension development is usually a >good reason to spin up a new working group. On a tangent - do you mean to say that extensions ought to cause a new WG? Up to now some extensions haven't been discussed in a (new) WG. >d. It allows us to avoid a core schema change and the resulting new >protocol version. > >Think about d. for a moment. A protocol version rev likely implies an >operational requirement for ALL conforming servers and clients to >support both old and new versions for some TBD period of time. An >extension can be deployed without introducing version management issues. I'm not so worried about IETF impacts (like, "respin at PS") as I am about software that has been distributed. That's been the achillies heel of many an old protocol. Do we really gain by no longer delivering messages to the initiator has Jay suggests? (Or can the initiator be counted on to just dump the extraneous message?) Do we really gain with priority queueing? I'm not sure I'd say yes or no to the first question, my gut tells me that answer to the latter is no. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CHklIt009389 for ; Fri, 12 Aug 2005 19:46:47 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7CHklNE029072 for ietf-provreg-outgoing; Fri, 12 Aug 2005 19:46:47 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CHkkq7018341 for ; Fri, 12 Aug 2005 19:46:46 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E3dcD-0003pW-JK for ietf-provreg@cafax.se; Fri, 12 Aug 2005 13:46:45 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id 7521113744; Fri, 12 Aug 2005 13:46:32 -0400 (EDT) Date: Fri, 12 Aug 2005 13:46:32 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Services messages in RFC 3730 Message-ID: <20050812174632.GK23651@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <046F43A8D79C794FA4733814869CDF07C92888@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF07C92888@dul1wnexmb01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Fri, Aug 12, 2005 at 01:23:43PM -0400, Hollenbeck, Scott wrote: > to everyone (as you say, "it should all be OPTIONAL"), documenting a new > feature (adding priority marks to messages and allowing a client to > specify how they wish to deal with the priorities) in a standard > extension seems like the least intrusive way to make the functionality > available for these reasons [&c.] I think an extension would be a good idea, too, as long as we make the current poll queue optional. In fact, if the requirements in RFC 3730 2.9.2.3 were a little weaker, I'd already have proposed an extension. It might be, in fact, that the only thing needed to facilitate that is a weakening of this: "Service messages MUST be created for all clients affected by an action on an object." This is in line with the suggestion Jim already made. I'm all for making any changes as painless as possible. Because I did have to support two protocols in production at one time, I am happy to agree with your observation that keeping both going at once is going to be something shy of fun. So if there is some way to address the issues folks have with the existing protocol without changing it, I'm certainly not opposed. (But also, of course, if we're forced to accept a protocol change, I'd much rather see it happen now, before the installed base gets any bigger.) A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CHO1PK028482 for ; Fri, 12 Aug 2005 19:24:01 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7CHO1C2028688 for ietf-provreg-outgoing; Fri, 12 Aug 2005 19:24:01 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CHNxo9011827 for ; Fri, 12 Aug 2005 19:24:00 +0200 (MEST) Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.1/8.12.11) with ESMTP id j7CHowa7032520; Fri, 12 Aug 2005 13:50:58 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 13:23:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ietf-provreg] Services messages in RFC 3730 Date: Fri, 12 Aug 2005 13:23:43 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07C92888@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-provreg] Services messages in RFC 3730 Thread-Index: AcWetXmWpEDQWlR6QCCvtczKRXsvmgAdnpYAAAPpWyAABKxE0A== From: "Hollenbeck, Scott" To: "Michael Young" , X-OriginalArrivalTime: 12 Aug 2005 17:23:58.0109 (UTC) FILETIME=[9F79ACD0:01C59F62] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j7CHO0o9009005 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > -----Original Message----- > From: owner-ietf-provreg@cafax.se > [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Michael Young > Sent: Friday, August 12, 2005 10:10 AM > To: ietf-provreg@cafax.se > Subject: RE: [ietf-provreg] Services messages in RFC 3730 > > Well please see my comments below. You all know I don't > weigh in often but > frankly I needed to say something on this rather painful > debate. However, > before I start arguing heavily, I want to personally > acknowledge the huge > amount of effort Scott has put into this work thus far; I have been a > benefactor of those efforts and its not something that I will cease to > appreciate. [snip] > >"It typically either gets ignored or everything becomes > "high" priority in > someone's eyes." > > That's a very old line of argument in history and one that I > can't believe I > am hearing applied to this situation. Who is anyone to make > that assertion? > Its saying to someone I am going to dictate how you want your > messages and > in what order you must read them because if I give you the > freedom to make a > choice - you are too stupid to know what to do with it. > While there are > order of operation arguments applicable to types of > notifications, there is > no technical reason you can't populate a priority rating to a message > (define a type) and mark the sequence. At that point if a > registrar wants > to eat his pudding before they've had their supper then > that's their poor > choice. For that matter the Registry Operator can enforce > FIFO retrieval > within the priority class but it should all be OPTIONAL if you want a > protocol the industry can stay complaint with. Superlatives and astonishment aside, there are really three issues here: 1. Is priority-based messaging needed? You obviously think so assuming that messaging isn't optional, so let's continue. 2. If so, is this a specification issue or an implementation detail? I believe it's both. Implementation detail: how you implement your message queuing system is up to you. You might have three queues instead of one, with "high priority" messages going into one queue, "normal priority" messages going into a second queue, and "low priority" messages going into a third. As registry operator you make an implementation decision to determine which messages go where. The command can then be implemented to read from them in whatever order makes sense to you. Specification issue: if multiple queues are implemented, how does one let the client deal with that fact? As is, they could be read from in whatever order the server operator decides to impose on the reader. That's probably not too helpful. We also need to look at loosening up the text as Jim suggested. 3. If a specification issue, should something new be added to the core specs or should something new be defined in an extension? Given that we're talking about adding a new feature that may or may not be useful to everyone (as you say, "it should all be OPTIONAL"), documenting a new feature (adding priority marks to messages and allowing a client to specify how they wish to deal with the priorities) in a standard extension seems like the least intrusive way to make the functionality available for these reasons: a. It truly is optional. b. It doesn't complicate other existing implementations. c. It's common IETF practice to add new features via extensions once proposed standards are published. Extension development is usually a good reason to spin up a new working group. d. It allows us to avoid a core schema change and the resulting new protocol version. Think about d. for a moment. A protocol version rev likely implies an operational requirement for ALL conforming servers and clients to support both old and new versions for some TBD period of time. An extension can be deployed without introducing version management issues. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CGFuFx016805 for ; Fri, 12 Aug 2005 18:15:56 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7CGFui7013834 for ietf-provreg-outgoing; Fri, 12 Aug 2005 18:15:56 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ogud.com (ns.ogud.com [66.92.146.160]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CGFtj0020242 for ; Fri, 12 Aug 2005 18:15:55 +0200 (MEST) Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7CGFn9e090357; Fri, 12 Aug 2005 12:15:49 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <046F43A8D79C794FA4733814869CDF07C0AAAF@dul1wnexmb01.vcorp.ad.vrsn.com> References: <046F43A8D79C794FA4733814869CDF07C0AAAF@dul1wnexmb01.vcorp.ad.vrsn.com> Date: Fri, 12 Aug 2005 12:15:55 -0400 To: "Hollenbeck, Scott" From: Edward Lewis Subject: RE: [ietf-provreg] EPP Document Updates Cc: "Klaus Malorny" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 16:43 -0400 8/3/05, Hollenbeck, Scott wrote: >> From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de] >> One thing that really puzzles me in this context is that a >> registrar cannot >> allow the disclosure of one component (that is normally not >> disclosed) and to >> disallow the disclosure of another component (that his >> normally disclosed) at >> the same time. But maybe I am just misunderstanding the >> wording. I think I have >> to reread this at a later point in time. > >Remember that the whole "disclose" thing got crammed into the spec at >the last minute at the demand of the IESG. There were parts that didn't >make sense then (to me anyway) and I'm sure they still don't make sense >now. This is another one of those things that we should really consider >removing (if no one is using it) or revising (if it's not quite right). Our implementers support dumping the discloser elements as currently specified. The issue is that the communication is "binary" (ON/OFF, YES/NO). There is legacy data that is not tagged (it wasn't on collection), i.e., it should be NULL, UNSPEC, or DON'T CARE. One bug is that on "create" the submission might be left unspecified because the client "doesn't care". But on "info" the submission, if un"tagged" is assumed to follow default behavior. Doesn't seem very symmetric in a protocol sense. A suggestion is made to also make this a per time tag (but I have a sneaking submission that we nixed that in the discussions in early/January 2003). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CG7isj019486 for ; Fri, 12 Aug 2005 18:07:44 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7CG7iCg007630 for ietf-provreg-outgoing; Fri, 12 Aug 2005 18:07:44 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ogud.com (ns.ogud.com [66.92.146.160]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CG7f3A016677 for ; Fri, 12 Aug 2005 18:07:43 +0200 (MEST) Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j7CG7WtD090317; Fri, 12 Aug 2005 12:07:33 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200508041712.j74HCbhm018679@ns01.afilias.info> References: <200508041712.j74HCbhm018679@ns01.afilias.info> Date: Fri, 12 Aug 2005 12:07:12 -0400 To: From: Edward Lewis Subject: RE: [ietf-provreg] EPP Document Updates Cc: ed.lewis@Neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.52 on 66.92.146.160 Sender: owner-ietf-provreg@cafax.se Precedence: bulk At 13:13 -0400 8/4/05, Ram Mohan wrote: >We should consider re-initiating the provreg group. A number of changes are >due in EPP, and enough registries are now using EPP that actual practice has >exposed both issues and deviances from the protocol. Further, registries >have implemented extensions that, in some cases, make more sense to be part >of a standard -- the case of what happened with RGP is relevant here. I think it's clear that there's a demand (as in supply and demand) for coordination of work involving the EPP protocol. However, I don't think there's justification for an IETF-style working group. I think there are maybe three factors that prevent the EPP documents from being the epitome of perfection. 1) They were produced by humans. (Meaning errata are needed.) 2) The audience of interest grew as the specifications were put to RFC. (Meaning that elements were designed for domain specific applications.) 3) The protocol is supposed to be extensible and future looking. These are three reasons why there is a demand for EPP coordination. But is this demand best met by an IETF WG? Reason #1 is fairly self-explanatory, a number of textual edits have been identified. If RFC documents were "living" these changes would have been made without thought. An IETF WG isn't needed for this. Reason #2 is a bit more telling of the culture of the IETF and why I think an IETF-style WG might not be the correct path at this moment. The IETF isn't the right venue to attract interest of registries. For example, CENTR has a higher concentration of attendees that have applicable experience and interest in what is happening in EPP now. There was a time in which EPP development needed the input of other protocol engineering experts. EPP has an extension mechanism that separates the process of adding new messages to the protocol from issue dealing with security and transport. During the IETF run, we had to wrestle with the question of whether we could define SMTP as a transport for EPP elements - we decided no for various reasons. This is an IETF question. How to encode ENUM validation data into EPP is much less of a question that needs input from, say, the SMTP experts. I'm sure another run of the PROVREG WG would gather a different and probably more well-rounded set of participants than the first try. But still, there is no guarantee that we get who we need. Reason #3 is based on the existence of the final RFC of the original EPP documents (3735 I think). Basically, there is a statement from the WG on how to proceed with extensions. I don't believe this is enough, certainly, but I can't imagine how an IETF WG would improve. For one, just because guidelines are documented doesn't mean that "generations" of following implementers will grok and comply fully. My other experience is in DNS - looking closely at that I see there was about a decade between the original specifications and the beginning of a "reformation" in which the ad hoc coding practices had "voided" some of the basic assumptions about the DNS. The result is a plethora of badly written code screaming for backwards compatibility. Another factor here is that there are a need to reign in on some extension efforts. Sometimes there is too much freedom to expand and you wind up with a bloated protocol. E.g., let's say each of the 200 or so registries out there decides to extend EPP in some unique way. It's the registrars that suffer trying to maintain a client code base with the 200 or so unique extensions. I don't think this is an effort suited to the IETF, especially because it is operations (and market) based. What would be a good reason to reconvene an IETF (style) WG? A reason that requires an engineering solution, a reason that requires cross-checking with other protocol domain engineers. I liked the CENTR meeting that happened the day before the IETF in Paris. It was a dedicated registry meeting yet co-located with the IETF engineering meetings. I realize that CENTR is not the open forum that the IETF is, and it is not the only interested party, but it is a good example and has a significant concentration of interest in EPP. To emphasize this one more time - CENTR's meeting is an example of a non-IETF group that resulted in some interesting talk on EPP. An example. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CEMETL016717 for ; Fri, 12 Aug 2005 16:22:14 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7CEME5w026988 for ietf-provreg-outgoing; Fri, 12 Aug 2005 16:22:14 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CEMDAH015032 for ; Fri, 12 Aug 2005 16:22:13 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E3aQG-0005vq-L3 for ietf-provreg@cafax.se; Fri, 12 Aug 2005 10:22:12 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id 8E01213744; Fri, 12 Aug 2005 10:21:59 -0400 (EDT) Date: Fri, 12 Aug 2005 10:21:59 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Services messages in RFC 3730 Message-ID: <20050812142159.GB23651@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <046F43A8D79C794FA4733814869CDF07C927A9@dul1wnexmb01.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF07C927A9@dul1wnexmb01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi Scott, Thanks for your comments. On Fri, Aug 12, 2005 at 07:06:00AM -0400, Hollenbeck, Scott wrote: > > I don't see how you can interpret the queuing system as optional. The > text is completely clear about the need to create and enqueue the > messages. "dequeue and deliver messages" does NOT mean "route to > /dev/null". It can mean that messages be delivered via email, made > available for retrieval via ftp, etc. > > "dequeue and deliver". Not "throw away blindly". You're right that I'm probably overstating the case. But consider cases where the client just doesn't do anything in time for the notification to have been any use. For instance, in the ICANN world, we have 5 days in which a losing registrar may refuse a transfer (subject to a bunch of policy rules). If a transfer request message hasn't been picked up after five days, it's worthless. Worse, it's clogging the message queue, and delaying the delivery of other, potentially useful messages. The only sane thing to do with such a message is to throw it away. As a result of this sort of thing, as near as I can tell, at least some clients are completely ignoring the poll queue. We therefore have to support other kinds of notification mechanisms in parallel to the poll queue, which is a pointless duplication of effort. And as near as I can tell, this is because people find the poll queue less useful than alternative mechanisms. I was hoping to make it more useful. > What defines "explicitly required", though? I thought Jim's definition > was pretty reasonable: if you're a party to a transaction, but not the > recipient of a response, you get a message. We can't just limit > ourselves to transactions that cost money in the ICANN TLD world. No, I totally agree; and I thought Jim's definition was a good one, too; I support it. I absolutely do not want to propose anything that is restricted to the ICANN TLD world, because I think EPP has lots of potential outside that world. In fact, my view is that there are still some things in the protocol and mapping documents that are too ICANN-TLD-centric, and turn out to be more policy shaped than protocol shaped. (Just so I'm clear: I think that's an accident, and it's just the result of the collective experience of those who were working on the original protocol definition at the time the WG was active.) > On the priority-based multiple queue thing: priority is relative. It > typically either gets ignored or everything becomes "high" priority in Hrm. This makes me think that "priority" is an infelicitous word choice. What about "facility"? I'm basically thinking of something like syslog on UNIX here. You have some arbitrary tags that tell you what is generating the message; and that tag allows you to apply additional rules, depending on the tag. It's sure useful to sysadmins; I sort of think it might be useful to clients of a repository as well. > someone's eyes. I don't get a good feeling about adding complexity to > the mechanism if making it simpler is a viable option. What about the notion that you could give everything the same priority (or facility, or whatever we want to call it) value, so that you'd have something just like the current mechanism? For that matter, the attribute could be completely OPTIONAL, and its absense an indication that the client wants the next message in the queue regardless of facility. In that case, those who have implemented the current mechanism and don't want to do any more work wouldn't have any work they need to do. I could be, of course, completely wrong about the utility of a mechanism like this; I just know that people seem not to be using the poll queue as I'd like, and I'm trying to figure out how to persuade them to use it (so I can stop sending reams of email). A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CEASlS023729 for ; Fri, 12 Aug 2005 16:10:28 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7CEASBS008883 for ietf-provreg-outgoing; Fri, 12 Aug 2005 16:10:28 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CEARaK021061 for ; Fri, 12 Aug 2005 16:10:27 +0200 (MEST) Received: from roaming9.int.libertyrms.com ([10.1.3.239] helo=DUN911) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E3aEq-0005cn-FF for ietf-provreg@cafax.se; Fri, 12 Aug 2005 10:10:24 -0400 From: "Michael Young" To: Subject: RE: [ietf-provreg] Services messages in RFC 3730 Date: Fri, 12 Aug 2005 10:10:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <046F43A8D79C794FA4733814869CDF07C927A9@dul1wnexmb01.vcorp.ad.vrsn.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWetXmWpEDQWlR6QCCvtczKRXsvmgAdnpYAAAPpWyA= Message-Id: X-SA-Exim-Mail-From: myoung@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk Well please see my comments below. You all know I don't weigh in often but frankly I needed to say something on this rather painful debate. However, before I start arguing heavily, I want to personally acknowledge the huge amount of effort Scott has put into this work thus far; I have been a benefactor of those efforts and its not something that I will cease to appreciate. >"I don't see how you can interpret the queuing system as optional. The text is completely clear about the need to create >and enqueue the messages. "dequeue and deliver messages" does NOT mean "route to /dev/null". It can mean that messages >be delivered via email, made available for retrieval via ftp, etc." >"dequeue and deliver". Not "throw away blindly". >"Servers MAY implement other mechanisms to dequeue and deliver > messages if queue maintenance needs exceed server resource consumption > limits." Lets look at this line for a second, first of all taken in context (in other words not dropping the sentence after "dequeue and deliver") it seems to be describing an out for the operator and the registrar if the message queue gets out of control. It is no less and no more specific than that, near as I can tell from my understanding of the English language. If you meant "dequeue and deliver via an alternate mechanism", then that's what you should say. Frankly it's a cosmetic change and I don't even see why folks are wasting breath - it should just be modified. Of course the minute you do that you can now output the messages to a proprietary priority based queue or other such system and then what's point of having the queue defined in the protocol in the first place? So really this part of the discussion seems to be missing the larger point I have commented on further below. >"My personal preference leans towards "some class of service messages (preferably "all the ones not explicitly required") >be made optional." >What defines "explicitly required", though? I thought Jim's definition was pretty reasonable: if you're a party to a >transaction, but not the recipient of a response, you get a message. We can't just limit ourselves to transactions that >cost money in the ICANN TLD world. >On the priority-based multiple queue thing: priority is relative. It typically either gets ignored or everything becomes >"high" priority in someone's eyes. I don't get a good feeling about adding complexity to the mechanism if making it >simpler is a viable option." Personally I don't have any issue with making a completely inadequate mechanism more complex. In case this minimally more complex. >"On the priority-based multiple queue thing: priority is relative." Right that's exactly the point its relative to the registry operator and the registrar and the policies they are working under. >"It typically either gets ignored or everything becomes "high" priority in someone's eyes." That's a very old line of argument in history and one that I can't believe I am hearing applied to this situation. Who is anyone to make that assertion? Its saying to someone I am going to dictate how you want your messages and in what order you must read them because if I give you the freedom to make a choice - you are too stupid to know what to do with it. While there are order of operation arguments applicable to types of notifications, there is no technical reason you can't populate a priority rating to a message (define a type) and mark the sequence. At that point if a registrar wants to eat his pudding before they've had their supper then that's their poor choice. For that matter the Registry Operator can enforce FIFO retrieval within the priority class but it should all be OPTIONAL if you want a protocol the industry can stay complaint with. Further: >"What defines "explicitly required", though? I thought Jim's definition was pretty reasonable: if you're a party to a >transaction, but not the recipient of a response, you get a message." It seems to me this argument supports exactly why a priority-based multiple queue is a necessity. If you follow Jim's suggestion you are saying then that it makes sense to populate the poll queue on all Registry Operator maintenance activities. Every time you touch an object according to well communicated policy behavior you have to populate the poll queue. Well there's a four letter word for that in this industry "spam". Imagine if you had no choice but to read through your email in a enforced FIFO retrieval when you had those kinds of volumes (wait a second no imagining needed, its what's defined currently). Its absolutely off the map and it will almost guarantee eventual non-compliance or foolish workarounds of the protocol(see earlier comment). While it should certainly be optional, a priority setting mechanism in the poll queue is a basic and very necessary feature. While I realize no one wants to step up and do more work than necessary on these documents, its clear that after several years of banging our heads against walls like this one some changes are required. This is an emerging marketplace and the protocol needs to evolve as required if we expect implementers to remain really compliant with it. I think however its important that we see some volunteers here to assist with this, so that Scott is not again burdened with what was frankly an unjust amount of the work. Michael Young Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CB6INY015219 for ; Fri, 12 Aug 2005 13:06:18 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7CB6IWZ005750 for ietf-provreg-outgoing; Fri, 12 Aug 2005 13:06:18 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7CB6GMB000278 for ; Fri, 12 Aug 2005 13:06:17 +0200 (MEST) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id j7CBXYZK026247; Fri, 12 Aug 2005 07:33:34 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 07:06:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ietf-provreg] Services messages in RFC 3730 Date: Fri, 12 Aug 2005 07:06:00 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07C927A9@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-provreg] Services messages in RFC 3730 Thread-Index: AcWetXmWpEDQWlR6QCCvtczKRXsvmgAdnpYA From: "Hollenbeck, Scott" To: "Andrew Sullivan" , X-OriginalArrivalTime: 12 Aug 2005 11:06:14.0570 (UTC) FILETIME=[DAF410A0:01C59F2D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j7CB6HMB022105 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > -----Original Message----- > From: owner-ietf-provreg@cafax.se > [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Andrew Sullivan > Sent: Thursday, August 11, 2005 4:30 PM > To: ietf-provreg@cafax.se > Subject: Re: [ietf-provreg] Services messages in RFC 3730 > > On Thu, Aug 11, 2005 at 02:24:22PM -0400, James Gould wrote: > > All, > > > > I believe the current text describing who receives service > messages in RFC > > 3730 is too strict. The text that I'm referring to reads: [snip] > To me, one of the strange things about the service message > description in the RFC is that it appears to be both mandatory and > optional. On the one hand, we have, "Service messages MUST be > created for all clients affected by an action on an object." On the > other hand, we have, "Servers MAY implement other mechanisms to > dequeue and deliver messages if queue maintenance needs exceed server > resource consumption limits." Since one could easily construct an > argument that any queue at all causes too much overhead, the latter > permission amounts to a permission that the message queue be hooked > up to /dev/null. Indeed, the description of service messages appears > to require that any effect at all in the repository not explicitly > requested by the client causes a service message to be generated. So > the repository operator has to be able at least to purge the queue > sometimes, because otherwise it'll consume all the server's > resources. Hence the provision that servers may use some other > mechanism. I don't see how you can interpret the queuing system as optional. The text is completely clear about the need to create and enqueue the messages. "dequeue and deliver messages" does NOT mean "route to /dev/null". It can mean that messages be delivered via email, made available for retrieval via ftp, etc. "dequeue and deliver". Not "throw away blindly". [snip] > If this approach is unacceptable, I think that the message > queue should > either be made entirely optional, or that some class of service > messages (preferably "all the ones not explicitly required") be made > optional. The way 3730 reads today, the message queue is a > bottleneck, and I don't think it was intended to be that way. My personal preference leans towards "some class of service messages (preferably "all the ones not explicitly required") be made optional." What defines "explicitly required", though? I thought Jim's definition was pretty reasonable: if you're a party to a transaction, but not the recipient of a response, you get a message. We can't just limit ourselves to transactions that cost money in the ICANN TLD world. On the priority-based multiple queue thing: priority is relative. It typically either gets ignored or everything becomes "high" priority in someone's eyes. I don't get a good feeling about adding complexity to the mechanism if making it simpler is a viable option. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7BKTqJW014608 for ; Thu, 11 Aug 2005 22:29:52 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7BKTqNm003613 for ietf-provreg-outgoing; Thu, 11 Aug 2005 22:29:52 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7BKToTL013629 for ; Thu, 11 Aug 2005 22:29:51 +0200 (MEST) Received: from dba3.int.libertyrms.com ([10.1.3.12] helo=dba3.int.libertyrms.info ident=postfix) by mail.libertyrms.com with esmtp (Exim 4.22) id 1E3JgT-0005NF-Eh for ietf-provreg@cafax.se; Thu, 11 Aug 2005 16:29:49 -0400 Received: by dba3.int.libertyrms.info (Postfix, from userid 1019) id 8C45913744; Thu, 11 Aug 2005 16:29:33 -0400 (EDT) Date: Thu, 11 Aug 2005 16:29:33 -0400 From: Andrew Sullivan To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] Services messages in RFC 3730 Message-ID: <20050811202933.GM3904@libertyrms.info> Reply-To: Andrew Sullivan Mail-Followup-To: Andrew Sullivan , ietf-provreg@cafax.se References: <42F276FB.5090804@nic.ve> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-SA-Exim-Mail-From: andrew@libertyrms.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false Sender: owner-ietf-provreg@cafax.se Precedence: bulk On Thu, Aug 11, 2005 at 02:24:22PM -0400, James Gould wrote: > All, > > I believe the current text describing who receives service messages in RFC > 3730 is too strict. The text that I'm referring to reads: I think you're right. More generally, if I'm reading you correctly, the principle is that only the uninformed parties are subject to notification by poll queue for any case where a service message is required. But I think your rewording doesn't go far enough. (I put some discussion of this in the draft I put up recently -- it's been submitted since the Paris meeting, but it's still currently only available at , in case anyone is waiting, breathless). To me, one of the strange things about the service message description in the RFC is that it appears to be both mandatory and optional. On the one hand, we have, "Service messages MUST be created for all clients affected by an action on an object." On the other hand, we have, "Servers MAY implement other mechanisms to dequeue and deliver messages if queue maintenance needs exceed server resource consumption limits." Since one could easily construct an argument that any queue at all causes too much overhead, the latter permission amounts to a permission that the message queue be hooked up to /dev/null. Indeed, the description of service messages appears to require that any effect at all in the repository not explicitly requested by the client causes a service message to be generated. So the repository operator has to be able at least to purge the queue sometimes, because otherwise it'll consume all the server's resources. Hence the provision that servers may use some other mechanism. Now, part of the reason for this provision is obviously that sometimes clients won't clear out their queues. My impression is that the "won't clear out" problem is exacerbated by the FIFO nature of the queue: I know that our registrars want a notification of things that possibly cost them money (like a transfer loss or an auto-renewal) way more than they want a notice about something that costs them nothing (like denying a transfer request). I'd therefore like to suggest the addition of a "priority" attribute to the command. This would allow server operators to put messages of different importance in different queues, and to publish different retention policies for their different queues. If a server operator didn't want to go to the trouble of administering different queues, the operator could still get the current behaviour by setting all the priorities to the same value. A magic priority value (I've suggested 1000, but some other value will do) could be used to indicate "give me the next highest-priority message". This approach has the advantage not only that different kinds of messages can be put into different queues; but that for some of them, the server could publish (out of band) a retention policy that says, "queues with priorities 4, 5, and 6 will be retained for 0ms," which is an effective way of tagging certain kinds of messages as ones that will never be delivered through the poll queue (internally, an implementer could just as well drop those messages in the bit bucket). If this approach is unacceptable, I think that the message queue should either be made entirely optional, or that some class of service messages (preferably "all the ones not explicitly required") be made optional. The way 3730 reads today, the message queue is a bottleneck, and I don't think it was intended to be that way. Thoughts? A -- ---- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada M2P 2A8 +1 416 646 3304 x4110 Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7BIOIlH006948 for ; Thu, 11 Aug 2005 20:24:18 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7BIOIWN014219 for ietf-provreg-outgoing; Thu, 11 Aug 2005 20:24:18 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7BIOHLr005948 for ; Thu, 11 Aug 2005 20:24:18 +0200 (MEST) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id j7BIpQvx002071 for ; Thu, 11 Aug 2005 14:51:26 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 14:24:16 -0400 Received: from 10.131.29.3 ([10.131.29.3]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Thu, 11 Aug 2005 18:24:15 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 11 Aug 2005 14:24:22 -0400 Subject: [ietf-provreg] Services messages in RFC 3730 From: James Gould To: Message-ID: In-Reply-To: <42F276FB.5090804@nic.ve> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3206615064_2502336" X-OriginalArrivalTime: 11 Aug 2005 18:24:16.0021 (UTC) FILETIME=[E1817C50:01C59EA1] Sender: owner-ietf-provreg@cafax.se Precedence: bulk > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3206615064_2502336 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable All, I believe the current text describing who receives service messages in RFC 3730 is too strict. The text that I'm referring to reads: > Service messages MUST be created for all clients affected by an action o= n an > object. For example, actions MUST be reported to both the cli= ent > that requests an object transfer and the client that has the authority t= o > approve or reject the transfer request. This means that the client making the request also receives a poll message even through the client receives the same information in the response and can receive the same information with a transfer query. I would prefer that the text read like the following: > Service messages MUST be created for all clients affected by an action o= n an > object that did not directly execute the action. For example, > actions MUST be reported to both the client that requests an object tran= sfer > and the client that has the authority to approve or reject the transfer > request for a server action. Based on the update text, the client that MUST receive a poll message for each transfer operation is below (requesting client is the client that executed the transfer request and the owning client is the current owning client of the object): * Transfer Request =AD owning client * Transfer Approve =ADrequesting client * Transfer Reject =AD requesting client * Transfer Cancel =AD owning client * Transfer Auto Approve =AD owning client and requesting client * Transfer Auto Reject =AD owning client and requesting client --=20 JG=20 James F. Gould VeriSign Naming and Directory Services jgould@verisign.com This message is intended for the use of the individual or entity to which i= t is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. Any unauthorized use, distribution, or disclosure is strictly prohibited. If you have received this message in error, please notify sender immediately and destroy/delete the original transmission --B_3206615064_2502336 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Services messages in RFC 3730 All,<= BR>
I believe the current text describing who receives service messages in RFC = 3730 is too strict.  The text that I'm referring to reads:

Service messages MUST be  created for all c= lients affected by an action on an object. For  example, <transfer&g= t; actions MUST be reported to both the client that  requests an object= transfer and the client that has the authority to  approve or reject t= he transfer request.

This means that the client making the request also receives a poll message = even through the client receives the same information in the response and ca= n receive the same information with a transfer query.  

I would prefer that the text read like the following:

Service messages MUST be  created for all clients = affected by an action on an object that did not directly execute the acti= on. For  example, <transfer> actions MUST be reported to both= the client that  requests an object transfer and the client that has t= he authority to  approve or reject the transfer request for a server= action.


Based on the update text, the client that MUST receive a poll message for e= ach transfer operation is below (requesting client is the client that execut= ed the transfer request and the owning client is the current owning client o= f the object):

  • Transfer Request – owning client
  • Transfer Approve –requesting client
  • Transfer Reject – requesting client
  • Transfer Cancel – owning client
  • Transfer Auto Approve – owning client and requesting clie= nt
  • Transfer Auto Reject – owning client and requesting clien= t


--

JG

James F. Gould
VeriSign Naming and Directory Services
jgould@verisign.com

This message is intended for the use of the individual or entity to which i= t is addressed, and may contain information that is privileged, confidential= and exempt from disclosure under applicable law. Any unauthorized use, dist= ribution, or disclosure is strictly prohibited. If you have received this me= ssage in error, please notify sender immediately and destroy/delete the orig= inal transmission

 --B_3206615064_2502336-- Return-Path: Received: from localhost (87.Red-80-35-179.pooles.rima-tde.net [80.35.179.87]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j7AJKuS3020674 for ; Wed, 10 Aug 2005 21:20:57 +0200 (MEST) Date: mié, 10 ago 2005 21:21:29 +0100 From: "Frankel" To: Subject: Any med for your girl to be happy! Message-ID: <000a01c59d80$883b0070$0100a8c0@msge> MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C59D99.ABD642B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C59D99.ABD642B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C59D99.ABD642B0" ------=_NextPart_001_0007_01C59D99.ABD642B0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_0007_01C59D99.ABD642B0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
3D""=20
------=_NextPart_001_0007_01C59D99.ABD642B0-- ------=_NextPart_000_0006_01C59D99.ABD642B0 Content-Type: image/gif; name="erec.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c59d80$8686c0c0$0100a8c0@sanya> R0lGODlhWAIsAdUAAP//////zP/MzP/Mmf/MZv/MAMz//8z/zMzM/8zMzMzMmczMZszMAMyZM8yZ AMxmM8xmAJnM/5nMmZmZM5lmAJkzZpkzM5kzAGbM/2bMzGbMAGaZmWZmzGZmZmYzZmYAZmYAM2YA ADOZzDOZADNmzDNmZjNmADMzmTMzMzMzADMAZjMAMzMAAABmzABmZgBmAAAzmQAzAAAAZgAAMwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAABYAiwBQAb/QIBw SCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+AgYKD hIWGh4iJiouMjVMBHwYBFy6RkyJFl0UDKxFCAyoGTAEhmJyeAKQYBDAGDS0AECKaUKSYtEUNLiGw SapCBDKiwMKbncaoRLZWp6dCv0+gE6siFZIhGM8X2Zesw0fOAKAG4dBH5uLHqdi+FyLe6aiq0BCw 6Ezh5di42r31ROGQ5At1LZsydrFgqRt3ENM6g5/UzUM4hJ+ji0S2ATxxgOKae7U81mGIBaQfSMMa FMPIsqXLjyJfyjxjcqbNmziNEGhBShgE/wzQJgF1J6RBqyXliIoL9XAUwlO0xukD+lRdPG0OSRoh lUHjM4RCp74K4MGDK4dL/kFrJnEfwldfIbZzaJRcW6oG4dZEEmxYUI0m+wJrBVdWkX9NKyrVKtAq sW/oojIVYjinZYwEZsi7QIOG5iqZk52LeWhS588zGSdSfbl1zsAwHogGIBig460hhA1AceJbbQEI 4iYWCqABauFEgCMffeuCvZjGZzNP5dy2vNzkeF9r3ov2jBQGlSeePum5XOp0hWlqQMO8tqHPV55T irWo/CLif5GyVx1k9IbU8RffN5mItF57tBEGiyy0qFQQfsENh51rFFZo4YUYZqjhhhx26P/hhyDi c8ICLVyQgQURkNLZadJFhIpWtS0lCYrrrOhZi48RV9tEeXU3mlx/UWXjcXzdNwALCA5xZJLQ6BXC kPLQ6MsHB1yAgggDkKDNis/RcNRXULbDZRK1edOkjzsa+OSXUyzZi4oranbPmeOBGSeO1I0Z5EAE 5tLcLezsVwQBXnYEEVRqGoTSEIjV2NlRNUHAJm5oLQdVJCodYMmTLBJR2Xj1wOmlKChlGgmjPlJW aQN/1hnIXm8EBAyRa7BWRmghjmErG7j6QppLu0oBax6kdPDoMITSIIKT5xW1onpgaZTsDBKw0MKS na16p5g0FBOkkrelqahX7HXK12nV8hT/LTdPyqDAZLg1W9y283a2Urk3DhEjdZPiS2smF7BpWrfI ZstsE6IimPCbnCrc8KiLFgfts6Q+3Iqok+LW7bsPDmowwxuHgq2yStQUo4ruhvItbStWekSyJOdJ 8BKTCMzZzCwrezDC7XIs80oDe0vakS6fBEIK9liilINI9CSKpNfIKeVjyC0qAKlLEyluEkzXJQ4L GDjjdCwXLw3teXSSIjUqXWdM85PsDpVenwfJWyYNGERnWNt0q0q2ATsBcDV6rrrK99+x3NfE4Jqo GDfiECjuRaNrqfxrgY/PSd9hqcabY6DVMYpWoxUZuLlikuf6xbBiQICzFqyrLvvstNdu//vtuOeu ++689+7778AHL/zwVDCtzGKWjyv3J8kX6dfpZB47HqLyJlRyKWSmTrqstAEdcN9IuF6p6/8aQX6U KXrVdFXpZ9W8UwZJdVfNBErm19TE56///vz37///AAygAN8AAdQEIELlEhoGXJekegmtK/kKGoHw 5bZPWGsICfiZbyhmnS29Dlvl0xcMFKClrUCvdAbpCzT2dZAMPOk4CawYBEPowQ0wRYIWNJcDIaO+ Afrwhx6KHRCHSMQiGvGISLwVDfnQKzXgqzsM7Jz5pKcksMUKXlcQYhK3qASY4c1ZLFqZv1L0q33h K3WOwhnMHBIpKZowYzGaVrpqlLKOEf9BjhdEwhm/EcXS3QdfaOshbow1qiGMUYgo8xkOR6YtcxGN i5CMpCQnScnZFeCSmMykJjfJyU56EpOVDKXupmKRIJWyjN4rWhLqAZc7es8fsOCT5mBZhE6aoAAx YEABQqABTNJAl56EQC8zyUtMsgCYl6xbjk4XOz5NBUAWEaU0p0nNalrzmtjMpja3yc1uevOb4Ayn OMdJznKa85zoTKc618nOdrrznfCMpzzn6U21eSJiMTSkvZ7XGRuC72vmwiErKECDrqAmn0kAYTLy +UiJgY8rL7znzRTHvYAoVCcVJBzA9lmLHg6AI9iIIj+8Np/OlOCGE/0nA1c0Lo7OZ1X/ZeNo2kIw QzyBKxk4BGMhYWak25iwnwThCmc+k7abnVQUF11pZ1o6M6HmC4ySgwc9CaHFO1TVCSRFWOjSkNUQ lWeqmxhRiU5ERuV1TxKCvCMMFiCCn8hGZg10EwoPEqb12W0l3ijMLB5Gw4E5THl8Wl9d6TfXwh5v THxRUCzeATS3KC9hn1Gh+rgHVmleFRw+vQNl4deGy/qhiVIAbRq418RoakyHlU1D5K7hHuqMK6PI IMIYgdEyXxGSTbPFYbGo6CLZ0stzk5DTujRIGQF1EV3WCgAIJkDFnCZrWd1ZI82+pxiXPndnTtia a2mbLVciS7GGwWMvpKvTJV7Fu4bV/6e5CFW91JJhTmA5FdU6uEpMQC1w84XvF3/BN3sGgEZCZBxR /CulwyFBwJUKh2HuCwsEnzUuAcYaoNamUQfNdL/sgFri/hkZsz1UTcWAGoHZVgyvORhyaBxxYuDC Xr3NwsMq9qx7x+k6NGZIxjPOsY53bBOP9uYmkbmcHWBFCkjxwlft5QOOGxEsfvmlYY3dFnnhqygq 3cxGMOiIjQB1ntUyKqOicsiUsZeKTWH5GjbqkkwfBig2WtlGj9IyYp28nD9IFQxLjuSdv/DRf/JY Q2vpxEwD6bKVoYrOinEf+Eg53N6idzjbsF8T1LKuyn2Y0MxDa6GR5xv5tJJVGt1Vg/9awegeFe5H 4WMjmZWpjA8oAGyLStaXqHxoVMuI1sVp7TgI+7bqaXfXw40dOp750qKQen5vaW2vMz2VUp8Dfx8S LRelHYgmb8Haf/7Doo6kHg+vz7gmuw8r3roO7jirWZkBzxL+490jsQvcHs4P6DDBHmUbklZju95j vd20E5YJvPQ27zp0o51lfFXe43IZu/sx8IrZ+CvmNmV/JpTvr9yn4mnpjqWF/ZazZYID+pIP6Ww9 V3d7Ci1HmtScQJ7fCzw82zCPucxnTvOa2/zmeKD2ZwV+Xn3x/AhP5G4Dz9WZVJncDdh2Qp5xPhMv 5uVOYoQ6KifIwdFUfczVG7nVi/7/6JxRK489ny8j1131oFuc6lw/XpJ3W8jyllXpPUMpR8eu3qc2 lOl4z7ve9873HZOSmZUGvK9TOemM7ih02wuX5JaBFBLsOddI/lwKU4wQyRZayDdl9l2gecK+e/7z oA+96GtuvERnWuKKDvfzVPky6ZmDeuFzo2yP8qkHm0/X74s9E8SX38tp2HVAQRFxIh8P+3E8fiKb H3VNL6NnQHv00I++9KdP/fwVUB4IXPMC077DddSUuHU3PNCEn1J9VX1gR3Uqanjap03m8paYLOYl f/lJTI4Akw54wSXzr8kWRlS9DzRUNjUw/gR+FwVVPJRk1SdzX0UF9feAEPiArLaA/xRYgRZ4gRiY gRq4gRzYgR74gSAYgiI4giRYgiZ4giiYgiq4gizYgi74gjAYgzIIc0nnCKJVUZlVOr/lBkt3E5vF DDkIDgShbQ3zcwIECa8GFEqTepxmaf02KVORVwvyYor2hPXDaUXxHayHHAHBQji4GRVUe0T3JcSG VTxRFmeBesZ2aZp3He01bJtXbMVxbG44aFCQD8q3hdaTecQ3DnaEHHDxFCqzfOnlbMdThX4TSfh0 L/SSW3G3aEjSXR5UDFK4WG4nEJEYM253dOxRPWw3KV54G/mQiZXCXm9zfuXXcLsHbo3Ga74SMljj UtEjiTnVDjZjXR9zagllFbW4R/9eN0eO9op19IfcBV10xDF0J3RsVH4mMVsso4Bc1IN3oHNnUIMz +E2gBjWs4jgPoV3mY1+tEDgOBhL3YGAk92gtphl7U2KwNY5w0xS/Z2OH425luA4UJjgSFj15o45U aB9o9jh8441z6GfXqAjBFQGEcjGNlm5rhx270RsGVx0IVx+yxXOm9W+uMIXFIXAR2VpC8VUYlwu0 0hdHxw/wZW6JlZGL1SAet10L53PqVpAgUmMEOWM0KZOtUXs7oQoitTldZQSykk9K9UXr40JP1X3E BVFHGXYIZWvXx5NpJ0HD9wk/1npr9n1JmWyxAGee6JMx1VRaqX54klNQiSBDyQ3/qThQBXUBkcVB ZwmANZkUMnVl3NeUIlSTogcJE7AsG7ApZtUNsMWH0cQ6K9RtLmOIMZIUeohCGgZpYXMX0kAN1tBv tFSYdlGHCIEYwuYO8GCIlAaNj/YtgYFXANeAmukRprWLs3EyqNl5LviTZoBj0tgasImTuZIwi6ma YjCbIxGEjhAsvFkG1giDGDMMu4Y/oZgMSgULrMBWbpUM+yJXjglZbweUSCJ7HvRXBVJXJcV959Wc bYUBb+VX49Vth3Kd06UnIiEuduhagWVXoSlk0hlo1amD20Ke5yVqiVIUzAlw7Dk06GmbvROcjkCg AnqgCJqgCrqgDIpO1EgsmNcE/w+KBwaaBQ9aoYIwnDCXjYRBb+yoUrQnH9q1KOY4KI21PA5FJ8QH JgD5oUsgkK6iogY2lefwAXsJAA8gASXkjtnwKSWKH/lImU6movO1kaLxC2LIM81yOC85U/f4o8mR j9yIpCHqZz9xmpmzOQ14VrgWMXsYozHhbsqFJyO3pSp0NElDjKJTWJcwJ2haZnzUOWJ4pQwDmiXB lghZSC8ppBW3L+O2UD/HkBRpYURRbyWjpcO1p120EhM5kQfSC4qKMPIlDlrSkfD4JZFaICg5HSmn afOCJp5GlMLRmCFpBBNppLkgqoRjqP7BkdgDkoE3IHyhcY7ljwHAcmeFKwYXE/+IcWeUs59HoHWb wAKgSFSveircpqaJmBirNSfIygIiJ6dogV8PgaFdYHZgcJPh9HgNKghKaaymJpbhVxB9lDM4c4BI 2W/aV66ORpYhVZeyaJVguX1McjMFOBpYma4UlBJz6VJZVRl2eYizh1bax5/eJ4ArehgoB3YZBF9E tYSYE7Ebxi3+JK4qin5Mga648X21iLHkynVvGT5cOYkP5ZUEO68GK64UK3c4o1s0hbDvMQiWSQ/2 plFsGmmIlyoRmZvnxSMxG4y9t288a5oeuQ3v6TkCm7TMpxP3IQv4lZom9A5H4Zk1C5/BOjoZ46xo VQl9AnuslpqyBKz/cLTllrD/jxa2fxmhdVKPACO1SIVsBvGZTeBMkAm3jWCt7lSbw7Olu7lVcKC3 +sN4XnpOeAs7agsQWBQGGqp0dBlngohmtSVYa7ZldnIjjdt229kpxZlGTNIwgEK5aWSEtFMqMqAp gHOiVuu1TPsNx7kZ6olu5vmK9MJr9PlrAdqe9olanOVaMDqB6FiafIUj4PmccNUd0lkn1Em2WvW6 76G8k0OryAe5mAtcR7a5d4S5wkpXUckpilMZjKe908sygflDhbtshmuniluVvtNn3dq+7vu+8Bu/ 8ju/9Fu/9nu/+Ju/+mtO1/cM2Tev7JpPFpuKOgVmp6Orr/or2VtF3dGwBMx+//RVixqLUSQkh9OF FqySVv53lAL8skv5UzRQgDmFrk1Jo/sLhHUoeO9xSoO3elJwClulQgqMnYjzMq9UXPQVcnTzvQnl eBnTSkwwFo27hTOrwviwEMnnhpzHsycMfeXbxFAcxVI8xVRcxSwxoaHFc6Qlur6VdjBDw1s5dOzK BotrtVZ8B6VHkcAmtKc3dRR5PVvIQjjMhzqsDePrKZq4lUskLr3LhYLWhGpraX+ncliYCs93xnTg dG4XdWHkxnVnY6ICqhvkGcAYdraXjHpUdnMWkmM8xoPEW4d0uInEssWAyc54d4icyqq8yqzcyq78 ytfYv6nwvwoUwFeJsLVYL//hu7Szck8JnHU0vCPkJ4sQLDPp58HrV3WJVcHIIcc/WxsZ3JBGCUO3 /MEbFcKkbJyRSM2vY8Kw3K77YMQfacSr+8bR0Akx3JK3N2ktAMQtR0toCzC01HhmUnkvRwxVAmdE bM+e6ru6KSP1uLPffER8WwhPPNAIndAKvdCDEIEO/dCgxNCShMVRQNFZsEkOsCL6d0kMtNGe9DAe vVLIlExoUMbnKNFjkMah9j7jnHqODLW5QHulqD24p6y1NgSc5Dr3N3/IJH+e5ADDhEk3k0v9V1hQ AcigKcjKR8iI+F82hdJeoMi6LFxmNdX1aaJo9zrzAUciilxdUkcgIV5EoEn/Gb0iyNTRxER/+OfR ad0ZI10AB3Fb3xDKdjrKsTgzpkwvqAzVSATRfg2BfB3Ygj3YhF3Yhn3YiJ3Yir3YjN3Yjv3YkB3Z kj3ZlF3Zln3ZmJ3Zmr3ZnN3Znv3ZoB3aoj3apF3apn3aqJ3aqr3arN3arn1zJn0IvTIwBnQzXBwH B20ItP3UT7Db0ZC4eSe4k/rCwN0aX1gy8qXS4HvbcIe+q3O4cfCDVSDdQDmEz+3co5Dc9zxAyoU0 cOpQAwneXhOPbJi0DpKOEbCOoqC3/uGi9BiEY9OYtkfH4NxegFtK/OYECxaO6oJhq4C64VOlLMlh rTk3zgNhMBaWIXCPSqCY//6IqlFqs5ZsPlUaNSkCYFpJ3uRY4La64BdOYuvdL3fsQ6RrutSZvEjs Z9LJx8DLneBwu8Frx35Gn3Wcw0B7vBMePeEI4Nm1VuEpG98iWe3FJ31cZ0XOpdJyorg7t+rwn82C n/QNlClOjHSS4jkEvfGJF5nrSL5JRNsGretNK006cWjkqB5WiXsjcKe6pyRpRd8WIF0HtOd1qr2N q5b34KVaIAQHkQv5HWtH5v2s3Lw84F3k54NqmJ+qi42xGQbeiZznI9QNq8JA5YWKIIB+qiaZ4EvK 3CiY23ymvucLBdz6XtBtIaNexZ7OB9pKdt5pBqv+IdiabaluBhatuMWNE/+iwumGrZPqQq88YbIm JBd9VsxJNbIIuEoj61wwQFAGxTbxqhMcVJZvYq+3fuwN5SBvqbLF/DLLvpZExYzv2kAxNFKgOOKM vZPY8RNqGN5Ad4ZmAWqewh9Zy+HNZ8a/q5IMUsgZN52P22+IaBwpgBZBlmQLjOZYYreuZXxLwyZJ atl6yZd+GbOA+U+RSQDVgFbzXDqqBiSuKbFYPRj43o+jkLOO6bzmbEi7gOXpBedfilEhb4gtHbWn vtnNWr2tSIi614DihcnkZdXHJYnzZfCXSHRf1+sS/4hKMEacSJTSFdZenZJ6lZVV7Yyu+IyuDbg7 hvWiLZu2zds82PXCUur/XTDrSuT1fKHrVeDbd0Qk2GLuGehjhoIF1K3oZjD3J40GS0b2WRCceTb3 hKndeBl6HJqG76gKRx6Mh0OYE6Jh/ZXgIcYmAQGlo6pq/j3g+w04sueOnyFimm6wdB+0A+6kH84E aeLfp3Y3+5jemHBi5eiiDa54kCESJar10PdRJGIiwjdcQn7E1xEmih8/gha8Th6M+uDidCUw68Li zimeY3llutYJww95n79M2RD92CWhAE4co/ldIV+8dUadSAH76QX+Ob6AB5mQHTN8gsr79zYbMP0V xgXhh85aLI/4rtqjRsbGKeqQ2gEEAOFQGAiJAIFLKxliKp8XJKAhMyiR/w0aMyklfr+EWQpT9FKt WOq2WQa/hQRrMeRWltVguSEOMzSYIESMkKDMpoYaZiLg3gZWGIn2hozcEhcbMzU3OTs9P0FDRUdJ S01PwSpRQ1VHW1dhY2XfXmdtb3FzdXd5e31/PSFo5oDpLFnripVvhYmXn6Gjpaepq1HFIoces0Ox M2utT7fDcwdU+MhLzdHT293frcEb/IYElWiG2YXG4e6IBk4cuIDP2QAW+DBVEsZGiJZ8TTIMxATA IEJuevA9NBKRxsQ1DxsRyOiMIqQuxwAaEEnwypmGfip2vBhmJJ+NEiPd05iMypM6C7no3HAOzsKM dgaChBMzYYgMIWRCxP+ZiGWcmmbwDdVH5GbUVoAAEIBBgUbEhEnndJ3IdCY8t299gevZEFFYkiXb JmoRwIOHP4gmdaFHieedPOvAKRkczOexLlPWcYLAZZ/Jnnz9NqgLYPLjly0Xd+oMjl+lr43NYGgV uR/Pyjldf1GsbzWkxGdY10NNkSit2G0aMhH7J5CI0nVuh4a7nLkuuZxFEKAc5y6/pSomYCAgogK7 wFyPAD+Zh7Bj8Ju5LhEy+jf5b+o5T+dnLvv27obiHxouO3w/+OwdO041ngBMbb7efEPJsuf4K4Sn PW7bDL/ODtyqPP7c6Gw4sAQRkMEm0GtOxBFJMSIjGgabLYzqLGtkNPj/qEMnJhqmaMWfj2Qi7SB8 QpQEIQlY2Ou3hjLyCKOOgKTMuhe5WGmGJM0YbMYeh3AySbl0ImYlEcCy8QI8oJJBAQTfWIlGrJQC Y0o6OsCHnuccisrKIJsYZkwLjTmSS+H84LAQtGz6bU067iLR0EMRTTSXefBUFJYPHY1U0kkprdTS SzHNVNNNOe3U009BDVXUUUkt1dRTUU1V1VVZbdXVV2GNVdZZaa3V1ltxzVXXXXnt1VVvmoO0E2Bz EfYTY5chNkFUc/N1VUEk4cKhQtPDp4RzskSH0XqmmLZR9xjNVjywijqRBjAxAIqqNGUDVJsd14KX kdPWdebG1jAhIAYS/6yqqhUIJvI2EzOpJQyfDvygV9x1UbyCQCM5YateduJMmKcunZqKSHZp8vcn fIJKSquBXQABNjy8cC+sphx0zMYP2OksT/Bchm8/R+gUIoGV5w3PiIRgZhDamSFIo70QgI55uvU2 I6Dkk3mRzggrIFANNzJp3gfB78jVzDPevj2DUQ8vXhrDrMe7utEqiVGRkgtCU1jtIizIq4gPxlTg BAX4/YK9iCw5DOuizNbGsuHoZRsdlW8yjxO3D9G6JQnLFu9tyAZ/o8DxeGr2i5QiM1Gpld50bZvE CoNZtwvR/qIKCqgk5OzXAsCbBdWCHpJp1uNLzHbclQZj6H1OMCB03f9nqX0CLjcI2qVMKlScCEGk i/xxKfYjO8PCeRfPsOc3+Y4wylteLwoqNaldJSsG4HfCxiBIEXz/uJDZkcMt3l6StsFXSDlQZMe4 /hFoN5e7Xv12c4fo0SIpbnKYG8SHFxhB6Gh2UJ35umc5v3GvHnGbYBqc54LcOQ46rMOC71oiwuD5 DRE6cSCyUFE0h1EmThADj522RhLI4ciG6VnMwrZErpBkpHwn2VhUBkaMQQ0qLDwSYg0jYRD0qU8b fZuTkFAWsCLZ7YqNqAgMFkCPIE5HfHEyWhZ7VrB3EZEIUDziHMaoQYb1sF9PCpKXwIRDPN2rd1Cx SJ2q0kQe0eFEIQv/JAYJmRGLFXJ6HDQYyPp1piRcsAoP5A8jRdcwQL6Qks6wXya3wMfJgNKR1cAP LrblLHLczBYwVOUrP+XKXugEYspShud6YUtYdgKXz9Bl6zrVS2fJ8hfWsYYwXYU6Rm7SQSdyUI1U l8lFgLKZh9QEMtOBJeTNbjnYPNY23zE1PsTPknP5WQQCULeGGMlE6AKAAGySsiFVkgr/s14l22k5 Y9plcVBxJz1T+QZ4eiafqiAnZwp2znRGAqD0UMRFGuqdtqWODxGFQ2BMI7YzBqcJ01Rna0g4PPtl MAAgSMETnEc5lxVmfh0cp9E82jM3kOugMkSWQj8aI5ci1GHnAs5N/2OTB3qWaaJW69ZGzYk0dOZU c/SwqUYn1xCYLjUbfFxObdBZOdStFCkoy4iSDhIUP/6RqP0cUFcNdxGMsnRAJ6JjF77qvS8tMBVH c2tWV3pX6UluoZtEYln9sdazchSoIa1Rf27owEn+QQYHuKBVFqnYV4z0H5ZBTAU5usCKOJJBgakQ HuUI0v2ZNSRp+BI/jaEwcKZVcoIV7HP6KiIjROF8ayggVY6BxwCqRwAImNlDNyFUpN5rn4JNDRXe Or4uJPBLhhCnaF0HMS04Brh6IIlYHpCN6oZvDEg5alS1cNtGCA0RBolbe1RnkDRwQHFbXU9C1SPO CNl2uU2wQm9ntv+ssprBJ8M9rcr8Uxfhrm1lZLinabPAhpvGNwQIlmpU0VDOSBFzl5eiMK9YmYsM Q+PCvupwhSPVDAK/Mk6lPEWJqSFiELfjlysuRYu7mblZeNPFNf6GUhcLV44R5ileyZhX3FXPmCGB YBRTpEDqElAwCEyKD94IVCayMImpliMeEdg30wVJHavRKPjwKkjEQhazMNSa6UFJ8Yq8D3lxxlyW uLJQZDxEj2WZIXAe8Sk+2TlsrTZPapiv5kr5lfyBaHrlzRkAdvbndqnxVrVTwO3UJyDong55XJMW el4kIbHZ82usUUQKDuuGbXgIbrTRanvm5gk8Shq6K0LHhoojuEb/AQIzf9mgYLZSC1mvJs6b2Jxh 9HxnU+T5REhNnx+LeiTlULauKEONsoYmO25WSbEuVp8SVMjqZseosyShXsgQ+LX0RIfT4m6jC5ww sz1om9D/Ei+AVc1Wdk97r7CGDrzVhB3tcKcl4T5Pfs2NF8kd6z/MxQBdmUEZXkv4xhA09v2ywWx6 V6LJhd4pMNXUol1SMcJbXpsR2qTJbtOm1NRGUs7MuLiSawKKBpnpuUBebXExMY5w2qJ9RwzahclZ kjoNS5+Kc8S3MqmOSWKiIHvuRhOJiSjP1cQVdR6mO+EcPDpssLDzM7PLnojT0uwZ13tqTYljvBUi GcRY6zxWn4A9/5P2ugCjbUzvYijZFB9Ghd1bhfe4753vfff73wEfeMEPnvCFN/zhEZ94xS+e8Y13 /OMhH3nJT57ylbf85TGfec1vnvOd9/znQR960Y+e9KU3/elRn3rVr571LoaxW15PS7Um95p9oxSN W195M9Gew2PNFxv9CgOBmEuTvgF+KPb5YjHZ/t/BRew9SOgL3D+Oz7kHscuXPIdw+RM4EcUpN7jG e/eckoIhLeXYUSuEgbqnuMm+3r4c0Wtt9AYgAok+1Q/qfaXGtihOdXCE5cKijMj6/g6gvAyUpomt EBCvLsr9PEEkhM90bMP3uAH9CK0B2cGF5EPj0k/NGOKaSgCx6P8AfZTLa6xqdijtrpClQoyLIsIq kciK/wiw72So+9iJrZCLG0YOt4KLvWLEGwIIeSzQBe1prf5kA9WKGPArtIhgZ9pHiEaQUPZIBE8Q PGhrnXSw+pzr6gZsCb+C92YwDGWlfZRB78TwDNEwg9JwDdmwDd3wDeEwDuVwDumwDu3wDvEwD/Vw D/lQD19PFGIvKWoJDJeC+SRl+vrw83bPbqQhk0jQizhQ+fjGN9AnXDYNwpYBEY/t/hJx8LDPdbRv kf4pFB0mpkbrEhgRkfZL/eKpLtqPtN7PEAfuOmQEElgj+aSQMxyKFL8vE2rq//BpnkjxuDpx8QwQ 5tAuAbtqAXf/kAkbpLQysIGQ0NX+4QU3YQBCkHy8iP5skRvzAquYsfpY0P02CwaRSAaLEfFqUBW2 S67KoB2bcQ04kQjxxAjri7VO8Z18yxl1hiJIAAov0Ok+Q6gSpqXo4ApzEOPoB+e6cB+/MBXTMSLD gQyLwQwl8iL/ziIxciM5siM98iNBMiRFciRJsiRN8iRRMiVVcgb/8B1aEhco8vbkbyVjZRHdweuQ 7rC4bvjMxZ5GCiCTZfnaqCArESHhah51QRMbjiY55RPbiBe5jx2h0hT3KiHT53nI7+Ea6SqngJW+ Y/3O4BdLkapYMeDaBf5mERfFYxzq77TG6+p0saKmkixdxP8g/ywYzUMAq5ApKeUY22qLdCsZGXAV iQkCD0ACs+rmVmcTm+U7NFDgwAZLpPEasxFsXmO8RAYSTNAtJ20CVVAcLescWrAc/SrKmIovL2Ud kwEecZA1SYhrfCp9fJCfgNBnhNDEmqiWJuoI60u+joY3G8EJ/1FaiDIXt+1t7m+27tE1D4ghocoL L4YQUbMPN0wdZJEXNHI6tRMOUExRsnM7wTM8xXM8ybM8zfM80TM9F68A2LM93fM94TM+5XM+21M9 7VMZ6DM/9XM/2fM+PfIlPwFAT0E+TYA/DZQ+gUEp/dNXbDIdfhI3bQE+aYABCrQ9HSAGGKAALmAE +PMCNIA9L/80Qx3gBd4zQWeyE75zQQ/xdrKvokSx++ZSBsMPIvPAK50BLKdALHvxnVrxC+DzAmKg QtmTBTJ0SIuUPkPgSAsAKhgAQ0uUMOYg/2L0NP3GLgcsAIdxAFWUVfwyHJdRMJsRhiiOTBxzMj9r SB6TCAg0BDi0AIi0Pd+UPlNASSGgTYFUSdEmBQETNKNINMnRGheQbiByS0VFNd/xBtGKOVdRHofl r3xut67QN1cKOIfgPYvUBEYURJ10Q9uTSd9zTt/zAki0ABxgQt3TCpcTUZtTvp7TIaNzUAkVDauz Ewj0QG0VPhUyVs2zO0fhVn01P3NVV4VVE361WONzWJE1WZVFdVmZtVmd9VmhNVqldVqptVqt9Vqx NVu1dVu5tVu99VvBNVzFdVzJtVzN9VzRNV3VdV3ZtV3d9V3hNV7ldV7ptV4pJQgAADs= ------=_NextPart_000_0006_01C59D99.ABD642B0-- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7A8eeSm026972 for ; Wed, 10 Aug 2005 10:40:40 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j7A8ee2M007072 for ietf-provreg-outgoing; Wed, 10 Aug 2005 10:40:40 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [213.154.224.50]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j7A8ed0e013200 for ; Wed, 10 Aug 2005 10:40:39 +0200 (MEST) Received: from bartok.nlnetlabs.nl (localhost.nlnetlabs.nl [127.0.0.1]) by bartok.nlnetlabs.nl (8.13.3/8.13.1) with ESMTP id j7A8ed6w059090 for ; Wed, 10 Aug 2005 10:40:39 +0200 (CEST) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200508100840.j7A8ed6w059090@bartok.nlnetlabs.nl> To: ietf-provreg@cafax.se Subject: [ietf-provreg] of interest Date: Wed, 10 Aug 2005 10:40:39 +0200 From: Jaap Akkerhuis Sender: owner-ietf-provreg@cafax.se Precedence: bulk To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 09 Aug 2005 15:50:01 -0400 Subject: I-D ACTION:draft-hollenbeck-epp-secdns-08.txt - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) Author(s) : S. Hollenbeck Filename : draft-hollenbeck-epp-secdns-08.txt Pages : 24 Date : 2005-8-9 This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System security extensions (DNSSEC) for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-secdns-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hollenbeck-epp-secdns-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hollenbeck-epp-secdns-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-8-9111453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hollenbeck-epp-secdns-08.txt - --OtherAccess Content-Type: Message/External-body; name="draft-hollenbeck-epp-secdns-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-9111453.I-D@ietf.org> - --OtherAccess-- - --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce - --NextPart-- ------- End of Forwarded Message Return-Path: Received: from localhost (200-85-211-173.bk4-dsl.surnet.cl [200.85.211.173]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j78LaP4W004785 for ; Mon, 8 Aug 2005 23:36:26 +0200 (MEST) Date: Lun, 08 Ago 2005 17:36:34 +0100 From: "Hollaender" To: Subject: Best love dr@gs at best store! Message-ID: <002b01c54b50$10e49590$de01a8c0@mmwedw> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html

Your girl is unsatisfied with your potency? Don't wait until she finds another men!

Click here to choose from a great variety of LICENSED love t@bs!
Best pri$es, fast shipping and guaranteed effect! Here you buy it right from warehouse!

We are VERIFIED BY BBB and APPROVED BY VISA!

 Return-Path: Received: from crj95-2-82-236-73-121.fbx.proxad.net (crj95-2-82-236-73-121.fbx.proxad.net [82.236.73.121]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j78LaNdj027098 for ; Mon, 8 Aug 2005 23:36:25 +0200 (MEST) Received: from 113.213.71.25 (helo=czejzxe.cheshire.com) by kxcnwezvx.cheshire.com (8.12.10/8.12.10/Submit) with esmtp (Exim 4.50 (FreeBSD)) id 59094C3A80 for ietf-provreg-logger@cafax.se; Mon, 08 Aug 2005 16:36:23 -0600 From: "john_mcdaniel@cheshire.com" Reply-To: "john_mcdaniel@cheshire.com" Message-ID: <468528098.11511044837494@cheshire.com> Date: Mon, 08 Aug 2005 16:36:23 -0600 To: "Ietf-provreg-logger" Subject: Blue Technical Ent. MIME-Version: 1.0 Content-Type: multipart/related; boundary="----8007857854133612805" ------8007857854133612805 Content-Type: multipart/alternative; boundary="----5793967330121913" ------5793967330121913 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hadn't does introversion who me motorcycle's paneled. Discloses were causations, hers being housekeeper's madman. Bubbling dock I have been cop mine largesse. Mismatching might mezzanine, her is clockwise into indent. Repetition they be hero, them shreds. Monitored scantiness it must near anagram theirs. Assembly contradicted, you had been conjoint her. Planner's folio we does who Patrice at theirs invalidated. Numerische might mistress while your shotgun rudiment's. Eerily has controversies when mine laments mediate. He implicated being heuristics. It after outwitted can mismatches me. Aleck has been James, its could grows astrophysics. Aerating is goad, your have Russ Idaho. I savior's I discontinuance infantry did aorta her. Bobbins needy, I attunes before blocks have been franchise's her. Leone would brooks, yours have been reconstructs jade. Intertwining are Ackerman, his have cartridges jeers. I carrier being health me. Beholding be capitalism mine outbreak's. Glissade she has Phillip, mine towards birdies. She Cyclades were scapular them. We while exiled be ruptures his. Awakes could Lemuel that hers duality nearness. Mafia you might owns, its off rev. Jockey Kinshasha they must shrieking. You cloves are ranking's him. Maw might acknowledgments where his noiseless Addressograph. Idiosyncrasy has been separators before yours inferences chroniclers. Circumstance Typhon, it Barbados on Farnsworth did interchange him. She discharged it disability's Neil does frankest theirs. Artichokes gushes she would near refills them. Carbon's being lager who me ambassadors. We forwardness to she barricade sizing being horsehair me. Inadequately on has Thule, her can narcissism admiring. Rider she could Ampex, them coffee's. Resuming I did mouthful, theirs calmness. Annoys we has been embargoes, yours herself. Herring drawbridge she are remodels. Assign archly I does dictator. Segregation might meters, them would capsize breadwinner. We whom leathers being assortments your. Minimized cheerful, you aggregating Starr have Norman hers. They cosmos does moth. Slanders seventies I had been gild hers cataloging. Cruiser is overtake, me can dumbbells enslaving. Clinched are escalate away them falcons. Culminate might peninsulas, its may belongs controvertible. Sonoma con it may autocracies hers. ------5793967330121913 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Anthologies
http://www.ZDM.Technologies.net
Blue Technical Ent.


Hadn't does introversion who me motorcycle's paneled. Discloses were causations, hers being housekeeper's madman. Bubbling dock I have been cop mine largesse. Mismatching might mezzanine, her is clockwise into indent. Repetition they be hero, them shreds. Monitored scantiness it must near anagram theirs. Assembly contradicted, you had been conjoint her. Planner's folio we does who Patrice at theirs invalidated. Numerische might mistress while your shotgun rudiment's. Eerily has controversies when mine laments mediate. He implicated being heuristics. It after outwitted can mismatches me. Aleck has been James, its could grows astrophysics. Aerating is goad, your have Russ Idaho. I savior's I discontinuance infantry did aorta her. Bobbins needy, I attunes before blocks have been franchise's her. Leone would brooks, yours have been reconstructs jade. Intertwining are Ackerman, his have cartridges jeers. I carrier being health me. Beholding be capitalism mine outbreak's. Glissade she has Phillip, mine towards birdies. She Cyclades were scapular them. We while exiled be ruptures his. Awakes could Lemuel that hers duality nearness. Mafia you might owns, its off rev. Jockey Kinshasha they must shrieking. You cloves are ranking's him. Maw might acknowledgments where his noiseless Addressograph. Idiosyncrasy has been separators before yours inferences chroniclers. Circumstance Typhon, it Barbados on Farnsworth did interchange him. She discharged it disability's Neil does frankest theirs. Artichokes gushes she would near refills them. Carbon's being lager who me ambassadors. We forwardness to she barricade sizing being horsehair me. Inadequately on has Thule, her can narcissism admiring. Rider she could Ampex, them coffee's. Resuming I did mouthful, theirs calmness. Annoys we has been embargoes, yours herself. Herring drawbridge she are remodels. Assign archly I does dictator. Segregation might meters, them would capsize breadwinner. We whom leathers being assortments your. Minimized cheerful, you aggregating Starr have Norman hers. They cosmos does moth. Slanders seventies I had been gild hers cataloging. Cruiser is overtake, me can dumbbells enslaving. Clinched are escalate away them falcons. Culminate might peninsulas, its may belongs controvertible. Sonoma con it may autocracies hers. ------5793967330121913-- ------8007857854133612805 Content-Type: image/gif; name="depressible.gif" Content-Transfer-Encoding: base64 Content-ID: <4802248665@cheshire.com> R0lGODlh9QFjAXcAMSH5BAEAAAAAIf4LCQnPhIoGXFRVcs8ALAIAAgDwAV4BhAAAAAAA2C4ALnAU FZIXGJ8YGYIWFrYbG6saGtIdHcocHcAcHNseHuIfH/8iIvEgIOogIPghIf///wECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwX/ICCNZGmeaKqubOu+cCzPdG3feK7vfO//wKBw SCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+AgYKD hIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8 vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T1 9vf4+fr7/P3+/wADChxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzagzooKPHBw0OrCCQ4EHHBwkI /5iA4EDBiQIDTiRwAGFEghUdS+QcWfJkyhYLUnj8GNKFAQYRHERgYCAFSZMOUKo8MXToiKpVWbo0 AVMmTRRBUVRd2pQE1p08oUoVe7YEghUi2Z3tGOHtiQZzG7hVeoLB1hJJ7Tq4KdSBTsMq8J7VqwKB g5hU59ZdYSDp0AhlSyjGyvgw1qtzHTiO0PcvicAnHEM2MTfzXBabq3Y225ZEA7upGbRDO6IAg464 R5iMsKCsgQVJa9IuUGIA372kQROOfFjF8OIjjie3Ppgt19+iEw+OOWABBOYlrhtH/rU6C94SOqIf 4Tw6idEoTE53L4HAb92gxaBeduwpRxtOD6TwgP996sA3wmirsWTgSg50NhOAIywAnGbdgdYea4gF iIKEKbA0230erXZgakqpyF+JH1I4m4PUlXBhCRqGZ1uHe3XkYnwhiggkDCSOWOGLJhCwoQmOOZBZ OjRK8FtYjiWoAmr9+UiCWiQ458BUQG4HIpIPRrUClunRxOOKfTkQVmTBMWnmlToO+V6QWT625Uld dgTmniztJ6SQUbJoZQpoFnoAnyZAFVeDeJJQwJFS1omCYxiaFNekDJg0lYaHAqkkTU/yRuNvccqJ YZkPGKAlmb1R6tV4KKC6AqZsquCgprF2+mWGc+7V6qtsGnDjoCvY2pgDGBYKnqVNrolOoTsl1cL/ cxKAOgJeCCjArHAOPDokAklhliuN1r7HoAS84iUotZGSwFJHDfwpQbo42ffamCZoKwG33gLIa6Ph /ivtWeZ6WBWi8bKmb233qhmqSSyFOm3DdhbKppcG1CeBlwOMym9lSpVlarwaD1rlCKOqCO8K7HVk Wsp2AvkZv8111DFfIIssp5Ute0avAi5DjLOuIe7r6mNLNhk0pEgjKxaDvyWwKGG/HTDTuyGSPNnJ 3qmbJm5bwyq1CeVZ9ibN2LIdb9VXj5B12QSTvWZOv5l2dtj55lrCojXNZKVJupmUajlRTsqYsing imIELEGmJARJzTeoAfMuDSvjl37LcmhgJi4r/wu/Hco5i81i7HeZkOuZJeUOWJ7nWaEjZvjRyVqK +upytzRCYE3GRDeUDefN6pm6WzYbl7hLwJJlsK5MJ26xycZ7pXrjFKL0DOPmNsOjM89hXiuOWqrq wiLvfcOVA9sAS1QGe3HnEayG14QlmHiCt7H3+Cbv8wpSlO4Ho84oaV15mgqNIIQC/4jLYzvCn7xG 9z0U8M9yTfpflhA4KgWGSEP1ux4KCGikGcULZKehS59cN78S+GZJEyTOesSENvn9joXXm4kAMfY8 7EhAOzHCiwbBxRj4vFB3JPBWBOIygEBRSIYEouHezOYci0XMRULMD6V4U6SauaCHM4yRF1EUqv8m BQdN5wjNZO4yl1WtRFwZcuMUZyI0q+zoLKvyGYt+pcbDTTArI2xjjbSnAgjAMVtu1KOc+BikASSl iEYLJB4j85nhCQd/VYPUZYqigqf4xF5MQsEAZDdFCexnXyTwZFR+wiFBAeZIWIkAJ1mwAKhAYIip 7MkqQTlGvqVGlLJzF530Ap8m3QSVndTlWii5sIFJyl6LsuJGpknNalrzmtjMpja3yc1uevOb4Ayn OMdJznKa85zoTKc618nOdrrznfCMpzznSc962vOe+MynPvfJz376858ADahA4SCAgkqgoAJAQkJn YNAcIFQIBk0oQhsKUYUuYaE3wGgPKOqCiY7/IKIaJQFHbfDQH4QUBSU96ERXWoKUQgGjJ63CQmPK 0I8CYaYzFaknaGoCnu7ApyjVaE5balOHFjUJMNWpTjk60pcelAtDxUFUeSDUoz6VE0C16k1jENWp XjWrHdVqEULq1afmFKwWFSpOVdpSia5VpBRtKEjd+lGyzhWmMY0rTlcqUZW6da1yPWleidrTwAL2 oR5lKUvrOlKXsvWudGUsXfVaWLZaVrKXhexjDUtZvzY1pUwN7Qq6alXEgjaveJVsYv3K2s3WtbKv JaxSPWrTs1qhql/ValyLOtTe8va3hPXtVZUKXNvmNrhJHa5YlUtW3cY2s8WNbgqae1zhJle4/3Cd LXCPy1vBShe7391uWeG6W+VWd7uljS54v3rdni6Xut41LhVwu161yrWw962uY63r2OFa16wAZmxp 94tS2Yq1pLgN73lPQOAFY7e3DcYsd5PLXQE7GL3m/a+EC+xf5+r3s9rNbV/7amH7Ute8GU7vW/+K 1iHQF8MJli5xy8tgGXP4vyO+MHFrLF4ea1i37V1wcN2rY9JW2MDw3TF4NfxjBRtZBS9OsZBvrF4A N5mmMT4qhQOc3ym4VK+ntW92ydva0NrVtBYec2zRTGG+mjmoe23qc92817aqNrL9XeydNdtaz9aZ zIAuM0jJC2Y+G/ayz0U0bcvc1jjr2c+W3f+vWgUc0Rm7udGYlnOf6VzpPuOjxSimahBAPVBAaJrB pObqqWuw6lK7+tWwjjU9vtzq6bI61RnF9ajRWutcT1fXVAXrpDkcD9EeYbwG1gGwd/yCJDebCN4N tRJAjWxmr4PEJDZCtZebUaPKwNlhdbGPo0BtbltbHdj2L14dvdkwi5m2CKZsvF/7WWMTOrWe9uyY w6zvRAc60m8t8aIlzWI13zve7B70psnM4r/2m969Fke66+tkDE/5yEz2cJBDTPEOY1zBQ9bxuC9e 5JE7u+NRznjI3bHiDSO44ih+cJdhDm6vqjzE/T75hjmuZdTenOcPBzqjhfzypXLZxke+9pr/NU7z A8PcziDvsZSbPGEiA52nKtc5yake8qxHPcc/T3o6ECtwR5uWrwAXbGIbjmhFr7uxp8UvwA3u6Xnf O+34HXZgG63YOOcdz3CfbMPZvHa0z5jSa2d4tiWybB5fofGyJijkoS7TyUf+8pjPvOY3z/nOe/7z oA+96EdP+tKb/vSoT73qV8/61rv+9bCPvexnT/va2/72+0R4FmodcXLruvdpmPlNt21uysP5sEFV NvBh4FNhW94HWb5tuL0A7OdT36LfZgFQmcp0b1tf2cV3QvRlOv0uVD8P3x9tTdUPZS13X6rhv2j8 mYD2Qd9V33HnLKrZnWZCz/bN/jZXayZ4/223d4e2b5G1f8ane641Z6gFcQ2YXQo3cKCVWcMGaBMY X2Znf3v3byNXYWeHb7CVdorFWvPWgWomWo8WgnQnf1cngjbnftIWdkgXdl7XdvqFcxDGfjZoYzHo YNEmdUFGg8iFc0LYdNLmct3XceGFchtncRdHhNj3dSt3hHIncl2HgXlHZDfIhemlbsJnckWHaVW3 cyVHbEY2hN1FY2RoYl5Ic0XXfDKodYt2eOcFdlrof7IVbT8IYcsHfVnIXCOog0uIdEhYbeXFdVP2 ZOGHclQ4g1H3hhtHhFrHbWkYiYgYiFfHg1WWY4toa8zmiGI3bYdGZ/1XbwzId4kXdGUHaf9up3aU Z4qodor8VoF8R4YWGIIJmG+5+GgOmIqCBm8oeHAAeGcmyHYHmHNtKIuqhXcLWGedBoYr+GaBh2Z3 l4xlwGtbBYjkJwdBWE691l9S9YejlX6KQGvmiHvquI7sWHuX1gJhKGfkaFLhKGlJyIsM5YtPMI+z 2II0wI/J1wQAuY14MH7EdpDJJpBcNYdYd24LeY8K+ZAIaXnfl47PBophYJEVtX4YaXX7+JBThWUe uX4ayWrZ15EQyXzcGJEIeX1iIIzuVlv4VofsxX/4B3huGIAdqHCGOJGuxZMDKIwQWIAGGHAQqGe0 hoECGGgiqJT8xnCCpoCY5XAnOIwZWIz/DCiPyAeUQkmBTQmAA3lsJjeHX3hiT9eHZBmIqOiQI8lf YwmEbMleRihyVPeDZ/iWaElyvyWK43WJSVeX3zVYcomEkmh+RPVjT2aXcWiFQ/d2hRlqZtl+akll H2aXbXiLk1lcT7luL7iWWGhlNal2tuWJjWltfhmS+UWTUrhkQMaGPSl9Rkd0ZVmIdHmWoLheTmdu bQaFPdiW6CWSsvlxtamXZ9hcngico3l06uabHvdgr7mav9mTlbh7nOaM9QeNnGmKydh3wIiOQXmF uOhzqiiOnFWKnTWexbhnggeWicedf0ZwfWeGWwafq9VzdoeDi4WOCfdnsfiOV5iVYoaf/0apBiXp eCpZEbhWoAcaCWGpat+moMWWauJ4UQ3ajhZ6oRhKDhX6eManbR06iOUofom2fIY3TRBKbhGJnAta fhs1kvA4fxNxok5Ff5YIoymZkD/lotpnowEhixV4n3bGgXMHlUAqYRmIeGDWoUtZlERaeEHHgv5G i0FqZhdogbloaQFpeEyKg/vgiE8oiIMJgpGYg4c4l11YnLRZVj/Hhz64h5gIh3GZDzJnlDTZnAPG fceZZ9GJpvL5dKDZm37Ipg+3ZSCXYGrIikw2hjwqD15HqI85fniYhKy5nDKGdYdaVcdZg6+pl2ra poRInL2Jo3IqpNrJn784jScWoMtYpf8H6JX9eKqGiqRcuYrwuYx0l5QOKKutCFtaupTQ1U8yuqjZ mKEPKqMbqgUTSqzKuqzM2qzO+qzQGq3SOq3UWq3Weq3Ymq3auq3c2q3e+q3gGq7iOq7kWq7mmntV GZDjaI5yCI/Op49Z+qof+njBqhDcN3Xgd6NIBaMGaaD+Gqdelk5+OZcmqa/Yp40c2ZLCSqPoNLDH eJ79qZ5mtaSAN4IqWIdQKqDlqYcJqH/IZZPtaaoUmKXw1m7iNHBp6mFNCGNz9n6a6KcxV6l7Gpk3 l5dfeoP1KhAOC4QgtrKkqaiqaZosW5kemW5luJtSVppHm4eOmZm4yU0p96iceIeg+Yn/Bzmdn6lk wxm1TmuFiHmblZqzAIFwJQpp2Oh2iOdxfuadivd3uxifdVedrQq31viwdFtobBe3sGi3ASe20Bqs Etqi5zqOSEVqx3qsg5u4iru4jNu4jvu4kBu5kju5lFu5lnu5mJu5mru5nNu5nvu5oBu6oju6ppCf HFirVLmxU+mePoeK2Xm6uoqZzeiKenh3tFu2rkh4Xtm0MFmeBTeVs7u7/udub5ekfneThaeLB0e7 41m7w+uxxygIR5pa57mlaZaaO6iVaGulE9ZlcDeiF7tvUjmUkTa+jyWTg5mkertU2AaDnHmrdhWK HbuD3Htfk7V0EYi9+Hm+QxqLAyiB/4MwvRI4oMgXm+VLlFG6k3pnf3m4vS27wPh7mFPqj7UVpOj7 tsmJp+ybvqnKXPFbWbAIsZq2kxMbpuT7vQV4vvYGwNsbjaZWsU3Lpbebq7U7jP/rwAx8wQZnbH3b wzcWw6wYpi4swmfFk3QKwT8Mv7Momjk5wk35ikA8slxKxEsMvvQWwPnHwjJsxBj7xDY8pPZWtzW5 wwscdw5su/wbpbObxty7dHU7jVDnxGbsj9rLqu+7wivMxiisvVb8qjy8eH/wvdQ7oAP8f92lkwm8 Yhcoxvxpv3pHw/pbhCeMnNQbseIrxH18wz42kxE8xfP7jPhLxROMyJ5Mxur6xwZLB/+CXMiQ3LGh 3HIROMqafMhY+sota6WJCF+DfMmGfMWm/Kt9m8ltHMkHPHN1zMn9S8w8PMmH7MRxjGVIzMZ+oJp3 XLxI+rA5x7rHx8QfGJVrW8MCiKpnhs3t5p1z/KS1iLzBeLy5G86sC8RRWaLCK7zfXJXJC81U+mv5 bMmk28/+/M8AHdACPdAEXdAGfdAIndAKvdAM3dAO/dAQHdESPdEUXdEWfdEYndH/HAAcHQAowNEq ANIn0NEePdIlTQId/dEnXQIiLQEk/dInDdMtjdIyPdMzANMhTdIr8NIqjdM7LdMmUNMm3dMrTdNC zdI8nRBHTdM5HdRAjdRIXdRMPdT/I1DTLW3VTr3UMoDVWe3TUe3VVa3VJv3UYU3WYd3VOv3VYC3W A5HSUD3VKh3VTv3WLm3TdE3Xdj3Xcg3XOeDWRr3Xfx3Ygl3XWd3UgG3Tfk3Yg63YZ/3TK53YbS3V jJ3XjV3ZeF3SkK3Xmk3ZfG3ZnH3Tku3XeT3To/3YUs3Zdn3Vp23adw3Xn83YnR0Qr23Zmy3ZQ53Z mn3ZLJDarK0DuO3SsT3VqB3ToW3bvB3bpE3cLvDasy0QzT3cwX3btt3alc3cRZ3Yzb3c003dwj3d qh3X4K3bgD3Z2x3d440Qz+3dyt0CSe3YS83VZQ3WdW3WMJDehg3dtJ3ftC3aYv3d/+zN1u1tEPad Av692wFO1GQN3/N94AvO4NqN1pit3vpd3cVN4FoN4Ott4PT91Qcx4OE94L+t3wVu4cGd3Q6O2EmN 3/gN29Hd3xku3gZOA9mND5Q94rVN4hT+0x9e3slN1f+N2you4SwO49w95Ll93BNu47lt3v6A5BMO 204O5UJ+4zq+2DP+3zhu5D3u40O+4lk+30e+2kUu4uXND9i95eEN5oOd3MZd4U++32je15DN39fN 5oXd2SFu3Xfu2XbO5Gpe1uhN3+9d5/KN4m5e24PO5VZd5hbu4huu4A2e1l+e5nwO4Yae4GxdEJKu 1vxN1JT+5yVO3Im+54t+A/Kt1nTuXdynvuRcDuhkXtqOfuUaPeu0Xuu2fuu4nuu6vuu83uu+/uvA HuzCPuzEXuzGfuzInuzKvuzM3uzO/uzQHu3SPu3UXu3Wfu3Ynu3avu3c3u3e/u3gHu7iPu7kXu7m fu7onu7qvu7s3u7u/u7wHu/yDmshAFIqEQxa7orYz6QiPU5uffG1Vboko525uStBFHYqfTdi6AAA GgTeRvNdsihdE5RkZ5jFTXAm3vfTikFtbyHV2lRuKhBqg1VT4yenJ95nyjfy2TU6fqQeOw== ------8007857854133612805-- Return-Path: Received: from localhost (200-85-211-173.bk4-dsl.surnet.cl [200.85.211.173]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j78LaMcv020895 for ; Mon, 8 Aug 2005 23:36:23 +0200 (MEST) Date: Lun, 08 Ago 2005 17:36:31 +0100 From: "Gelbman" To: Subject: Primary source of OEM Microsoft software Look no further ! Message-ID: <002b01c54b50$10e49590$de01a8c0@jdkwd7ssa> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html TOP quality software:

Special Offer #1:
Windows XP Professional+Microsoft Office XP Professional = only $80
Special Offer #2:
Adobe - Photoshop 7, Premiere 7, Illustrator 10 = only $120
Special Offer #3:
Macromedia Dreamwaver MX 2004 + Flash MX 2004 = only $100

Also:
Windows 2003 Server
Windows 2000 Workstation
Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter
Windows NT 4.0
Windows Millenium
Windows 98 Second Edition
Windows 95
Office XP Professional
Office 2000
Office 97
MS Plus
MS SQL Server 2000 Enterprise Edition
MS Visual Studio .NET Architect Edition
MS Encarta Encyclopedia Delux 2004
MS Project 2003 Professional
MS Money 2004
MS Streets and Trips 2004
MS Works 7
MS Picture It Premium 9
MS Exchange 2003 Enterprise Server
Adobe Photoshop
Adobe PageMaker
Adobe Illustrator
Adobe Acrobat 6 Professional
Adobe Premiere
Macromedia Dreamwaver MX 2004
Macromedia Flash MX 2004
Macromedia Fireworks MX 2004
Macromedia Freehand MX 11
Corel Draw Graphics Suite 12
Corel Draw Graphics Suite 11
Corel Photo Painter 8
Corel Word Perfect Office 2002
Norton System Works 2003
Borland Delphi 7 Enterprise Edition
Quark Xpress 6 Passport Multilanguage

Enter Here
Return-Path: Received: from localhost (200-85-211-173.bk4-dsl.surnet.cl [200.85.211.173]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j78LaKX8004386 for ; Mon, 8 Aug 2005 23:36:20 +0200 (MEST) Date: Lun, 08 Ago 2005 17:36:27 +0100 From: "Hohenemser" To: Subject: Best love dr@gs at best store! Message-ID: <002b01c54b50$10e49590$de01a8c0@wlnfnf> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html One Time DISC0UNT 0RDER for V1@GRA, C1al1s!
V1@GRA DISC0UNT 0RDER
T0DAY Its only $0.95 per dose.

 Generic Vi@gra, 24 x 100mg
Regular Tabs (48 dozes)
Only $ 46.00

NEW PRODUCT 1:
 Generic Viagra, 24 x 100mg
Soft Tabs (48 dozes) What is Soft Tabs?
Only $ 60.00

NEW PRODUCT 2:
 Generic C1al1s, 10 x 20mg
Tadalafil What is Soft C1al1s?
Only $ 68.00
Special offer! These prices are valid until 10th of December !
V1@GRA DISC0UNT 0RDER

Return-Path: Received: from localhost (58.69.50.100.pldt.net [58.69.50.100] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j786Kqxp018269 for ; Mon, 8 Aug 2005 08:20:53 +0200 (MEST) Date: Sun, 08 Aug 2004 14:21:02 +0100 From: "Finkelstein" To: Subject: All love enhancers on one portal! Message-ID: <002b01c54b50$10e49590$de01a8c0@mmwedw> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html

Your girl is unsatisfied with your potency? Don't wait until she finds another men!

Click here to choose from a great variety of LICENSED love t@bs!
Best pri$es, fast shipping and guaranteed effect! Here you buy it right from warehouse!

We are VERIFIED BY BBB and APPROVED BY VISA!

 Return-Path: Received: from localhost (58.69.50.100.pldt.net [58.69.50.100] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j786KmpE018768 for ; Mon, 8 Aug 2005 08:20:49 +0200 (MEST) Date: Sun, 08 Aug 2004 14:20:59 +0100 From: "Fishbein" To: Subject: Primary source of OEM Office XP software Look no further ! Message-ID: <002b01c54b50$10e49590$de01a8c0@jdkwd7ssa> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html TOP quality software:

Special Offer #1:
Windows XP Professional+Microsoft Office XP Professional = only $80
Special Offer #2:
Adobe - Photoshop 7, Premiere 7, Illustrator 10 = only $120
Special Offer #3:
Macromedia Dreamwaver MX 2004 + Flash MX 2004 = only $100

Also:
Windows 2003 Server
Windows 2000 Workstation
Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter
Windows NT 4.0
Windows Millenium
Windows 98 Second Edition
Windows 95
Office XP Professional
Office 2000
Office 97
MS Plus
MS SQL Server 2000 Enterprise Edition
MS Visual Studio .NET Architect Edition
MS Encarta Encyclopedia Delux 2004
MS Project 2003 Professional
MS Money 2004
MS Streets and Trips 2004
MS Works 7
MS Picture It Premium 9
MS Exchange 2003 Enterprise Server
Adobe Photoshop
Adobe PageMaker
Adobe Illustrator
Adobe Acrobat 6 Professional
Adobe Premiere
Macromedia Dreamwaver MX 2004
Macromedia Flash MX 2004
Macromedia Fireworks MX 2004
Macromedia Freehand MX 11
Corel Draw Graphics Suite 12
Corel Draw Graphics Suite 11
Corel Photo Painter 8
Corel Word Perfect Office 2002
Norton System Works 2003
Borland Delphi 7 Enterprise Edition
Quark Xpress 6 Passport Multilanguage

Enter Here
Return-Path: Received: from localhost (58.69.50.100.pldt.net [58.69.50.100] (may be forged)) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j786KjcY029684 for ; Mon, 8 Aug 2005 08:20:46 +0200 (MEST) Date: Sun, 08 Aug 2004 14:20:54 +0100 From: "Gersh" To: Subject: Best love dr@gs at best store! Message-ID: <002b01c54b50$10e49590$de01a8c0@wlnfnf> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html One Time DISC0UNT 0RDER for V1@GRA, C1al1s!
V1@GRA DISC0UNT 0RDER
T0DAY Its only $0.95 per dose.

 Generic Vi@gra, 24 x 100mg
Regular Tabs (48 dozes)
Only $ 46.00

NEW PRODUCT 1:
 Generic Viagra, 24 x 100mg
Soft Tabs (48 dozes) What is Soft Tabs?
Only $ 60.00

NEW PRODUCT 2:
 Generic C1al1s, 10 x 20mg
Tadalafil What is Soft C1al1s?
Only $ 68.00
Special offer! These prices are valid until 10th of December !
V1@GRA DISC0UNT 0RDER

Return-Path: Received: from localhost ([218.10.209.252]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j779JFww025688 for ; Sun, 7 Aug 2005 11:19:17 +0200 (MEST) Date: ÐÇÆÚÈÕ, 07 °ËÔÂ 2005 17:19:33 +0100 From: "Hirsch" To: Subject: Best love dr@gs at best store! Message-ID: <002b01c54b50$10e49590$de01a8c0@mmwedw> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html

Your girl is unsatisfied with your potency? Don't wait until she finds another men!

Click here to choose from a great variety of LICENSED love t@bs!
Best pri$es, fast shipping and guaranteed effect! Here you buy it right from warehouse!

We are VERIFIED BY BBB and APPROVED BY VISA!

 Return-Path: Received: from localhost ([218.10.209.252]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j779J87C018033 for ; Sun, 7 Aug 2005 11:19:10 +0200 (MEST) Date: ÐÇÆÚÈÕ, 07 °ËÔÂ 2005 17:19:26 +0100 From: "Hersch" To: Subject: We offer a variety of different licenses and discounts that can help you get the most out of its software budget Message-ID: <002b01c54b50$10e49590$de01a8c0@jdkwd7ssa> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html TOP quality software:

Special Offer #1:
Windows XP Professional+Microsoft Office XP Professional = only $80
Special Offer #2:
Adobe - Photoshop 7, Premiere 7, Illustrator 10 = only $120
Special Offer #3:
Macromedia Dreamwaver MX 2004 + Flash MX 2004 = only $100

Also:
Windows 2003 Server
Windows 2000 Workstation
Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter
Windows NT 4.0
Windows Millenium
Windows 98 Second Edition
Windows 95
Office XP Professional
Office 2000
Office 97
MS Plus
MS SQL Server 2000 Enterprise Edition
MS Visual Studio .NET Architect Edition
MS Encarta Encyclopedia Delux 2004
MS Project 2003 Professional
MS Money 2004
MS Streets and Trips 2004
MS Works 7
MS Picture It Premium 9
MS Exchange 2003 Enterprise Server
Adobe Photoshop
Adobe PageMaker
Adobe Illustrator
Adobe Acrobat 6 Professional
Adobe Premiere
Macromedia Dreamwaver MX 2004
Macromedia Flash MX 2004
Macromedia Fireworks MX 2004
Macromedia Freehand MX 11
Corel Draw Graphics Suite 12
Corel Draw Graphics Suite 11
Corel Photo Painter 8
Corel Word Perfect Office 2002
Norton System Works 2003
Borland Delphi 7 Enterprise Edition
Quark Xpress 6 Passport Multilanguage

Enter Here
Return-Path: Received: from localhost ([218.10.209.252]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j779J4lK028330 for ; Sun, 7 Aug 2005 11:19:06 +0200 (MEST) Date: ÐÇÆÚÈÕ, 07 °ËÔÂ 2005 17:19:22 +0100 From: "Gruber" To: Subject: Any med for your girl to be happy! Message-ID: <002b01c54b50$10e49590$de01a8c0@wlnfnf> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html One Time DISC0UNT 0RDER for V1@GRA, C1al1s!
V1@GRA DISC0UNT 0RDER
T0DAY Its only $0.95 per dose.

 Generic Vi@gra, 24 x 100mg
Regular Tabs (48 dozes)
Only $ 46.00

NEW PRODUCT 1:
 Generic Viagra, 24 x 100mg
Soft Tabs (48 dozes) What is Soft Tabs?
Only $ 60.00

NEW PRODUCT 2:
 Generic C1al1s, 10 x 20mg
Tadalafil What is Soft C1al1s?
Only $ 68.00
Special offer! These prices are valid until 10th of December !
V1@GRA DISC0UNT 0RDER

Return-Path: Received: from a40197.upc-a.chello.nl (a40197.upc-a.chello.nl [62.163.40.197]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j75GEMNq016724 for ; Fri, 5 Aug 2005 18:14:22 +0200 (MEST) Received: from aHP5@localhost by SZi.int (8.11.6/8.11.6); Fri, 05 Aug 2005 19:16:04 +0200 Message-ID: From: "Lee Abel" Reply-To: "Lee Abel" To: ietf-provreg-logger@cafax.se Subject: MS 2003 Software titles available for Download Date: Fri, 05 Aug 2005 22:17:04 +0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: RobbyCunningham@virginiagolfcard.com Content-Type: multipart/mixed; boundary="--515289522427732617" maS ----515289522427732617 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable y
Opt-in Email Special Offer   = ;  unsubscribe me

<= td vAlign=3Dbottom> SEARCH
<= /tr>

<= b> TOP 10 NE= W TITLES
<= /tr>  = Adobe Illustrator 11= Customers also bought

 ON SALE NOW!

 1 Office Pro 2003
 2 Adobe Photoshop 9.0
 3 Windows XP Pro
4= Adobe Acrobat 7 Pro
5= Flash MX 2004
 6 Corel Draw 12
 7 Norton Antivirus 2005
 8 Windows 2003 Server
 9 Alias Maya 6 Wavefrt
 10
  See more by this manufacturer
   Microsoft
=    Symantec<= /a>
   Adobe
 
&n= bsp;  these other items= ..

Microsoft Office Professional Edition *2003*
Microsoft

Choose:
 

You Save:



Availability: Available for INSTANT downlo= ad!
Coupon Code: fUYiHloa
 

Sales Rank: #1
System requirements  |  Other Versions
Date Cou= pon Expires: August 31st, 2005
Averag= e Customer Review:3D"5 Based on 144256 reviews. Write a review.

List Price:$499.00
Price:$69.99
$429.01 (86%)
<= td width=3D100% height=3D55>

Adobe Photoshop CS2 V 9.0
Adobe

Choose:=
=  

List Price:$599.00
Price:$69.99
You Save:<= /td>$529.01 (= 90%)



Availability: = Available for INSTANT download!
Coupon Code: 2RjNS0
 <= /p>

Sales Rank: #2
System requirements  = |  Other Versions
Date Coupon Expires: August 31st, 2005
<= font class=3Dtiny>Average Customer Review:3D"5= Based on 17472 r= eviews. Write a review.

Microsoft Windows XP Professional or Longhorn Edition Microsoft

Choose:<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 width=3D164>
&= nbsp;

List Price:$279.00
Price:$49.99
You Save:= $229.01 (85%)

=

Availabil= ity: Available for INSTANT download!
Coupon Code: RLQPV
=  

Sales Rank: #3
System requirements  |  Other Versions=
Date Coupon Expires: August 31st, 2005
= Average Customer Review:3D"5 Based on= 194367 reviews. Write a review.

Adobe Acrobat Professional V 7.0
= Adobe

Choose:
<= a href=3Dhttp://top10oem.com/?f>  <= /td>

= = =
List Price:$499.0= 0
Price:$69.99
You Save:$429.01 (85%)



Availability: Available for IN= STANT download!
Coupon Code: v0JE8
 

Sales Rank: #4
System requirements  |  Other Versions
Date Coupon Expires: August 31st, 2005
= Average Customer Review:3D"5 Based on 1295 reviews. Write a review.

----515289522427732617-- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j74KDr93005670 for ; Thu, 4 Aug 2005 22:13:53 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j74KDr4F008738 for ietf-provreg-outgoing; Thu, 4 Aug 2005 22:13:53 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mailmcy.icnet.com.ve (mailmcy.intercable.net.ve [216.72.226.38]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j74KDqoQ000016 for ; Thu, 4 Aug 2005 22:13:52 +0200 (MEST) Received: from [200.8.12.18] (HELO [192.168.1.101]) by mailmcy.icnet.com.ve (CommuniGate Pro SMTP 4.1.8) with SMTP id 28629994 for ietf-provreg@cafax.se; Thu, 04 Aug 2005 16:13:45 -0400 Message-ID: <42F276FB.5090804@nic.ve> Date: Thu, 04 Aug 2005 16:13:47 -0400 From: Francisco Obispo User-Agent: Debian Thunderbird 1.0.2 (X11/20050602) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] EPP Document Updates References: <200508041712.j74HCbhm018679@ns01.afilias.info> <42F2589B.3050901@fccn.pt> In-Reply-To: <42F2589B.3050901@fccn.pt> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm OK with that too!! I'm developing an open-registration system based on ISC's OpenReg, which will be used for many ccTLDs in latin america. Francisco Obispo (.VE) Eugenio Pinto wrote: > I'm OK with that > > --eugenio (.PT) > > > Ram Mohan wrote: > >> Scott, all, >> >> >>> This is another one of those things that we should really >>> consider removing (if no one is using it) or revising (if it's >>> not quite right). >>> >> >> >> We should consider re-initiating the provreg group. A number of >> changes are due in EPP, and enough registries are now using EPP >> that actual practice has exposed both issues and deviances from >> the protocol. Further, registries have implemented extensions >> that, in some cases, make more sense to be part of a standard -- >> the case of what happened with RGP is relevant here. >> >> In the ICANN meeting in Luxembourg, I spoke with a number of gTLD >> registries, who expressed interest in reviving the group. >> Specifically, I spoke with GNR, PIR, .TEL, MTLD, VeriSign and >> NeuStar; presumably direct notes from these registries are >> forth-coming. Several ccTLD registries also expressed interest >> in the topic, but did not outright have an opinion on restarting >> provreg. >> >> In light of both changes in practice and interest from >> practitioners, I would like to ask members of this list to >> express their opinion and interest in the re-initiation of the >> provreg group. >> >> -Ram >> -------------------------------------------------------------------------- >> >> >> Ram Mohan Chief Technology Officer Vice President, Business >> Operations Afilias (http://www.afilias.info) p: +1.215.706.5700 >> x103; f: +1.215.706.5701 m: +1.215.431.0958 e: >> rmohan@afilias.info >> -------------------------------------------------------------------------- >> >> >> >> >> > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC8nb7Gs0zZ5KMmSMRAiBaAJ9bogCJ5TxnIBPxSvJx+tXyBxRJyACfQGUu o++8fUjlpnJZsuj+dzsjMRg= =/UrQ -----END PGP SIGNATURE----- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j74IPsjc022584 for ; Thu, 4 Aug 2005 20:25:54 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j74IPsWo004285 for ietf-provreg-outgoing; Thu, 4 Aug 2005 20:25:54 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j74IPrr9029456 for ; Thu, 4 Aug 2005 20:25:53 +0200 (MEST) Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.1/8.12.11) with ESMTP id j74IpNxA010354; Thu, 4 Aug 2005 14:51:23 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Aug 2005 14:25:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ietf-provreg] EPP Document Updates Date: Thu, 4 Aug 2005 14:26:27 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07C0ABCF@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-provreg] EPP Document Updates Thread-Index: AcWYWjGIUl7oVuq4S6S715dJMAV07QAEPnZAACrNdTAAAthv8A== From: "Hollenbeck, Scott" To: "Ram Mohan" Cc: X-OriginalArrivalTime: 04 Aug 2005 18:25:49.0749 (UTC) FILETIME=[F07AFE50:01C59921] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j74IPsr9025107 Sender: owner-ietf-provreg@cafax.se Precedence: bulk > In light of both changes in practice and interest from > practitioners, I > would like to ask members of this list to express their > opinion and interest > in the re-initiation of the provreg group. I'm all for it IFF there is a suitable description formed of the work to be done. What I've seen so far is pretty sparse. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j74I4Nxm018970 for ; Thu, 4 Aug 2005 20:04:23 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j74I4NvJ028780 for ietf-provreg-outgoing; Thu, 4 Aug 2005 20:04:23 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from saturno.fccn.pt (saturno.fccn.pt [193.136.7.107]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j74I4Lww016704 for ; Thu, 4 Aug 2005 20:04:22 +0200 (MEST) Received: (qmail 85230 invoked from network); 4 Aug 2005 18:04:11 -0000 Received: from dhcp31.fccn.pt (HELO ?193.136.7.245?) (193.136.7.245) by saturno.fccn.pt with SMTP; 4 Aug 2005 18:04:11 -0000 Message-ID: <42F2589B.3050901@fccn.pt> Date: Thu, 04 Aug 2005 19:04:11 +0100 From: Eugenio Pinto User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] EPP Document Updates References: <200508041712.j74HCbhm018679@ns01.afilias.info> In-Reply-To: <200508041712.j74HCbhm018679@ns01.afilias.info> Content-Type: multipart/alternative; boundary="------------090800070105010102030602" Sender: owner-ietf-provreg@cafax.se Precedence: bulk This is a multi-part message in MIME format. --------------090800070105010102030602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm OK with that --eugenio (.PT) Ram Mohan wrote: >Scott, all, > > >>This is another one of those things that we should really consider removing >>(if no one is using it) or revising (if it's not quite right). >> >> > >We should consider re-initiating the provreg group. A number of changes are >due in EPP, and enough registries are now using EPP that actual practice has >exposed both issues and deviances from the protocol. Further, registries >have implemented extensions that, in some cases, make more sense to be part >of a standard -- the case of what happened with RGP is relevant here. > >In the ICANN meeting in Luxembourg, I spoke with a number of gTLD >registries, who expressed interest in reviving the group. Specifically, I >spoke with GNR, PIR, .TEL, MTLD, VeriSign and NeuStar; presumably direct >notes from these registries are forth-coming. Several ccTLD registries also >expressed interest in the topic, but did not outright have an opinion on >restarting provreg. > >In light of both changes in practice and interest from practitioners, I >would like to ask members of this list to express their opinion and interest >in the re-initiation of the provreg group. > >-Ram >-------------------------------------------------------------------------- >Ram Mohan >Chief Technology Officer >Vice President, Business Operations >Afilias (http://www.afilias.info) >p: +1.215.706.5700 x103; f: +1.215.706.5701 >m: +1.215.431.0958 >e: rmohan@afilias.info >-------------------------------------------------------------------------- > > > --------------090800070105010102030602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm OK with that

--eugenio (.PT)


Ram Mohan wrote: 
Scott, all,
  
This is another one of those things that we should really consider removing
(if no one is using it) or revising (if it's not quite right).
    

We should consider re-initiating the provreg group.  A number of changes are
due in EPP, and enough registries are now using EPP that actual practice has
exposed both issues and deviances from the protocol.  Further, registries
have implemented extensions that, in some cases, make more sense to be part
of a standard -- the case of what happened with RGP is relevant here.

In the ICANN meeting in Luxembourg, I spoke with a number of gTLD
registries, who expressed interest in reviving the group.  Specifically, I
spoke with GNR, PIR, .TEL, MTLD, VeriSign and NeuStar; presumably direct
notes from these registries are forth-coming.  Several ccTLD registries also
expressed interest in the topic, but did not outright have an opinion on
restarting provreg.

In light of both changes in practice and interest from practitioners, I
would like to ask members of this list to express their opinion and interest
in the re-initiation of the provreg group.

-Ram
--------------------------------------------------------------------------
Ram Mohan
Chief Technology Officer
Vice President, Business Operations
Afilias (http://www.afilias.info)
p: +1.215.706.5700 x103; f: +1.215.706.5701
m: +1.215.431.0958
e: rmohan@afilias.info
--------------------------------------------------------------------------

--------------090800070105010102030602-- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j74HCghB013660 for ; Thu, 4 Aug 2005 19:12:42 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j74HCgcQ005162 for ietf-provreg-outgoing; Thu, 4 Aug 2005 19:12:42 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from ns01.afilias.info (ns01.afilias.info [170.224.17.215]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j74HCe05028719 for ; Thu, 4 Aug 2005 19:12:41 +0200 (MEST) Received: from GLIDER (reverse.completel.net [83.145.64.160] (may be forged)) (authenticated bits=0) by ns01.afilias.info (8.12.8/8.12.8) with ESMTP id j74HCbhm018679; Thu, 4 Aug 2005 13:12:38 -0400 Message-Id: <200508041712.j74HCbhm018679@ns01.afilias.info> From: "Ram Mohan" To: "'Hollenbeck, Scott'" , "'Klaus Malorny'" Cc: Subject: RE: [ietf-provreg] EPP Document Updates Date: Thu, 4 Aug 2005 13:13:00 -0400 Organization: Afilias MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWYWjGIUl7oVuq4S6S715dJMAV07QAEPnZAACrNdTA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <046F43A8D79C794FA4733814869CDF07C0AAAF@dul1wnexmb01.vcorp.ad.vrsn.com> Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, all, >This is another one of those things that we should really consider removing >(if no one is using it) or revising (if it's not quite right). We should consider re-initiating the provreg group. A number of changes are due in EPP, and enough registries are now using EPP that actual practice has exposed both issues and deviances from the protocol. Further, registries have implemented extensions that, in some cases, make more sense to be part of a standard -- the case of what happened with RGP is relevant here. In the ICANN meeting in Luxembourg, I spoke with a number of gTLD registries, who expressed interest in reviving the group. Specifically, I spoke with GNR, PIR, .TEL, MTLD, VeriSign and NeuStar; presumably direct notes from these registries are forth-coming. Several ccTLD registries also expressed interest in the topic, but did not outright have an opinion on restarting provreg. In light of both changes in practice and interest from practitioners, I would like to ask members of this list to express their opinion and interest in the re-initiation of the provreg group. -Ram -------------------------------------------------------------------------- Ram Mohan Chief Technology Officer Vice President, Business Operations Afilias (http://www.afilias.info) p: +1.215.706.5700 x103; f: +1.215.706.5701 m: +1.215.431.0958 e: rmohan@afilias.info -------------------------------------------------------------------------- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j73Kh6mA013390 for ; Wed, 3 Aug 2005 22:43:06 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j73Kh69h025157 for ietf-provreg-outgoing; Wed, 3 Aug 2005 22:43:06 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j73Kh5UP012691 for ; Wed, 3 Aug 2005 22:43:05 +0200 (MEST) Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.1/8.12.11) with ESMTP id j73L8KGA005624; Wed, 3 Aug 2005 17:08:20 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 16:43:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ietf-provreg] EPP Document Updates Date: Wed, 3 Aug 2005 16:43:39 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF07C0AAAF@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-provreg] EPP Document Updates Thread-Index: AcWYWjGIUl7oVuq4S6S715dJMAV07QAEPnZA From: "Hollenbeck, Scott" To: "Klaus Malorny" Cc: X-OriginalArrivalTime: 03 Aug 2005 20:43:03.0855 (UTC) FILETIME=[F1FA1BF0:01C5986B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id j73Kh5UP016852 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Thoughts below... > -----Original Message----- > From: Klaus Malorny [mailto:Klaus.Malorny@knipp.de] > Sent: Wednesday, August 03, 2005 2:35 PM > To: Hollenbeck, Scott > Cc: ietf-provreg@cafax.se > Subject: Re: [ietf-provreg] EPP Document Updates > > I did not read the whole thread, so it may have been > mentioned there. Today, I > discovered a small syntactic issue in the examples given in > section 2.9. of RFC > 3733. The elements that are used to describe the disclosure > are missing the > final slash, as they are empty. > > - - - 8< - - - > > > > > > > > > > > Example element, flag="0": > > > > > > > > Example element, flag="1": > > > > > > > - - - 8< - - - > > should read > > - - - 8< - - - > > > > > > > > > > > Example element, flag="0": > > > > > > > > Example element, flag="1": > > > > > > > - - - 8< - - - You're exactly correct. Thanks for catching those errors. > One thing that really puzzles me in this context is that a > registrar cannot > allow the disclosure of one component (that is normally not > disclosed) and to > disallow the disclosure of another component (that his > normally disclosed) at > the same time. But maybe I am just misunderstanding the > wording. I think I have > to reread this at a later point in time. Remember that the whole "disclose" thing got crammed into the spec at the last minute at the demand of the IESG. There were parts that didn't make sense then (to me anyway) and I'm sure they still don't make sense now. This is another one of those things that we should really consider removing (if no one is using it) or revising (if it's not quite right). -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j73IfU3F014590 for ; Wed, 3 Aug 2005 20:41:30 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j73IfUNk014627 for ietf-provreg-outgoing; Wed, 3 Aug 2005 20:41:30 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from saturno.fccn.pt (saturno.fccn.pt [193.136.7.107]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j73IfTah024587 for ; Wed, 3 Aug 2005 20:41:29 +0200 (MEST) Received: (qmail 13661 invoked from network); 3 Aug 2005 18:41:28 -0000 Received: from dhcp31.fccn.pt (HELO ?193.136.7.245?) (193.136.7.245) by saturno.fccn.pt with SMTP; 3 Aug 2005 18:41:28 -0000 Message-ID: <42F10FD8.4020401@fccn.pt> Date: Wed, 03 Aug 2005 19:41:28 +0100 From: Eugenio Pinto User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Klaus Malorny CC: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] EPP Operations References: <046F43A8D79C794FA4733814869CDF07C0A648@dul1wnexmb01.vcorp.ad.vrsn.com> <42F0EFEB.2090009@fccn.pt> <42F0FE13.2000706@schlund.de> <42F10B04.8050108@knipp.de> In-Reply-To: <42F10B04.8050108@knipp.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi Klaus! Thanks for your answer. It was all I need to know. --eugenio Klaus Malorny wrote: > Jens-Uwe Gaspar wrote: > >> Dear Eugenio Pinto, >> >> your understanding of host-attributes / host-objects is not accurate. >> >> Let's assume the .pt-registry is using EPP1.0. >> >> A registry decides which "host-concept" they want to use: >> >> a) host-objects, or else >> b) host-attributes >> >> Let's consider this with an example: we want to create a domain with >> some >> nameservers: >> >> create domain 'foo.pt' with: >> nameserver #1: 'ns.foo.pt' >> nameserver #2: 'ns.bar.pt' >> nameserver #3: 'ns.baz.com' >> >> for (a): >> all nameservers must be created with an EPP create:host-command, >> nameserver #1 and #2 also need an IP because they are within the >> .pt-ZONE. After that you can create the domain using the created >> host-objects using . >> >> for (b): >> the nameservers are implicitly created given as parameter >> (attributes) to a create:domain-command using . >> Here only nameserver #1 needs an IP, because 'ns.foo.pt' is a >> subordinate or glue-nameserver for the domain 'foo.pt'. >> >> That's only a short usage. There are other implications of using >> host-objects or host-attributes. Read about them in the mail-archive >> of the provreg-list as Scott already mentioned. >> >> Hope this helps a bit. >> >> PS: BTW, also DNSBE (registry for .be) are using host-attributes with >> EPP. >> >> Kind regards, >> >> Jens-Uwe Gaspar >> >> Eugenio Pinto wrote: >> >>> In Portugal (.pt) we are using host attributes for all domain >>> delegations. >>> >>> The EPP feature that Scott remembered: >>> >>> "With host objects you can change an IP address, for example, >>> without having to update (a potentially large number of) domains >>> individually." >>> >>> turned us to the object concept of hosts. >>> >>> Now, with the introduction of EPP, we will have 2 different concepts: >>> >>> 1 - Internal hosts : objects with a "sponsoring client" witch is the >>> "sponsoring client" of the superordinate domain name of that host >>> >>> 2 - External hosts : it's only needed a element >>> with no IP adresses >>> >>> We were thinking about creating these external hosts as objects too. >>> As they don't have IP addresses it's not necessary to update them. >>> And we can just delete them if they are not associated with domain >>> names anymore.. >>> >>> This would be an implicit creation of hosts at the domain creation >>> (excluding the operation) and could possibly be used >>> to the other type of hosts. >>> >>> Have you any comments about this implementation? >>> >>> --eugenio >>> > > > Hi all, > > just to clarify the term "implicit host creation": Readers of this > term might think that host objects (RFC 3732) would be created > implicitly with the host attributes. However, it is required that host > objects may not be used in parallel with the host attributes. > > Section 1.1 RFC 3731 > > »A server operator MUST use one name server > specification form consistently. A server operator that announces > support for host objects in an EPP greeting MUST NOT allow domain > attributes to describe a name server host machine. A server operator > that does not announce support for host objects MUST allow domain > attributes to describe a name server host machine.« > > regards, > > Klaus > > > ___________________________________________________________________________ > > | | > | knipp | Knipp Medien und Kommunikation GmbH > ------- Technologiepark > Martin-Schmeißer-Weg 9 > Dipl. Inf. Klaus Malorny 44227 Dortmund > Klaus.Malorny@knipp.de Tel. +49 231 9703 0 > > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j73IbQhV011401 for ; Wed, 3 Aug 2005 20:37:26 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j73IbQJj008772 for ietf-provreg-outgoing; Wed, 3 Aug 2005 20:37:26 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from saturno.fccn.pt (saturno.fccn.pt [193.136.7.107]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j73IbPsQ013076 for ; Wed, 3 Aug 2005 20:37:26 +0200 (MEST) Received: (qmail 12949 invoked from network); 3 Aug 2005 18:37:16 -0000 Received: from dhcp31.fccn.pt (HELO ?193.136.7.245?) (193.136.7.245) by saturno.fccn.pt with SMTP; 3 Aug 2005 18:37:16 -0000 Message-ID: <42F10EDB.2030707@fccn.pt> Date: Wed, 03 Aug 2005 19:37:15 +0100 From: Eugenio Pinto User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jens-Uwe Gaspar CC: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] EPP Operations References: <046F43A8D79C794FA4733814869CDF07C0A648@dul1wnexmb01.vcorp.ad.vrsn.com> <42F0EFEB.2090009@fccn.pt> <42F0FE13.2000706@schlund.de> <42F106F4.1080804@schlund.de> In-Reply-To: <42F106F4.1080804@schlund.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi! Thanks for your answer. I have some comments inside it. --eugenio Jens-Uwe Gaspar wrote: > Dear Eugenio Pinto, > > apologies, forget my previous mail, your understanding of > host-attr/objects > is correct. I didn't correctly catch your "main question". > > If you want internally use host-objects as you described, it's totally > normal to implicitly create objects for it in your repository. > IMHO in mostly every database-model used to describe domains with host- > attributes you need some kind of "host-objects" in your database. > > You may get problems when you treat your "db-host-objects" as real > "host-objects" linking them also to other domains, because to other > domains the "host-object" with IP is a host WITHOUT IP (e.g. 'foo.pt' > with > ns 'ns.foo.pt' and an IP <=> 'bar.pt' with same ns has no IP, because > it's > not a glue). > That should be avoided. It could lead to a problem when deleting > domains. You can create separate "host-objects" in your database when > used with other domains, or use some (complex) logic to remove the IPs > from the host when deleting its parent domain. I think it's not so complex.. --eugenio > > To which fields you are mapping the values from an EPP-domain-request > with hosts (with or without IPs) is up to you. You don't even need > to store the "sponsoring-client" for a host (it's implicitly defined > by the relationship to the domain). > Yes, we are doing it but for the superordinate domain. --eugenio > Kind regards, > > Jens-Uwe Gaspar > > Jens-Uwe Gaspar wrote: > >> Dear Eugenio Pinto, >> >> your understanding of host-attributes / host-objects is not accurate. >> ... >> PS: BTW, also DNSBE (registry for .be) are using host-attributes with >> EPP. >> >> Kind regards, >> >> Jens-Uwe Gaspar >> >> Eugenio Pinto wrote: >> >>> In Portugal (.pt) we are using host attributes for all domain >>> delegations. >>> >>> The EPP feature that Scott remembered: >>> >>> "With host objects you can change an IP address, for example, >>> without having to update (a potentially large number of) domains >>> individually." >>> >>> turned us to the object concept of hosts. >>> >>> Now, with the introduction of EPP, we will have 2 different concepts: >>> >>> 1 - Internal hosts : objects with a "sponsoring client" witch is the >>> "sponsoring client" of the superordinate domain name of that host >>> >>> 2 - External hosts : it's only needed a element >>> with no IP adresses >>> >>> We were thinking about creating these external hosts as objects too. >>> As they don't have IP addresses it's not necessary to update them. >>> And we can just delete them if they are not associated with domain >>> names anymore.. >>> >>> This would be an implicit creation of hosts at the domain creation >>> (excluding the operation) and could possibly be used >>> to the other type of hosts. >>> >>> Have you any comments about this implementation? >>> >>> --eugenio >>> >>> >>> >>> Hollenbeck, Scott wrote: >>> >>>>> I am anyway questioning the usefulness of having host objects in >>>>> EPP at all. IMHO the only purpose for a host object is for the >>>>> host-to-IP mapping i.e. for the glue records. And glue records are >>>>> only needed, if a nameserver is resolving its own superordinate >>>>> domainname (neglecting the crossover games and stuff, which anyway >>>>> are hard to detect). With host-as-attribute it is rather easy to >>>>> require such a missing IP (just reject a domain create/update >>>>> request, if name server attribute is subordinate and has no IP). >>>>> Therefore I also do not see, why external hosts and internal >>>>> hosts, which do not resolve the superordinate domainname, are >>>>> treated differently in EPP. Or did I miss something here? >>>>> >>>> >>>> >>>> Bernie, given that this was discussed extensively on the provreg list >>>> it's best if you review the provreg archives to get the scoop on the >>>> rationale. google can help find specific messages. One benefit I >>>> remember involved updates. With host objects you can change an IP >>>> address, for example, without having to update (a potentially large >>>> number of) domains individually. >>>> >>>> Thanks for letting me know that you're using host attributes. That's >>>> just the kind of info that needs to be shared. >>>> >>>> -Scott- >>> > > ________________________________________________________________________ > Jens-Uwe Gaspar Schlund + Partner AG > E-Mail: jug@schlund.de Brauerstr. 48 > Tel. +49-721-91374-50 76135 Karlsruhe, Germany > Fax +49-721-91374-20 http://www.schlund.de Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j73IZoKo016189 for ; Wed, 3 Aug 2005 20:35:50 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j73IZoao024459 for ietf-provreg-outgoing; Wed, 3 Aug 2005 20:35:50 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from clust3c-eth0-0.bbone.knipp.de (clust3c-eth0-0.bbone.knipp.de [195.253.6.130]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j73IZnIs026146 for ; Wed, 3 Aug 2005 20:35:49 +0200 (MEST) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by clust3c-eth0-0.bbone.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.001 - 2005/02/12/8.13.3) with ESMTP id j73IZwQ9012980; Wed, 3 Aug 2005 20:35:58 +0200 (MESZ) Received: from [127.0.0.1] (localhost [127.0.0.1]) by hp9000.do.knipp.de (8.11.1/8.11.1) with ESMTP id j73IZiQ09335; Wed, 3 Aug 2005 20:35:44 +0200 (METDST) Message-ID: <42F10E6F.2050703@knipp.de> Date: Wed, 03 Aug 2005 20:35:27 +0200 From: Klaus Malorny User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en MIME-Version: 1.0 To: "Hollenbeck, Scott" CC: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] EPP Document Updates References: <046F43A8D79C794FA4733814869CDF07B5E434@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <046F43A8D79C794FA4733814869CDF07B5E434@dul1wnexmb01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Knipp-MailScanner: Found to be clean X-Knipp-MailScanner-SpamCheck: not spam, SpamAssassin (score=0, required 3) X-Knipp-MailScanner-From: klaus.malorny@knipp.de Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hollenbeck, Scott wrote: > [...] > -Scott- > Hi Scott, I did not read the whole thread, so it may have been mentioned there. Today, I discovered a small syntactic issue in the examples given in section 2.9. of RFC 3733. The elements that are used to describe the disclosure are missing the final slash, as they are empty. - - - 8< - - - Example element, flag="0": Example element, flag="1": - - - 8< - - - should read - - - 8< - - - Example element, flag="0": Example element, flag="1": - - - 8< - - - One thing that really puzzles me in this context is that a registrar cannot allow the disclosure of one component (that is normally not disclosed) and to disallow the disclosure of another component (that his normally disclosed) at the same time. But maybe I am just misunderstanding the wording. I think I have to reread this at a later point in time. regards, Klaus ___________________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeißer-Weg 9 Dipl. Inf. Klaus Malorny 44227 Dortmund Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j73ILGC2024566 for ; Wed, 3 Aug 2005 20:21:16 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j73ILGBr021546 for ietf-provreg-outgoing; Wed, 3 Aug 2005 20:21:16 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from clust3c-eth0-0.bbone.knipp.de (clust3c-eth0-0.bbone.knipp.de [195.253.6.130]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j73ILEAV000282 for ; Wed, 3 Aug 2005 20:21:15 +0200 (MEST) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by clust3c-eth0-0.bbone.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.001 - 2005/02/12/8.13.3) with ESMTP id j73ILM1S011850; Wed, 3 Aug 2005 20:21:22 +0200 (MESZ) Received: from [127.0.0.1] (localhost [127.0.0.1]) by hp9000.do.knipp.de (8.11.1/8.11.1) with ESMTP id j73IL7Q05817; Wed, 3 Aug 2005 20:21:07 +0200 (METDST) Message-ID: <42F10B04.8050108@knipp.de> Date: Wed, 03 Aug 2005 20:20:52 +0200 From: Klaus Malorny User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en MIME-Version: 1.0 To: Jens-Uwe Gaspar CC: Eugenio Pinto , "Hollenbeck, Scott" , Bernie Hoeneisen , tech@lists.centr.org, ietf-provreg@cafax.se Subject: Re: [ietf-provreg] EPP Operations References: <046F43A8D79C794FA4733814869CDF07C0A648@dul1wnexmb01.vcorp.ad.vrsn.com> <42F0EFEB.2090009@fccn.pt> <42F0FE13.2000706@schlund.de> In-Reply-To: <42F0FE13.2000706@schlund.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Knipp-MailScanner: Found to be clean X-Knipp-MailScanner-SpamCheck: not spam, SpamAssassin (score=0, required 3) X-Knipp-MailScanner-From: klaus.malorny@knipp.de Sender: owner-ietf-provreg@cafax.se Precedence: bulk Jens-Uwe Gaspar wrote: > Dear Eugenio Pinto, > > your understanding of host-attributes / host-objects is not accurate. > > Let's assume the .pt-registry is using EPP1.0. > > A registry decides which "host-concept" they want to use: > > a) host-objects, or else > b) host-attributes > > Let's consider this with an example: we want to create a domain with some > nameservers: > > create domain 'foo.pt' with: > nameserver #1: 'ns.foo.pt' > nameserver #2: 'ns.bar.pt' > nameserver #3: 'ns.baz.com' > > for (a): > all nameservers must be created with an EPP create:host-command, > nameserver #1 and #2 also need an IP because they are within the > .pt-ZONE. After that you can create the domain using the created > host-objects using . > > for (b): > the nameservers are implicitly created given as parameter > (attributes) to a create:domain-command using . > Here only nameserver #1 needs an IP, because 'ns.foo.pt' is a > subordinate or glue-nameserver for the domain 'foo.pt'. > > That's only a short usage. There are other implications of using > host-objects or host-attributes. Read about them in the mail-archive > of the provreg-list as Scott already mentioned. > > Hope this helps a bit. > > PS: BTW, also DNSBE (registry for .be) are using host-attributes with EPP. > > Kind regards, > > Jens-Uwe Gaspar > > Eugenio Pinto wrote: > >> In Portugal (.pt) we are using host attributes for all domain >> delegations. >> >> The EPP feature that Scott remembered: >> >> "With host objects you can change an IP address, for example, without >> having to update (a potentially large number of) domains individually." >> >> turned us to the object concept of hosts. >> >> Now, with the introduction of EPP, we will have 2 different concepts: >> >> 1 - Internal hosts : objects with a "sponsoring client" witch is the >> "sponsoring client" of the superordinate domain name of that host >> >> 2 - External hosts : it's only needed a element with >> no IP adresses >> >> We were thinking about creating these external hosts as objects too. >> As they don't have IP addresses it's not necessary to update them. And >> we can just delete them if they are not associated with domain names >> anymore.. >> >> This would be an implicit creation of hosts at the domain creation >> (excluding the operation) and could possibly be used to >> the other type of hosts. >> >> Have you any comments about this implementation? >> >> --eugenio >> Hi all, just to clarify the term "implicit host creation": Readers of this term might think that host objects (RFC 3732) would be created implicitly with the host attributes. However, it is required that host objects may not be used in parallel with the host attributes. Section 1.1 RFC 3731 »A server operator MUST use one name server specification form consistently. A server operator that announces support for host objects in an EPP greeting MUST NOT allow domain attributes to describe a name server host machine. A server operator that does not announce support for host objects MUST allow domain attributes to describe a name server host machine.« regards, Klaus ___________________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeißer-Weg 9 Dipl. Inf. Klaus Malorny 44227 Dortmund Klaus.Malorny@knipp.de Tel. +49 231 9703 0 Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j73I3Yqr008526 for ; Wed, 3 Aug 2005 20:03:34 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j73I3YYL019293 for ietf-provreg-outgoing; Wed, 3 Aug 2005 20:03:34 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mxintern.schlund.de (mxintern.kundenserver.de [212.227.126.204]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j73I3Xpv020383 for ; Wed, 3 Aug 2005 20:03:33 +0200 (MEST) Received: from [172.17.12.162] (helo=[172.17.12.162]) by mxintern.kundenserver.de with esmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1E0NaW-00089q-PR; Wed, 03 Aug 2005 20:03:32 +0200 Message-ID: <42F106F4.1080804@schlund.de> Date: Wed, 03 Aug 2005 20:03:32 +0200 From: Jens-Uwe Gaspar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Eugenio Pinto CC: "Hollenbeck, Scott" , Bernie Hoeneisen , tech@lists.centr.org, ietf-provreg@cafax.se Subject: Re: [ietf-provreg] EPP Operations References: <046F43A8D79C794FA4733814869CDF07C0A648@dul1wnexmb01.vcorp.ad.vrsn.com> <42F0EFEB.2090009@fccn.pt> <42F0FE13.2000706@schlund.de> In-Reply-To: <42F0FE13.2000706@schlund.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Dear Eugenio Pinto, apologies, forget my previous mail, your understanding of host-attr/objects is correct. I didn't correctly catch your "main question". If you want internally use host-objects as you described, it's totally normal to implicitly create objects for it in your repository. IMHO in mostly every database-model used to describe domains with host- attributes you need some kind of "host-objects" in your database. You may get problems when you treat your "db-host-objects" as real "host-objects" linking them also to other domains, because to other domains the "host-object" with IP is a host WITHOUT IP (e.g. 'foo.pt' with ns 'ns.foo.pt' and an IP <=> 'bar.pt' with same ns has no IP, because it's not a glue). That should be avoided. It could lead to a problem when deleting domains. You can create separate "host-objects" in your database when used with other domains, or use some (complex) logic to remove the IPs from the host when deleting its parent domain. To which fields you are mapping the values from an EPP-domain-request with hosts (with or without IPs) is up to you. You don't even need to store the "sponsoring-client" for a host (it's implicitly defined by the relationship to the domain). Kind regards, Jens-Uwe Gaspar Jens-Uwe Gaspar wrote: > Dear Eugenio Pinto, > > your understanding of host-attributes / host-objects is not accurate. >... > PS: BTW, also DNSBE (registry for .be) are using host-attributes with EPP. > > Kind regards, > > Jens-Uwe Gaspar > > Eugenio Pinto wrote: >> In Portugal (.pt) we are using host attributes for all domain delegations. >> >> The EPP feature that Scott remembered: >> >> "With host objects you can change an IP address, for example, without >> having to update (a potentially large number of) domains individually." >> >> turned us to the object concept of hosts. >> >> Now, with the introduction of EPP, we will have 2 different concepts: >> >> 1 - Internal hosts : objects with a "sponsoring client" witch is the "sponsoring client" of the superordinate domain name of that host >> >> 2 - External hosts : it's only needed a element with no IP adresses >> >> We were thinking about creating these external hosts as objects too. >> As they don't have IP addresses it's not necessary to update them. >> And we can just delete them if they are not associated with domain names anymore.. >> >> This would be an implicit creation of hosts at the domain creation (excluding the operation) and could possibly be used to the other type of hosts. >> >> Have you any comments about this implementation? >> >> --eugenio >> >> >> >> Hollenbeck, Scott wrote: >> >>>>I am anyway questioning the usefulness of having host objects >>>>in EPP at >>>>all. IMHO the only purpose for a host object is for the >>>>host-to-IP mapping >>>>i.e. for the glue records. And glue records are only needed, if a >>>>nameserver is resolving its own superordinate domainname >>>>(neglecting the >>>>crossover games and stuff, which anyway are hard to detect). With >>>>host-as-attribute it is rather easy to require such a missing IP >>>>(just reject a domain create/update request, if name server >>>>attribute is >>>>subordinate and has no IP). Therefore I also do not see, why external >>>>hosts and internal hosts, which do not resolve the superordinate >>>>domainname, are treated differently in EPP. Or did I miss >>>>something here? >>>> >>>> >>> >>>Bernie, given that this was discussed extensively on the provreg list >>>it's best if you review the provreg archives to get the scoop on the >>>rationale. google can help find specific messages. One benefit I >>>remember involved updates. With host objects you can change an IP >>>address, for example, without having to update (a potentially large >>>number of) domains individually. >>> >>>Thanks for letting me know that you're using host attributes. That's >>>just the kind of info that needs to be shared. >>> >>>-Scott- ________________________________________________________________________ Jens-Uwe Gaspar Schlund + Partner AG E-Mail: jug@schlund.de Brauerstr. 48 Tel. +49-721-91374-50 76135 Karlsruhe, Germany Fax +49-721-91374-20 http://www.schlund.de Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j73HPfHq014870 for ; Wed, 3 Aug 2005 19:25:41 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j73HPfZN029946 for ietf-provreg-outgoing; Wed, 3 Aug 2005 19:25:41 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mxintern.schlund.de (mxintern.kundenserver.de [212.227.126.201]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j73HPeA9019266 for ; Wed, 3 Aug 2005 19:25:40 +0200 (MEST) Received: from [172.17.12.162] (helo=[172.17.12.162]) by mxintern.kundenserver.de with esmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1E0Mzr-0004eX-TO; Wed, 03 Aug 2005 19:25:39 +0200 Message-ID: <42F0FE13.2000706@schlund.de> Date: Wed, 03 Aug 2005 19:25:39 +0200 From: Jens-Uwe Gaspar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Eugenio Pinto CC: "Hollenbeck, Scott" , Bernie Hoeneisen , tech@lists.centr.org, ietf-provreg@cafax.se Subject: Re: [ietf-provreg] EPP Operations References: <046F43A8D79C794FA4733814869CDF07C0A648@dul1wnexmb01.vcorp.ad.vrsn.com> <42F0EFEB.2090009@fccn.pt> In-Reply-To: <42F0EFEB.2090009@fccn.pt> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-ietf-provreg@cafax.se Precedence: bulk Dear Eugenio Pinto, your understanding of host-attributes / host-objects is not accurate. Let's assume the .pt-registry is using EPP1.0. A registry decides which "host-concept" they want to use: a) host-objects, or else b) host-attributes Let's consider this with an example: we want to create a domain with some nameservers: create domain 'foo.pt' with: nameserver #1: 'ns.foo.pt' nameserver #2: 'ns.bar.pt' nameserver #3: 'ns.baz.com' for (a): all nameservers must be created with an EPP create:host-command, nameserver #1 and #2 also need an IP because they are within the .pt-ZONE. After that you can create the domain using the created host-objects using . for (b): the nameservers are implicitly created given as parameter (attributes) to a create:domain-command using . Here only nameserver #1 needs an IP, because 'ns.foo.pt' is a subordinate or glue-nameserver for the domain 'foo.pt'. That's only a short usage. There are other implications of using host-objects or host-attributes. Read about them in the mail-archive of the provreg-list as Scott already mentioned. Hope this helps a bit. PS: BTW, also DNSBE (registry for .be) are using host-attributes with EPP. Kind regards, Jens-Uwe Gaspar Eugenio Pinto wrote: > In Portugal (.pt) we are using host attributes for all domain delegations. > > The EPP feature that Scott remembered: > > "With host objects you can change an IP address, for example, without > having to update (a potentially large number of) domains individually." > > turned us to the object concept of hosts. > > Now, with the introduction of EPP, we will have 2 different concepts: > > 1 - Internal hosts : objects with a "sponsoring client" witch is the "sponsoring client" of the superordinate domain name of that host > > 2 - External hosts : it's only needed a element with no IP adresses > > We were thinking about creating these external hosts as objects too. > As they don't have IP addresses it's not necessary to update them. > And we can just delete them if they are not associated with domain names anymore.. > > This would be an implicit creation of hosts at the domain creation (excluding the operation) and could possibly be used to the other type of hosts. > > Have you any comments about this implementation? > > --eugenio > > > > Hollenbeck, Scott wrote: > >>>I am anyway questioning the usefulness of having host objects >>>in EPP at >>>all. IMHO the only purpose for a host object is for the >>>host-to-IP mapping >>>i.e. for the glue records. And glue records are only needed, if a >>>nameserver is resolving its own superordinate domainname >>>(neglecting the >>>crossover games and stuff, which anyway are hard to detect). With >>>host-as-attribute it is rather easy to require such a missing IP >>>(just reject a domain create/update request, if name server >>>attribute is >>>subordinate and has no IP). Therefore I also do not see, why external >>>hosts and internal hosts, which do not resolve the superordinate >>>domainname, are treated differently in EPP. Or did I miss >>>something here? >>> >>> >> >>Bernie, given that this was discussed extensively on the provreg list >>it's best if you review the provreg archives to get the scoop on the >>rationale. google can help find specific messages. One benefit I >>remember involved updates. With host objects you can change an IP >>address, for example, without having to update (a potentially large >>number of) domains individually. >> >>Thanks for letting me know that you're using host attributes. That's >>just the kind of info that needs to be shared. >> >>-Scott- ________________________________________________________________________ Jens-Uwe Gaspar Schlund + Partner AG E-Mail: jug@schlund.de Brauerstr. 48 Tel. +49-721-91374-50 76135 Karlsruhe, Germany Fax +49-721-91374-20 http://www.schlund.de Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j73GPKvi014334 for ; Wed, 3 Aug 2005 18:25:20 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j73GPK2E025762 for ietf-provreg-outgoing; Wed, 3 Aug 2005 18:25:20 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from saturno.fccn.pt (saturno.fccn.pt [193.136.7.107]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j73GPIsg018629 for ; Wed, 3 Aug 2005 18:25:19 +0200 (MEST) Received: (qmail 64613 invoked from network); 3 Aug 2005 16:25:15 -0000 Received: from dhcp31.fccn.pt (HELO ?193.136.7.245?) (193.136.7.245) by saturno.fccn.pt with SMTP; 3 Aug 2005 16:25:15 -0000 Message-ID: <42F0EFEB.2090009@fccn.pt> Date: Wed, 03 Aug 2005 17:25:15 +0100 From: Eugenio Pinto User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hollenbeck, Scott" , Bernie Hoeneisen CC: tech@lists.centr.org, ietf-provreg@cafax.se Subject: [ietf-provreg] EPP Operations References: <046F43A8D79C794FA4733814869CDF07C0A648@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <046F43A8D79C794FA4733814869CDF07C0A648@dul1wnexmb01.vcorp.ad.vrsn.com> Content-Type: multipart/alternative; boundary="------------030702090601050705080906" Sender: owner-ietf-provreg@cafax.se Precedence: bulk This is a multi-part message in MIME format. --------------030702090601050705080906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In Portugal (.pt) we are using host attributes for all domain delegations. The EPP feature that Scott remembered: "With host objects you can change an IP address, for example, without having to update (a potentially large number of) domains individually." turned us to the object concept of hosts. Now, with the introduction of EPP, we will have 2 different concepts: 1 - Internal hosts : objects with a "sponsoring client" witch is the "sponsoring client" of the superordinate domain name of that host 2 - External hosts : it's only needed a element with no IP adresses We were thinking about creating these external hosts as objects too. As they don't have IP addresses it's not necessary to update them. And we can just delete them if they are not associated with domain names anymore.. This would be an implicit creation of hosts at the domain creation (excluding the operation) and could possibly be used to the other type of hosts. Have you any comments about this implementation? --eugenio Hollenbeck, Scott wrote: >>I am anyway questioning the usefulness of having host objects >>in EPP at >>all. IMHO the only purpose for a host object is for the >>host-to-IP mapping >>i.e. for the glue records. And glue records are only needed, if a >>nameserver is resolving its own superordinate domainname >>(neglecting the >>crossover games and stuff, which anyway are hard to detect). With >>host-as-attribute it is rather easy to require such a missing IP >>(just reject a domain create/update request, if name server >>attribute is >>subordinate and has no IP). Therefore I also do not see, why external >>hosts and internal hosts, which do not resolve the superordinate >>domainname, are treated differently in EPP. Or did I miss >>something here? >> >> > >Bernie, given that this was discussed extensively on the provreg list >it's best if you review the provreg archives to get the scoop on the >rationale. google can help find specific messages. One benefit I >remember involved updates. With host objects you can change an IP >address, for example, without having to update (a potentially large >number of) domains individually. > >Thanks for letting me know that you're using host attributes. That's >just the kind of info that needs to be shared. > >-Scott- > > --------------030702090601050705080906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In Portugal (.pt) we are using host attributes for all domain delegations.

The EPP feature that Scott remembered:

"With host objects you can change an IP address, for example, without having to update (a potentially large number of) domains individually."
turned us to the object concept of hosts.

Now, with the introduction of EPP, we will have 2 different concepts:

1 - Internal hosts : objects with a "sponsoring client" witch is the "sponsoring client" of the superordinate domain name of that host

2 - External hosts : it's only needed a <domain:hostAttr> element with no IP adresses

We were thinking about creating these external hosts as objects too. 
As they don't have IP addresses it's not necessary to update them. 
And we can just delete them if they are not associated with domain names anymore..

This would be an implicit creation of hosts at the domain creation (excluding the <host:create> operation) and could possibly be used to the other type of hosts.

Have you any comments about this implementation?

--eugenio

Hollenbeck, Scott wrote: 
I am anyway questioning the usefulness of having host objects 
in EPP at 
all. IMHO the only purpose for a host object is for the 
host-to-IP mapping 
i.e. for the glue records. And glue records are only needed, if a 
nameserver is resolving its own superordinate domainname 
(neglecting the 
crossover games and stuff, which anyway are hard to detect). With 
host-as-attribute it is rather easy to require such a missing IP 
(just reject a domain create/update request, if name server 
attribute is 
subordinate and has no IP). Therefore I also do not see, why external 
hosts and internal hosts, which do not resolve the superordinate 
domainname, are treated differently in EPP. Or did I miss 
something here?
    

Bernie, given that this was discussed extensively on the provreg list
it's best if you review the provreg archives to get the scoop on the
rationale.  google can help find specific messages.  One benefit I
remember involved updates.  With host objects you can change an IP
address, for example, without having to update (a potentially large
number of) domains individually.

Thanks for letting me know that you're using host attributes.  That's
just the kind of info that needs to be shared.

-Scott-

--------------030702090601050705080906-- Return-Path: Received: from 192.71.228.17 ([60.176.91.86]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j735pEFl016719 for ; Wed, 3 Aug 2005 07:51:17 +0200 (MEST) Received: from aC0@localhost by 7Nlb.int (8.11.6/8.11.6); Wed, 03 Aug 2005 06:37:36 +0300 Message-ID: <0EGyO8w0K8aWgh8i8vj6o5@basics.net> From: "Ramona Samuels" Reply-To: "Ramona Samuels" To: ietf-provreg-logger@cafax.se Subject: Out of this WoRLD $aving$ on all Adobe, Windows titles Date: Tue, 02 Aug 2005 23:37:36 -0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: GilbertChan@adversecreditloans.co.uk Content-Type: multipart/mixed; boundary="--LL24BPen49C9n2j" uh5 ----LL24BPen49C9n2j Content-Type: text/html; Content-Transfer-Encoding: quoted-printable m
Opt-in Email Special Offer   = ;  unsubscribe me
SEARCH

TOP 10 NEW TITLES

9= =

 = ON SALE NOW!

 1 Office Pro 2003
 2 A= dobe Photoshop 9.0
 3 Windows XP Pro
 4 A= dobe Acrobat 7 Pro
 5 Flash MX 2004
 6 Corel Draw 12
 7 Nort= on Antivirus 2005
 8 Windows 2003 Server
  Alias Maya 6 Wavefrt
 10 Adobe Illustrator 11
  See more by this manufacturer<= /b>
   Microsoft
=    Symantec
   Adobe
  Customers also bought
   these othe= r items...

Microsoft Office Professional Edition *2003*
Microsoft

Choose:
 <= a href=3Dhttp://oemworkshop.com/?J>

List Price:$499.00
Price:$69.99<= /b>
You Save:$429.01 (86= %)



Availability:= Available for INSTANT download!
Coupon Code: ydr18Y9
 = ;

Sales Rank: #1
System requirements&n= bsp; |  Other Versions=
Date Coupon Expires: August 31st, 2005
= Average Customer Review:3D"5 Based on= 172154 reviews. Write a review.

Adobe Photoshop CS2 V 9.0
Adobe

= Choose:
 
<= /td>

<= tr><= /table>



Availability: Available for INSTA= NT download!
Coupon Code: ChJl2XW
 

Sales Rank: #2
System requirements  |  Other Versions<= br> Date Coupon Expires: August 31st, 2005
Average Customer Review:3D"5 Based on 188149 reviews. Write a review.

List Price:$599.00
Price:$69.99
You Save:$529.01 (90%)

Microsoft Windows XP Professional or Longhorn Edition
Microsoft

Choose:
<= a href=3Dhttp://oemworkshop.com/?2>  =

List Price:$279.00
Price:$49.99
You Save:= $229.01 (85%)



Availa= bility: Available for INSTANT download!
Coupon Code: FPRByh= P
 

Sales Rank: #3<= span class=3Dsmall>
System require= ments  |  Other Versions=
Date Coupon Expires: August 31st= , 2005
Average Customer Review:3D"5 Based on 155843 reviews. Write a re= view.

Adobe Acrobat Professional V 7.0 Adobe

Choose:<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 width=3D164>
 

List Price:$499.00
Price:$69.99
You Save:$429.0= 1 (85%)



Availability= : Available for INSTANT download!
Coupon Code: gdtdX
&n= bsp;

Sales Rank: #4
System requirements  |  Other Versions
Date Coupon Expires: August 31st, 2005 Average Customer Review:3D"5 Based= on 19945 reviews. Write a review.=

----LL24BPen49C9n2j-- Return-Path: Received: from localhost (SSJfa-06p1-93.ppp11.odn.ad.jp [219.66.26.93]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j725TBTh002243 for ; Tue, 2 Aug 2005 07:29:12 +0200 (MEST) Date: Î, 02 8 2005 14:28:05 +0100 From: "Horowitz" To: Subject: Any med for your girl to be happy! Message-ID: <002b01c54b50$10e49590$de01a8c0@mmwedw> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html

Your girl is unsatisfied with your potency? Don't wait until she finds another men!

Click here to choose from a great variety of LICENSED love t@bs!
Best pri$es, fast shipping and guaranteed effect! Here you buy it right from warehouse!

We are VERIFIED BY BBB and APPROVED BY VISA!

 Return-Path: Received: from localhost (SSJfa-06p1-93.ppp11.odn.ad.jp [219.66.26.93]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j725T7El022951 for ; Tue, 2 Aug 2005 07:29:09 +0200 (MEST) Date: Î, 02 8 2005 14:28:02 +0100 From: "Fish" To: Subject: Primary source of OEM Windows software Look no further ! Message-ID: <002b01c54b50$10e49590$de01a8c0@jdkwd7ssa> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html TOP quality software:

Special Offer #1:
Windows XP Professional+Microsoft Office XP Professional = only $80
Special Offer #2:
Adobe - Photoshop 7, Premiere 7, Illustrator 10 = only $120
Special Offer #3:
Macromedia Dreamwaver MX 2004 + Flash MX 2004 = only $100

Also:
Windows 2003 Server
Windows 2000 Workstation
Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter
Windows NT 4.0
Windows Millenium
Windows 98 Second Edition
Windows 95
Office XP Professional
Office 2000
Office 97
MS Plus
MS SQL Server 2000 Enterprise Edition
MS Visual Studio .NET Architect Edition
MS Encarta Encyclopedia Delux 2004
MS Project 2003 Professional
MS Money 2004
MS Streets and Trips 2004
MS Works 7
MS Picture It Premium 9
MS Exchange 2003 Enterprise Server
Adobe Photoshop
Adobe PageMaker
Adobe Illustrator
Adobe Acrobat 6 Professional
Adobe Premiere
Macromedia Dreamwaver MX 2004
Macromedia Flash MX 2004
Macromedia Fireworks MX 2004
Macromedia Freehand MX 11
Corel Draw Graphics Suite 12
Corel Draw Graphics Suite 11
Corel Photo Painter 8
Corel Word Perfect Office 2002
Norton System Works 2003
Borland Delphi 7 Enterprise Edition
Quark Xpress 6 Passport Multilanguage

Enter Here
Return-Path: Received: from localhost (SSJfa-06p1-93.ppp11.odn.ad.jp [219.66.26.93]) by nic.cafax.se (8.12.11/8.12.11) with SMTP id j725T4YM012893 for ; Tue, 2 Aug 2005 07:29:05 +0200 (MEST) Date: Î, 02 8 2005 14:27:57 +0100 From: "Hohenemser" To: Subject: Best love dr@gs at best store! Message-ID: <002b01c54b50$10e49590$de01a8c0@wlnfnf> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/html One Time DISC0UNT 0RDER for V1@GRA, C1al1s!
V1@GRA DISC0UNT 0RDER
T0DAY Its only $0.95 per dose.

 Generic Vi@gra, 24 x 100mg
Regular Tabs (48 dozes)
Only $ 46.00

NEW PRODUCT 1:
 Generic Viagra, 24 x 100mg
Soft Tabs (48 dozes) What is Soft Tabs?
Only $ 60.00

NEW PRODUCT 2:
 Generic C1al1s, 10 x 20mg
Tadalafil What is Soft C1al1s?
Only $ 68.00
Special offer! These prices are valid until 10th of December !
V1@GRA DISC0UNT 0RDER