idnits 2.17.1 draft-ietf-imapext-window-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([IMAP4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 410 has weird spacing: '... window map f...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (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 (June 2001) is 8351 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) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) == Outdated reference: A later version (-20) exists of draft-ietf-imapext-sort-03 -- Possible downref: Normative reference to a draft: ref. 'THREAD' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IMAP Extensions Working Group C. Daboo 2 Internet Draft: IMAP WINDOW Extension C. Newman 3 Document: draft-ietf-imapext-window-00.txt June 2001 5 IMAP WINDOW Extension 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. Internet-Drafts are 11 working documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other documents 17 at any time. It is inappropriate to use Internet-Drafts as 18 reference material or to cite them other than as "work in progress." 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 22 Draft Shadow Directories can be accessed at 23 http://www.ietf.org/shadow.html. 25 Copyright Notice 27 Copyright (C) The Internet Society (2001). All Rights Reserved. 29 Table of Contents 30 1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2 31 2 Conventions Used in This Document . . . . . . . . . . . . . 2 32 3 Introduction and Overview . . . . . . . . . . . . . . . . . . 3 33 4 Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 4 34 5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 35 5.1 Input Window . . . . . . . . . . . . . . . . . . . . . . 5 36 5.2 Output Results . . . . . . . . . . . . . . . . . . . . . 5 37 5.3 Output Position . . . . . . . . . . . . . . . . . . . . 5 38 5.4 Output Window . . . . . . . . . . . . . . . . . . . . . . 5 39 5.5 Anchor . . . . . . . . . . . . . . . . . . . . . . . . . 5 40 5.6 Anchor Offset . . . . . . . . . . . . . . . . . . . . . . 5 41 6 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 42 7 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 6 43 7.1 WINDOW Command . . . . . . . . . . . . . . . . . . . . . 6 44 7.1.1 WINDOW SET . . . . . . . . . . . . . . . . . . . . . 6 45 7.1.2 WINDOW SHOW . . . . . . . . . . . . . . . . . . . . 7 46 7.1.3 WINDOW UPDATE . . . . . . . . . . . . . . . . . . . . 8 47 7.1.4 WINDOW MAP . . . . . . . . . . . . . . . . . . . . . 9 48 7.2 UID Command modifications . . . . . . . . . . . . . . . . 10 49 7.2.1 UID WINDOW SHOW . . . . . . . . . . . . . . . . . . 10 50 7.2.2 UID WINDOW MAP . . . . . . . . . . . . . . . . . . . 10 51 8 Responses . . . . . . . . . . . . . . . . . . . . . . . . . 10 52 8.1 WINDOW SET Untagged Response . . . . . . . . . . . . . . 10 53 8.2 WINDOW Untagged Response . . . . . . . . . . . . . . . . 10 54 8.3 WINDOW MAP Untagged Response . . . . . . . . . . . . . . 10 55 9 Handling message expunges . . . . . . . . . . . . . . . . . 10 56 10 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 57 11 Security Considerations . . . . . . . . . . . . . . . . . . 12 58 12 References . . . . . . . . . . . . . . . . . . . . . . . . . 12 59 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12 60 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 62 1 Abstract 64 The WINDOW extension to the Internet Message Access Protocol [IMAP4] 65 permits windowing of the results of specific IMAP commands, so that 66 clients can retrieve the results in ranges to implement paging of 67 results or virtual scrollbars. This eliminates the need to get and 68 manage the entire result set, improving scalability for large 69 mailboxes and slow connections. 71 2 Conventions Used in This Document 73 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 74 NOT", and "MAY" in this document are to be interpreted as described 75 in "Key words for use in RFCs to Indicate Requirement Levels" 76 [KEYWORDS]. 78 Formal syntax is defined using ABNF [ABNF]. 80 In examples, "C:" and "S:" indicate lines sent by the client and 81 server respectively. 83 3 Introduction and Overview 85 The WINDOW extension is present in any IMAP4 implementation which 86 returns "WINDOW" as one of the supported capabilities in the 87 CAPABILITY command. 89 The WINDOW extension specifies one new command (with a number of 90 variants) and introduces one new untagged response (with a number of 91 variants). 93 The WINDOW command is an optimization for scalability purposes; 94 clients can provide the same functionality, albeit more slowly, by 95 using existing commands. 97 The SEARCH [IMAP4], SORT [SORT] and THREAD [THREAD] commands in 98 IMAP4 return a list of results equal to the size of the input 99 window. The input window is determined by the parameters to each 100 command. For example, the SEARCH command can limit its input window 101 by using sequence number or UID number ranges as parameters to the 102 SEARCH: 104 Example: C: A999 SEARCH UNSEEN 10:20 105 S: * SEARCH 1 2 4 6 106 S: A999 OK SEARCH completed 108 In the above example, an input window of messages with sequence 109 numbers in the range 10 through 20 are the only ones considered by 110 the SEARCH command. This limits the output to a maximum of 11 hits. 111 The SORT and THREAD commands both take search criteria as 112 parameters, and thus can also accomplish input windowing if desired. 114 While input windowing can reduce the number of results returned, it 115 does not offer a way to window the results based on their output 116 ordering or size. The design goal of the WINDOW extension is to 117 allow clients to do output windowing of the results of SEARCH and 118 SORT commands, and to provide an extensible mechanism for future 119 IMAP command extensions that return results as a list of sequence 120 numbers or UIDs. 122 In order to keep the WINDOW extension simple, the THREAD command is 123 not included as one of the commands that WINDOW works with, due to 124 the hierarchical nature of the THREAD command results. 126 This extension makes the following changes to the IMAP4 protocol: 128 (a) Adds a new WINDOW command which takes one of four forms: 130 (i) The first form, WINDOW SET, takes an optional sub-command 131 and is used to initiate or cancel the windowing mechanism on the 132 server. When initiating a window, the server creates an output 133 results set consisting of all messages returned by the 134 sub-command, in their appropriate ordering. The server returns 135 the maximum size of the output results set as well as the 136 position of the first unseen message in the output results set. 138 (ii) The second form, WINDOW SHOW, takes parameters that allow 139 the client to precisely specify the output window range. This 140 command causes the server to return the message numbers for 141 messages in this output window, which is a subset of the entire 142 output results set. 144 (iii) The third form, WINDOW UPDATE, causes the server to update 145 the output results set to reflect any changes to the state of 146 the mailbox since the last WINDOW SET command was 147 issued. 149 (iv) The fourth form, WINDOW MAP, the client provides a set of 150 ordered message sequence numbers or UIDs and the server returns 151 the output positions of those messages in the current output 152 results set. For example, this allows a client to preserve user 153 message selections across WINDOW UPDATEs or other mailbox 154 changes. 156 (b) Adds a new WINDOW untagged response which takes one of three 157 forms: 159 (i) The first form, WINDOW SET, returns the size and position of 160 the first unseen message in the output results set. 162 (ii) The second form, WINDOW, returns the output window range. 164 (iii) The third form, WINDOW MAP, returns the mapping results 165 from message sequence number or UIDs to output positions in the 166 current output results set. 168 (c) Modifies the EXPUNGE untagged response to include the output 169 position of the message being expunged, when a WINDOW SET 170 operation is in effect. 172 The rest of this document describes these changes more rigorously. 174 4 Open Issues 176 - Should we have WINDOW FETCH and WINDOW STORE commands to allow 177 accessing messages by output position? 178 5 Terminology 180 5.1 Input Window 182 The set of messages used as input to a SEARCH or SORT command. In 183 the case of SEARCH this can be controlled via the message number or 184 UID range search criteria. In the case of SORT this is controlled 185 by the search criteria used with those commands. 187 5.2 Output Results 189 The set of ordered message numbers or UIDs that are the results of a 190 SEARCH or SORT command. 192 5.3 Output Position 194 The position of a message in the output results, a number from 1 to 195 where is the total number of messages in the output results. 197 5.4 Output Window 199 A contiguous range of messages in the output results that the client 200 wishes to know about. 202 5.5 Anchor 204 A specific message that the client wants to appear at a particular 205 position in the output window, requiring the server to determine the 206 actual output window range to accommodate this requirement. For 207 example, when first opening a mailbox, the client may want to 208 position the first unseen message at the top of the list presented 209 to the user by scrolling its graphical window to the appropriate 210 place. 212 5.6 Anchor Offset 214 The position of the anchor message in the output window, relative to 215 the start or end of the output window. 217 6 Examples 219 The examples below will all use the following output results set for 220 consistency. There are a total of 20 messages in this set and the 221 first unseen message in the set has a sequence number of 14 and 222 appears at output position 3. 224 Output results: 226 11 12 14 16 30 22 24 13 15 31 10 44 21 23 42 41 37 27 26 25 227 ^ 228 first unseen message 229 The output results after an update. There are a total of 14 230 messages in this set and the first unseen message in the set has a 231 sequence number of 22 and appears at output position 6. 233 Output results after an update: 235 11 12 14 16 30 22 24 13 15 31 10 44 21 23 236 ^ 237 first unseen message 239 7 Commands 241 7.1 WINDOW Command 243 The WINDOW command is only available when the server is in 'selected 244 state' [IMAP4]. Thus a successful SELECT or EXAMINE command MUST 245 have been issued before WINDOW can be used. If a client attempts to 246 use WINDOW while the server is not in 'selected state', then the 247 server MUST respond with a BAD response. 249 To avoid ambiguities when messages are expunged from the mailbox, 250 the server MUST NOT send untagged EXPUNGE responses whilst a WINDOW 251 command is in progress, 253 The WINDOW command takes one of four forms. 255 7.1.1 WINDOW SET 257 Arguments: OPTIONAL sub-command and associated arguments: 258 this draft currently only allows the SEARCH and 259 SORT [SORT] commands as the sub-commands. 261 Responses: REQUIRED untagged responses: WINDOW SET 263 Result: OK - window set completed, now in window state 264 NO - window set failure 265 BAD - command unknown or arguments invalid 267 The WINDOW SET command is used to define the set of messages that 268 form the output results. This set is determined by the result of 269 the sub-command, and is ordered according to the sub-command. The 270 server stores the output results, which are used to return the data 271 the client may request using other WINDOW commands. The server MUST 272 return an untagged WINDOW SET response to the WINDOW SET command, 273 indicating the total number of messages in the output results, as 274 well as the output position number of the first unseen message in 275 the output results, or zero if there are no unseen messages in the 276 output results. 278 Example: C: A999 WINDOW SET SEARCH FROM "Smith" 279 S: * WINDOW SET 20 3 280 S: A999 OK WINDOW SET completed 282 In this example an output results set on a SEARCH command is 283 created. The output results have a total of 20 messages in it, and 284 the first unseen message is at output position 3 in the output 285 results. 287 A WINDOW SET command with no arguments is used to cancel an earlier 288 WINDOW SET with a sub-command. This allows a client to turn off the 289 windowing behaviour. 291 7.1.2 WINDOW SHOW 293 Arguments: the message number or starting position of the anchor message, 294 the anchor position within the output window, 295 the size of the output window to return. 297 Responses: REQUIRED untagged responses: WINDOW 299 Result: OK - window show completed 300 NO - window show failure 301 BAD - command unknown or arguments invalid 303 The WINDOW SHOW command is used by the client to retrieve portions 304 of the output results defined by an earlier WINDOW SET command. If 305 the server is in selected state and there was no previous WINDOW SET 306 command, or the WINDOW SET command was cancelled, then the server 307 MUST respond with a BAD response. 309 The WINDOW SHOW command takes three parameters: 311 a) An identifier indicating the position of the anchor message in 312 the output window. The client can specify the message by either its 313 sequence number, uid or position in the output results set. This is 314 done by using a single character before the numeric value to 315 indicate what type it is: 'S' for sequence number, 'U' for uid and 316 'P' for output position. 318 b) The requested anchor position where the anchor message should 319 appear in the output window, relative to either the start or end of 320 the output window. The server MUST return a BAD response if the 321 requested anchor position exceeds the size of the output window, as 322 specified in the third argument. 324 c) The size of the output window. If the size provided by the 325 client exceeds the size of the output results, the server MUST 326 return a BAD response. 328 The server MUST respond with an untagged WINDOW response indicating 329 the output position of the first message in the output window range, 330 followed by the message numbers of the messages in the range 331 requested by the client. In some cases the anchor may not appear at 332 the relative offset in the output window requested by the client, 333 because the offset would result in the output window exceeding the 334 range of the output results. 336 Example: C: A999 WINDOW SHOW P 3 +0 10 337 S: * WINDOW 3 14 16 30 22 24 13 15 31 10 44 338 S: A999 OK WINDOW SHOW completed 340 In this example the client requests the server to return the message 341 sequence numbers for 10 messages, anchored on output position 3 (the 342 first unseen message), with the anchor set to appear first in the 343 output window. The server responds with the output position of the 344 first message in the output window range, followed by the 10 message 345 sequence numbers corresponding to the requested messages - the 346 message with sequence number 14 is the anchor and the first unseen 347 message in the output results. 349 Example: C: A999 WINDOW SHOW P 20 -0 10 350 S: * WINDOW 11 10 44 21 23 42 41 37 27 26 25 351 S: A999 OK WINDOW SHOW completed 353 In this example the client requests the server to return the message 354 sequence numbers for the last ten messages in the output results. 355 This is accomplished by setting the anchor to the last output 356 position, and requesting the anchor to appear last in the output 357 window. 359 Example: C: A999 WINDOW SHOW S 14 +5 10 360 S: * WINDOW 1 11 12 14 16 30 22 24 13 15 31 361 S: A999 OK WINDOW SHOW completed 363 In this example the client requests an output window centered on the 364 message with sequence number 14. However, that message actually 365 appears at output position 3, so the specified anchor position 366 cannot be accommodated, so the output window contains the anchor at 367 position 3 instead of the requested position 5 from the start. 369 7.1.3 WINDOW UPDATE 371 Arguments: None. 373 Responses: REQUIRED untagged responses: WINDOW SET 375 Result: OK - window update completed 376 NO - window update failure 377 BAD - command unknown 379 The WINDOW UPDATE command is used to update the output results 380 created by a previous WINDOW SET command. This is needed because 381 WINDOW SET's output results are static - i.e. they do not change 382 even when the state of messages changes, or new messages are added 383 to the mailbox. In order to account for change to the mailbox, the 384 client must use the WINDOW UPDATE command. If the server is in 385 selected state and there was no previous WINDOW SET command, or the 386 WINDOW SET command was cancelled, then the server MUST respond with 387 a BAD response. 389 The server MUST return an untagged WINDOW SET response to the WINDOW 390 SET command, indicating the total number of messages in the new 391 output results, as well as the output position number of the first 392 unseen message in the new output results, or zero if there are no 393 unseen messages in the new output results. 395 Example: C: A999 WINDOW UPDATE 396 S: * WINDOW SET 14 6 397 S: A999 OK WINDOW UPDATE completed 399 In this example the new output results have a total of 14 messages 400 in it, and the first unseen message is now at output position 6 in 401 the new output results. 403 7.1.4 WINDOW MAP 405 Arguments: Message number range. 407 Responses: REQUIRED untagged responses: WINDOW MAP 409 Result: OK - window map completed 410 NO - window map failure 411 BAD - command unknown 413 The WINDOW MAP command allows a client to determine the output 414 positions of messages based on their sequence number or uid (if the 415 UID command modifier is also used). This is required to help 416 preserve a user's message selection state before and after a WINDOW 417 UPDATE command is used. 419 If the server is in selected state and there was no previous WINDOW 420 SET command, or the WINDOW SET command was cancelled, then the 421 server MUST respond with a BAD response. 423 The server MUST return an untagged WINDOW MAP response to the WINDOW 424 MAP command, indicating the new output positions of the requested 425 messages, corresponding to the range used as the argument to the 426 command. The server MUST return an output position number of zero 427 for any messages that are no longer in the output results. 429 If the message number argument specifies one or more messages that 430 are not in the output results set, the server MUST respond with a 431 BAD response. 433 Example: C: A999 WINDOW MAP 5,14:16,22,24 434 S: * WINDOW MAP 0 3 9 4 5 6 435 S: A999 OK WINDOW MAP completed 436 In this example the client requests the output positions of messages 437 with sequence numbers 5, 14, 15, 16, 22 and 24. Message 5 is not in 438 the output results set, so its output position number is zero. 440 7.2 UID Command modifications 442 The IMAP UID command is used to modify the meaning of another 443 command and/or the untagged results of a command. The WINDOW 444 extensions extends the UID command to accept certain WINDOW commands 445 as outlined below. 447 7.2.1 UID WINDOW SHOW 449 The UID WINDOW SHOW causes the untagged WINDOW response for the 450 WINDOW SHOW command to contain message uids rather than message 451 sequence numbers. 453 7.2.2 UID WINDOW MAP 455 The UID WINDOW MAP causes the message number range argument to the 456 WINDOW MAP command to be interpreted as message uids rather than 457 message sequence numbers. 459 8 Responses 461 8.1 WINDOW SET Untagged Response 463 The WINDOW SET untagged response is used to inform the client of the 464 total number of messages in the output results set and the output 465 position of the first unseen message in the output results, or zero 466 if no unseen message is present in the output results. The WINDOW 467 SET results can only occur as the result of a WINDOW SET or WINDOW 468 UPDATE command. 470 8.2 WINDOW Untagged Response 472 The WINDOW untagged response returns the output position of the 473 first message in the requested output window, followed by the 474 message numbers of the messages in the requested output window. The 475 message numbers may be either sequence numbers or uids depending on 476 whether the UID command modifier is used. The WINDOW response can 477 only occur as the result of a WINDOW SHOW command. 479 8.3 WINDOW MAP Untagged Response 481 The WINDOW MAP untagged response returns the output positions of 482 messages in the output results, ordered according to the ordering of 483 message numbers in the WINDOW MAP command. The WINDOW MAP response 484 can only occur as the result of a WINDOW MAP command. 486 9 Handling message expunges 488 When a WINDOW SET command is in effect, the server MUST modify any 489 untagged EXPUNGE responses it sends to the client to include the 490 output position of the message being expunged, or zero if the 491 message being expunged is not in the output results. After each 492 EXPUNGE response the output positions for the current WINDOW SET 493 must be readjusted to account for the expunged message. When an 494 untagged EXPUNGE response with a non-zero output position is seen by 495 the client, the client MUST adjust its output window and output 496 results state to take account of the expunged message. 498 Example: C: A999 NOOP 499 S: * 1 EXPUNGE 0 500 S: * 10 EXPUNGE 1 501 S: * 10 EXPUNGE 1 502 S: A999 OK 504 In this example three messages are expunged from the mailbox. 505 Message number 1 is not part of the previously determined output 506 results so its output position is shown as zero. Message number 11 507 was at output position 1, and message number 12 was at output 508 position number 1 after message number 11 was expunged. 510 10 Formal Syntax 512 The following syntax specification uses the Augmented Backus-Naur 513 Form (ABNF) notation as specified in [ABNF]. 515 Non-terminals referenced but not defined below are as defined by 516 [IMAP4]. 518 Except as noted otherwise, all alphabetic characters are case- 519 insensitive. The use of upper or lower case characters to define 520 token strings is for editorial clarity only. Implementations MUST 521 accept these strings in a case-insensitive fashion. 523 window-set-cmd = "WINDOW SET" SP window-set-arg 525 window-set-arg = search / sort / OTHER 526 ; search is defined in [IMAP4] 527 ; sort is defined in [SORT] 528 ; OTHER reserved for future definition 530 window-update-cmd = "WINDOW UPDATE" 532 window-set-resp = "*" SP "WINDOW SET" SP number SP number 534 window-show-cmd = "WINDOW SHOW" SP anchor-pos 535 SP anchor-rel SP nz-number 536 anchor-pos = ("S" / "U" / "P") SP nz-number 537 ; "S" indicates sequence number 538 ; "U" indicates uid 539 ; "P" indicates output position 541 anchor_rel = ("+" / "-") number 542 ; "+" indicates offset from start 543 ; "-" indicates offset from end 545 window-resp = "*" SP "WINDOW" SP nz-number *(SP nz-number) 547 window-map-cmd = "WINDOW MAP" SP set 549 window-map-resp = "*" SP "WINDOW MAP" SP number *(SP number) 551 message-data /= nz-number SP "EXPUNGE" SP number 552 ; modifies [IMAP4] EXPUNGE response 553 ; to return output position when 554 ; WINDOW SET is in effect 556 11 Security Considerations 558 There are no known security issues with this extension. 560 12 References 562 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 563 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, 564 November 1997. 566 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 567 Requirement Levels", RFC 2119, Harvard University, March 1997. 569 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 570 4rev1", RFC 2060, University of Washington, December 1996. 572 [SORT] Crispin, M., "Internet Message Access Protocol - SORT 573 Extension", draft-ietf-imapext-sort-03.txt (Work in progress) 575 [THREAD] Crispin, M., "Internet Message Access Protocol - THREAD 576 Extension", draft-crispin-imapext-thread-01.txt (Work in progress) 578 13 Acknowledgments 580 This work is the result of many discussions within the imap-ext 581 working group, and is based on the original VIEW draft. 583 14 Authors' Addresses 585 Cyrus Daboo 586 Cyrusoft International, Inc. 587 Suite 780, 5001 Baum Blvd. 588 Pittsburgh, PA 15213 USA 590 Email: daboo@cyrusoft.com 592 Chris Newman 593 Sun Microsystems 594 1050 Lakes Drive 595 West Covina, CA 91790 USA 597 Email: cnewman@iplanet.com