diff options
| -rw-r--r-- | source4/ldap_server/devdocs/draft-armijo-ldap-syntax-00.txt | 137 | ||||
| -rw-r--r-- | source4/ldap_server/devdocs/ldapext-ldapv3-vlv-04.txt | 655 |
2 files changed, 0 insertions, 792 deletions
diff --git a/source4/ldap_server/devdocs/draft-armijo-ldap-syntax-00.txt b/source4/ldap_server/devdocs/draft-armijo-ldap-syntax-00.txt deleted file mode 100644 index 3cd0aebba9..0000000000 --- a/source4/ldap_server/devdocs/draft-armijo-ldap-syntax-00.txt +++ /dev/null @@ -1,137 +0,0 @@ -INTERNET-DRAFT Michael P. Armijo -Status: Informational Microsoft Corporation -January 1999 -Expires July 1999 - - - Active Directory Syntaxes - draft-armijo-ldap-syntax-00.txt - - -1. Status of this Memo - - -This memo provides information for the Internet community. It does not specify -an Internet standard of any kind. Distribution of this memo is unlimited. - -This document is an Internet-Draft. Internet-Drafts are working documents of the -Internet Engineering Task Force (IETF), its areas, and its working groups. Note -that other groups may also distribute working documents as Internet-Drafts. - -Internet-Drafts are draft documents valid for a maximum of six months and may be -updated, replaced, or obsoleted by other documents at any time. It is -inappropriate to use Internet- Drafts as reference material or to cite them -other than as "work in progress." - -To view the entire list of current Internet-Drafts, please check the "1id- -abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on -ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it -(Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or -ftp.isi.edu (US West Coast). - -2. Abstract - -The purpose of this document is to inform the Internet community of LDAP -syntaxes available in the Windows NT Active Directory. These syntaxes provide -additional functionality to the Active Directory. - - -3. RFC Key Words - -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", -"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be -interpreted as described in RFC 2119. - - -4. LDAP Syntaxes - -CaseIgnoreString: 1.2.840.113556.1.4.905 - Encoded as a Printable String (OID 1.3.6.1.4.1.1466.115.121.1.44) - - -OR-Name: 1.2.840.113556.1.4.1221 - Encoded as: - ORName = DN | "X400:" ORaddress "#X500:" DN | "X400:"ORaddress - DN = normally encoded rfc 1779 name - ORaddress = some string encoding for OR addresses. - -Note that an unescaped # character must not be legal in this encoding. -This is necessary to be able to identify where the #X500 starts if the -middle choice of the encoding is chosen. - - -DNWithOctetString: 1.2.840.113556.1.4.903 - Encoded as a : - DNWithOctetString = OctetTag ':' Count ':' OctetString ':' DN - OctetTag = 'B' | 'b' - Count = positive decimal number, counting number of encoded characters - in OctetString - OctetString = [EncodedByte]* // Note: the number of characters in the - string encoding of the OctetString is Count. - EncodedByte = [0-9 | a-f | A-F] [0-9 | a-f | A-F] - DN = <normal string encoding of a DN> - - As an example, the string encoding of the combination of 0x74 0x65 0x73 - 0x74 and DC=Microsoft,DC=Com is - - B:8:74657374:DC=Microsoft,DC=Com - - -DNWithString: 1.2.840.113556.1.4.904 - Encoded as a : - DNWithString = StringTag ':' Count ':' String ':' DN - OctetTag = 'S' | 's' - Count = positive decimal number, counting number of bytes in String - String = <normally encoded (i.e. UTF8 for V3) string> // Note: the number - of bytes in the string encoding of the String is Count. - - DN = <normal string encoding of a DN> - - As an example, the string encoding of the combination of "test" and - DC=Microsoft,DC=Com is - - B:4:test:DC=Microsoft,DC=Com - - As an example, the string encoding of the combination of XYZ (where X, Y, - and Z all have two byte UTF-8 encodings) and DC=Microsoft,DC=Com is - - B:6:XYZ:DC=Microsoft,DC=Com - -Note: Characters with multibyte UTF-8 encodings contribute more than one to the count - - -Large-Integer: 1.2.840.113556.1.4.906 - Encoded as an Integer (OID 1.3.6.1.4.1.1466.115.121.1.27), but guaranteed - to support 64 bit numbers. - - -Object-Security-Descriptor: 1.2.840.113556.1.4.907 - Encoded as an Octet-String (OID 1.3.6.1.4.1.1466.115.121.1.40) - - -5. References - -[RFC 2251] - M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol - (v3)", RFC 2251, December 1997. 1997. - -[RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," - RFC 2119, Harvard University, March 1997. - - -6. Authors Address - - Michael P. Armijo - One Microsoft Way - Redmond, WA - 98052 - USA - - (425)882-8080 - micharm@microsoft.com - - - - - diff --git a/source4/ldap_server/devdocs/ldapext-ldapv3-vlv-04.txt b/source4/ldap_server/devdocs/ldapext-ldapv3-vlv-04.txt deleted file mode 100644 index e7bb99ef8a..0000000000 --- a/source4/ldap_server/devdocs/ldapext-ldapv3-vlv-04.txt +++ /dev/null @@ -1,655 +0,0 @@ - -INTERNET-DRAFT David Boreham, Netscape - Jim Sermersheim, Novell - Anoop Anantha, Microsoft - Michael Armijo, Microsoft -ldapext Working Group 6 April, 2000 - - - LDAP Extensions for Scrolling View Browsing of Search Results - - draft-ietf-ldapext-ldapv3-vlv-04.txt - This document expires on 5 October 2000 - -1. Status of this Memo - -This document is an Internet-Draft and is in full conformance with all -provisions of Section 10 of RFC2026. Internet-Drafts are working docu- -ments of the Internet Engineering Task Force (IETF), its areas, and its -working groups. Note that other groups may also distribute working -documents as Internet-Drafts. - -Internet-Drafts are draft documents valid for a maximum of six months -and may be updated, replaced, or obsoleted by other documents at any -time. It is inappropriate to use Internet- Drafts as reference material -or to cite them other than as "work in progress." - -The list of current Internet-Drafts can be accessed at -http://www.ietf.org/ietf/1id-abstracts.txt - -The list of Internet-Draft Shadow Directories can be accessed at -http://www.ietf.org/shadow.html. - -2. Abstract - -This document describes a Virtual List View control extension for the -LDAP Search operation. This control is designed to allow the "virtual -list box" feature, common in existing commercial e-mail address book -applications, to be supported efficiently by LDAP servers. LDAP servers' -inability to support this client feature is a significant impediment to -LDAP replacing proprietary protocols in commercial e-mail systems. - -The control allows a client to specify that the server return, for a -given LDAP search with associated sort keys, a contiguous subset of the -search result set. This subset is specified in terms of offsets into the -ordered list, or in terms of a greater than or equal comparison value. - -3. Background - -A Virtual List is a graphical user interface technique employed where - - - -Boreham et al [Page 1] - - - - - -RFC DRAFT April 2000 - - -ordered lists containing a large number of entries need to be displayed. -A window containing a small number of visible list entries is drawn. The -visible portion of the list may be relocated to different points within -the list by means of user input. This input can be to a scroll bar -slider; from cursor keys; from page up/down keys; from alphanumeric keys -for "typedown". The user is given the impression that they may browse -the complete list at will, even though it may contain millions of -entries. It is the fact that the complete list contents are never -required at any one time that characterizes Virtual List View. Rather -than fetch the complete list from wherever it is stored (typically from -disk or a remote server), only that information which is required to -display the part of the list currently in view is fetched. The subject -of this document is the interaction between client and server required -to implement this functionality in the context of the results from a -sorted LDAP search request. - -For example, suppose an e-mail address book application displays a list -view onto the list containing the names of all the holders of e-mail -accounts at a large university. The list is sorted alphabetically. -While there may be tens of thousands of entries in this list, the -address book list view displays only 20 such accounts at any one time. -The list has an accompanying scroll bar and text input window for type- -down. When first displayed, the list view shows the first 20 entries in -the list, and the scroll bar slider is positioned at the top of its -range. Should the user drag the slider to the bottom of its range, the -displayed contents of the list view should be updated to show the last -20 entries in the list. Similarly, if the slider is positioned somewhere -in the middle of its travel, the displayed contents of the list view -should be updated to contain the 20 entries located at that relative -position within the complete list. Starting from any display point, if -the user uses the cursor keys or clicks on the scroll bar to request -that the list be scrolled up or down by one entry, the displayed con- -tents should be updated to reflect this. Similarly the list should be -displayed correctly when the user requests a page scroll up or down. -Finally, when the user types characters in the type-down window, the -displayed contents of the list should "jump" or "seek" to the appropri- -ate point within the list. For example, if the user types "B", the -displayed list could center around the first user with a name beginning -with the letter "B". When this happens, the scroll bar slider should -also be updated to reflect the new relative location within the list. - -This document defines a request control which extends the LDAP search -operation. Always used in conjunction with the server side sorting -control[SSS], this allows a client to retrieve selected portions of -large search result set in a fashion suitable for the implementation of -a virtual list view. - -The key words "MUST", "SHOULD", and "MAY" used in this document are to - - - -Boreham et al [Page 2] - - - - - -RFC DRAFT April 2000 - - -be interpreted as described in [Bradner97]. - -4. Client-Server Interaction - -The Virtual List View control extends a regular LDAP Search operation -which must also include a server-side sorting control[SSS]. Rather than -returning the complete set of appropriate SearchResultEntry messages, -the server is instructed to return a contiguous subset of those entries, -taken from the sorted result set, centered around a particular target -entry. Henceforth, in the interests of brevity, the sorted search result -set will be referred to as "the list". - -The sort control MAY contain any sort specification valid for the -server. The attributeType field in the first SortKeyList sequence ele- -ment has special significance for "typedown". - -The desired target entry, and the number of entries to be returned both -before, and after, that target entry in the list, are determined by the -client's VirtualListViewRequest control. - -When the server returns the set of entries to the client, it attaches a -VirtualListViewResponse control to the SearchResultDone message. The -server returns in this control: its current estimate for the list con- -tent count, the location within the list corresponding to the target -entry, and any error codes. - -The target entry is specified in the VirtualListViewRequest control by -one of two methods. The first method is for the client to indicate the -target entry's offset within the list. The second way is for the client -to supply an attribute assertion value. The value is compared against -the values of the attribute specified as the primary sort key in the -sort control attached to the search operation. The first sort key in -the SortKeyList is the primary sort key. The target entry is the first -entry in the list with value greater than or equal to (in the primary -sort order), the presented value. The order is determined by rules -defined in [SSS]. Selection of the target entry by this means is -designed to implement "typedown". Note that it is possible that no -entry satisfies these conditions, in which case there is no target -entry. This condition is indicated by the server returning the special -value contentCount + 1 in the target position field. - -Because the server may not have an accurate estimate of the number of -entries in the list, and to take account of cases where the list size is -changing during the time the user browses the list, and because the -client needs a way to indicate specific list targets "beginning" and -"end", offsets within the list are transmitted between client and server -as ratios---offset to content count. The server sends its latest esti- -mate as to the number of entries in the list (content count) to the - - - -Boreham et al [Page 3] - - - - - -RFC DRAFT April 2000 - - -client in every response control. The client sends its assumed value -for the content count in every request control. The server examines the -content count and offsets presented by the client and computes the -corresponding offsets within the list, based on its own idea of the con- -tent count. - - Si = Sc * (Ci / Cc) - - Where: - Si is the actual list offset used by the server - Sc is the server's estimate for content count - Ci is the client's submitted offset - Cc is the client's submitted content count - The result is rounded to the nearest integer. - -If the content count is stable, and the client returns to the server the -content count most recently received, Cc = Sc and the offsets transmit- -ted become the actual server list offsets. - -The following special cases are allowed: a client sending a content -count of zero (Cc = 0) means "client has no idea what the content count -is, server MUST use its own content count estimate in place of the -client's". An offset value of one (Ci = 1) always means that the target -is the first entry in the list. Client specifying an offset which equals -the content count specified in the same request control (Ci = Cc) means -that the target is the last entry in the list. Ci may only equal zero -when Cc is also zero. This signifies the last entry in the list. - -Because the server always returns contentCount and targetPosition, the -client can always determine which of the returned entries is the target -entry. Where the number of entries returned is the same as the number -requested, the client is able to identify the target by simple arith- -metic. Where the number of entries returned is not the same as the -number requested (because the requested range crosses the beginning or -end of the list, or both), the client must use the target position and -content count values returned by the server to identify the target -entry. For example, suppose that 10 entries before and 10 after the tar- -get were requested, but the server returns 13 entries, a content count -of 100 and a target position of 3. The client can determine that the -first entry must be entry number 1 in the list, therefore the 13 entries -returned are the first 13 entries in the list, and the target is the -third one. - -A server-generated context identifier MAY be returned to clients. A -client receiving a context identifier SHOULD return it unchanged in a -subsequent request which relates to the same list. The purpose of this -interaction is to enhance the performance and effectiveness of servers -which employ approximate positioning. - - - -Boreham et al [Page 4] - - - - - -RFC DRAFT April 2000 - - -5. The Controls - -Support for the virtual list view control extension is indicated by the -presence of the OID "2.16.840.1.113730.3.4.9" in the supportedControl -attribute of a server's root DSE. - -5.1. Request Control - -This control is included in the SearchRequest message as part of the -controls field of the LDAPMessage, as defined in Section 4.1.12 of -[LDAPv3]. The controlType is set to "2.16.840.1.113730.3.4.9". The cri- -ticality SHOULD be set to TRUE. If this control is included in a Sear- -chRequest message, a Server Side Sorting request control [SSS] MUST also -be present in the message. The controlValue is an OCTET STRING whose -value is the BER-encoding of the following SEQUENCE: - - VirtualListViewRequest ::= SEQUENCE { - beforeCount INTEGER (0..maxInt), - afterCount INTEGER (0..maxInt), - CHOICE { - byoffset [0] SEQUENCE { - offset INTEGER (0 .. maxInt), - contentCount INTEGER (0 .. maxInt) }, - greaterThanOrEqual [1] AssertionValue }, - contextID OCTET STRING OPTIONAL } - -beforeCount indicates how many entries before the target entry the -client wants the server to send. afterCount indicates the number of -entries after the target entry the client wants the server to send. -offset and contentCount identify the target entry as detailed in section -4. greaterThanOrEqual is an attribute assertion value defined in -[LDAPv3]. If present, the value supplied in greaterThanOrEqual is used -to determine the target entry by comparison with the values of the -attribute specified as the primary sort key. The first list entry who's -value is no less than (less than or equal to when the sort order is -reversed) the supplied value is the target entry. If present, the con- -textID field contains the value of the most recently received contextID -field from a VirtualListViewResponse control. The type AssertionValue -and value maxInt are defined in [LDAPv3]. contextID values have no -validity outwith the connection on which they were received. That is, a -client should not submit a contextID which it received from another con- -nection, a connection now closed, or a different server. - - -5.2. Response Control - -This control is included in the SearchResultDone message as part of the -controls field of the LDAPMessage, as defined in Section 4.1.12 of - - - -Boreham et al [Page 5] - - - - - -RFC DRAFT April 2000 - - -[LDAPv3]. - -The controlType is set to "2.16.840.1.113730.3.4.10". The criticality is -FALSE (MAY be absent). The controlValue is an OCTET STRING, whose value -is the BER encoding of a value of the following SEQUENCE: - - VirtualListViewResponse ::= SEQUENCE { - targetPosition INTEGER (0 .. maxInt), - contentCount INTEGER (0 .. maxInt), - virtualListViewResult ENUMERATED { - success (0), - operationsError (1), - unwillingToPerform (53), - insufficientAccessRights (50), - busy (51), - timeLimitExceeded (3), - adminLimitExceeded (11), - sortControlMissing (60), - offsetRangeError (61), - other (80) }, - contextID OCTET STRING OPTIONAL } - -targetPosition gives the list offset for the target entry. contentCount -gives the server's estimate of the current number of entries in the -list. Together these give sufficient information for the client to -update a list box slider position to match the newly retrieved entries -and identify the target entry. The contentCount value returned SHOULD be -used in a subsequent VirtualListViewRequest control. contextID is a -server-defined octet string. If present, the contents of the contextID -field SHOULD be returned to the server by a client in a subsequent Vir- -tualListViewRequest control. - -The virtualListViewResult codes which are common to the LDAP sear- -chResponse (adminLimitExceeded, timeLimitExceeded, busy, operationsEr- -ror, unwillingToPerform, insufficientAccessRights) have the same mean- -ings as defined in [LDAPv3], but they pertain specifically to the VLV -operation. For example, the server could exceed an administration limit -processing a SearchRequest with a VirtualListViewRequest control. How- -ever, the same administration limit would not be exceeded should the -same SearchRequest be submitted by the client without the VirtualList- -ViewRequest control. In this case, the client can determine that an -administration limit has been exceeded in servicing the VLV request, and -can if it chooses resubmit the SearchRequest without the VirtualList- -ViewRequest control. - -insufficientAccessRights means that the server denied the client permis- -sion to perform the VLV operation. - - - - -Boreham et al [Page 6] - - - - - -RFC DRAFT April 2000 - - -If the server determines that the results of the search presented exceed -the range provided by the 32-bit offset values, it MUST return -offsetRangeError. - -6. Protocol Example - -Here we walk through the client-server interaction for a specific vir- -tual list view example: The task is to display a list of all 78564 peo- -ple in the US company "Ace Industry". This will be done by creating a -graphical user interface object to display the list contents, and by -repeatedly sending different versions of the same virtual list view -search request to the server. The list view displays 20 entries on the -screen at a time. - -We form a search with baseDN "o=Ace Industry, c=us"; search scope sub- -tree; filter "objectClass=inetOrgPerson". We attach a server sort order -control to the search, specifying ascending sort on attribute "cn". To -this base search, we attach a virtual list view request control with -contents determined by the user activity and send the search to the -server. We display the results from each search in the list window and -update the slider position. - -When the list view is first displayed, we want to initialize the con- -tents showing the beginning of the list. Therefore, we set beforeCount = -0, afterCount = 19, contentCount = 0, offset = 1 and send the request to -the server. The server duly returns the first 20 entries in the list, -plus the content count = 78564 and targetPosition = 1. We therefore -leave the scroll bar slider at its current location (the top of its -range). - -Say that next the user drags the scroll bar slider down to the bottom of -its range. We now wish to display the last 20 entries in the list, so -we set beforeCount = 19, afterCount = 0, contentCount = 78564, offset = -78564 and send the request to the server. The server returns the last 20 -entries in the list, plus the content count = 78564 and targetPosition = -78564. - -Next the user presses a page up key. Our page size is 20, so we set -beforeCount = 0, afterCount = 19, contentCount = 78564, offset = -78564-19-20 and send the request to the server. The server returns the -preceding 20 entries in the list, plus the content count = 78564 and -targetPosition = 78525. - -Now the user grabs the scroll bar slider and drags it to 68% of the way -down its travel. 68% of 78564 is 53424 so we set beforeCount = 9, after- -Count = 10, contentCount = 78564, offset = 53424 and send the request to -the server. The server returns the preceding 20 entries in the list, -plus the content count = 78564 and targetPosition = 53424. - - - -Boreham et al [Page 7] - - - - - -RFC DRAFT April 2000 - - -Lastly, the user types the letter "B". We set beforeCount = 9, after- -Count = 10 and greaterThanOrEqual = "B". The server finds the first -entry in the list not less than "B", let's say "Babs Jensen", and -returns the nine preceding entries, the target entry, and the proceeding -10 entries. The server returns content count = 78564 and targetPosition -= 5234 and so the client updates its scroll bar slider to 6.7% of full -scale. - -7. Notes for Implementers - -While the feature is expected to be generally useful for arbitrary -search and sort specifications, it is specifically designed for those -cases where the result set is very large. The intention is that this -feature be implemented efficiently by means of pre-computed indices per- -taining to a set of specific cases. For example, an offset relating to -"all the employees in the local organization, sorted by surname" would -be a common case. - -The intention for client software is that the feature should fit easily -with the host platform's graphical user interface facilities for the -display of scrolling lists. Thus the task of the client implementers -should be one of reformatting up the requests for information received -from the list view code to match the format of the virtual list view -request and response controls. - -Client implementers should note that any offset value returned by the -server may be approximate. Do not design clients > which only operate -correctly when offsets are exact. - -Server implementers using indexing technology which features approximate -positioning should consider returning context identifiers to clients. -The use of a context identifier will allow the server to distinguish -between client requests which relate to different displayed lists on the -client. Consequently the server can decide more intelligently whether to -reposition an existing database cursor accurately to within a short dis- -tance of its current position, or to reposition to an approximate posi- -tion. Thus the client will see precise offsets for "short" repositioning -(e.g. paging up or down), but approximate offsets for a "long" reposi- -tion (e.g. a slider movement). - -Server implementers are free to return status code unwillingToPerform -should their server be unable to service any particular VLV search. -This might be because the resolution of the search is computationally -infeasible, or because excessive server resources would be required to -service the search. - -Client implementers should note that this control is only defined on a -client interaction with a single server. If a server returns referrals - - - -Boreham et al [Page 8] - - - - - -RFC DRAFT April 2000 - - -as a part of its response to the search request, the client is responsi- -ble for deciding when and how to apply this control to the referred-to -servers, and how to collate the results from multiple servers. - - -8. Relationship to "Simple Paged Results" - -These controls are designed to support the virtual list view, which has -proved hard to implement with the Simple Paged Results mechanism -[SPaged]. However, the controls described here support any operation -possible with the Simple Paged Results mechanism. The two mechanisms are -not complementary, rather one has a superset of the other's features. -One area where the mechanism presented here is not a strict superset of -the Simple Paged Results scheme is that here we require a sort order to -be specified. No such requirement is made for paged results. - - -9. Security Considerations - -Server implementers may wish to consider whether clients are able to -consume excessive server resources in requesting virtual list opera- -tions. Access control to the feature itself; configuration options lim- -iting the feature's use to certain predetermined search base DNs and -filters; throttling mechanisms designed to limit the ability for one -client to soak up server resources, may be appropriate. - -Consideration should be given as to whether a client will be able to -retrieve the complete contents, or a significant subset of the complete -contents of the directory using this feature. This may be undesirable in -some circumstances and consequently it may be necessary to enforce some -access control. - -Clients can, using this control, determine how many entries are con- -tained within a portion of the DIT. This may constitute a security -hazard. Again, access controls may be appropriate. - -Server implementers SHOULD exercise caution concerning the content of -the contextID. Should the contextID contain internal server state, it -may be possible for a malicious client to use that information to gain -unauthorized access to information. - -10. Acknowledgements - -Chris Weider of Microsoft co-authored a previous version of this docu- -ment. - - - - - - -Boreham et al [Page 9] - - - - - -RFC DRAFT April 2000 - - -11. References - -[LDAPv3] - Wahl, M, S. Kille and T. Howes, "Lightweight Directory Access Pro- - tocol (v3)", Internet Standard, December, 1997. RFC2251. - -[SPaged] - Weider, C, A. Herron, A. Anantha, and T. Howes, "LDAP Control - Extension for Simple Paged Results Manipulation", September - 1999. RFC2696 - -[SSS]Wahl, M, A. Herron and T. Howes, "LDAP Control Extension for Server - Side Sorting of Search Results", Internet Draft, April, 1999. - Available as draft-ietf-asid-ldapv3-sorting-02.txt. - -[Bradner97] - Bradner, S., "Key Words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - -12. Authors' Addresses - - David Boreham - iPlanet e-commerce solutions - 501 E. Middlefield Road - Mountain View, CA 94043, USA - +1 650 937-5206 - dboreham@netscape.com - - Jim Sermersheim - Novell - 122 East 1700 South - Provo, Utah 84606, USA - jimse@novell.com - - Anoop Anantha - Microsoft Corp. - 1 Microsoft Way - Redmond, WA 98052, USA - +1 425 882-8080 - anoopa@microsoft.com - - Michael Armijo - Microsoft Corp. - 1 Microsoft Way - Redmond, WA 98052, USA - +1 425 882-8080 - micharm@microsoft.com - This document expires on 5 October 2000 - - - -Boreham et al [Page 10] - - - - - -RFC DRAFT April 2000 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Boreham et al [Page 11] - - |