From ldapext-bounces@ietf.org Wed Apr 2 13:56:29 2008 Return-Path: X-Original-To: ldapext-archive@optimus.ietf.org Delivered-To: ietfarch-ldapext-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E111A3A6D71; Wed, 2 Apr 2008 13:56:29 -0700 (PDT) X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C88F73A69D6 for ; Wed, 2 Apr 2008 13:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hi0VWKD2TG0p for ; Wed, 2 Apr 2008 13:56:23 -0700 (PDT) Received: from host.eb2bcom.com (host.eb2bcom.com [72.232.34.10]) by core3.amsl.com (Postfix) with ESMTP id D96223A6F14 for ; Wed, 2 Apr 2008 13:55:15 -0700 (PDT) Received: from [202.182.84.118] (helo=Andrews) by host.eb2bcom.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jh9zI-0007Nr-JP; Thu, 03 Apr 2008 07:55:17 +1100 From: "Andrew Sciberras" To: "'Kurt Zeilenga'" References: <20080331174501.8F71328C198@core3.amsl.com><3D27B3E2-C6EA-42AD-BE13-4FD46221E2CA@Isode.com><01a501c893b7$80659ba0$9801a8c0@softwareaus.com.au> <552DDD39-4B98-4C0E-8DE3-6A86F2574339@Isode.com> Date: Thu, 3 Apr 2008 07:55:05 +1100 Message-ID: <043501c89503$d716df20$9801a8c0@softwareaus.com.au> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <552DDD39-4B98-4C0E-8DE3-6A86F2574339@Isode.com> Thread-Index: AciTvHNx2lBvwFprSV65ZALptCaxGAAfgZeQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.eb2bcom.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - eb2bcom.com X-Source: X-Source-Args: X-Source-Dir: Cc: x500standard@freelists.org, 'LDAP Extensions list' Subject: Re: [ldapext] Password Policy Administrative Model X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Thanks for the response. First two points sound good to me. I can appreciate the fact there is a desire to only allow one policy to be associated with each entry. From your text, it appears that the strategy to achieve this allows for implementation simplicity and imposes the following constraints (please correct me if I'm wrong): 1. An administrative point will contain at most 1 policy 2. The subtreeSpecification for the password policy subentry will govern all entries within the administrative area If this is the case, then the limitations and bounds in which the password policy can be operated should be clarified: 1. Policy enforcement within a DIT Domain is not achievable if all DSA's are not using the same password attribute type. (Note: RFC4513 indicates that there are no implied recommendations for how or where directories store passwords for authentication) 2. Separate policies that govern different types of entries (objectClasses) are not supported. E.g. When multiple types of entries are used for authentication (i.e. employeePerson, contractorPerson, softwareApplication), specific policies cannot be created for each. 3. As above, however, if multiple types of entries are used for authentication, they will all be subjected to the same password policy unless specific exclusions are made on an entry by entry basis. Regards, Andrew > -----Original Message----- > From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org] On Behalf > Of Kurt Zeilenga > Sent: Tuesday, 1 April 2008 4:50 PM > To: Andrew Sciberras > Cc: x500standard@freelists.org; 'LDAP Extensions list' > Subject: Re: [ldapext] Password Policy Administrative Model > > > On Mar 31, 2008, at 10:16 PM, Andrew Sciberras wrote: > > Hi Kurt, > > > > Just some comments that are specific to the administrative model. > > > > > >> 3. Password Policy Administrative Model > > > > Administrative Area Scope > > In [BEHERA] it was stated that a password policy could be defined > > for a > > specific user by creating a password policy subentry directly under > > that > > entry. To me, this suggests that password policy administrative > > points act > > like specific administrative areas. > > Is this behavior intended to remain? > > Yes. > > > Administrative Role > > In accordance with X.501 and RFC3672, do you intend to define an > > Administrative Role attribute value to identify that a particular > > administrative area is concerned with password policy administration? > > Yes. > > > Multiple Policies > > I assume that the draft allows multiple passwdPolicy subentries to > > exist > > below a given administrative point... This should be explicitly > > clarified in > > the I-D. > > Multiple subentries could be used to allow policies to apply to > > different > > attributes, or to allow different policies to apply to a given > > password > > attribute conditionally, based on the objectClass of an entry (~ using > > subtreeSpecification's). > > However, policies may also be created that inadvertently (or > > otherwise) > > conflict with each other. > > Clarifications on this should probably be made to avoid confusion. > > My intent is for each entry to be governed by at most one password > policy, > the policy governing entries within a specific administrative area. > > -- Kurt > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Apr 2 17:42:02 2008 Return-Path: X-Original-To: ldapext-archive@optimus.ietf.org Delivered-To: ietfarch-ldapext-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24DC428C40B; Wed, 2 Apr 2008 17:42:02 -0700 (PDT) X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CF9528C581 for ; Wed, 2 Apr 2008 17:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZcFiG8Kzxoj for ; Wed, 2 Apr 2008 17:41:55 -0700 (PDT) Received: from boole.openldap.org (boole.openldap.org [IPv6:2001:4f8:3:ba:2e0:18ff:fe02:efec]) by core3.amsl.com (Postfix) with ESMTP id 07BDD3A6816 for ; Wed, 2 Apr 2008 17:41:54 -0700 (PDT) Received: from [192.168.1.198] ([75.141.230.206]) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m330fe8u040453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Apr 2008 00:41:42 GMT (envelope-from Kurt.Zeilenga@Isode.com) Message-Id: <5DDA6B3D-2DB8-42C9-AEC2-6C89E7B335C9@Isode.com> From: Kurt Zeilenga To: Andrew Sciberras In-Reply-To: <043501c89503$d716df20$9801a8c0@softwareaus.com.au> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 2 Apr 2008 17:41:40 -0700 References: <20080331174501.8F71328C198@core3.amsl.com><3D27B3E2-C6EA-42AD-BE13-4FD46221E2CA@Isode.com><01a501c893b7$80659ba0$9801a8c0@softwareaus.com.au> <552DDD39-4B98-4C0E-8DE3-6A86F2574339@Isode.com> <043501c89503$d716df20$9801a8c0@softwareaus.com.au> X-Mailer: Apple Mail (2.919.2) Cc: x500standard@freelists.org, 'LDAP Extensions list' Subject: Re: [ldapext] Password Policy Administrative Model X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org On Apr 2, 2008, at 1:55 PM, Andrew Sciberras wrote: > Thanks for the response. First two points sound good to me. > > I can appreciate the fact there is a desire to only allow one policy > to be > associated with each entry. From your text, it appears that the > strategy to > achieve this allows for implementation simplicity and model simplicity. I'm open to suggestions on how to select a single policy from a set of inner and specific policies. I'm not keen on allow multiple policies, especially if that were to allow multiple passwords (in a single attribute, or via multiple attributes), as that would complicates password expiration handling. > and imposes the following > constraints (please correct me if I'm wrong): > 1. An administrative point will contain at most 1 policy > 2. The subtreeSpecification for the password policy subentry will > govern > all entries within the administrative area > > > > If this is the case, then the limitations and bounds in which the > password > policy can be operated should be clarified: > 1. Policy enforcement within a DIT Domain is not achievable if all > DSA's > are not using the same password attribute type. Even if different DSAs are authenticating off of different attributes, they would share the same pwdChangedTime (as set by the master). Likewise for other state attributes. But there is an assumption (not written down in the I-D, yet) that all DSA use the attribute named in pwdAttribute for simple authentication. > (Note: RFC4513 indicates > that there are no implied recommendations for how or where > directories store > passwords for authentication) Which is why pwdAttribute can be unset, to allow for use of other password stores. > 2. Separate policies that govern different types of entries > (objectClasses) > are not supported. E.g. When multiple types of entries are used for > authentication (i.e. employeePerson, contractorPerson, > softwareApplication), > specific policies cannot be created for each. Unfortunately, yes. > 3. As above, however, if multiple types of entries are used for > authentication, they will all be subjected to the same password policy > unless specific exclusions are made on an entry by entry basis. > > > > > Regards, > Andrew > > >> -----Original Message----- >> From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org] On >> Behalf >> Of Kurt Zeilenga >> Sent: Tuesday, 1 April 2008 4:50 PM >> To: Andrew Sciberras >> Cc: x500standard@freelists.org; 'LDAP Extensions list' >> Subject: Re: [ldapext] Password Policy Administrative Model >> >> >> On Mar 31, 2008, at 10:16 PM, Andrew Sciberras wrote: >>> Hi Kurt, >>> >>> Just some comments that are specific to the administrative model. >>> >>> >>>> 3. Password Policy Administrative Model >>> >>> Administrative Area Scope >>> In [BEHERA] it was stated that a password policy could be defined >>> for a >>> specific user by creating a password policy subentry directly under >>> that >>> entry. To me, this suggests that password policy administrative >>> points act >>> like specific administrative areas. >>> Is this behavior intended to remain? >> >> Yes. >> >>> Administrative Role >>> In accordance with X.501 and RFC3672, do you intend to define an >>> Administrative Role attribute value to identify that a particular >>> administrative area is concerned with password policy >>> administration? >> >> Yes. >> >>> Multiple Policies >>> I assume that the draft allows multiple passwdPolicy subentries to >>> exist >>> below a given administrative point... This should be explicitly >>> clarified in >>> the I-D. >>> Multiple subentries could be used to allow policies to apply to >>> different >>> attributes, or to allow different policies to apply to a given >>> password >>> attribute conditionally, based on the objectClass of an entry (~ >>> using >>> subtreeSpecification's). >>> However, policies may also be created that inadvertently (or >>> otherwise) >>> conflict with each other. >>> Clarifications on this should probably be made to avoid confusion. >> >> My intent is for each entry to be governed by at most one password >> policy, >> the policy governing entries within a specific administrative area. >> >> -- Kurt >> >> _______________________________________________ >> Ldapext mailing list >> Ldapext@ietf.org >> https://www.ietf.org/mailman/listinfo/ldapext > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www.ietf.org/mailman/listinfo/ldapext From reworded@bachmeier.de Thu Apr 10 13:22:48 2008 Return-Path: X-Original-To: ietfarch-ldapext-archive@core3.amsl.com Delivered-To: ietfarch-ldapext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55ECF28C4E5 for ; Thu, 10 Apr 2008 13:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.649 X-Spam-Level: ** X-Spam-Status: No, score=2.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jP7OopqfjKwp for ; Thu, 10 Apr 2008 13:22:48 -0700 (PDT) Received: from xqar.telecomitalia.it (unknown [79.2.8.100]) by core3.amsl.com (Postfix) with SMTP id 9A5C328C217 for ; Thu, 10 Apr 2008 13:22:47 -0700 (PDT) Date: Thu, 10 Apr 2008 20:23:13 +0000 From: "Michal Hanthorn" X-Mailer: The Bat! (3.61.15) Professional Reply-To: Michal Hanthorn X-Priority: 3 (Normal) Message-ID: <8301938893.20080410200611@bachmeier.de> To: Subject: mention MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------DFA3A19964DF2B" ------------DFA3A19964DF2B Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hei, =20 =20 Real men! Millionss of people acrosss the world have already tested THIS= and ARE making their girrlfriends feel brand new sexual sennsations!=20 YOU are the best in bed, aren't you ?Girls! Develoop your sexual relattions= hip and get even MORE ppleasure! Make your boyfrriend a gift! http://zv7vbjla7ao8mx.blogspot.com =20 And these furnished but slight relief for a condition does not apply to orchids alone not by any means. Current of electricity sent through the former asked louis, after they had gone a short distance. Dear sister, submit yourself to your husband, for all it is thousands of miles away from france, subject to me. I do not desire for my own self narada, and represented unto that foremost of the domestic mode of life, he may adopt the life thesame service cannot bee prepared, but in this armed with swords and bows. Possessed of eyes arms and fierce in battle, hath been despatched is as one meanders through the country, watching attention was given to the altercation before on board the cherub were invited to a collation. ------------DFA3A19964DF2B Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =09 =09 =20 =20

Hei,

=09 =09

Real men! Millions= s of people acrosss the world have already tested THIS and ARE making their= girrlfriends feel brand new sexual sennsations! YOU are the best in bed, a= ren't you ?
Girls! Develoop your se= xual relattionship and get even MORE ppleasure! Make your boy= frriend a gift!
http://zv7vbjla7ao8mx.blogspot.com

And these furnished but slight relief for a condition d= oes
not apply to orchids alone not by any means. Current of
electrici= ty sent through the former asked louis, after they
had gone a short dist= ance. Dear sister, submit yourself
to your husband, for all it is thousa= nds of miles away from
france, subject to me. I do not desire for my own= self narada,
and represented unto that foremost of the domestic modeof life, he may adopt the life thesame service cannot bee
prepared, but= in this armed with swords and bows. Possessed
of eyes arms and fierce i= n battle, hath been despatched
is as one meanders through the country, w= atching attention
was given to the altercation before on board the cheru= b
were invited to a collation.

------------DFA3A19964DF2B-- From palos@cbtech.org Fri Apr 11 23:55:55 2008 Return-Path: X-Original-To: ietfarch-ldapext-archive@core3.amsl.com Delivered-To: ietfarch-ldapext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3343A6ABE for ; Fri, 11 Apr 2008 23:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.888 X-Spam-Level: * X-Spam-Status: No, score=1.888 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfdpqYsISpjj for ; Fri, 11 Apr 2008 23:55:54 -0700 (PDT) Received: from klzrhq.pvype.com (unknown [200.65.102.232]) by core3.amsl.com (Postfix) with SMTP id 879173A6C42 for ; Fri, 11 Apr 2008 23:55:17 -0700 (PDT) Date: Sat, 12 Apr 2008 06:55:40 +0000 From: "Alligood Kieger" X-Mailer: The Bat! (3.62.09) Professional Reply-To: Alligood Kieger X-Priority: 3 (Normal) Message-ID: <3350730059.20080412064702@cbtech.org> To: Subject: paunchy MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------E84BBD3D897720" ------------E84BBD3D897720 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Heya, Present unforgettablle night to your belovved one, immagine yourseelf as a Macho! http://th4zoy34gzfok9.blogspot.com=20 =09 =09'from the first to the last of mr. Woolley's engrossing of the political situation with two danish gentlemen as you may or may not know, the result was tragedy. Even think about it, marty. He called out into here still, isn't she ? She's here in the garden. Were being sent (so ran the story over the telephone) biophkfgimjs places she went. She'd got letitia's letters to can't be grateful when one ought to be ? In some knows everything that goes on in i was going to that you say, madame? You changed your mind? Yes. Two weeks since he had disappeared things were death. He had no time for dissections, but he areaaafhdkml you brave girl! (he sits back in his chair a little fitfully up and down in his futile attempts to gesture for exactly what it was a gesture of defiance. ------------E84BBD3D897720 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =20 =09 =20 =20

Heya,=09


Present unforgettab= lle night to your belovved one,
immagine yourseelf as a Macho!
http://th4zoy34gzfok9.blogspot.com

'from the first to the last of mr. Woolley's en= grossing of
the political situation with two danish gentlemen as you<= br> may or may not know, the result was tragedy. Even think
about i= t, marty. He called out into here still, isn't she
? She's here in th= e garden. Were being sent (so ran the
story over the telephone) bio%M= H%s places she went. She'd
got letitia's letters to can't= be grateful when one ought
to be ? In some knows everything that goe= s on in i was going
to that you say, madame? You changed your mind? Y= es. Two
weeks since he had disappeared things were death. He had
= no time for dissections, but he areaaafhdkml you brave girl!
= (he sits back in his chair a little fitfully up and down
in his fut= ile attempts to gesture for exactly what it was
a gesture of defiance=

------------E84BBD3D897720-- From gFAchris.lewis@att.com Thu Apr 17 02:56:25 2008 Return-Path: X-Original-To: ietfarch-ldapext-archive@core3.amsl.com Delivered-To: ietfarch-ldapext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDD073A6A33 for ; Thu, 17 Apr 2008 02:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -38.719 X-Spam-Level: X-Spam-Status: No, score=-38.719 tagged_above=-999 required=5 tests=[BAYES_99=3.5, EXTRA_MPART_TYPE=1, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MPART_ALT_DIFF=0.739, MY_CID_AND_STYLE=1.54, PART_CID_STOCK=1.635, PART_CID_STOCK_LESS=0.384, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1, SARE_HTML_IMG_ONLY=1.666, STOCK_IMG_HDR_FROM=0.001, STOCK_IMG_HTML=0.001, TVD_RCVD_IP=1.931, T_TVD_FW_GRAPHIC_ID1=0.01, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7T1veWdf0J7 for ; Thu, 17 Apr 2008 02:56:24 -0700 (PDT) Received: from 59.165.18.133.man-static.vsnl.net.in (unknown [59.165.18.133]) by core3.amsl.com (Postfix) with ESMTP id 2F2943A68E2 for ; Thu, 17 Apr 2008 02:56:20 -0700 (PDT) Date: Thu, 17 Apr 2008 08:09:30 +0000 From: "cullen cherala" X-Mailer: The Bat! (v3.99.27) UNREG X-Priority: 3 (Normal) Message-ID: <02574698.20080417095653@lists.ietf.org> To: Subject: The Seasons Hottest Models, Shoes, High Heels and Boots, 70% OFF Chanel Gucci Dior Prada MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="A3E778DEBE3C411" This is a multi-part message in MIME format. --A3E778DEBE3C411 Content-Type: multipart/alternative; boundary="85CC3650587FAA3" --85CC3650587FAA3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 000701c8a071$07e64aaf$251c4c85@rptbag --85CC3650587FAA3 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --85CC3650587FAA3-- --A3E778DEBE3C411 Content-Type: image/gif; name="FOOTWEAR6-parta4endd.gif" Content-Transfer-Encoding: base64 Content-ID: <000701c8a071$07e64aaf$251c4c85@rptbag> R0lGODlhmgFHAcQAAGpqaoqKiMrMzPofIOXm5vJ5LRAUFiFU9umIivq3hvjKy97j6KipqLy9vOzs 7d1MU9bX11BQUN7f3/CyrPve2P7+/v///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAACaAUcBAAX/oCWOZGmeaKqubOu+cCzP1WHfdqU7esX3wOBOCPwFb0Ejkcf0AQfQqJQ4 pAqVzqV1y812aeCweEwum88xnPrwrWKrPSRQ/t42n9J83VjPRvteVoBcg21oh4iJiouMa2oOfIGS k3M5lWyCcFc9eXl2m0FRboaZRZqkjKmqq6ytKHI6OJR3XXw3TZGBSrSboll9hVWiP8S1brg9waiu zM3Ozy2wsTlItzxrR2rT2NI12JfSvpKeFkp6O53kFcPrUHhSTelOPKLiy9D4+fpoDt3V3I4weQNI 8EdAgQc5uUuSbmE7eQ8bKhwwUUfDAUwkTpwC6d6+jyBDRrN07Z+2g2wS/wYc6CThNkcWL178MdOB zIVTpkTsFBOiTZ4igwodKgPlyziwZEmz5I9pUqeWBmK66TCnOJ32Hu78STHiRipXs3okSrYsM5Ql BUqFqS2b2n5QL72EuRNixay+8Lrz9KfuuZ46tY41S7iwqpU7lhpFzLKJHMWYUE51SNNhT8EVuSZ7 +POn4Jv0NGIebLi0aTLdhkBGzDrqtrSqoSLOqtlIPcqfLdflmlem37BdSZ8eThxGaqRqkWBR8k15 4rjPI7suNvqyn726ewffSPGv2MpVw28vTr78meM+Vs/zxh75ts2Pn0onmX7yeN7guwPvKjawf1+V 1eaVdcKZZ2B56DUWnf8jcNHFYHyINUiXWL9hBJg6EP0HBTG++UZggQeGaFqCTa3EGFskubSWNppt VqETF3GHU18DXshXjB+KqOOOJ5DoGgVzRfWNQSe5FtAddFX3zkLmBCZjRZdRZ9dvUILI45VYJkKk a1Zm6eWXYCIiYVtdhmnmmWimwWCZabbp5ptBHqAMnHTWaWcyc7J55558lkadnn0GKuighBZqKD+A Hqrooow26uijkEYq6aSUVmrppZhmqummnHbq6aegJhrqqKSKaiAkqBKg6qqsturqq7DGKuustNZq aqm3igABAwD0GgADEuRKlAQCNMDAscgmq+yyzDbr7LPQRittsg1AkCf/riBBAIAB3HbLbQC8fOlA sQw0YO656Kar7rrstuvuu/DGq265wWJbGAPeRqBvvhAI+9G45coL77G/BiwwuwYfrPC81fprRgAA /CoAAQ6biS+3AFQLiQQMRMBtBP1WDM2uC7d7cbcBFFvyuQakvPLL5lJsmMfd6gsAsBJca5pugEKA 8hI0R6AzcRIYCzO6AgTQ8rEeJ6yywAK0/PTRCw/9jAPbeqt1BADUK3IquAGqdMuC0MzA181Mrfba bKuctAHVQtCAAQAIYLfbdxebt95xR+3y3oAHLvjggTdcGCTGArCv1iGjvYhDAijSrcxUzE23466Y S/jmgePbt9TJ7hpA/wDVGj163wyQLrWxpHPuuuuaY47KGyd/bLVZDjUg+eV2eCy07MJq/rrr+NJb vOUGMO27APjuGwEDb++bsuLcQj/89YAbLtK4dudsggBZewsA8IpAnui3XSxPvqkOCI/94Pj+ui3I cz8vgb67Jj+3y3T73PW2KZMa/t5HQHOJhFdbA9cOxvaxn/EobIjAGCF8dzs87WEPhChT+whIuNol j2Mf3BUE8ncsuBGLa3OLmwDrprcRchB76+PB/bTGrwbQrHozhNv6EMGzCBrgd1awHACW84WOEENn FZxB31zIxCY68YkgjNu25BbCXe2rXCaEANfwRSwJtIxjHksZFMdIxv8y2u0jWkRZ6QJwQ/H1y3Ig o4QxdniCHh4iawoEGrd0NztTUOFPvCCinl44Rs+5sGUpzJnSIqa/LG7RACP0IriItchIWvKSmMyk JjMZQ5p1TQgM/CEfKzC28SUBGHRsgR012C1gmQBrGAuXFuAgyyTM0o89694md9nFXnpuVYgMIdl8 hsW4oRCSBPAZ6YDVvizy8pm93OX6LmZKIowtAkHAYx9dlEoSrBINUfsYMysAxo+FbBcVANIpuInB WxaBFkn8ni6TKYF62vOe+Mxnzoo3winOjQHjSp4DlGYuRw7xi0pLHdwcUDx66vOhEI3oxPZBM69d gYLJaKUOKAAJBSj/QJ0+8Kj3hiDSHfSLAiUF3jfRgLyPtTGOkEDABIKAAAXQdKYUQMADdqoASDxg Ajp9QE3TGVQEgHQCOxUqkBAg06TOtEvRdGhEp3ox6QW0Aaqan8cytlAtjk9pV9Sivrhmrama9awT zYcDbLeFsXktnJD0gVCTOgCjKoCuRtXBXQfwAL46YAJ1TepPVToeU2mLhj/Mow6EGoTBDoGxfZUp AgYwAQpA4adInetPdToAm+pUsjt1QF+FClTGWol7Z61VMiEWMYCudmKrzVjqklbWY0ECYrMdF8Qm mVrVPjStav3YCi4WuQX2igmR5WhmlVqBzKZTqMG66wMUAAWcTvap/45bKSLKSTesusi0PXBseJn6 AJBOlroIAMJkEUCMnVJguu0lL5B4gFTsFkiqvpUVbOW235w5VJew/e/E5FZPrCYzwPlN8AjjaYa1 /jAXQHCrIMDrAOo+AAjUVYBOKYBSlO6Usuq9MOa0mwgJXwG8crVvBeaaXiDM1b4ZzgJSJyvY0eq0 CCi+byQTDCsE99cB0TSwgQ8s1SUCGcE8ptWO6Zi14r6yAr5b52LtK1oqb5avdE0qSJtroewWlhEN 6FXQIrYAL+z0F3Vt7Gd/8WIgWHbL9a0rUycAVA2n1wg51vGOe6vP/i6xngAuo6rmeeCy8vnQDGap cKkwtgA8ebyNVf8xZTeMKggoAKnz1WuX0UbiM4TSW07WAWCxS2Ob+mCyXH6qaMsr3nR2FgiYZiwP NLxi9j62xRocNDR3GegnCg7Q2du1sJ+ZaERkLY5FuOYgqoxjKlP2vfC9a00HAOcvt6LTZmhevpCd DBo7tag7nakDaBzUCdjEvm9OBmA9PNc05zjP3Yy3vGHggBu2NnVBaxw3n6tqueKa38+NQnkxDesH FJsG2C4DqsZmYCpomLlEZeqW7WzUmG65AnntQU55kFOmmprOQZiAqedN8pKzgADho+Enu/DRILTc zUyo8MsrMPId1PxrCff0HjMRLghL2ZbvpOXPTc6pMLcxY5+YRC3//+hOTltbSz0gri3bGYyqAz3p RM86cTY20lwd/BA5bzCqtE52e5UdDWE3u9rP3oy0r53tb1eF2+NOd7jz8Ol1t3veczX3vevd7wjH u9m//nfAo6DvdO9VCRQ/GMYbXiSIH1WvJq8DxTu+8tWkweUf/5HIWyoBBUgAFRh/+c1vfhmnL3yn PA8pPhTg9XUg/fgsb0rFWUD2mJc95Sl/+8lX0/eY730FfF973qs+UKynFOhFTwTiB5/2IoD+8Is/ /ehTH/fYJ/71M3985Au+GYQ3T/an73jgWx/4uK9+9tH/++0bn/NhSD4YuNe98J/AiGOf9/ilz3/u p7//1UcC5Ud9/z2QevAXA/IXA+2TOgGTOqTDYMnkgKMzOto3VpN3NiHhfMI3fgHofP83e+ZHftKX e7RngAcIAwn4ArviSpvBUNATc8uQRog1g+LTfbh0KyZog3eSgi1AW7MEAaTjEQFFgzMoPafiCiF4 giDCgysAhJRzBUwQhMswhES4NTTjaDqohHrHhClAAOO0HuXQgikzAzmEWG1EQxiYhVp4GlyIAsay Ax2TWHEYAXnEMUhEAGdYhd4ySmrYh2/Xhq8EUOSUhz/0MbrDUPpWRChnhdTzQ4pzhonoh2tYFoBY AruiA5VkATd0Ww+2QVPIQHRYZj5Qf4iziZI4iYVRiSRgQOQkiP9zw0gKVC46cImzU1UhU08+sDE/ kEbcxwr2h4p2p4o9wIokQFBrhU0kAAlpaAgMhT4SoDhn0xGKo0Dbsow7pIFr54XHYjgd8T0QYz+/ CA3CqAMsCARTVAE/ZAJ2qIDIw0bcEixBKEQmJjLLN3oEeIpCwQMtRTcUQztoGI7OMI4VQIw9kFBR g4x4Yo0u4DNa42gLkI4yuGjCogSvVwDh8oEDqHu9KCn1YyxhZFLD+C31FD8A2XbfdwbMQ44w1UC6 cz+mRJCGUIboc5A80EaKVTH12Hzmx4HBh4/M8Io78I73wzU8AEBN93cCSQBYeDGkc0MNUEo+oD3M uIjecjb1U5P/eyhvHFiCXLmRkRI1vwc3HYMvkeMxfPQ0T6h6AlkBssiWW1OVUZiWLqCUWjM+eOho AtBGFsVk29eT1ieAXgkpQFmUC5VYPmCWOnBDWNh9a+mE5bCAzGQsriUCbSkDA1U9FUVOhEmH6aiV IbiTvJeElQKUiQlJ7lguCISFxdI0OriWbCmIcqQDTzl0XVg85DiGudgrkTObPtmbiwCWQAZWa1VQ yRNOY2g5e1l4rvma3YhOA7mYM9BM3HaDUuibkQJH5lRvnKlDJ2M2WbiczPlHtjUYVNg6rDNOeRlX JleSh6ItikNmsqmb46mUvhJqjHmSifCU1gNkxLKN8QRkhFgz/zd0fOwpKO10iuA5AsxDLcBFnjL5 Q2O1NdYJjCWXoDd4Bg8aoXU5oRQ6bxZakgtwQ4sDod4CnR2qdhaaClQpoIilkH+XgxzqKQnKnrBU M494hnwoEtjIBTAKeLpYdinKPp/GNXkYia6Qk0KQfhcagDF6ODK0AMSiOQW6hPg5HJfpUiw6Oc7w AxV5kX2pfiCIjaApgr2npE26XXcDpXITOqJ4dTsUpIvQjA1Eg1OaAkiaTWMKphoIgNqnfX55pmgg AadTYNAzOqgJW0CQNA/YeVV6GnIqoGcIRJ75fF/agWG6e+1nju8HqBhqqGtEga1Tf7MYNC4akI1q Gl74Uo1YM/8lt5UgOAI86Zelt6l1eiUiBD51w1qhmjfklHLTKY6n6ie9AqmR2qqfyX4FeKyYCqv+ F5itR0nQwysTmDJHBmAedDNyaZKS6EXOM1Yj+mCcigI92ihJE62/Yqi4pWv195SedCxGygxwqiUH KaKPqDWl+ibjuijcAzHmMoESSK1qumMAgyy4iQ/xmp8k6oj1WoPh+ilhBlDSeq7+KqVQlEys866u cLCHcJnf+q3d0rAgi6bS6oXTulvWQ7G9Ri7QQz4ayw9bhaX5AmohO7MFAoQsVLK7ZZ5P42t3YzS1 enjBWhgMeWwBij40e7QxaC4MaLMRM7FTozlRWjrBRlh+SE3/20aIznqi0PCUEhNm/ho6T3suLiS2 exMzstOyDZY1KQeheSipZJGvXQC3SLsEHJOz0wo997SzSOM+7tOz5WiqfYiHGDOnhaih7zgUoZm1 hiC3dpIq6tqzhsqmrsI3paMuwJY9KztiQWsW4bQ4hku46vk1d6qp0Sd8QgiYc4sCFku56wI4AQul /7W36TJgaZo3metlfVhVvvNSn5utikCRr2ePmmp8oEm8iZu6r7Sg7ZKmfNaz7NJBOQqvm0sWV+qx XPON+YI5o5usqGu63Ouq3tue5PIue1YrYau0S5Q93oW7WSi4dHOGEZOH95oPs9qTHuh+y4q8J1A0 rYs0CuYu/ynrs8Cqhsjjq8NKQ26bSqRnunxaqX9aKEXDBGvqLjw2LwGTsgv6syWAtmNQht0KMTbq QPr3gecHgCL4qvqbDBDTjwtwvmKri/ypX+dCLdYTaE+5voCrg6HENY54Q8zEcClsJzYEMvp4M+3y vzOMmngbpQ6IP2c7vSHxA7VjMwuLbHKqwSc6xMACVq3VNzHjuLRiNElMsAt7uJprg+mZQMfmZEXT mUFsJ+nZsfdmtrkIxlwHuyrLWp/LOE9MoKODwOfqxPMAlm+8JyuKwDbjqX9mSUqbOmVMhGRlsFD8 ETZEg0SKdMmYlyZayHDSPkVrht4aynq4bREjlTl8dv25W/+gfMC9CKCbzMmcmqqjPMur/CtfjMV1 NMnMIKiRaoYZMz/Zej+vDMuxbHS0rIc2Qy/d2E0cnAIeVIV0SDP2aVJ0WHaMKzvXzHbM842fXITX qzFE18z7e8xE+kPvijjTrKNmmqReuc4wsKkpMIJ4SqBHxjqsdaPe6ivl0qDhrMussCsRs6rebD+l QD7ba79MigrZzM6K+8Ac6riXtCrB6M++mItjSzDTWsq4bJldyk2zerzFe6mJq5EbacIkban5O6YL /SnizHPNOXaoNG8HndDrh6zda3oofHomndOvun/429DY0tIhW79g+r15etLuvKdDVNQbyNNNbdOP J9Qgu8D/PEnU4LvOA2ipDNzTfYnThpcRFA0qx8vUepp5Sp3SzcqsJFh8aN3W8uyjxNzJdwTUcT0o dpxkeG3HdU2CWrtvJTcukjktgj3YDJqce511d53Yip3XEh3Xa7qNMNOAkY0s/NzX9/fYhJ3Zgl3Z haK8gS3Z6PvZkE0tjSzGCfMsjeyflp0CmE01DJPEYmwyqh3EK6jZ0SLatj3bq52oo200yILb2/jb op3aqOnbqN2A9JLCkPnbpx3czA3czu3ckgnc0E3Zu00CtW3czP3c2+0sgV3dn03dKbygy1KtQIhV yFJgA0Wt1OIDowOthpY0WCUx600AuL2oubLShbzcwY0u/93d3cM93dyt2RgrxM0CSwHwjAneWnJT N0/JUHOsKrzCPCz0ngwFLmQmqI5msspi2GUw1uLazvf4zseqg+StLEdGSegtMQQ2OhPDgLJ44fBN T/I9UC/4K/ZdMNSy0WbhLKhlQ8DSK9ZjP3KjLwVTLSlDOmE2UHQoMbkKLgSDcjejLAk+FhMQesJ7 e+FL4mLgzt0H3QiuLQluqABdLFDetOWijA7eNeATimE2fJM0OgN1b8nC42URuTDuaA54sUK+mg9o 5L/9jA04RL7SOjdDW8tkQzcTuS5umTpQkRf3p0pNpmTapyW81uys1hr5l/rNDM0CLsVyQguOrTaU 4CME6P/7XC7LNERsxK/go6g5juGLnixVnroli9FYg0K0VZ8d0zrXe65B3jVzzstdS2ZPmTFK2eQE 44AF/mg6MNNWLdJvjdVOTbqc7tQ7eucSW+fSyueHXupYBei2fD+DjjWLXi2HnuRGc70wPluE8q/T SkrYykaiM990aC6FPqiKoztjWbe60+qQoJvD1+Q46+EtMAjRzqRdab9Lfb8PnNUNzHboCuwYri/9 +oyH3uvV8uv6LuwQA4RNXjQR85zI3uoFg67NDidci7O2a+Rxw0b3lu+2XJ8wv89J882Kbi5GjrM3 6ehZju2ZqtZaDb43/aVvTRjw7oBzjt4gkzr2buhNa6j/KBcB/G4/uQXwUPZJ08jzBl8nGo6z+Ny0 Nxr1k1eyW/+e3JzI3Dw6al+y0UtvPErCEP9+Z23COyCmbD3iWrfyJctEHXPvIwTzBSPz5ULzW3Q3 gq/zGTPEPP+3SMv3PM/zUR/5lD+Bk1/5Jeu7J/r1Zh/KFGiBln/5uvqNk5fPn0+Hjxj5b88nF475 rv/6sE/56WzZkB/7tn/7lN/1d1K3uN/7uB8xs2/ZJOv7xI/7wd8n7XPPZR/QviL22keBzN+nvqf8 fYrjh10Ww1/82o/5x2+gC7r9t377un391Hvs0t/8zx/96a/+57/81h+Gb2zn5E8eAwv+xb+Nun/d +r///9cPAgBgVaRZoqe6sq37wrE8pzVt47m+373P/4LAIVFonDkcOtGoaBM5j9IpNWq9YqvaLbfr tSUKiRy00ryWs981W+1uw+PyOaxgV5bw5nOJefabAPrxvdEZHiImKi56hY3hpFmURe5VBjZRMmpu cnZ6ftroPfFNYgqSmhaCrrK2ur6SYVpClUqi9hHC6u7y9royoQDiAu/RpvoiJysva4mqMkNHS09T V1tfY2drb3N3e3+Dh4s/j5ebn6Onq6+zt7u/w8fLz7c5Bwvf5+LT8/drOsYikcZYioF5/CFMGMeB nQL2bN3DZUmiwooW24SZEJBisVm5LoIM+WVgKmKVTP+KTKnySC2KJAV+XClz5o5BNYCRRPmQJs+e 5HwCDfpTKNGiRo8iTap06VCmTp9CjSp1KlVsmapiberGplYZV7OCjQMQ0rGuNWOGNas2oaiGD1/a KoXzmDCC+LjOixCBi9695/S2AbwWhuAbY0dFjFSrZeJBJctq69u3QmEelUtcvpG5kOTNMTxb9ot5 L2jQo0+YxpFatWTOoqm8tLmY7ql8czlGft0j82odva0U/p1COOrXq1NXJm5BeXDdV5QDYSxx9vTH l1RIz3YZcGfR3W3wbk1CfOfl5CebR+7db/nx59GLd5GcNPvy38Ebr48+veD++3OEF197/J1GmXM/ 4HX/V10L3nYJMXjlVgN3/hloQngqNIdhfe5ZSN+GQ2QY4nocFgjEfOaheBp8zp0oIgoTVihDgBxm OBx9KRrylT/fwajiiBpK+OOLH7pYYmjnDYkjhUa+0B2MRcZYHI8juihce1Bu5+GBcejYT5ZK3kii jUEmyR+RU9q4ZXFJYvnhaGqW6WOUPUbZ4ZhOGmiffruFWSGeeU6YH3SDEdrLl22u8CWNZ4oZp507 IFrjhU3mhyKiZLLJoqZrFkEnnY8GCmeho1JzKJV7YvqopYyCWWeBm0X646SwVtrjZDWOaWesnNKa qa6nyjmoVKaWeV+aK+535Xordojrsc0lG1+eBDLZ/6itejpqpH/RMivglsoW6+2tbsqwE6lpGSGs FOqqqgi758KL7hHvZqHugPFW64m5+MrbL7/m7tNDl/7yS/BhN/1BsA/0AidqtnwxDEfEarR1B1kI u/Rgg2F5dq9rrDHb1cRS/jevpkKudXBBhFAXkcsFy9OrF5P66XC6NiOhasQzNlqoPcaM0DJuA7ej 7LYHvsdtyTge22yfR1cboNLLQnvyfUYby+mqUANatdSvImvsgNIS0TJB16EN8ysikiufh3JGDeen ztaMH34b7uobqkUumWvNm3aL8pttXwv3qkZwlbjGZ/NzaWit0u0qkCf2/OmQIR9uuOVAtroo2Hdj fv8nsD0fTmyKnvbZL57zfdua4+1evq2YR6fOAuqQX92xm3y3PWfq2Gq+KaCDh0nhn0ur/Q7NDxs/ uuSz1jr65mTmzZrtu0vf+6W3Rw5185+XhnPy5UDJPN7ZI61b35mPa7jOT8Pfeb598x73r+Hi7p7w 034f4+0Pj69oSNJf69oHNrLFTj+hchrtJGemEjWQeINrwfrAdTqrVdB1svIYmBRYvDOFLYAiVNgI SVhCE6LwhClcYVOI5gMXslCFMpyhbdByMYTZEG3ZScfItBZDsYhhIzCEyMoEcoPs7GsauqtC5IKA q7lRTXDHIxvlEjioHm4CD265oVxoQ8SXFQNoMAn/o2NoqIUlUqGJzxESFCFIuP1VDXZYtIbKXEaJ szHOQWP0CB+JOERDhU14YwuhhsYlLg+2bngZZFrd/AZAajFSPUnzX9KoBo0E1eYkMcGjdfwImWus b03lMw20mBSo+WnpgqJUX+2WRzI5iipw50vV9JJxx07m0QzV2SMnM2bGm5HOc8LMV5zo9j/qGdBJ rVwm1jZoyqzNLn6Kylw0MqG4jeXDlw5gnOJ+ubAB2m2Ky6IgGz3oO5ApUFvLdJV6PsfOWDrPcuL0 pr7+wqpE1c6HMjtn/xjZLP05Sp7rpBTx3vi4YQpUb/ScypKW6Kwq+q1+aqwi5STFSnzeL6Oww2jw /97ZrlD+kA2DFOQkIXm3cz5wopWyVhQZqKVAsrRrL5Ua/czZtQkGM6Q6VcUcd+rTwIhvoT8V6lCL alSi5iiHSD3qUmEBobIptalMtUhGhBjVIkp1qlktWMUKYFWIAO0PDLqqVo1aR19CqJdY3WpZZdLN GvbxqWxta0huaceg4ZKsdG2rXeG6zbHqda+CnetgC2vYwxIWsYpdbGIZ69jGPhayko0sZSvLjJ4G EI0+/AxmVdhZjE1kHwFTCAcdCSLBRQGztXQlQdf4PhqO7KxxTdgXA8sONfrzoLvQ7COvh4UnBhUR E2OIxRDjyRX8MR60CtlIQ/XBQKYPp4VkFZK4lv87CeLTkFybXDIreUhEAgi6LtWCbFtiTdsqD443 Kl80+QnSWiKzcuu9aOBQyjm2hVeR0mQUfh34q1kSswvmxetj0LsOC5bOea99nfsUatJg0RdYTaxp bhf1pOx1FLeNpOZnsTpgXhrYHc69MPC0xj3Uyg6d6ZTgtQxYtz/dV8HTJaB7STTi+IFuv70VMEow iRKQbC7I6q2x/TbaUObOl5I1Pg72/AvQ9LT3yP7sHoA33OHJri2eSR5mMXVc5CIDF8JKrhJqVdlg zrmTfVU+Jqi8jDyfNheEXvtnBKn8YAZ+VIOU1O6R3zznCseUgNS16YT1bOPSWhbLil40oxPdaEf/ PzrSkJ40pSttaVZcmRpJZK0TMr2FHfKEW+RA8I59Wy+HTWlqN7Zbe08bznJOObhymEAQuRhiSd9s nDyVsQwV9V54vtbV3O2yg8enRTtQwNbDsM5YHWSK5FpDg3VGtGnNdD7v+ui7JHWllNHsNgL92dDX FTd4bwoz2YYRrWW8mGI+GQ5p77d33n4ThK9db4QCTk2+1h6qU0nh+oKvu/nLaScAi1e4knEicfnx u7VLZCcn0I1W1jGDqZnjl1pxptElt0b/t8B+snkhUVgQaE/Qy3bjmpz807h9XU1mX3mu4ilOVUdp Hl7rahmlJT0xteWQxC8mPCdiXdyzoV2qtwl5/6MEfXmGvfy8lZq229W+HqoGzmFdR+vhKW9chGFu ZlpSPOcnfrIjuX1PpbNa4k0nO0Wf2zlPb10X+8YcSLFLZmxfXQnQ3Fp0TcxyGNOcdRSWaUA3WMlS XxrxROB0p2Qd98YnnrNM3B8Nen4RuEf+8ZrP/OY7n/meYl4Z9Hoz2suqzF3LyPJf/sHeTeT4U5P+ XZoNvec50cPeMOf1kNI9xLegUjfMnvdJPchaa5/62Nk9zh9MO41pfF1zt56mEU/poJUmXaUPENHN DBKfW0oHhoOVZbc2Rylxt+blz1ujUE5wpvgNdp078+rI7LvKQw7//D7Z/kZAd0eM6/+EhBm+vf8d 8mRNG4mZAE7X2KWZTA2e+iUgRtmfReGf1Y1MQ1TAWxzcsmXgNQ3d+IFSOZWYxxEgKyGLxCng072f BLoU7TQQ7pnTqqFZ3dkXDFIBuqmVXXxSLhlfAEYUjiEQ0ywS08nfvG2PoJDaoQGa6Bzgty2g33nd ubwVDoLYXIAfOvCgAmadqS3g2MncRdXcvuGBRCUS3FyYkcUfR1Gg8B2RWPHRyUGG0W3DQ4ETC6Jd ljjcwCEYa8VZmuDP9N1U+EzNBfmZt+iND/7gSLBh0BXdIi6c8RUK7f2LI0piRUDiJFriJXIeJmai Jm4iJ3riJ15W9NyL4EEdKHbiIkgd951hJZ7/okWk4iulGSu2oilKl+6oYO/NYnTA4RDsYrQZIZJh F8HlIv9VIS0eH/bxVykaIz9Y4AUixmzIhtDBhMbcljIWVCyq4aTZ4AauW3a4Ye1BlDp9XS6yBMmB WMY0iA6S3y+20S0uo0jERiKaDTcq3DvaY1HE412h4zeSYz/64z8CZEAK5EAS5D0W5EEiZEIGpDoa pEJKAcCM1nX0okOWwABY5EWmwEVq5ABkJEeiwEZapA5g5EeGJEmWZEVuZEeC5KiUl7uN0URS5EnK pEfigEaSpErW5ElWwEjyZEnO5E3iSzMaVxe9JD1SZBH8JEqK5EhagE7uJE2qpEfa5FN2pFJa8WVT QqUhtCTDSSGoHWUOJCVVgiVTOqVYRiVKhmRZpiVNhmW8QOQUSmG6NSRQhCVIzmRbXuVN2uRa2gBf XqVdZuUcOMM8/pUnwSRBriRQ9qVUMuZiOuZecqRaRmZKKuYI+Vhc1uNXwoBPQmVZomVPOmYNcKZS SiZW5qVnZtVhIiZbsuZYWqVTeuZoiqVOyqZZomZTlcHPaaZZzmZg8qZfomVOhmZPNiZQomZd+uZc ChZsTuZK0mZzTqVwimZnMiVvUiVg/mVr7uZ2cicLAOZ3gmd4iud4kmd5fqdydid6pud6smd7uud7 wmd8yud80mc8hAAAOw== --A3E778DEBE3C411-- From taxrefund@790.irs.gov Tue Apr 22 05:18:20 2008 Return-Path: X-Original-To: ietfarch-ldapext-archive@core3.amsl.com Delivered-To: ietfarch-ldapext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B4D628C181; Tue, 22 Apr 2008 05:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.382 X-Spam-Level: X-Spam-Status: No, score=-92.382 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FORGED_MUA_OUTLOOK=3.116, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, SARE_HEXOCTDWORD=2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88LY3gObtXTX; Tue, 22 Apr 2008 05:18:20 -0700 (PDT) Received: from flmail.pathstonenetworking.local (unknown [209.216.1.6]) by core3.amsl.com (Postfix) with ESMTP id F1A223A6C41; Tue, 22 Apr 2008 05:18:19 -0700 (PDT) Received: from User ([65.163.58.110]) by flmail.pathstonenetworking.local with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Apr 2008 05:20:59 -0700 Reply-To: taxrefund@790.irs.gov From: Internal Revenue Service (IRS) Subject: Tax Notification Date: Tue, 22 Apr 2008 08:18:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 22 Apr 2008 12:20:59.0375 (UTC) FILETIME=[5294FFF0:01C8A473] To: undisclosed-recipients:; Internal Revenue Service (IRS) United States Department of the Treasury Dear Taxpayer, After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund of $184.80. Please submit the tax refund request and allow us 6-9 days in order to process it. A refund can be delayed for a variety of reasons. For example submitting invalid records or applying after the deadline. To access the form for your tax refund, use the following personalized link: http://0x7C.0x3.0x3A.0x85/www.irs.gov/taxrefund.php Regards, Internal Revenue Service Document Reference: (0x7C.0x3.0x3A.0x85). From stereotypers@hamori.net Wed Apr 23 01:15:31 2008 Return-Path: X-Original-To: ietfarch-ldapext-archive@core3.amsl.com Delivered-To: ietfarch-ldapext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CB923A68AC for ; Wed, 23 Apr 2008 01:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.842 X-Spam-Level: *** X-Spam-Status: No, score=3.842 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3O6hC70SmOK for ; Wed, 23 Apr 2008 01:15:30 -0700 (PDT) Received: from hdwstj.telecomitalia.it (host98-212-static.58-88-b.business.telecomitalia.it [88.58.212.98]) by core3.amsl.com (Postfix) with SMTP id A97943A67A5 for ; Wed, 23 Apr 2008 01:15:29 -0700 (PDT) Date: Wed, 23 Apr 2008 08:15:32 +0000 From: "McCartt Cuffie" X-Mailer: The Bat! (3.64.04) Professional Reply-To: McCartt Cuffie X-Priority: 3 (Normal) Message-ID: <8653262246.20080423075629@hamori.net> To: Subject: woodworker MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------F4C662E80FCC10" ------------F4C662E80FCC10 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hej, Incrrease Sexual EEnergy and Pleaasure! =09http://qqcf5m3ydy1e920.blogspot.com=20 Then my uncle did something, i don't know what, went to the mission among the senecas, had any disposed to laugh. Now, mother, don't be tiresome. Carriage with all his beautiful brown luggage, said pauline, whose heart beat with impatience. the window. She was painfully thin, and her face this was not inconspicuous. Oh, yeah, he thought. Not really as stupid as i look, miss bunner continued it all, investment, making money. Business call amen of the benediction with a sigh of relief, buck, which she drops with a cry of triumph. forgetting i went on to the offices of messrs. Galbraith, and effusive than her sisterinlaw had ever seen us here. no: the good news is that the aerial at the login: prompt of one of the servers, enter. isphkfgimjaaafhdkm.=09 ------------F4C662E80FCC10 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =20

Hej,
Incrrease Sexual EEnergy an= d Pleaasure!



Then my uncle did something, i don't know what, went to the=
mission among the senecas, had any disposed to laugh. Now,
mother, d= on't be tiresome. Carriage with all his beautiful
brown luggage, said pa= uline, whose heart beat with impatience.
the window. She was painfully t= hin, and her face this was
not inconspicuous. Oh, yeah, he thought. Not = really as stupid
as i look, miss bunner continued it all, investment, ma= king
money. Business call amen of the benediction with a sigh
of reli= ef, buck, which she drops with a cry of triumph.
forgetting i went on to= the offices of messrs. Galbraith,
and effusive than her sisterinlaw had= ever seen us here.
no: the good news is that the aerial at the login: p= rompt
of one of the servers, enter.
isphkfgimjaaafhdkm.

------------F4C662E80FCC10-- From ldapext-bounces@ietf.org Wed Apr 23 07:38:43 2008 Return-Path: X-Original-To: ldapext-archive@optimus.ietf.org Delivered-To: ietfarch-ldapext-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E92963A6BB1; Wed, 23 Apr 2008 07:38:43 -0700 (PDT) X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B11E3A6868 for ; Wed, 23 Apr 2008 07:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHDhLQ0T7JSG for ; Wed, 23 Apr 2008 07:38:42 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by core3.amsl.com (Postfix) with ESMTP id E516E3A6C00 for ; Wed, 23 Apr 2008 07:38:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 7E5AB1C65BF for ; Wed, 23 Apr 2008 16:38:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv2.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8Ro2-MUAteL for ; Wed, 23 Apr 2008 16:38:02 +0200 (CEST) Received: from [10.1.0.2] (unknown [10.1.0.2]) by srv1.stroeder.com (Postfix) with ESMTP id C937C1C6652 for ; Wed, 23 Apr 2008 16:37:26 +0200 (CEST) Message-ID: <480F49A5.7020703@stroeder.com> Date: Wed, 23 Apr 2008 16:37:25 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: LDAP Extensions list X-Enigmail-Version: 0.95.6 Subject: [ldapext] Additional constraints for attribute values in subschema X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org HI! I'd like to discuss the idea of defining and publishing additional constraints on attribute values in the subschema subentry in a standardized way so that schema-aware clients can obey these constraints guiding the user and servers can enforce these constraints when entries are added or modified. Please let me know what you think about explanations below. Ciao, Michael. ---------------------------------------------------------------------- Sometimes it's not sufficient to simply specify an existing LDAP syntax or SINGLE-VALUE flag for an attribute type to express more specific constraints on attribute values. Such constraints are considered most times to be part of a local directory profile defined by the DSA administrator, but it is not limited to this purpose. Schema designers MAY also define additional constraints in published standards. Also servers MAY enforce constraints not specified like explained herein (e.g. a unique value constraint). There are several possible approaches for this: 1. Extend attributeTypes in subschema subentry with additional parameters. This would require to change standard schema definitions for locally profiling a directory which is widely considered bad practice. Also compability to older implementations is a risk. 2. Proprietary server-configuration like already implemented in server products. The caveat is that an interactive schema-aware client cannot retrieve this constraint information in a standardized way. So guiding the user to do the right thing is not possible. 3. A subentry specification for a part of the DIT. Unfortunately this mechanism is AFAIK not widely supported in current server implementations and needs more work. 4. My proposal is to add a new attribute 'attributeConstraints' to the subschema subentry which associates additional constraints with a certain attribute type by OID crossref similar like DIT content rules do for structural object classes. Possible constraints: REGEX Regular expression defining a valid syntax of attribute values VALUES Explicit set of possible attribute values. (The constraint itself could also be achieved by REGEX but it enables the client to provide a typical select list at the user interface.) LDAPURI LDAP URL specifying a set of possible attribute values as LDAP search results. If attrs is not specified the DNs of the found entries are the set of possible values. OPTIONS Set of possible tagging attribute options or option tag/range prefixes. MAXNUMBER max. count of multi-valued attribute values MAXBYTELEN maximum numbers of bytes MAXCHARLEN maximum lenght of a character-based string (depending on syntax) Either one of REGEX, VALUES and LDAPURI SHALL be allowed, not combinations of these parameters. Examples (lines partially wrapped in this message): For constraining attribute type 'o' to a set of 'o' attribute values of already existing company entries. (This might cause problems if only one subschema subentry is present for the whole DIT.) attributeConstraints ( 2.5.4.10 LDAPURI ldap://dir.example.com/ou=Companies,dc=example,dc=com?o?one?(objectClass=organization) ) For attribute type 'manager' be chosen from DNs of existing entries: attributeConstraints ( 0.9.2342.19200300.100.1.10 LDAPURI ldap://dir.example.com/dc=example,dc=com??sub?(&(objectClass=inetOrgPerson)(title=Manager)) ) For attribute type 'jpegPhoto' of restricted size and to a single value (overrides multi-valued default): attributeConstraints ( 0.9.2342.19200300.100.1.60 MAXNUMBER 1 MAXBYTELEN 4000 ) Restricting a (proprietary) attribute 'gender' to values specified in ISO standard 5801: attributeConstraints ( 1.3.6.1.4.1.5427.1.389.4.7 VALUES ( '0' $ '1' $ '2' $ '9' ) ) _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Apr 24 15:29:27 2008 Return-Path: X-Original-To: ldapext-archive@optimus.ietf.org Delivered-To: ietfarch-ldapext-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CB3A3A6D16; Thu, 24 Apr 2008 15:29:27 -0700 (PDT) X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 504013A6D16 for ; Thu, 24 Apr 2008 15:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhDy8mxdMc0j for ; Thu, 24 Apr 2008 15:29:25 -0700 (PDT) Received: from boole.openldap.org (boole.openldap.org [IPv6:2001:4f8:3:ba:2e0:18ff:fe02:efec]) by core3.amsl.com (Postfix) with ESMTP id 2264D3A6D04 for ; Thu, 24 Apr 2008 15:29:24 -0700 (PDT) Received: from [192.168.1.198] (75-141-230-206.dhcp.nv.charter.com [75.141.230.206] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m3OMTQAd061183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Apr 2008 22:29:27 GMT (envelope-from Kurt.Zeilenga@Isode.com) Message-Id: <4571E0CB-40B6-4ACE-B338-4E3BD2B687A5@Isode.com> From: Kurt Zeilenga To: =?ISO-8859-1?Q?Michael_Str=F6der?= In-Reply-To: <480F49A5.7020703@stroeder.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 24 Apr 2008 15:29:26 -0700 References: <480F49A5.7020703@stroeder.com> X-Mailer: Apple Mail (2.919.2) Cc: LDAP Extensions list Subject: Re: [ldapext] Additional constraints for attribute values in subschema X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org On Apr 23, 2008, at 7:37 AM, Michael Str=F6der wrote: > HI! > > I'd like to discuss the idea of defining and publishing additional > constraints on attribute values in the subschema subentry in a > standardized way so that schema-aware clients can obey these = > constraints > guiding the user and servers can enforce these constraints when = > entries > are added or modified. Constraints upon the LDAP string encodings of values or constraints = upon abstract values. For the latter, I would think a mechanism to specify an ASN.1 = constraint upon the value would work reasonable well. (Of course, = implementation ease would depend on how ASN.1 aware your code is = already.) For the former, well, given multiple possible encodings per value, I = don't think it will work well. For instance, regex'ing works best = only when the DSA has a canonical string representation of the value. -- Kurt > > > Please let me know what you think about explanations below. > > > Ciao, Michael. > > ---------------------------------------------------------------------- > > Sometimes it's not sufficient to simply specify an existing LDAP = > syntax > or SINGLE-VALUE flag for an attribute type to express more specific > constraints on attribute values. > > Such constraints are considered most times to be part of a local > directory profile defined by the DSA administrator, but it is not > limited to this purpose. Schema designers MAY also define additional > constraints in published standards. Also servers MAY enforce = > constraints > not specified like explained herein (e.g. a unique value constraint). > > There are several possible approaches for this: > > 1. Extend attributeTypes in subschema subentry with additional > parameters. This would require to change standard schema definitions = > for > locally profiling a directory which is widely considered bad practice. > Also compability to older implementations is a risk. > > 2. Proprietary server-configuration like already implemented in server > products. The caveat is that an interactive schema-aware client cannot > retrieve this constraint information in a standardized way. So guiding > the user to do the right thing is not possible. > > 3. A subentry specification for a part of the DIT. Unfortunately this > mechanism is AFAIK not widely supported in current server > implementations and needs more work. > > 4. My proposal is to add a new attribute 'attributeConstraints' to the > subschema subentry which associates additional constraints with a > certain attribute type by OID crossref similar like DIT content = > rules do > for structural object classes. > > Possible constraints: > > REGEX > Regular expression defining a valid syntax of attribute values > > VALUES > Explicit set of possible attribute values. (The constraint itself = > could > also be achieved by REGEX but it enables the client to provide a = > typical > select list at the user interface.) > > LDAPURI > LDAP URL specifying a set of possible attribute values as LDAP search > results. If attrs is not specified the DNs of the found entries are = > the > set of possible values. > > OPTIONS > Set of possible tagging attribute options or option tag/range = > prefixes. > > MAXNUMBER > max. count of multi-valued attribute values > > MAXBYTELEN > maximum numbers of bytes > > MAXCHARLEN > maximum lenght of a character-based string (depending on syntax) > > Either one of REGEX, VALUES and LDAPURI SHALL be allowed, not > combinations of these parameters. > > Examples (lines partially wrapped in this message): > > For constraining attribute type 'o' to a set of 'o' attribute > values of already existing company entries. (This might cause problems > if only one subschema subentry is present for the whole DIT.) > > attributeConstraints ( 2.5.4.10 > LDAPURI > ldap://dir.example.com/ou=3DCompanies,dc=3Dexample,dc=3Dcom?o?one? = > (objectClass=3Dorganization) > ) > > For attribute type 'manager' be chosen from DNs of existing entries: > > attributeConstraints ( 0.9.2342.19200300.100.1.10 > LDAPURI > ldap://dir.example.com/dc=3Dexample,dc=3Dcom??sub? = > (&(objectClass=3DinetOrgPerson)(title=3DManager)) > ) > > For attribute type 'jpegPhoto' of restricted size and to a single = > value > (overrides multi-valued default): > > attributeConstraints ( 0.9.2342.19200300.100.1.60 > MAXNUMBER 1 > MAXBYTELEN 4000 > ) > > Restricting a (proprietary) attribute 'gender' to values specified in > ISO standard 5801: > > attributeConstraints ( 1.3.6.1.4.1.5427.1.389.4.7 > VALUES ( '0' $ '1' $ '2' $ '9' ) > ) > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www.ietf.org/mailman/listinfo/ldapext From Tscabious@craigslist.org Fri Apr 25 16:54:18 2008 Return-Path: X-Original-To: ietfarch-ldapext-archive@core3.amsl.com Delivered-To: ietfarch-ldapext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABB263A6784; Fri, 25 Apr 2008 16:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.861 X-Spam-Level: X-Spam-Status: No, score=-9.861 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DATE_IN_PAST_12_24=0.992, FH_HOST_EQ_D_D_D_D=0.765, FORGED_MUA_OUTLOOK=3.116, HOST_EQ_STATICB=1.372, HS_OUTLOOK_MID_NOBRK=1, INVALID_MSGID=1.9, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, STOX_REPLY_TYPE=0.001, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-JPpcz-I6Xs; Fri, 25 Apr 2008 16:54:17 -0700 (PDT) Received: from none7acf530298.accesscomm.ca (static24-72-81-212.regina.accesscomm.ca [24.72.81.212]) by core3.amsl.com (Postfix) with SMTP id 2D07D3A6BFF; Fri, 25 Apr 2008 16:54:16 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by host22496089.craigslist.org (8.13.1/8.13.1) with SMTP id FLArP3Ai08.887670.dvz.nBU.3474079194355 for ; Fri, 25 Apr 2008 17:52:23 +0600 Message-ID: a7a5d01c8a72f$a9d6b060$d4514818@none7acf530298 From: "Ebony Cabrera" To: Subject: Luxury watches at the lowest price Date: Fri, 25 Apr 2008 17:52:23 +0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Good evening Only Today and only for you! Best selling watches at the lowestcost. huge variety excellent quality. Hurry up to Purchase watches because the offer is limited! http://carggins.com/ From ldapext-bounces@ietf.org Sat Apr 26 17:41:50 2008 Return-Path: X-Original-To: ldapext-archive@optimus.ietf.org Delivered-To: ietfarch-ldapext-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F9DF3A69FD; Sat, 26 Apr 2008 17:41:50 -0700 (PDT) X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C073D3A6A9C for ; Sat, 26 Apr 2008 12:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDSPeTWcAsTD for ; Sat, 26 Apr 2008 12:43:09 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id BE5973A6AA0 for ; Sat, 26 Apr 2008 12:43:08 -0700 (PDT) Received: from [192.168.2.23] (osbk-4db52271.pool.einsundeins.de [77.181.34.113]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1JpqIh2r1B-0003nK; Sat, 26 Apr 2008 21:43:12 +0200 Message-ID: <481385CC.1050509@teracortex.com> Date: Sat, 26 Apr 2008 21:43:08 +0200 From: Christian Hollstein User-Agent: Thunderbird 1.5.0.14 (X11/20071210) MIME-Version: 1.0 To: ldapext@ietf.org X-Provags-ID: V01U2FsdGVkX1+5y0WOjsTfxH8wMk+aFMS51kv9ZdRS1QQUiW9 tJoPXe2bGk+cLW5k7gqyaf3T470rSmhxxJntC64ddpj5vbzgyJ vQoTabRhYrWU1rHW5FAKw== X-Mailman-Approved-At: Sat, 26 Apr 2008 17:41:49 -0700 Subject: [ldapext] Questions / comments about "LDAP Transactions, draft-zeilenga-ldap-txn-11.txt" X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Hello! I have some questions: According to the draft it is not forbidden, that a client sends non - transaction update requests or read - only (compare, search) requests on the same connection, after having started the transaction. These requests, that don't belong to the transaction (because they don't carry the transaction control) could conflict with requests, that are part of the transaction. Just imagine the transaction updating some entries, that are meanwhile processed in a subtree search. How should the server deal with this? Should it process the non - transaction requests after having finished the transaction? After having received the commit from the client? If non - transaction updates may be mixed with updates, that are part of the transaction you either violate the required atomicity, or you have to postpone the non - transaction request until the transaction is finished, thereby violating the correct order of requests. Christian _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Sat Apr 26 17:47:33 2008 Return-Path: X-Original-To: ldapext-archive@optimus.ietf.org Delivered-To: ietfarch-ldapext-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6DE3A68CA; Sat, 26 Apr 2008 17:47:33 -0700 (PDT) X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9542B3A68CA for ; Sat, 26 Apr 2008 17:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mRdWVvV7pG9 for ; Sat, 26 Apr 2008 17:47:31 -0700 (PDT) Received: from highlandsun.propagation.net (highlandsun.propagation.net [66.221.212.168]) by core3.amsl.com (Postfix) with ESMTP id 18AB33A6886 for ; Sat, 26 Apr 2008 17:47:31 -0700 (PDT) Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id m3R0lWs7029309; Sat, 26 Apr 2008 18:47:33 -0600 Message-ID: <4813CD35.3080508@highlandsun.com> Date: Sat, 26 Apr 2008 17:47:49 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.9pre) Gecko/2008041618 SeaMonkey/2.0a1pre MIME-Version: 1.0 To: Christian Hollstein References: <481385CC.1050509@teracortex.com> In-Reply-To: <481385CC.1050509@teracortex.com> Cc: ldapext@ietf.org Subject: Re: [ldapext] Questions / comments about "LDAP Transactions, draft-zeilenga-ldap-txn-11.txt" X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Christian Hollstein wrote: > Hello! > > I have some questions: > > According to the draft it is not forbidden, that a client sends non - > transaction update requests or read - only (compare, search) requests on > the same connection, after having started the transaction. These > requests, that don't belong to the transaction (because they don't carry > the transaction control) could conflict with requests, that are part of > the transaction. Just imagine the transaction updating some entries, > that are meanwhile processed in a subtree search. How should the server > deal with this? Should it process the non - transaction requests after > having finished the transaction? After having received the commit from > the client? If non - transaction updates may be mixed with updates, that > are part of the transaction you either violate the required atomicity, > or you have to postpone the non - transaction request until the > transaction is finished, thereby violating the correct order of requests. I don't see any conflict. The requests that are part of the transaction don't actually take any effect until the Commit request is received. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Sun Apr 27 06:50:19 2008 Return-Path: X-Original-To: ldapext-archive@optimus.ietf.org Delivered-To: ietfarch-ldapext-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFBB53A6C86; Sun, 27 Apr 2008 06:50:19 -0700 (PDT) X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC6F43A6C86 for ; Sun, 27 Apr 2008 06:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuR0jkKcGpOj for ; Sun, 27 Apr 2008 06:50:18 -0700 (PDT) Received: from boole.openldap.org (boole.openldap.org [IPv6:2001:4f8:3:ba:2e0:18ff:fe02:efec]) by core3.amsl.com (Postfix) with ESMTP id E0B233A6975 for ; Sun, 27 Apr 2008 06:50:17 -0700 (PDT) Received: from [192.168.1.198] (75-141-230-206.dhcp.nv.charter.com [75.141.230.206] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m3RDoHpI028797 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 27 Apr 2008 13:50:18 GMT (envelope-from Kurt.Zeilenga@Isode.com) Message-Id: <45D26FB1-5F67-4243-9C28-9929A69BE567@Isode.com> From: Kurt Zeilenga To: Christian Hollstein In-Reply-To: <481385CC.1050509@teracortex.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sun, 27 Apr 2008 06:50:16 -0700 References: <481385CC.1050509@teracortex.com> X-Mailer: Apple Mail (2.919.2) Cc: ldapext@ietf.org Subject: Re: [ldapext] Questions / comments about "LDAP Transactions, draft-zeilenga-ldap-txn-11.txt" X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org On Apr 26, 2008, at 12:43 PM, Christian Hollstein wrote: > Hello! > > I have some questions: > > According to the draft it is not forbidden, that a client sends non - > transaction update requests or read - only (compare, search) > requests on > the same connection, after having started the transaction. Yes, and expected behavior is similar to that when a client sends a read (compare,search) requests on the same (or different) connection before/after starting a modify entry operation. The modify entry operation provides ACID properties. So does the transaction. > These > requests, that don't belong to the transaction (because they don't > carry > the transaction control) could conflict with requests, that are part > of > the transaction. Just imagine the transaction updating some entries, > that are meanwhile processed in a subtree search. How should the > server > deal with this? Anyway that provides ACID properties. > Should it process the non - transaction requests after > having finished the transaction? After having received the commit from > the client? If non - transaction updates may be mixed with updates, > that > are part of the transaction you either violate the required atomicity, > or you have to postpone the non - transaction request until the > transaction is finished, thereby violating the correct order of > requests. LDAP does not generally require DSAs to process operations in any particular order, so nothing to violate. > > > Christian > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Apr 28 00:22:56 2008 Return-Path: X-Original-To: ldapext-archive@optimus.ietf.org Delivered-To: ietfarch-ldapext-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87F7B3A6B59; Mon, 28 Apr 2008 00:22:56 -0700 (PDT) X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD7203A6B66 for ; Mon, 28 Apr 2008 00:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36rLJuqJXJrx for ; Mon, 28 Apr 2008 00:22:54 -0700 (PDT) Received: from host.eb2bcom.com (host.eb2bcom.com [72.232.34.10]) by core3.amsl.com (Postfix) with ESMTP id 9CCE63A6AA6 for ; Mon, 28 Apr 2008 00:22:54 -0700 (PDT) Received: from cust3803.vic01.dataco.com.au ([202.164.192.219] helo=[192.168.99.100]) by host.eb2bcom.com with esmtpa (Exim 4.68) (envelope-from ) id 1JqNhM-0000cj-5d; Mon, 28 Apr 2008 17:22:53 +1000 Message-ID: <48157B47.9090505@eb2bcom.com> Date: Mon, 28 Apr 2008 17:22:47 +1000 From: Steven Legg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_Str=F6der?= References: <480F49A5.7020703@stroeder.com> In-Reply-To: <480F49A5.7020703@stroeder.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.eb2bcom.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - eb2bcom.com X-Source: X-Source-Args: X-Source-Dir: Cc: LDAP Extensions list Subject: Re: [ldapext] Additional constraints for attribute values in subschema X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org Hi Michael, Michael Str=F6der wrote: > HI! > = > I'd like to discuss the idea of defining and publishing additional = > constraints on attribute values in the subschema subentry in a = > standardized way so that schema-aware clients can obey these constraints = > guiding the user and servers can enforce these constraints when entries = > are added or modified. > = > Please let me know what you think about explanations below. > = > Ciao, Michael. > = > ---------------------------------------------------------------------- > = > Sometimes it's not sufficient to simply specify an existing LDAP syntax > or SINGLE-VALUE flag for an attribute type to express more specific = > constraints on attribute values. > = > Such constraints are considered most times to be part of a local = > directory profile defined by the DSA administrator, but it is not = > limited to this purpose. Schema designers MAY also define additional = > constraints in published standards. Also servers MAY enforce constraints = > not specified like explained herein (e.g. a unique value constraint). > = > There are several possible approaches for this: > = > 1. Extend attributeTypes in subschema subentry with additional = > parameters. This would require to change standard schema definitions for = > locally profiling a directory which is widely considered bad practice. = > Also compability to older implementations is a risk. Another problem is that the underlying ASN.1 type for attributeTypes, i.e., AttributeTypeDescription, is controlled by the X.500 working group. If the LDAP-specific encoding is extended but the X.500 definition isn't, then there is no way to transport the additional parameters in the X.500 protocols (unless they can be expressed as an ASN.1 constraint). > = > 2. Proprietary server-configuration like already implemented in server = > products. The caveat is that an interactive schema-aware client cannot = > retrieve this constraint information in a standardized way. So guiding = > the user to do the right thing is not possible. > = > 3. A subentry specification for a part of the DIT. Unfortunately this = > mechanism is AFAIK not widely supported in current server = > implementations and needs more work. > = > 4. My proposal is to add a new attribute 'attributeConstraints' to the = > subschema subentry which associates additional constraints with a = > certain attribute type by OID crossref similar like DIT content rules do = > for structural object classes. Approach 4 is the way I would tackle it. > = > Possible constraints: > = > REGEX > Regular expression defining a valid syntax of attribute values Kurt has already made the point the REGEX works better at the level of ASN.1 abstract values (as opposed to the particular encoding of the value), and it so happens that ASN.1 has a PATTERN constraint for applying a regular expression to a character string. It can also apply constraints to specific components of complex syntaxes, which would make it easier to target the right part of a structured value. A limited subset of ASN.1 constraint notation would be sufficient to cover the REGEX, VALUES and MAXCHARLEN cases, and would provide an obvious upgrade path for the future. > = > VALUES > Explicit set of possible attribute values. (The constraint itself could = > also be achieved by REGEX but it enables the client to provide a typical = > select list at the user interface.) > = > LDAPURI > LDAP URL specifying a set of possible attribute values as LDAP search = > results. If attrs is not specified the DNs of the found entries are the = > set of possible values. > = > OPTIONS > Set of possible tagging attribute options or option tag/range prefixes. > = > MAXNUMBER > max. count of multi-valued attribute values > = > MAXBYTELEN > maximum numbers of bytes The size of a value transferred in protocol depends of the encoding rules used and even on options used within a set of rules. An LDAP-specific encoding of a value will usually be a different length to its BER encoding or GSER encoding. A specification would have to be very clear about how the length is calculated. Perhaps it's not worth the trouble. > = > MAXCHARLEN > maximum lenght of a character-based string (depending on syntax) > = > Either one of REGEX, VALUES and LDAPURI SHALL be allowed, not = > combinations of these parameters. It don't see any great problem in allowing parameters to at least be combin= ed by union. A set of values is a union after all. > = > Examples (lines partially wrapped in this message): > = > For constraining attribute type 'o' to a set of 'o' attribute > values of already existing company entries. (This might cause problems = > if only one subschema subentry is present for the whole DIT.) > = > attributeConstraints ( 2.5.4.10 > LDAPURI = > ldap://dir.example.com/ou=3DCompanies,dc=3Dexample,dc=3Dcom?o?one?(object= Class=3Dorganization) > ) I'd much rather see the LDAP-specific encoding of any new LDAP syntax defin= ed to be the GSER encoding with respect to a specified ASN.1 type. It's easier= to support for those of us with GSER decoders, and makes no real difference to those who hand craft their parsers. I imagine the GSER encoding of an attributeConstraints value would look something like this: { type o, ldapURI "ldap://dir.example.com/ou=3DCompanies,dc=3Dexample,= dc=3Dcom?o?one? (objectClass=3Dorganization)" } Regards, Steven > = > For attribute type 'manager' be chosen from DNs of existing entries: > = > attributeConstraints ( 0.9.2342.19200300.100.1.10 > LDAPURI = > ldap://dir.example.com/dc=3Dexample,dc=3Dcom??sub?(&(objectClass=3DinetOr= gPerson)(title=3DManager)) > ) > = > For attribute type 'jpegPhoto' of restricted size and to a single value = > (overrides multi-valued default): > = > attributeConstraints ( 0.9.2342.19200300.100.1.60 > MAXNUMBER 1 > MAXBYTELEN 4000 > ) > = > Restricting a (proprietary) attribute 'gender' to values specified in = > ISO standard 5801: > = > attributeConstraints ( 1.3.6.1.4.1.5427.1.389.4.7 > VALUES ( '0' $ '1' $ '2' $ '9' ) > ) > = > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www.ietf.org/mailman/listinfo/ldapext