idnits 2.17.1 draft-ietf-ldapext-ldapv3-vlv-06.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2002) is 8010 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 237 -- Looks like a reference, but probably isn't: '1' on line 240 ** Obsolete normative reference: RFC 2251 (ref. 'LDAPv3') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Downref: Normative reference to an Informational RFC: RFC 2696 (ref. 'SPaged') Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft D. Boreham, Bozeman Pass 2 LDAPext Working Group J. Sermersheim, Novell 3 Intended Category: Standards Track A. Kashi, Microsoft 4 5 Expires: Nov 2002 May 2002 7 LDAP Extensions for Scrolling View Browsing of Search Results 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This document is intended to be submitted, after review and revision, 30 as a Standards Track document. Distribution of this memo is 31 unlimited. 32 Please send comments to the authors. 34 2. Abstract 36 This document describes a Virtual List View control extension for the 37 Lightweight Directory Access Protocol (LDAP) Search operation. This 38 control is designed to allow the "virtual list box" feature, common 39 in existing commercial e-mail address book applications, to be 40 supported efficiently by LDAP servers. LDAP servers' inability to 41 support this client feature is a significant impediment to LDAP 42 replacing proprietary protocols in commercial e-mail systems. 44 The control allows a client to specify that the server return, for a 45 given LDAP search with associated sort keys, a contiguous subset of 46 the search result set. This subset is specified in terms of offsets 47 into the ordered list, or in terms of a greater than or equal 48 comparison value. 50 Boreham et al Internet-Draft 1 51 Browsing of Search Results 53 3. Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are 56 to be interpreted as described in RFC 2119 [Bradner97]. 58 4. Background 60 A Virtual List is a graphical user interface technique employed where 61 ordered lists containing a large number of entries need to be 62 displayed. A window containing a small number of visible list entries 63 is drawn. The visible portion of the list may be relocated to 64 different points within the list by means of user input. This input 65 can be to a scroll bar slider; from cursor keys; from page up/down 66 keys; from alphanumeric keys for "typedown". The user is given the 67 impression that they may browse the complete list at will, even 68 though it may contain millions of entries. It is the fact that the 69 complete list contents are never required at any one time that 70 characterizes Virtual List View. Rather than fetch the complete list 71 from wherever it is stored (typically from disk or a remote server), 72 only that information which is required to display the part of the 73 list currently in view is fetched. The subject of this document is 74 the interaction between client and server required to implement this 75 functionality in the context of the results from a sorted LDAP search 76 request. 78 For example, suppose an e-mail address book application displays a 79 list view onto the list containing the names of all the holders of e- 80 mail accounts at a large university. The list is sorted 81 alphabetically. While there may be tens of thousands of entries in 82 this list, the address book list view displays only 20 such accounts 83 at any one time. The list has an accompanying scroll bar and text 84 input window for type-down. When first displayed, the list view shows 85 the first 20 entries in the list, and the scroll bar slider is 86 positioned at the top of its range. Should the user drag the slider 87 to the bottom of its range, the displayed contents of the list view 88 should be updated to show the last 20 entries in the list. Similarly, 89 if the slider is positioned somewhere in the middle of its travel, 90 the displayed contents of the list view should be updated to contain 91 the 20 entries located at that relative position within the complete 92 list. Starting from any display point, if the user uses the cursor 93 keys or clicks on the scroll bar to request that the list be scrolled 94 up or down by one entry, the displayed contents should be updated to 95 reflect this. Similarly the list should be displayed correctly when 96 the user requests a page scroll up or down. Finally, when the user 97 types characters in the type-down window, the displayed contents of 98 the list should "jump" or "seek" to the appropriate point within the 99 list. For example, if the user types "B", the displayed list could 100 center around the first user with a name beginning with the letter 101 "B". When this happens, the scroll bar slider should also be updated 102 to reflect the new relative location within the list. 104 Boreham et al Internet-Draft 2 105 Browsing of Search Results 107 This document defines a request control which extends the LDAP search 108 operation. Always used in conjunction with the server side sorting 109 control [SSS], this allows a client to retrieve selected portions of 110 large search result set in a fashion suitable for the implementation 111 of a virtual list view. 113 5. Client-Server Interaction 115 The Virtual List View control extends a regular LDAP Search operation 116 which must also include a server-side sorting control [SSS]. Rather 117 than returning the complete set of appropriate SearchResultEntry 118 messages, the server is instructed to return a contiguous subset of 119 those entries, taken from the sorted result set, centered around a 120 particular target entry. Henceforth, in the interests of brevity, the 121 sorted search result set will be referred to as "the list". 123 The sort control MAY contain any sort specification valid for the 124 server. The attributeType field in the first SortKeyList sequence 125 element has special significance for "typedown". 127 The desired target entry and the number of entries to be returned, 128 both before and after that target entry in the list, are determined 129 by the client's VirtualListViewRequest control. 131 When the server returns the set of entries to the client, it attaches 132 a VirtualListViewResponse control to the SearchResultDone message. 133 The server returns in this control: its current estimate for the list 134 content count, the location within the list corresponding to the 135 target entry, any error codes, and optionally a context identifier. 137 The target entry is specified in the VirtualListViewRequest control 138 by one of two methods. The first method is for the client to indicate 139 the target entry's offset within the list. The second way is for the 140 client to supply an attribute assertion value. The value is compared 141 against the values of the attribute specified as the primary sort key 142 in the sort control attached to the search operation. The first sort 143 key in the SortKeyList is the primary sort key. The target entry is 144 the first entry in the list with value greater than or equal to (in 145 the primary sort order), the presented value. The order is determined 146 by rules defined in [SSS]. Selection of the target entry by this 147 means is designed to implement "typedown". Note that it is possible 148 that no entry satisfies these conditions, in which case there is no 149 target entry. This condition is indicated by the server returning the 150 special value contentCount + 1 in the target position field. 152 Because the server may not have an accurate estimate of the number of 153 entries in the list, and to take account of cases where the list size 154 is changing during the time the user browses the list, and because 155 the client needs a way to indicate specific list targets "beginning" 157 Boreham et al Internet-Draft 3 158 Browsing of Search Results 160 and "end", offsets within the list are transmitted between client and 161 server as ratios---offset to content count. The server sends its 162 latest estimate as to the number of entries in the list (content 163 count) to the client in every response control. The client sends its 164 assumed value for the content count in every request control. The 165 server examines the content count and offsets presented by the client 166 and computes the corresponding offsets within the list, based on its 167 own idea of the content count. 169 Si = Sc * (Ci / Cc) 171 Where: 172 Si is the actual list offset used by the server 173 Sc is the server's estimate for content count 174 Ci is the client's submitted offset 175 Cc is the client's submitted content count 176 The result is rounded to the nearest integer. 178 If the content count is stable, and the client returns to the server 179 the content count most recently received, Cc = Sc and the offsets 180 transmitted become the actual server list offsets. 182 The following special cases exist when the client is specifying the 183 offset and content count: 184 - an offset of one and a content count of non-one (Ci = 1, Cc != 1) 185 indicates that the target is the first entry in the list. 186 - equivalent values (Ci = Cc) indicate that the target is the last 187 entry in the list. 188 - a content count of zero, and a non-zero offset (Cc = 0, Ci != 0) 189 means the client has no idea what the content count is, the server 190 MUST use its own content count estimate in place of the client's. 192 Because the server always returns contentCount and targetPosition, 193 the client can always determine which of the returned entries is the 194 target entry. Where the number of entries returned is the same as the 195 number requested, the client is able to identify the target by simple 196 arithmetic. Where the number of entries returned is not the same as 197 the number requested (because the requested range crosses the 198 beginning or end of the list, or both), the client must use the 199 target position and content count values returned by the server to 200 identify the target entry. For example, suppose that 10 entries 201 before and 10 after the target were requested, but the server returns 202 13 entries, a content count of 100 and a target position of 3. The 203 client can determine that the first entry must be entry number 1 in 204 the list, therefore the 13 entries returned are the first 13 entries 205 in the list, and the target is the third one. 207 A server-generated context identifier MAY be returned to clients. A 208 client receiving a context identifier SHOULD return it unchanged in a 209 subsequent request which relates to the same list. The purpose of 211 Boreham et al Internet-Draft 4 212 Browsing of Search Results 214 this interaction is to enhance the performance and effectiveness of 215 servers which employ approximate positioning. 217 6. The Controls 219 Support for the virtual list view control extension is indicated by 220 the presence of the OID "2.16.840.1.113730.3.4.9" in the 221 supportedControl attribute of a server's root DSE. 223 6.1. Request Control 225 This control is included in the SearchRequest message as part of the 226 controls field of the LDAPMessage, as defined in Section 4.1.12 of 227 [LDAPv3]. The controlType is set to "2.16.840.1.113730.3.4.9". The 228 criticality SHOULD be set to TRUE. If this control is included in a 229 SearchRequest message, a Server Side Sorting request control [SSS] 230 MUST also be present in the message. The controlValue is an OCTET 231 STRING whose value is the BER-encoding of the following SEQUENCE: 233 VirtualListViewRequest ::= SEQUENCE { 234 beforeCount INTEGER (0..maxInt), 235 afterCount INTEGER (0..maxInt), 236 CHOICE { 237 byoffset [0] SEQUENCE { 238 offset INTEGER (0 .. maxInt), 239 contentCount INTEGER (0 .. maxInt) }, 240 greaterThanOrEqual [1] AssertionValue }, 241 contextID OCTET STRING OPTIONAL } 243 beforeCount indicates how many entries before the target entry the 244 client wants the server to send. afterCount indicates the number of 245 entries after the target entry the client wants the server to send. 246 offset and contentCount identify the target entry as detailed in 247 section 4. greaterThanOrEqual is an attribute assertion value defined 248 in [LDAPv3]. If present, the value supplied in greaterThanOrEqual is 249 used to determine the target entry by comparison with the values of 250 the attribute specified as the primary sort key. The first list entry 251 who's value is no less than (less than or equal to when the sort 252 order is reversed) the supplied value is the target entry. If 253 present, the contextID field contains the value of the most recently 254 received contextID field from a VirtualListViewResponse control. The 255 type AssertionValue and value maxInt are defined in [LDAPv3]. 256 contextID values have no validity outwith the connection on which 257 they were received. That is, a client should not submit a contextID 258 which it received from another connection, a connection now closed, 259 or a different server. 261 6.2. Response Control 263 Boreham et al Internet-Draft 5 264 Browsing of Search Results 266 This control is included in the SearchResultDone message as part of 267 the controls field of the LDAPMessage, as defined in Section 4.1.12 268 of [LDAPv3]. 270 The controlType is set to "2.16.840.1.113730.3.4.10". The criticality 271 is FALSE (MAY be absent). The controlValue is an OCTET STRING, whose 272 value is the BER encoding of a value of the following SEQUENCE: 274 VirtualListViewResponse ::= SEQUENCE { 275 targetPosition INTEGER (0 .. maxInt), 276 contentCount INTEGER (0 .. maxInt), 277 virtualListViewResult ENUMERATED { 278 success (0), 279 operationsError (1), 280 unwillingToPerform (53), 281 insufficientAccessRights (50), 282 busy (51), 283 timeLimitExceeded (3), 284 adminLimitExceeded (11), 285 sortControlMissing (60), 286 offsetRangeError (61), 287 other (80) }, 288 contextID OCTET STRING OPTIONAL } 290 targetPosition gives the list offset for the target entry. 291 contentCount gives the server's estimate of the current number of 292 entries in the list. Together these give sufficient information for 293 the client to update a list box slider position to match the newly 294 retrieved entries and identify the target entry. The contentCount 295 value returned SHOULD be used in a subsequent VirtualListViewRequest 296 control. contextID is a server-defined octet string. If present, the 297 contents of the contextID field SHOULD be returned to the server by a 298 client in a subsequent VirtualListViewRequest control. 300 The virtualListViewResult codes which are common to the LDAP 301 searchResponse (adminLimitExceeded, timeLimitExceeded, busy, 302 operationsError, unwillingToPerform, insufficientAccessRights) have 303 the same meanings as defined in [LDAPv3], but they pertain 304 specifically to the VLV operation. For example, the server could 305 exceed an administration limit processing a SearchRequest with a 306 VirtualListViewRequest control. However, the same administration 307 limit would not be exceeded should the same SearchRequest be 308 submitted by the client without the VirtualListViewRequest control. 309 In this case, the client can determine that an administration limit 310 has been exceeded in servicing the VLV request, and can if it chooses 311 resubmit the SearchRequest without the VirtualListViewRequest 312 control. 314 insufficientAccessRights means that the server denied the client 315 permission to perform the VLV operation. 317 Boreham et al Internet-Draft 6 318 Browsing of Search Results 320 If the server determines that the results of the search presented 321 exceed the range specified in INTEGER values, it MUST return 322 offsetRangeError. 324 6.2.1 virtualListViewError 326 A new LDAP error is introduced called virtualListViewError. Its value 327 is 76. 328 [Note to the IESG/IANA/RFC Editor: the value 76 has been suggested by 329 experts, had expert review, and is currently being used by some 330 implementations. The intent is to have this number designated as an 331 official IANA assigned LDAP Result Code (see draft-ietf-ldapbis-iana- 332 xx.txt, Section 3.5)] 334 If the server returns any code other than success (0) for 335 virtualListViewResult, then the server SHOULD return 336 virtualListViewError as the resultCode of the SearchResultDone 337 message. 339 7. Protocol Example 341 Here we walk through the client-server interaction for a specific 342 virtual list view example: The task is to display a list of all 78564 343 people in the US company "Ace Industry". This will be done by 344 creating a graphical user interface object to display the list 345 contents, and by repeatedly sending different versions of the same 346 virtual list view search request to the server. The list view 347 displays 20 entries on the screen at a time. 349 We form a search with baseDN "o=Ace Industry, c=us"; search scope 350 subtree; filter "objectClass=inetOrgPerson". We attach a server sort 351 order control to the search, specifying ascending sort on attribute 352 "cn". To this base search, we attach a virtual list view request 353 control with contents determined by the user activity and send the 354 search to the server. We display the results from each search in the 355 list window and update the slider position. 357 When the list view is first displayed, we want to initialize the 358 contents showing the beginning of the list. Therefore, we set 359 beforeCount = 0, afterCount = 19, contentCount = 0, offset = 1 and 360 send the request to the server. The server duly returns the first 20 361 entries in the list, plus the content count = 78564 and 362 targetPosition = 1. We therefore leave the scroll bar slider at its 363 current location (the top of its range). 365 Say that next the user drags the scroll bar slider down to the bottom 366 of its range. We now wish to display the last 20 entries in the list, 367 so we set beforeCount = 19, afterCount = 0, contentCount = 78564, 368 offset = 78564 and send the request to the server. The server returns 370 Boreham et al Internet-Draft 7 371 Browsing of Search Results 373 the last 20 entries in the list, plus the content count = 78564 and 374 targetPosition = 78564. 376 Next the user presses a page up key. Our page size is 20, so we set 377 beforeCount = 0, afterCount = 19, contentCount = 78564, offset = 378 78564-19-20 and send the request to the server. The server returns 379 the preceding 20 entries in the list, plus the content count = 78564 380 and targetPosition = 78525. 382 Now the user grabs the scroll bar slider and drags it to 68% of the 383 way down its travel. 68% of 78564 is 53424 so we set beforeCount = 9, 384 afterCount = 10, contentCount = 78564, offset = 53424 and send the 385 request to the server. The server returns the preceding 20 entries in 386 the list, plus the content count = 78564 and targetPosition = 53424. 388 Lastly, the user types the letter "B". We set beforeCount = 9, 389 afterCount = 10 and greaterThanOrEqual = "B". The server finds the 390 first entry in the list not less than "B", let's say "Babs Jensen", 391 and returns the nine preceding entries, the target entry, and the 392 proceeding 10 entries. The server returns content count = 78564 and 393 targetPosition = 5234 and so the client updates its scroll bar slider 394 to 6.7% of full scale. 396 8. Notes for Implementers 398 While the feature is expected to be generally useful for arbitrary 399 search and sort specifications, it is specifically designed for those 400 cases where the result set is very large. The intention is that this 401 feature be implemented efficiently by means of pre-computed indices 402 pertaining to a set of specific cases. For example, an offset 403 relating to "all the employees in the local organization, sorted by 404 surname" would be a common case. 406 The intention for client software is that the feature should fit 407 easily with the host platform's graphical user interface facilities 408 for the display of scrolling lists. Thus the task of the client 409 implementers should be one of reformatting up the requests for 410 information received from the list view code to match the format of 411 the virtual list view request and response controls. 413 Client implementers should note that any offset value returned by the 414 server may be approximate. Do not design clients > which only operate 415 correctly when offsets are exact. 417 Server implementers using indexing technology which features 418 approximate positioning should consider returning context identifiers 419 to clients. The use of a context identifier will allow the server to 420 distinguish between client requests which relate to different 421 displayed lists on the client. Consequently the server can decide 422 more intelligently whether to reposition an existing database cursor 424 Boreham et al Internet-Draft 8 425 Browsing of Search Results 427 accurately to within a short distance of its current position, or to 428 reposition to an approximate position. Thus the client will see 429 precise offsets for "short" repositioning (e.g. paging up or down), 430 but approximate offsets for a "long" reposition (e.g. a slider 431 movement). 433 Server implementers are free to return status code unwillingToPerform 434 should their server be unable to service any particular VLV search. 435 This might be because the resolution of the search is computationally 436 infeasible, or because excessive server resources would be required 437 to service the search. 439 Client implementers should note that this control is only defined on 440 a client interaction with a single server. If a server returns 441 referrals as a part of its response to the search request, the client 442 is responsible for deciding when and how to apply this control to the 443 referred-to servers, and how to collate the results from multiple 444 servers. 446 9. Relationship to "Simple Paged Results" 448 These controls are designed to support the virtual list view, which 449 has proved hard to implement with the Simple Paged Results mechanism 450 [SPaged]. However, the controls described here support any operation 451 possible with the Simple Paged Results mechanism. The two mechanisms 452 are not complementary; rather one has a superset of the other's 453 features. One area where the mechanism presented here is not a strict 454 superset of the Simple Paged Results scheme is that here we require a 455 sort order to be specified. No such requirement is made for paged 456 results. 458 10. Security Considerations 460 Server implementers may wish to consider whether clients are able to 461 consume excessive server resources in requesting virtual list 462 operations. Access control to the feature itself; configuration 463 options limiting the feature�s use to certain predetermined search 464 base DNs and filters; throttling mechanisms designed to limit the 465 ability for one client to soak up server resources, may be 466 appropriate. 468 Consideration should be given as to whether a client will be able to 469 retrieve the complete contents, or a significant subset of the 470 complete contents of the directory using this feature. This may be 471 undesirable in some circumstances and consequently it may be 472 necessary to enforce some access control. 474 Boreham et al Internet-Draft 9 475 Browsing of Search Results 477 Clients can, using this control, determine how many entries are 478 contained within a portion of the DIT. This may constitute a security 479 hazard. Again, access controls may be appropriate. 481 Server implementers SHOULD exercise caution concerning the content of 482 the contextID. Should the contextID contain internal server state, it 483 may be possible for a malicious client to use that information to 484 gain unauthorized access to information. 486 11. Acknowledgements 488 Chris Weider, Anoop Anantha, and Michael Armijo of Microsoft co- 489 authored previous versions of this document. 491 12. References 493 [LDAPv3] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory 494 Access Protocol (v3)", Internet Standard, RFC 2251, 495 December, 1997. 497 [SPaged] Weider, C., Herron, A., Anantha, A. and T. Howes, "LDAP 498 Control Extension for Simple Paged Results Manipulation", 499 RFC2696, September 1999. 501 [SSS] Wahl, M., Herron, A. and T. Howes, "LDAP Control 502 Extension for Server Side Sorting of Search Results", 503 RFC 2891, August, 2000. 505 [Bradner97] Bradner, S., "Key Words for use in RFCs to Indicate 506 Requirement Levels", BCP 14, RFC 2119, March 1997. 508 Boreham et al Internet-Draft 10 509 Browsing of Search Results 511 13. Authors' Addresses 513 David Boreham 514 Bozeman Pass, Inc 515 +1 406 222 7093 516 david@bozemanpass.com 518 Jim Sermersheim 519 Novell, Inc 520 1800 South Novell Place 521 Provo, Utah 84606, USA 522 jimse@novell.com 524 Asaf Kashi 525 Microsoft Corporation 526 1 Microsoft Way 527 Redmond, WA 98052, USA 528 +1 425 882-8080 529 asafk@microsoft.com 531 14. Full Copyright Statement 533 Copyright (C) The Internet Society (2002). All Rights Reserved. 534 This document and translations of it may be copied and furnished to 535 others, and derivative works that comment on or otherwise explain it 536 or assist in its implementation may be prepared, copied, published 537 and distributed, in whole or in part, without restriction of any 538 kind, provided that the above copyright notice and this paragraph are 539 included on all such copies and derivative works. However, this 540 document itself may not be modified in any way, such as by removing 541 the copyright notice or references to the Internet Society or other 542 Internet organizations, except as needed for the purpose of 543 developing Internet standards in which case the procedures for 544 copyrights defined in the Internet Standards process must be 545 followed, or as required to translate it into languages other than 546 English. The limited permissions granted above are perpetual and will 547 not be revoked by the Internet Society or its successors or assigns. 548 This document and the information contained herein is provided on an 549 "AS IS" basis and THE INTERNET SOCIETY AND THE 550 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 551 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 552 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 553 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 555 Boreham et al Internet-Draft 11