CA2451875A1 - System and method for improved client server communications of email messages - Google Patents

Abstract

A system and method for improved client and server communications, more particularly, an improved protocol that may be used for communication between a client and a server, such as in an email environment. Many features are provided for improved communications. An email server may provide the best message body available for an email message, may transfer an entire data abject if requested property or properties are not well defined within the data object, may provide progress data for use in tracking download progress, and may send error information for a data object having an error. Email changes may be optimized at an email server component, even if the email changes occurred at another email server component. An email server may maintain a table of changes that occur to folders at an associated data store, and may notify a subscribed email client component of changes that occur in the table.

Description

G Vrt9 ?210.59 SYSTElVI AND METHOD FOR IMPROVED CLIENT SERVER
COMMUNICATIONS OF EMAIL MESSAGES
REFERENCE TO RELATED APPLICATION
[000Ij This application claims the benefit ofU.S. application number 60/437,869, attorney docket nuinbei-?70635, filed January 3, 2003, entitled "SYSTEM ANL~ METHOD FOR
IMPROVED CLIENT SERVER CONIMCJNICATIONS," and incorporated herein by reference.
FIELD OF THE INVENTION
j004~] This invention pertains generally to computer networlcs, and more particularly, to methods for communicating between client and server applications such as email applications.
BACKGROUND OF THE INVENTION
[0003] Einail leas become an important method for can~tnunicating. Email systems typically include a server component (e.g., Microsoft Exchange Server') and a client component (e.g., Microsoft Outlook or Microsoti: Outlook Express). These eocnponents are typically software applications that are conf gored to execute on computing devices (e.
g.., servers, PCs, laptops, arid PDAs).
[0004) Oiten, in order to facilitate communications, a client and server, such as client eon~ponent and a server component of an en 'tail system, agree on a communications protocoh The pi°otocol sets octt the tattles defining the expected behavior of each poi°ty daring communications, for example, the expected sequence ofrequest and response.
Sophisticated protocols have ntles for handling unexpected behavior.
[0005] As client and server components axe improved, the unproved versions are distributed to end users. In order to take advantage of new component features and netwarlC
features, it is often the case that a new communications protocol is inveazted. Where the installed base of server components is significant, a client component may have the ability to COt11I1111n1Cate, via a set of pi°otocols, with selected previous versions of server components.
[000Gj It is sorrtetunes the case that later' protocols build upon earlier protocols rather than replacing them wlzoIesale. In such a case, a Iater protocol may be built of protocol elements which can be enabled or disabled in order to simulate earlier protocols.
Likewise, where the L. fart 1231 fJ.S~
installed base of client co111pOnentS i5 SIgiII~ICailt, a server component may have tile ability to communicate, via a protocol, with selected pr°evious versions of cliel7t COn7poileIltS.
[0007 The invention provides such a system and method. These and other advantages of the invention, as well as additional inventive features, will be apparent from the descr~iptioll of the invention provided heI°eitl.
SUMMARY (3F THE TNVENTI(?hI
[a0U8j 'The present il7vention provides a system and method for' itnptroved client arid 5eI'ver COlnr11r1171CatronS. IV10TE particularly, the rnvetltloit !S dlr'eCted to all iinprOVed prOtOCOI that May be used for cotnmut7ication between a client and a server. The invention has particular relevance to an enroll server environment, but the features descl°ibEd herein may be utilized in other client and server networks.
j0009J In accordance witfl otle aspect of the present invention, an e111ai1 client component may indicate to alt email server component that it is il7terested in receiving the best message body available for an enroll message. The email server component may receive a request for a message, the request llavutg all IIldlCatlon that a best message body of the ntail is desired. Tlle email server component may access a data store associated with tile enroll server compollent and determine Clle best message body of the message That is available independent of converting tile format of available message bodies, arid retrieve and return the best message body without converting the fot;;rlat of the besfi message body. As such, the processing time at the email server component is reduced, because a conversion of the elnail body does not occur at the email server component.
[UOIOJ In accordance with another aspect of the present invention, an email server colnponent may, upol7 a request for' a transfer of a particular property or~
set of properties (e.g., lleaders), transfer an entire data object iftl7e property or properties are not well defined within the data object. An email client catnponent generates a request for data objects ill a folder, the request including at7 indication tllat at least one property of the data olajects is desired, The email sel-ver component receives the request, and accesses tile folder and data objects in the folder For each data object ill the folder, if tile at least one property is well defined in the data object, the email server component retrieves and returns the at least one property for that data object to the email client contpotlent. If the at least 011e properTy is not well defined for the data object, the erliail server component retrieves and returlts tile data object to the email client cotnponent~

c r>>ir ~~~ns~
[fl011 ) I11 accordance with yet another aspect of the present invention, an elnaiI client GOn7p017e17t Illay farce all elllall SerVel' GOlI7ponent to supply all Emall IlleSSage in UniGOde. T11E
el71a11 client COI11p017E11t 5eI7dS a rEqueSt for at IeaSt otle en7ail n7ESSage and an indication chat tile entail client Co171po17e17t deSireS f01' elnail lneSSageS to I7e i11 UnlCOde format. Tlle err3ail SerVel' Gonlpallent, in response to receiving tl7e request and indication, retrieves the at least one message, and, for each ernail message, if the entail message is available in Unicode format, provides fille UlliGOde foI-nlat to the email client component. If tile email n7essage is not available in Ullicode fol7nat, the en7ail server component converts tile email message to Unicode fol-lnat al7d provides the Ullicode format to tile elnail client component.
[ao~aj In aCCOrdal7Ge Wltl1 5t111 anOthel' aspect Of the present lI1Ve31t10i7, a reqlleSt SeI7d by a17 e111ai1 clie3lt COIIIpOneI7t may indicate llo lin7it for the size of a lwesponse to tl7e request, allowing a17 emote Servel' COlnpOnent t0 fill a bLlffel", 1f Deeded. The elllall client: C0111pOtlellt Sends a plLlr'allty Of SLlbl'eqLleStS within a reqLleSt, 8aC11 Of tile SL1171"BqLIeStS
lEqLleStlIlg a31 Opel"atI013 c1t all emote server COinpOnent alld inC111diI1g size InfOrrllatioll. II1 reSpa1158 t0 eaCl1 SLlbl'eqLieSt, if the SIZe lnfOrnlat3o11 117C1ude5 a Slze 1131111 3nSide a 1'allge expeCtEd by flee e171a1I server component, tlleIl the entail SerVeI' C0111p017ent 111113tS a I"eSpOnSe t0 tile Slze 1i111it. If flee Slze lnfol'7natlOn includes a size IIIIIIt outside a range expected by tl7e emote server component, then flee emote seI'ver colllpanellt looks for a new size Iinlit in the size infornlatio3l.
The new size limit may be arbitrary, such as "fill the available buffer."
BRIEF DESCRIPTION OF THE DRAWINGS
[0()1.3j FIG. I is a scl7elnatic diag3°an1 of computers Gollnected by a network.
[0U14) FIG. 2 is a schematic diagram Illustratnlg an exemplary computer system usable to inlplelnellt an enlbodilnent of the invention.
j0IIi5) FIG 3 is a SchelnatlC diagram depicting all environment with lllultiple versions of both e111ai1 client components al7d elnail server Gompollents.
[0f116] FIG. 4 is a protocol diagram showing an example of a protocol Negotiation proaedLlre beriveell an emote client component and an elllail server component.
[0Q17] FIG. S is a scllelnatiG diagram showing an example emote network in wllieh emote client components and entail server components leave fixed size connnunication bLlffers [OOIBj FIG. GA is a protocol diagl°am showing an example protocol requiril7g two request-reSpOnSe CyGIeS tp COnIpIetE a fast transfer operatiozl.
[OOI9j FIG. GB is a protocol dia,glaln sllowing an example prol:oGOl requiring a single request-response cycle to complete a fast transfer operation.

j, ~~I~l ~ ~ ~ ~.~ ~
~l [0020] FIG. 7A is a flowchart depicting an, example procedure for sending an entail 121.essage lsody to an email client COlIlpailelit.
[0021 j FIG. ~B 1S a flOwChar't deplCting a pt"aCedtire fOr Selldillg an entail message body t0 an emall client component in accordance with au aspect of the present FrlVet2tt011., [0022] FIG.. 8A is a seduence diagram illustrating a full item transfer made.
[002.3] FIG_ $B is a sequence diagram illustrating a headers first transfer mode.
[0024] FIG. 8C: is a sequence diagram illustrating a header's only transfer mode.
[0025] FIG. 8D is a sequence diagram illustrating an exceptian to a headers First or a headers only transfer mode.
[0026] FIG- 9 is a schematic dtc~~l'atll Sl20Wli2g ail entail client Ca122pOllent'S Ilanle e122ai1 ser~ez' canlponent being cllanged aver ti121e.
[0027] FIG. 10 is a protocol diaguanl showing all example protocol for synchronizing email folders between an email client con2po12ent and an eil2ail server' component.
(0028] FIG. I lA is a flowchart depicting an example pi"ocedure for optimizing part of a stateblob.
[0029) FIG. I 1B is a flowchart depicting a pt°ocedi.ire for' optiil2izing part of a statebloh in accordance with the present invention.
[0030] FIG. 12 is a scl2eillatic diagram illustrating ail en tail folder hier'aI°chy.
[0031 j FIG 13 is a pi-otocot diagram showing an example pratocol for synchs°ot2izing and maintaiiling synchronization of an email message store in accordance with an aspect of tlZe presel2t invention.
[00.32] FIG. 14A is a protocol diagram sl2awing a12 example protocol for communicating ewor information at the ROP level.
[0033] FIG.. I~.B is a protocol diagram sl2awing an example protocol for commuclicating error infon2lation on a per message basis in accordance with an aspect of the present invention.
[00.34] FIG. 15A is a flowcilart depicting a procedure far generating error information at tile RGP level.
[0035] FIG. 15B is a flowchart depicting a procedure for generating error information on a per message basis in accordance with ail aspect of the present invention, [0036] FIG. 1GA is a protocol diagram showing an example proCocol for canying cut a fast transfer operation.
[00.37] FIG. I6B is a protocol diagram showil2g an exa122p1e protocol for providil2g pragzess information while earryin g out a fast transfer operatior2 in accordance with an aspect of tl2e present invention.
[00.38] FIG, I 7A is a flowcllai°t depicting a procedure for strean2ing out a set of n2essages, 1.1~A! 2? t U.5 [0039) FIG. 17B is a flowchart depicting a procedure for streaming out a set of messages along with progress inforznatian in accordazxe with an aspect of the present invention.
(0040) FIG. I S is a sclzen~zatic diagram of multiple email client components being noti fled as the result of a change to the same data object at an email server component.
[0041] FIG. I9A is a flowchart depicting a pr'ocedur'e far notifying multiple subscz-ibers,.
[0042] FIG. 19B is a ilawchart depicting a praeedu re for notifying multiple subscribers in accordance will? an aspect of the present invention..
(0043) FIG. Z0 is a flowchart depicting a proceduz°e far providing an ernaii message tltat uses a desired code page in accordance with an aspect of the present invention _ DETAILED DESCRIPTION OF THE INVENTION
(0044] Prior to proceeding with a description of the various embodiments oT'thc invention, a description of the computer and i18t1~V0r'ICrtl~ erlVrr"allnlent In w111C11 the Var'tatrs ernbOdlrl'lellt5 of the invention may be practiced will now be provided. Although it is not reQuired, the present invention may be implemented by programs that are executed by a computer.
Generally, programs include routines, objects, components, data stn.rctur~es and the like that pez°form particular tastes or implement particular abstract data types The term "program" as used herein may connote a single program module or multiple program modules acting in concert. The terns "computer" as used herein includes any device that electronically executes one or more prograrns, such as personal computers (PCs, hand-held devices, molts-processor systems, microprocessor-based progr°amrnable consumer electronics, network PCs, minicomputers, tablet PCs, mainfiame computers, consumer appliances having a micr°oprocessor or micracontroIler, routers, gateways, hubs and the like. The invention may also be employed in distributed computing enviranznents, where tasks are performed by remote processing devices that are linlted through a communications network.. in a distributed computing environznent, programs may be located in bath local and remote memory storage devices.
(0045) An example ofa networked envir~orunent in which the invention may be used will now be described with reference to FIG. I. The example network includes several computers communicating ~.vith one another over a network 1 I, represented by a cloud.
Network 11 may include many well-kztown components, such as ratzters, gateways, hubs, ete. and allows the computers 10 to communicate via wired and/or wireless media. When interacting with one another over the net~vorlc l I, one or move ofthe computers may act as clients, servers oz° peers with respect to other computers. Accordingly, the various embodiments of the zz7Ve1?tlOrl may L, I~NI ?? ! 0.59 G
be practiced all clients, servers, peel's a1° combinations tllel"eaf, Even though spECiIic examples contained Iler'Ein do naf refer to all of these types of'conlputers.
[0046] Referring to FIG. ?, an example aCa basic coll~guz~atioll foI° a computer an which all or parts oftllE invention described herein Inay be illplementEd 1S shown. In its mast basic configuration, the cornplltel° 10 typically includes at least one processing unit 14 alld memory 1G. The prOCESSiiI~ uillt I~ exeCLIteS iIlSt1'lICt10i1S t4 CaITy alit taSICS
111 aCCOr'danCe Wltll various e111bOdI1neIltS Of the I11VE11t1011. III CaIT'ylllg alit SLICK taSkS, tllE
praCESSIng unit 14 play traIlSllllt eleCtranlC 5lgnalS t0 OtllEi pal-is of tile COlnputer I~ arid l0 dEVICES
OlItSIde Of the Calllptlter ~ ~ t0 GaIISE 5allle i"ESIIIt DEpOrldln~ all the e:CaCt C()llfi~hrat1011 arid typE Of the computEr I0, the memory I G may be volatile (such as RAM), null-valaCilE (such as ROM or' flash Inenlol"y) aI-sonle canlbination of the two. Tllis most basic canf gur'ation is illustrated in FTG. 2 by dashed line I~. Additionally, tl7e eolnpllter may also havE additional features/functionality, For example, computer 10 may alSO lnClude addItlallal stora~E (reI110Vable ?0l andlor IIOII-renlovablE 202) Including, but not limited ta, magnEtlc or optical disks or tape. Computer storage media includes volatile and non-volatllE, removable and non-removable lnedla 1111p12I13EIlted 111 ally Inethod ar tecllnola~y for Stal°agE of 111fOnnatlan, lnCILldlng con"iputer-ExeCLltable 111StrL1Ct10nS, data structures, program modules, al" other data.
Computer storage media includes, but is Ilot limited ta, RAM, ROM, EEPROM, flash lnemary, CL7~ROM, digital versatile disk (DVD) or otllel" optical storage, magnetic cassettes, magnetic tapE, magnetic disk Storage al" atIlEI' lnaglletlC stol'°a~e deVICES, ar any atllel"
Inediunl Wllicll call be LISEd to stored tile desired information and which Can be aCCessed by the Calnputer 10. Ally SLIGh COlnpLlter' storage media play be paxt aCeomputer I0, [0047] Computer IO preferably also contains communications coilllectians 20S
that allow the device t0 CainmtlilICate Wlth at12E1' devices. A COnllnulllCatlOn CO11r1eCtlan 15 all example Of a COnImL111ICatlan nledlllnl.. CollllllulliCation lnEdia typlCally enlbady COn111LItBr I"eada131E
lnStr11Ct1a11S, data strLlctures, progl°aIn InodLIIes or other' data in a modulated data signal Such aS
a earl"ier wavE or other tt"alasporl Illecllan.isnl and includes any information delivery media. By way of example, arid not limitation, the tEnll "colnlnunication media"
includes wired media such as a wired network or dir'ec;t-wil°ed connection, and wirEIESS
I'lledia sllcll as acoustic, R.F, illfi-ared arid otllEr wireless media. Tile term "colllputer-readable medium"
as Used herein includes bath computer star'age media arid co111lllunieatioll media..
[0048] Computer IO may also havE input devices 204 SLich as a keyboard, house, pen, voice input device, touch input device, Etc, Output dEVices Z03 sLlcll as a display 20, speaker's, a printer, etc. play also be included. All these devices are well lu'lown irl the art arid need not be discussed at length here.

G Veil 2211159 [0049] Tfle 171"eSeIlt IIIVelatI011 IS directed t0 a 5ySteln and nletlaOd f01"
LInprOVed Cllellt alld server' connnunications, and more particulazly is directed to an improved protocol that lnay be used for eomlnunicatioil between a client and a server.. Tlle invention has particulal° relevance t0 all eillail serves- ellvlrOnlaaellt, but the featLires deSGr'll)ed herein nlay be utillZed in other client and server neW orlcs. ):''Or ease of description, llowevez', tile li1Ve11t10I1 IS described with reference to a clietlt/seiwer entail environment.
[0050] Tlae preseilt invention may be implemented in a clientlserver enVlrOtlllaeilt haVlIlg tlw0 or more versions of client applicatioils or conlpolaents, and/or two or' snore versioils of sower applications or components. To this enrl, FIG 3 illListrates a blocl~
diagraln sllowiilg IaaLl1t3p1E VEr'5iO11S Of both Cllelat and server COInpO11EI1tS Ira a netWOrIC
ellaail envil-ollment In general, the client alld server co3npotlents are configured so that they are baclcwardly compatible. That is, a client compone3lt is capable of co3nnlunicating with r°ecent and legacy versiolas of server components, alad vice versa. A set of protocols a3;~e established to coinmLlnicate between the multiple versions, The set ofpl°otocols iaaay constitute several differ~ellt protocols, each being self contaiiaed. Alternatively, a set of protocol components play be available, and particular components are used to configuz~e particular pl'OtOCOIS Wltlllil tile prOtOC01 Set.
[0051] Iii ally event, IIl the IIetWOi"lv elnail enVtrOlllllent S110Wia IIa F1G 3, a lalOSt reCeilt VerS10I1 elnall clielll component 303 COn1I21L1111GateS best With a inOSt reCellt version emaii Server COInpOIlent .30G LISIIIg a protocol 307. fIOWeVer, the lnOSt recent Emall server component 30G 1S
also capable of comlnLlnlcatnlg With selected previous versiola einail Cllellt collaponents, far exanaple, elnail client component 302 and elnail client eonlpoilent 301, rising other pratocois (e.g, protocols 30$ and 309 ill FIG. 3} ill a protocol set. Enaail client conaponetat 30.3 is also able to colnmLlnicate with selected previous version elnail server components, for example, email server colnponelat 305 and elnail server component 304, using protocols sucla as the protocols 310 and 311..
[005Z] Generally, as Llserl laerein, for the purposes of describing the protocol of the present invention, a "most recent" eiaaail {server or client) colnpanent, ol° a laaost recent version of an email {server or' clielat} component, is a server or client conlponellt that is aware of the new feature or features being described, and call utilize, implemeiat, and/or act on those features..
Altllougb tile terms are used tlar'OLL,,Plloilt this documeiat to describe clielat and server components that are aware of the various aspects of the protocol of the present invention, the terms also include components that ale aware of only the particular aspect being described, or inai°e tlaan one aspect beillg descl°ibed. L,ilcewise, a "previoLls" email component or previous version of all LYI~I ?.? I D 53 elnail component is a con ~ponent that IS IlOt aware of, and CaiTZ70t act upon the aspects of-the protocol of tl~e present lnVel2tlotl.
[0053] A protocol negotiation procedure is often used to establish a protocol betweelz a client and a server (e.g., the most recent version email server component 306 and the most recent version email client component .303) Although sz.lch protocol negotiations are Iu~owlz, a brief description of a 1~1°oCocol negotiation procedure between email client Component 401 (FIG.
4) and elmail server' C0111p011eI1t 402 {also FIG. 4) is provided for' the benefit of the reader. L'.arly in a communication session between email client component 401 and en Zail server component 402, email client cotnpanent 401 sends elmail server component 402 a message 403 tflat inclaldes client version inforn~lation, For example, in the for~ln of a client componelxt version stamp. Lmail server component 402 responds to message 40.3 with message 404 that in chides server Ve1S1011 lllfOrTilat1017, for exalmple, in tile fOrln Of a 5ervel"
COnlpOnent Ve1"SiC311 stat27p.
[0054] The client and server Version lnfOL'mati0I1 131ay be LlSed in a vat°iety ofways to attempt to establish communication bet~.veen the emaiI client component 401 and the email server componel~lt 402. For' example, verSlon IIIfOrInat101'i lnay be llsed to soled a suitable protocol for continreed COm111LU11Cat1011s, Or to deterlnille if ftlrther° Con2mt1111CationS al°e even posSrble. In establishing a protocol, VerSlon IIlfOrnlati011 Illay be Used to 811abIe a11dI0r disable specif c available protocol aspects oz- components, far example.
[DOSS] An emaiI server component may receive and process requests from mtlEtiple email client components in parallel. Wlxere a single cIiellt is shown, clnless explicitly stated otherwise, it is merely to simplify the figures and accompanying explanation.
[(?056] The email networl Of the pz'esent invention utilizes request and response exchanges to pass queries and data between client and server components in the netwol°lc, In prawtioe, the performance of a protocol tray be effected by the underlying conirnunications network transport mechanism used to izmplelnent communications between clients and servers in an elnait network, For example, in an email netwoxlc that uses remote proGedrlre calls {RPCs) as the underlying conmnunicatiolxs netwol°k transport mechanism, it may be lmuch more efficient to make a single remote procedure call of larger size (e.g., 32K.B) than to male several remote procedure calls of smaller size (e.g., 2IC.B). C)ne way krlowla to improve performance in such an email network is to buffer multiple requests andlor respol~ses for transmission in a single remote procedure call.
[0057] As an example, FIG.. 5 shows a request and response exchange behveen an email client component 501 and an elnail server component 502. 'The email client Golnponent 501 and the en-lail server colmponent 502 each have fixed sized communication buffers 503, 504, 505 and 50G. The buffers 503, 504, S05 and 50G are reserved areas ofnaemoly Far' temporal-ily C, t~R I 23 I (J.59 balding data. Entail client component SOI begllls a 1°~qli8st-resp~OnSe CyCh by filling buffer 50.3 with one or more sub-requests or remote operations (ROPs) beFore tl"ansn7lttlng the contents of the buffer 50.3 to buffer 504.
[0058) After being z~eceived in the buffer 504, each ROP is processed in oz°del~ by ernail sewer con ~zponent S02 and the corresponding result written to bvffez°
505. Lath ROP does produce some result. The result may include data requested by email client camponellt SOI, for example, a pazticular set of email messages. Lmail server oompoa~ent 502 monitors buffer 505 and Whell It is nearly full (e.g., Iess than BIB ren~zai~~ing), email server component 5O2 wl°ites ally unprocessed RC~Ps to the end of buffer 50S and transmits bEEffer 505 to buffer 506. Enxail client can ~zpanent 501 then begins a new z°equest-z°esponse cycle by wr'ltillg unpz-oeessed ROPs to buffer' 503 far resubmission to email server component S02 when buffer S03 becomes full again.
[~OS9) The size of a response is typically larger on average than the size of a request.. For this reason, the size of response buffers SOS and S06 are typically con Lgured to be larger than the size ofrequest bczffers 50:3 and 50~. Ill one enlbOdllllel7t of tile nlvet'itlan, the optimal size of the response buffers 505 and 506 was determined to be 96ICB for a size of 32K.B for reql.lest buffers 50.3 and 504, a ratio of 3 to 1.. In one embodiment, the email client component is capable of configuring the size of any of the buffers 503, 50~, 505 and 506.
[0U60) Some email networla that utilize buffers, for example floe elnail network slrawl~ in FIG. S, may employ a Fast transfer mode between an emaEl client component and an email sewer component. Fast transfer mode includes requests, such as ROPs, by a client that are divided into at least two kinds: requests that result in an initialization of a fast transfer data source at the sewer, and requests that result in the efficient transfer of data from tile fast transfer data source to tire client. The Fast transfer data source may be, for example, a database table. The fast transfer data source serves as a ready temporary store of data that enables later requests for the data to be serviced with less delay than would otherwise be possible.
Sometimes the second kind of fast transfer mode request seeks to achieve efficient transfer of data by explicitly specifying the size of the response, for example, the size of the response znay be set to the size of the entire client receive buffer less response overhead.
[006X) FIG. 6A shows a fast transfer operation having at Least two request-response cycles.
In a first request 601 a ROP {e.g., FXPrepare) initializes a fast transfer data source on server 502. At the server, Only FXPrepare 1S processed (i.e., the fast transfer data source is initialized) and its 1°esult is returned in a fiz°st response 602.. In a second request 603 a R.OP {e.g., FXGetBuffez°) requests the server to fill the buffer 505 from the fast data source. The servel°
empties the fast data source into the buffer, and returns the result in a second response 604. If ~r~Nr?~la.s~
the output buffer 505 for the ernail server component fills before the fast data source is emptied, additional FXGetBuffer R.~'JPs rnay be required.
[0052) FIG. GB shows a fast transfer operation lravirlg only a single request-response cycle.
In a f rst request G05, both FXPrepare and FXGetBuffer are processed by en Zail server component 502 and the restdts of botlt operations are returned in first response GOG. The result of FXPrepare is available to FXGetBuffer at email server Component SOZ because part of each buffer 503, 504, 505 and 506 is explicitly defined as a slaared data table. It is desirable to reduce the number ofrequest-response cycles because it a°esults in a more efficient transfer of data. A fast transfer operation having mare tlratl only a single request-response cycle may occur when buffer 505 is too full to hold the result of an FXGetBuffer RAP.
[00G.3] It will be appreciated that the ROPs of FIGS. GA and GB and like figures tl~rougl~taut this application are sclxematic in that they cnay be implernented in practice by a series of RC7Ps, unless specifically stated otherwise.
[0064] Typically, the size of a R4P result is different from the size of a RUP
r°equest. It is rat always possible to predict the size of a ROP result. When data compression techniques are used to reduce the size of a RAP result, it is even more difficult to predict the size of a RQP
result. Not being able to predict the size of a R4P result can prevent manual tuning of a protocol to minimize the runner of request-r°esponse cycles required to complete particular client operations, for example, to ensure that all new messages are downloaded to the client in a single request-response cycle. Manual tuning of a protocol includes manually con figuring the sequence and/or size of protocol requests, responses and/or ROPs.
[0065] In accordance with one aspect of the present invention, the number of request-response cycles is automatically minimized by specifying that Icey ROPs (e.g., FXGetBuffer) ar-e free from the requirement to predict the size of their result. Instead, such ROPs are processed by email server component 50.2 until the limit ofbttffer SOS (which is the same as buffer SOG) is c°eached.
[0066] As an example, in an environment that includes multiple versions of email server components, separate RUPs may be defined for previous version server components and reCeIlt Ver'StoIl Ser'Ver Con2poilentS., The reGerlt VerSlOnS ar'e free from the requirement to predict the size of their result. The characteristics for these RUPs are set forth in the following table:

Ll~~~f ~~~~.~~

R0P that may be used by a ROP that may be used by a protocol for protocol for communicating with communicating witlr most previous version servers recent version server's ROP ID 1 FXGetBuffer I rXGetBuffer-Parameters used in Re~c aired size: the size that Re~c aired size: is set to a multiple modes the settler must reserve in its valGte beyond tl~e tnaxinv~tn otttpu t buffer, expected by tire previous vorsian, for example, to a value ~-oater than .32I~B.
This sigtzals the server to lank for the new size Iimit parameter.
New parameters n/a Size limit: informs the server of the limit up to which the sower n-tay fill its output buffer.
[0067j The ROPs for previous version server components are similar in constmction to existing, prior art ROPs. That is, the ROPs predict and dictate a size in tile output buffer (e..g., send buffer 505) that mast be reserved far holding a response. In Contrast, the dictated size for the output buffer for a mast recent version of a server catnpanent is not predicted, but instead is set tn a value beyond the maximum expected by the previous version server components, far' example, to a value greater than 32I~.B. The fact that the size of the atttput buffer is defined beyond a value expected by the server component signals tile Server Catnpallel7t to look for a new size Iin~it paratneter, which n zay be, far exatnple, a filling of the output buffer for the server component. These characteristics automatically minimize the number of request-response cycles, with only a small increase in the complexity of an email server component that processes the ROPs [0068] Note that the order of parameters shown in the table above and in like tables throughout this application do Ilot necessarily correlate with the order that, for example, the parameters are transmitted over the network or stored i11 memory by either an email client L. I~A~l 3? I 0.5 J

component or an email selves component, unless accolllpanled by an explicit statement to the contrary.. Ill aCldltlall, 1IIICIIallged pal'a111eter'S tnay be alnltted far tile sake of clarity.
[OOd9j In all eznail network, one of the typical duties of a protocol is to achieve the transfer of data objects, faz example, email messages, between email client components and email server components. Further examples of such data objects include email folders which play contain email messages and other data objects, and folder associated information (FAI} data ableCtS whlCll Inay, far e'CaInpIe, contain I211es f01" l7rOCessIllg email 111esSageS, or define Ilow the data objects contained by a folder will be displayed.. Data objects play be opaque to an entail client colnpollent; that is, an elllail client component lnay have no means of interpreting the contents of the data object. Alternatively, data al~jects nlay be composed of named properties, for example, an entail message lnay eonlprise properties named "to," "fi°om,"
"SllbleCt," "ilnpOrtanCe," "body l," "body ~," "bOdy .~," "attaCllmellt I,"
"attaCllmellt ?," alld Sa on.
[0070) ONe advantage of entail Networks where data objects may be composed of llalned properties aver entail networks where data objects az°e opaque is the potential t0 lnlpr'OVe protocol perfonnallGe because of the ability of a protocol to transfer only part of a data object-Having named properties permits particular' piopertles of tile data object to be transnlitted without transmitting the entire data object.
[0071] For example, an elnail message play be composed of a set of Ileader properties and a set ofbody properties. The needs of an entail client component allay be such that a protocol may transfer the header properties first and then the body properties Iater as not at all. Tllis feature permits a user to view the header information for Bevel°al messages prior to the entirety of all the messages being downloaded. Using this feature, a more fine-grained control over bandwidth utilizatiall lnay be obtained by the client component, which may positively effect protocol performance.. In addition, a client component play use this feature to result in lower bandwidth utilization (for example, bodies may be downloaded for only selected headers), wllicll is particularly desilwable in law bandwidth ellVIr'onlnentS.
[0072) The per~fol~nance of the protocol does not alecessarily increase iftlle sezwer component is configured to send body and header properties in two separate request-response cycles (i.e., one each for the lleader~ and the body). For example, ifthe needs ofthe email client component wet°e sucli that it redzzired botll header and body properties at the same time, then the performance of the protocol lnigllt be decreased verses a situation where a single 1°equest-response cycle could retrieve bath the leader and the body Thus, the simple act of enabling data ab,jects to be composed of namsd properties is not itself enough to automatically result in improved protocol performance. Achieving illlpl°oved protocol performance does depelad on 1. I~NI 2? 10.59 the elloice of properties that may retake ttp a data ol?ject and how they may be used by a protocol. That choice nlay depend on a nttnlber of factors including the needs of most recent and previous version email client components, and tile heeds of111ost recent and previous VerstOI1 et11a11 SeI'v~I' Co111ponellts. 1~xan7pIGS Of elilall Glient COlnpflllent IleedB lnCltlde satisfying different levels of urgency for the display of different information and complying with preferences set by an email client conlpollent user.. Examples of e111a11 server component needs include efficient storage and retrieval ofdata and efficient processing of pr~atocol requests.
[0073] Conventional prior' art en tail e11Vi1"OIlIneOt's LltilIZe data objects that may be composed of named properties, for example, an email message that may include a header set and a body set o f' named propel°ties so tllat the hvo sets may be requested and/or processed separately. Another prior art exanlpIe is an etnail message where the body set of named properties includes multiple versions of the email message body, for example, in multiple email message formats such as plain text, hypertext mark-up language (HTML), rich text forrrlat {RTF) and so on_ In this situation, prior art email server components may respond to a protocol request For the body of the entail message in a Number of ways. ~T'lle lowest complexity response may be to selld all vea°sions of the email message body but this response may result in increased bandwidth utilization..
[0074] FIG 7A depicts part of a procedure that a pl°eviotls (prior art) version email server component does use to respond in this situation. In step 701, tile email server component examines the fbrlnat of each enlaii message body. If' one of tile forlZlats is a pI°edetennined standard format (e. g,, RTF), then the procedure moues to step 703 and the standard fnrlllat email message body is sent to the requesting email client component. If none of the formats is a predeterlnined standard format, then step 701 branclles to step 702 wllere one of the email message body versions is converted to the standard folnlat. The subprocedure depicted by FIG.
?A may also be used when there is only a single version of an emaii message body but the elnail message body may not be in a statldard format that is required by a protocol.
Ioa~rs] FIG. 7B depicts part ofa procedure used by a mast recent version email server component in accordance with the present inventioll. Ill step 704, a protocol request that results in this subprocedLtre being used by an email server component is examined for a BEST~BODY
flag. The flag in this example and the other' flags used herein are used to the email server' component that the entail client component is a most recent version and desires to implement tile function associated with the flag. Other indications may be used. For example, the function relay be implemented by default if a most recent entail client component is detected.

L J~hl ?? ! lJ.i9 I~
[0076] In ally event, if the BEST BODY flag is slot found, then step 704 bl°anclles to step 701, and continues as described with reference to FIG. 7A.
[0077] if the flag is found, the procedure moves to step 705, where tile best elnail message body is selected for sending to the requesting email client con lponent.. If there is only a single email message body associated with the requested entail message, then it is the best. If there are several email message bodies available, for example, with different formats, then the email server component chooses the best fl-om amodg them accorditrg to, for example, a predetehtnined ranking of email message body formats (e.g., RTF, HTML, plain text). The process tlletl proceeds to step 703, where the cllosen etnail dressage body is sent to tile et11a11 Client COnlpOllellt. ~11 t1115 elllbOdt111ent, tile elnall Client GOnlpOrie2lt play 1Je Capable Of displaying multiple email message body formats tlrEtS freeing fihe email server component from the requirelllent to convert elllail message bodies to a standard format. Ill addition, the email client component nlay convert the best email message body to a different format, if desired.
[0078] Because the emait server component is relieved of the task of catlver~ting email nlessage bodies, the present invention provides improved performance. In addition, a toast recent version email server component nray respond to protocol requests front a previous version entail client component witll only a moderate increase in complexity.
[0079] ROPs may be used to achieve the replica#ion of an elnail folder between an email server component and an etnail client component. A request to synchronize a folder may be made, for example, by a SyncllFalder ROP. Wllere an email client component is capable of displaying non-standard etnail message body fol-nlats, it play set the BEST,~BODY flag in the SynchFolder ROP to indicate that the email server component may select the best fornlat from among the available elnail lnessage bodies, rattler than reqlllrlilg the Server t0 retL1I11 all email nlessage body ill a standard format. An email server component play properly process ROPs both with and without the BEST BODY flag with only a dloderate increase ill complexity.
ROPs for communicating with previous version atld most recent version server's may include, for example, the charac#er~istics set out in the table below:
RUP that may be used by a RUP that may be used by a protocol for protocol for communicating witty communicating with most previous version servers recent version servers ROP XD ~ SynchFolder ~ SynchFolder L.NtLi Z?10.59 R4P tizat may be used by a ROP tlxat may 6e used by a prokocoI for protocol for communicating wvit6 communicating witlr most previous version servers recent version servers Ne~v parameters ! n/a ( BLST BfJDY fla>;: if'set, the entail server cozllponent cllaoses tire best email message body to send to tire entail client component.
(y'onversion ofche emaiI
message body to a predetermined stalldarrl fornlat is z1111ecessary.
j0080j FIGS. 8A-8C show sever-al different existing 111odes of tr~azlsferniilg a set of eznail messages behveezl all ernail server component and az1 email client component.
For each mode, each eznail message has nanled properties including a header set and a body set, and several email messages are cozltained in a falder~. FIG. 8A illustrates a full item transfer mode. The illustration shows a first eznail message ll.eadef° 801 being tz°ansfen°ed and then a first email message body 802 before a second emaiI message header 803 and then a second eznait message body 804 and so on until the set of eznail messages has been transferred. FIG, 8B illustrates a headers fzrst transfer mode. Iz1 this mode, a first email message header 80S
is transferred and tllen a second email message headel° 806 and so oI1 L2z1t11 all ille emaiI message lleader5 have beeF1 transfers-ed alld 011Iy t11e11 15 a flrSt elnall 111eSSage body 807 transfers°ed and then a seCOnd ezllail message body 808 azld so an until the set of email messages sloe been transferred. FIG..
8C illustrates a lleade2S only transfer mode. As the name suggests, only tile email message headers 809 are transferred in response to a request to transfer a set of email messages. E111aiI
message bodies 810 will only be transfezxed in response to all additional explicit request. In any of these modes, the transfer sequence pray be temporarily interrupted by a higller priority entail client coznpnnent request, far example, for a particular eznail message body.
[0081 j An elnail folder is an example of a target for a request to trazlsfer a set of email messages. however, an eznail folder nlay contain data objects other than email messages. As discussed above, transfer modes alwe often defzned with 1°eference to email message headers and ~ l'!1~~ ~ ~ ~ ~ ) ~
email message bodies, such as the headers first al7d headez°s only transfer i7lodes. In such transfer modes, an attempt to transfer data objects for which a header set of named properties and/or a body set of named propertres may not be well defined nay result in protocol failure.
One aspect of the invention avoids this situation by providing that data objects for which a header and/or body set of named properties is not well defined, rnay always be transferred in whole rather than in part. This embodiment rnay be illustrated by example with FIC. 8D In this example, tr°ansferal between an ernail server component and an email client component nay be occurring Irl a headez°s only node. Accordingly, a .first enrail message lzeadei° 811 is transfer'r'ed a~~d then data object 812 becomes a next candidate for transferal. The header set of naInEd l5rapertieS 1S llOt well defined for a data object 812, such as FAI, so the entire data abject is transfec~red. A next candidate far' transferal does have a well defined header set of named properties (i.e , the candidate data object does possess all the named properties explicitly defined by the email client component as belonging to the header set of named properties) and so only an ernail message header 81.3 is tr°ansfen°ed.
[0082] An example of one way to implement this aspect of the present invention is by using a flag, such as IGNORE_MODI~._ON FAI, tl2at may be included ha a synclr.roniration ROP, such as Syncl~'older ROP described above. Asp email server component n7ay properly process ROPs both witl3 and without a IGNt7RE~MODE ON~FAI flag with only a n raderate increase in complexity. ROPs n gay include the characteristics set out in the table below to achieve the replication ofan ernail folder between an emai! server component and an email client component:
ROP that may be ROP drat tray be used used by a by a protocol for protocol for Camtr711nlCatln~ COmm~IllC~tIIr~ Wltlr Wltli mast previous version reCent version serve:s servers ROP ID SyrrchFalder SynchFolder New patameters n la IGNORE MODE ON f'AI

flag: if set, then for data objects, such as FAI, that do not have a well defined set of header and/or body named propar~iies, the eEnail L.YA~1 ??l0.59 ROP that may be used by a ROP that may be used by a protocol for protocoi for communicating with communicating with most previous version servers recent version servers server GOInpotlellt nay respond to a transfer request with tile entire data ol?ject zegardless of the prevailing transfer mode.
[0p83] Ematl n~essa~es are typically addressed to one or snore en pail network users An email message tray be considered delivered if it is accepted by an email server component for storage. An email network may have seveF°al etnail server components.
Typically, an email network protocol has same strategy for limiting the number of email server components that an email network user must check for new messages. A common example is the hone server strategy which pt°ovides that et11at1 messages addressed to a particular ematl network user will only be accepted by one particular email server component, called the user's home server. In such a case, an email client component may be configured to consider only the home server when, for example, periodically checking for' new ewail messages or registering for ratification of new email messages.
[0084] FIG. 9 shows that even a simple home server strategy example may have complications. Tn the example illustrated by FIG. 9, a particular email server component 901 is first designated as the home server for a particular etnail network user'.
Over time, the designated borne server far' the user is changed to different email server components 90.3 arid 905, typically for' administrative reasons. The email server components 901, 90.3 and 905 may, for example, be physically different, or logically different, or be different versions. Email client component 902 tray communicate only with email server cotnponent 901 from titre To until time T,, then entail client component 904 may communicate only with etnail server component 90.3 until time Ti, and then email client component 90C may communicate only with email server component 905 The etnail client components 902, 904 and 906 may be the same or different. EmaiI server components 90I and 903 tray or may not exist after time Tz.
These complications are particularly relevant to etnail message store replication which is discussed next.

L.f~it1??10.59 [nU85J Email messages may be stored 6y an emaiI server component in an explicit entail message store which may, for example, be implemented usit7g well ln~owF1 database teclutologies. An etnail server component may have one or more such message stores. At3 email network user may have a hone message store. Changing home message stores may have the same effects as described for changing hon're servers.
[~U86J Some email network protocols include an ability to replicate parts of~an email message store to a storage facility local to an email client component, Repticatiot~ of parts of a remote email message store to a Iocal email storage Facility may inxpr~ove protocol performance and/or perceived protocol performance by, for example, replicating aII new email messages to the local ernail storage facility in advance of an explicit email network user i°eq4rest to view them. Such replication tray also pt°ovide additional etnail client component functionality, for example, enabling an etnaii network user to view an etnail n xessage during network connectivity interruptions.
[008'x] In an email tletworlc ellVtrOr~tllent, simple replication may quickly become inefficient. For example, if an email server component has one email message associated with a particular email network user and that message has already been replicated at the client component for the nettvork user, and a new entail message arxives for' that email network user, then it is still required that two email messages must be sent in response to a simple replication request. If atxother ne~v emaiI message arrives after replication of the two email messages, then it is still required that three email messages must now be sent in response to a simple replication request and so on. Some email t~etworlc protocols have provided far an incremental replication of etnail message stores to alleviate this problem. In an incremental replication, only changes to an email message store that occut~red after a previous successful incxemental replication must be sent in response to a replication request, for example, where the only change since the last successful incremental replication is the arrival of a new emaiI message, then only the new email message need be sent in response to an in crementai replication request.
[U088] FIG.. I O shows a more detailed example of a protocol that provides for incremental replication. Att email message store may be subdivided into email folders.
Each email folder may be replicated independently of the others, providing for a more fine-grained control over the replication process. In this example, the incremental replication process is tertned synchronization because it includes the propagation of changes fuotn email client component 501 to email server component 502 as well as tiom email server component 502 to email client component 501. Following a syrlChrOIltZattoll reqt.le5t I00I, a SynchFolder R.(.?P is processed by email server component 502. The RdP includes a folderlD parameter {not shown) and a stateblobo parameter. The folderlD parameter identifies an email folder that is the target of the 1. f~Ad 33l U.i 9 synchronization reduest 1001. Tlle stateblobn parameter contains inforlllation that allows email server component 502 to deter111D11e Wllat changes, if any, have acCEti"D'ed to tile emote folder SIllce it Was last synchD°onized. If i'BqueSt 1 Qtl1 rcpt"eSeIltS the fir'St eves" SynClli'onizatDOn I"C(lILCSt for tile target folder by elilall Client CaIIlpanent 50I, then elllail server component 502 determines if the target entail folder in the emaii lllessage seal°e has changed in comparison to all empty folder. In response 1002 to request 1001, entail server' canlponent 502 sends any changes to e111aiI client component SOI lncludnlg any elllail messages andlor atller data objects that have been added to tile target folder alld a list of any email messages and/or' other data objects tllat have been deleted fiwam the target folder. The entail server' component 502 also creates a tlew stateblobi relaresenting the state of the target folder as it will be an etnail client colllpallent 501 inllllediately following the syllclll'ollization once also selects that stateblobt ill response I002.. Wheel entail client component 501 sends the ilext syDlcllr'onization request I003 for the salve folder as in redllest 1001, then request 1003 will include as a parameter the same stateblobt that was returtled with response 1002. As before, email server conlpollent 502 will use the information contained ill stateblobt to detel-inine what changes, if any, have occul-r'ed iii the target folder and send tflose changes along with a tlewly created stateblob~ back to entail client conlpollent 50I in response 1004.
[0089] If a stateblob data object is large in size, it play advel°sely effect pl°otocol per fonnance because it is sent to and front an email server component with, for exaDllple, every email folder syllchranization request. In some entail Iletwol°Ic protocols that provide for elnail folder sytlcllronization, the statebIob may, in large part, be made lap of a set ofmessage cllangeID data objects that identify changes to entail messages that leave been well by an email client conlpollent. All errlail message change play be said to have been seen by an email client and/or server component whets the changed email Illessage is trallsferr~ed to that coixDponent.
[0090] Qne goal of a message challgelD data object play be to uniquely identify a change to an entail message in the context of all entil'°e email Iletwal°lc. Ill all emaii Iletwoi°lt that employs a bottle server strategy, a llser's home server lnay be responsible far associating a message cllangelD data object with a previously unseen elnail message change.
For example, a borne server play employ message cllangelD data objects comprising a serverID
data object and a serial nulnber~. A serverlD data object nlay uniquely identify an emaii server colrlpolleilt in tile context of all entire email network usitlg well known techniques such as globally unidue identifier's. Where such identifiers ar'e themselves large ill size, the serverTD data object tray instead be all index into an identifiel° lookup table maintained by tile email sez"ver component.
TIIe serial number play be provided by a counter', for example, six bytes in width, local to all L.~AI 3?l059 ~a elllail server conlponetlt, that is inere111ellted whenever the emaiI server Component accepts a previously 11175ee11 elllall message for storage.
[0091] For discussion puzposes, a message changelD data ol?ject play be represented by, fol°
example, "Si:l",vhele 'Si' repr.esents th.e serverID data object for a first email sel-ver conlpollent and '1' represents a serial dumber. A set ofn7essage changelD data OE~JeCts allay be represented by, for example, "5~:1, S(:7, St:3" Wllere "S~:l", "51:~" ai7d "5~:.3" al''e cOTISeCiItlVe message changelD data obJects employed by an email Sel"Ver' ColnpOtlent with Sei"Ver'rD S1 .
[009Z] Where a stateblob is lllade up, n1 large part, of a Set Of message changelD data OllJeCtS I"epreSClltill~ e111a1I IlleSSasC CIla11ge5 S2eI1 by at7 e171at1 Cllellt C(7n1~(?nCllt (a "Me55a~8 C'.I7a11~eS Seen" Set}, 50171e teCI1171qileS l7aVe been developed t0 enCOde the set In order to reduce its size, for example, the set "S ~ :1, S 1:2, S 1:3, S a :4" lnay be encoded as "S 1: l -4". In addition, an entail servel° C0171pOllent play ensure that the serial Numbers it uses are always increasing In that Case a nOIl-COI7tIgLlOtiS Message Changes Seen set, for example, "51:1, 5,:.3, SI:S, 5,:7", tllay be encoded as "51:1-7", that is, as a range including the millilllum and Illaxilnunl serial nun7bers, witl7otlt loss of fullctionality.
[009.3] III a scenario depicted by FIG. 9, a Message Chatlges Seen set may include message cllangelD data objects that were created by en tail server conlpotlents (e.g., S t, Sz} other than the current home sehver (e.g., S3}. A message cllangeID data object created by the cul-1°ent home sel~ver play be tenned a native lnessage cllangelD, a message charlgeID data object created by other elnail server' colllponents Inay be terllled a foreign message cllangelD. Email network protocols for GOtnil1t1I71CatEng with previous version email server components have not provided for tile optimization of non-contiguous foreign message changelD sequences as a range including the mininlutll and maxinxtlln serial ntllnbers on a per email server compol~ent basis.
The following table illustrates a benefit of including such optimization in an elnbodimellt of tile presentinvention:
Optimization used by a Optimization used by a previous version server most recent version server {current liome server S3) (current tome server S3) Message ~IIa~~CS Seen set 51:1, 51:.3, S1:5, 51:7 before optimization ~ 5~:1, 5~:.3, Sz:.~, 52:7 Sl; l, 53:.3, 53:5, 53:7 L, ~rYl ?3!0.i 9 Optimization used by a Optimization used by a previous version server most c°ecent version server (current home server S3) (GUrrent home servea° S3) lVlessage Ci~anges Seen set 5~:1, 5~:.3, 51:5, Si:7 5,:1-7 after optimization 5~:1, SZ:3, 5~:5, Sa:7 5~:1-7 S3:1-7 53:1-7 [0094) One embodiment of the present invention ruses R.(~Ps that include the clra!°actel°istics set oLlt in the table below to aclrieve tire synchronization of an enrail folder between all email server component aIld all entail client colnponelrt. AIr entail server colnpollent pray lnrplement tire InIpTOVed StatEb101? encoding teC111riC(L1G WItl1 Qlrly a nrOdel"ate increase in COnrple:Ylty.
ROP result teat ROP result drat may be may be used by a protocolused by a pIotocal when rvllen communicating rvitl~communicating with most pa-evious version recent version servers servers ROP ID ~ SynchFolder ~ SyIlcllFolder Unchanged parameters stateblob: optilrrization not stateblob: improved used in a new mode including non-contiguous optimization including non-sets of foreign message contiguous sets of foreign cllangelD data objects. message chalrgelD data objects, [0095] FIG. 11A and FIG 11B depict a difference between a subprocedure that lnay be used by a previous version server and a most recent version server, respectively, to respond to a SynchFolderROP. FIG. I 1A SlroWS Steps 1101, I 102 and I10.3. At step 1201, an initial Message Clranges Seen set is canstrLlcted. At step 1102, members of the Message Changes Seen set drat are native message clrangeID data oujects are optilni.zed_ At step 1 I03, the optimized Message Changes Seen set is addEd to tile stateblob data object that may be sent With a response to an elnail Client component drat reqLlested the synahronlzatlon.
FIG. 11B includes additional step 1104 wllicll shows members of tile Message Changes Seen set that are foreiglr L, tnl,13? J 0.59 '7 7 message changeIT~ data objects also being optimized before the lVlessa,ge Clean ges Seen set, now with improved optnllrzatron, is added to a stateblab data ol~jeGt in step [0096] While subdividing an entail message store into ernail .folders does provide for a mare fine-grained control over tile sylrcJxronizatioll process, it does not automatically provide far an improvement in protocol perforrllance and it may result in a degr°adatian in protocol perforn lance. Far example, sable protocols require that each message stol°e folder be synchronized separately. Each sylxhronizatian operation typically has Borne overhead and that overhead nlay be sr~211~1Ga17t. ~yI1C11ral1rzat10I1S Operatlan5 that utilize stateblab data objects are an example ofoperations that may have significant overhead. In tile Gase of syncllranizing an entire message stare, protocols that I°eqclir°e eaclx Inessage store folder to be syllGhronized separately rnay be at a drsadvantage conlpalwed to protocols that redr.lire fewer synclxronization alxeratiorls.
[OU97) SyIIGIII"OI112lI1g art eiltlr"e nleSSage stOI'e alld n7aintairlilig synChl"OnlzatlQI1 IS a desirable goal for an email client component. Conventional prior art enroll CIIeIlt components leave sought to achieve tills goal even when It resulted Irr slgnrfiGant advel°se impact all protocol performance. An aspect Of the present 111V811ti0I1 IS that it is able to millirnize adverse protocol irllpact while achieving dais goal by utilizing a deep hierarchy table.
CanventroIlal prior art entail server components have not been able to provide a deep hierarchy table.
[0098 Wllere elnail message stores are subdivided into email folders, tlxase email folder's may be organized into hierwarchies F1G 12 shaWS al'I e:Canlple Of all elnall folder lrier~archy. In FIG. 12, folder 1204 is a subfolder of folder 1203. Folder 1203 is, in turn, a subfoldel° of folder 1202. Folder 1201 is a root folder: A root folder r5 real a subfolder of any other folder. All other folders are members of the folder lxierarGlly rooted at folder 1201.
Typically, each folder rIl a folder llierarclly does riot leave direct reference to evel-y other folder. A folder may only have direct reference to its subfolder-s. A folder may also have direct r°eference to any folders of which it is a subfolden. 1a1 many cases, it Inay be that tile only folder for which every folder leas a direct reference is the root folder of the hierarchy.
[~099J A deep llierarclly table may captain information about every folder in a folder hierarchy. Each folder may leave a raw in tile deep Ixierarclly table. The information in the deep hierarGlly table is such tllat it may be used to determine if the coraterlts of an entail folder eras chap ged duI°ing a partiGUIar~ tune pcr~iod. The daternlination of change to all email folder during a particular time period lnay be inlplelnellted using a simple comparison of a copy of a folder's row taken at the begilrlling of the tirrle period, to a copy oftllat folder's raw taken at Che End of the time period. Ire one embodiment, each I"aW Of the deep Ixier~archy table irlclrldes the following attributes:

1. J~RI 331059 Attribute Name Attribute Notes Type Folder ID FID The FID type comprises a global unicll.Ie identifier (GUTD) and a six byte selial rlulnber. T121S Vallle Illay be i1&ed t0 Lllllt~LLely ldentlfy all eInall folder' 1I'1 the COrltext Of all elnall l7etwOl"1C.

PR LOCALYCOMMIT~TIME. MAX Timestanap This tirnestarnp is updated anytime the contents of the folder is modified.

PR DELETED~COUNT~TOTAL QWORD This value is a count of the total number of items ever deleted f"om the folder, (OIOOj Attributes of an email folder's row in a deep hierarchy table may be updated whenever' a change is made to the contents of a folder. For efficient implementation of a deep hierarchy table update, applicants have found that it is helpful to have CjLIIGIC al'Id dlr'eCt reference to the deep hierarchy table. At a minimlun, applicants leave found that there shoLlld be a shall and pI"edictable number of levels of indirection when trying to access the deep hierarchy table. >jol° example, positioning a deep hierarchy table at an arbitrary level in a folder l~lierarchy would not provide for a predictable number of levels of indirection. In one enlbOdIInent of the present invention, a deep hierarchy table may be associated with the root folder of an email network user°'s elnail message store folder hieral"chy for this reason.
(OI01] Communications between aI~ elnail client component and an email server component may be divided into communication sessions. Lass of email message store synchronization may occur between sessions, for example, during a network connectivity interrLlption. In order to re-establisl-L email message store synchronization at the beginning of a communications session, some protocols far colnn xunicating with pl°evious version email sel~-ver components employed a SynchFolder RCMP for' each folder in the folder hierarchy. Typically, the contents of some of the folders will not have changed betweelx sessions. A
SynchFolder L. t't1I ??! 0.59 ROP with an unchanged folder as its target results ila a "null synch."
Although a "null synch"
sloes not result in any folder changes being transferred to an email client component, it does still have an overhead associated with it, for example, a stateblob data abject, which may be significant.
[~102 FIG. 13 illustrates an embodiment of floe invention that avoids such "null sylich"
results lay utilizing a deep hierarchy table, In a first request 1301, email client component S0I
sends a RAP {e.g., GetHiel°archyTable) requesting a deep hierarchy table to email server component 507. In a first response 1302, a copy of the deep hierarchy table is provided to elnail client component 501. Typically, eznail client component 501 will have a previous copy of tltv deep hieral°chy table. Email client canaponent SOI may determine quicl~ly which folders in user's en jail message store on email server component 50? have changed by utilizing a row by raw companisan of the two copies. Next, RC7Ps {e..g., SynchFolder) are employed to syllchranize only those folders that have changed. Request 1303 and response 1.304 naay be repeated as necessary to Syl'kChi'aIllLe the Cl'lallged falder'S. Followil~rg successful synchs°onization, the email client canlpollellt'S Copy of the deep hierarchy table may Iae updated to match the Iatest copy that was sent in ~°esponse 1302. If email client component 501 does not have a previous copy of the deep hierarchy table, then all folders that lxave a row in the latest copy may be sylxhronized.
[UI03] Once syl~chronization of a riser's email message stol°e has been established, Sy11CI71Ot11Zatlan play be 111a113tallled by per7adlCally repeating the start af'sessian steps described above {i.e., polling the emaiI selwer component), but this scheme has disadvantages.
For example, the palling period may be much shorter than a period between changes to a user's elnail message store. In that case, relatively many of the deep hierarchy table comparisons will indicate that no folders have changed.. Such catnparisons al°e, in effect, wasted effort, so a protocol that can avoid them may be more efficient.
[QI0~1J Some ernail netwol-I<s include a facility for an emaiI Client component to subscribe to be notified by an eznail server component when, far example, the contents of a par~tictllar emaiI folder chal~lges, Some previous version email client components da use such a facility to maintain synchronization ofa user's email message stone by creating a separate subscription for change nvtificatians associated with each folder in a user's folder hierarclay In an embodiment of the present invention, an email client component may create only a single subscription far change notifications associated with the deep hierarchy table. A single subscription is more efficient because fewer RC?Ps al°e required to establish it and less server-side resources az°e consumed.

L.Vrt-f ??lO.iJ
[0105] With further- refer°ence to FIG. I 3, Wllen a InOSt recent version email client COITIl)OI7e11t 501, Ill aCC01"dal7Ce Wlth all aSpeCt Of the preSeIlt INVent1011, en1p10yS a Getl-Iieral°chy'hable ROP in a first reduest 1301 at tl~e begmnlng of a communications session with an email server component 50.2, the email client component SOI is automatically subscribed t0 Gl7ailge IlOtIfICatI011S assOClated with the deep hieral°chy table that is returned in response 1.302. Whell a Chal7ge OCCtlrs to an email foldel° in a user's email message store at the elnail client component, for' example, an email message is added to the folder, the deep hierarchy table is also updated as previously described. The change to the deep bier°archy table tl~ggcrs a notification alert 1305 to email client component 501. ~Nhile the notification alert is in r~espol~se to the subscription placed by request 1.301, it is not part of an explicit reduest-response cycle.. Thus, use of the notification system as provided by the present nlVentlotl results in much less overhead for the email network.
[0106] A SII7gle SLIbSCI"ipti011 Inay result IIl nlaily nOtiflCatlons. IIl One en1170d1Ine17t, the alert is delivered using a connectionless networl: transport mechanism, for' example, User Datagram Protocol/Internet Protocol (UDP/IP), but any suitable networ~Ic tI-ansport mechanism may be used In response to the alert, ernail client component SOT sends a reduest 1306 containing a ROP (e.g., GetNotihcation) to email server' component 502. In response I307, any changed rows of the deep hierarchy table (i.e., rows corresponding to a clanged folder that triggered the notification) are sort to email client component 501. Email client component 501 then employs ROPs (e.g.., SynchFolder) t0 SyIlClll"Oi712e OIIIy the folders that have changed.
(0107] Multiple email client components may be subscribed for change notifcations associated with the same data object (e.g., the same email folder), far' example, to pI°ovide collaborative fuIICtIOnality. As illustrated by hIC3. I$, email client components 1801, 1802 and 1803 are subsczibed for change notifccations associated with the same data object (not shown) located on email server component 1804. Email client component 1803 sends a ROP 1805 to emaii server component 180 that results in a change to the data abject, As a result of the change, elnail server component 1804 sends otlt change notifications 1806, 1807 and 1808 to email client components 1801, 1802 and 1803. Change Notifications may carry little il~Iformatian beyond identifying the data object that has changed so that, for example, there may be no way for an email client con-Iponent to determine that it was the cause of a particular change. If the data object is, for example, an elnail folder, change notiCleatiolts 1806, 1807 and 1808 may result in each email client component 180I, 1802 and 1803 initiating synchronization for' the changed folder. Since email client component 1803 was, in this exalnple, responsible for the change, the result will be a "null synch."

L. F'rYt ? 21059 ?6 [0108[ For reasons pl°eviously discussed it nlay be desirable to eliminate synchronizatians that reszlIt in a "null synch." Ilawever, the notification behavior described play not always be undesirable and snnle entail client components rnay depend zlpan it. Azl aspect of the present invelltion is to provide for tile ability of an emaiI
client componeilt to Conf gibe a notifleatioll behavior of lllOSt rCCeilt Vel"Slap elI2all SeI'Vel' C0111pa11e11tS ih Ol"del" t0 improve protocol performance while at tile salve dine providing previous version email client Ca111panelltS Witll Li2lChanged IlOtlflCatlall behavior.
[0109[ FIG. 19A depicts notification behavior that may be provided by previous version email sel-ver~ COmponelltS. FIG. I9B depicts configurable notification behavior in accordance with all aspect of tile present invention. If desired, a lllost recent email clieilt colnpanent play indicate to an email server component that it is capable of the notification bellavior in FIG.
198, for example by supplying a flag witll a request, izl the exanlpIe shown in hIG, 198, all IGNORE-OWN flag.
[07.10] At step I90I, the next candidate from the set of subscribers to be notiFed is selected. Ac step 1904, the subscriptioil is exanlined for the I(~NOR.E_OWN
flag. If the Flag is not present, step 1904 branches to step I90?, where a notification is sent to the candidate subscriber. If the flag is fouled, step 1904 branches to step I905, where the subscr~iptial2 is examined again to detertnille if tile subscriber triggered this notification.
This deternlillatiole lxzay be made, far example, by examining a conlmunications sessiazl identifier ("session IL7") of the session tllat was used to place tile subscription. A session III, for exalleple, play conlpl-ise a global unique identifier and a six byte serial number. The notification is also examined for the session ID associated witl2 its cause. If~the two match, tllen the Notification is suppressed. A
1°esult is that all email client CO111pOliGilt tllat caused a notification will riot also receive that notification. The subprocedure then proceeds to step I903, described below..
[0111 J If the subscriber did slot trigger the notification, tleen the session ID associated witll the subscription is vat the same as the session ID associated with the cause of tile notification, and step 1905 braclles to step 1902, wleere tile notificatioll is sent. Tile process then proceeds to step 1903, where a determination is made whetller there are more subscribers to be notified. If there are, tile sutlprocedure returlls to step 190I, othezwvise tlliS subpracedure is finished.
[0112) As stated above, an email client component utilizing cache storage of email messages play request, for example via a ROP, syncllranization of messages or other data objects between a Iacal client data store acid tile data store available at the entail server component. Tile email client component may similarly r'eqziest messages to be copied from the L, YrYI 2? 1 OJ 9 server store to the client store. I11 either event, the request may be made using a fast transfer Illode.
[0I I.3) Typically, when n'lessages Or' other data such as files are requested for synclll°onization or copying, the reqltest (e.g., ROP) 1I1G1LIdeS all IndlC;at1011 O~~all the n185SageS
fol" whiCl7 Sy11C17rO111Zatton 15 desired. This llSt Illay be SLItOtTlatlGally COIIStrLICted by a17 entail server' compotlent by, for example, lltilizillg the stateblob feature described above.. laor previous vet°sion (prior az~t) ernait server components, an error in one message or data object in a ROP request would cause a failure of all items in the request. This process is shown in FIG.. 14A, where a request containing a R.OP (e.g., FXPrepare) is transmitted at step 1441 with a rnessagelD set designated for copying ol° syllchranization. A fast transfer' nleclla111S1n is Set Llp at tile elTlall server COn2pollellt SQL, ai3d a fast transfer I~ I5 tl°a215mltted t0 the erTlall ClIetTt component SOl at step 140?. The email client componellt 501 then reqtlests copying or SynChr'OnIZatI011 Of the data pb,JeCtS thI'OUgh a reqLleSt COIltalnlllg, for example, an FXOetBuffer ROh (Step 14~.~~,. All error' oCCUt"S Wltll orle Or i110re Of~tll8 n7esSageS
oI' OtI7eC data objects when the email selvez° component 502 attempts to open the requested messages. Examples of errors include a message or a data object being corrupt, sel-ver failure, the email server component S0~ being out of memory, or a virus being detected fox' the data object.
jOl I4) After the error, tile elllaiI server component SO2 5e17ds a fatal ROIP
error in the data streamed to the entail client component SO1 at step 1404.. As such, tl7e synchronlzatton fails, the n-lessages within the messageIl) set are not syllcllronlzed or copied, and tile stateblob or similar update information is not received by the email client component 501. Tile elnail client component SOl then has to request the syllch.ronization or' copyillg of the data objects at another tune. It is possible tl'lat, if an error is not fixed at tile emaiI
server component SOZ, error messages zl'lay continue to be sent, and the messages within the r'nessagelh7 set may never be synchronized or copied.
[OIIS] In accordance with one aspect of the present invenfiion* instead of a fatal ROl' error, a most recent email server component tnay send error information regarding the particular data object (e.g., an elnail message) so that syncllronlzatzon for only that data object fails. This feature pern'lits messages or other data objects within a ROP
oz° otller request to be transn'litted and SyllClll"onlZed or' copied even if a message or other data object having an error' is included within the response.
f aI I6] As one example of how to handle an ol?ject-specific error, a Irlost recent email server component Inay send an error message ill a data stream for the data object having an object error In this example, fol° ease of reference, the error' is referred to as FXErrorinfo. If desired, as further' descl°ibed below, FXEzx'or'Info Inay itlclucJe infozn'latiorl suc;lr as the message c,ynr ~~m.s~

ID For the dicta Oh~eGt having the error, and add1t10rlal i.nforlnatioll regarding Wlly the message failed.
[0117) F1G.. f4B 5110~VS a SyllChi"a111Zat10n In WhlCh an erral' occurs in a message M3.
The error results in a FXGetBuffer 1°esponse 1405 including message M1, and message M2, followed by FXError~Info, and then Illessage Ma. Tlle FXErrorInfo i11fa1'lnation pernlits the email client C0111pal1ent SOl to know wllicll message had an error, and t0 SyI1C11.rOlllze all other IlleSSageS W1t11111 the 1°esponse. If tile error message FXEl~rorlnfo includes infa1~11aation about the reason For the error, the infol°nlation may be acted tlpoll accordingly by tile client co111ponent, For example, by displaying all error message to a user°.
[0118] The following table shows all example of the fol-lrlat that the FXErrorlllfo play tah.e:
FXErrorlnfo Attriblrte Name Attribute Type Notes Versiall WORD Tlle version of thlS StTliCtl.lre..

Ernor~ code DWORD

Message ID MTI3 The MID type C0111pE1Se5 d g1t717a1 U111C1L1e ldelltlfier (GUID) and a six byte serial nurnbel~. This is the massage 1D Of tht. 111eSSage tllat CatlSed the error.

.. . . . . Zero Or IIlOre attributes rrlay be added here.

Auxiliary Field ULONG The size of llle array Size to fallow.

Auxiliary Field BYTE array An unstnlctured array For' cornrnttnicating error details.

~,~~1~~.~~~ps~

[01 I9j As can be seen, the example format includes a version attribute, an error code, and a messagelD. In addition, if desired, one or attributes may be added.
FurtIzeF°, as stated above, an auxiliary field may be defined for con xn~unieating error details.
As such, an attribute may be defined for drctaUng the field size of the en -or details (e.g., an array), acrd a field may be provided, which may be, for example, an unstructured array far communicating the error details. As stated above, the en wor details may be handled as desired by the email client component 501.
[0120j The FXEn~orlnfo permits the synchronization of tile first response to be complete, for example resulting in a stateblob or other information being provided to ernail client component 501. Because the email client component is now synchronized through message M.~, the next request 1 ~Q~ fOr Sy11C11r017IZatlol7 play result in a response 1 X07 having the messages after IVI~ {e.g.., M; and MG).
[U121] To indicate that an email client component SOI is a most recent version, and thus is capable of handling tlFe FXEn~or°Infa message, a flag may be defined, for example, FXRecoverMode, that may be transmitted with a ROP requesting synchronization or copying, Other indications may be used for' the ernail client component 50 t to communicate to the email server component 502 that it is capable of handling the FXErr~orInfa message.
j0122] Wham the etnail server component 502 sends one or rrFOre messages or other data objects to the email client component 501, the data stream to the email client component may be separated or' defined by property tags (e.g., ptags). For example, a list of messages may include for each message a stark message ptag and an end message ptag. Between the start and end ptags may be a property list ptag and a subject ptag, which may have the property of a string. The subject ptag may be followed by the subject itself Others property tags may be included.
[0123) Izz the case where an error occurs in transmitting a message, the FXErrorlufo may be provided as a ptag, and may have binary properties, such as is defined by the table above. An example of a data stream follows having both a successful message and a message in which an error occurs. In the case wheF°e the error' occurs, the end message ptag is not used for that particular message and the ptag FXErrorInfo is the last ptag for that message.
ptagMessageListStart ptagMessageStart ptagPropList ptagSubject [PT STRxNG]
"Re: Xour email"

Lrri??rn.s~
ptagMessageEnd ptagMessageStart ptagF?~Ea;xorlnfo [PT BTNARY]
[Contents as described by table]
ptagMessageStart ptagMessageEnd ptagNiessageListCnd (0124] FIG. I SA shows steps that an en sail server component 502 naay utilize to transfer messages to a previous version email client carnponent 501.
BEglnrzrng at step 1 SO1, the message set is prepared, foiw example by placing the message set in tha fast transfer data store. At step 1502, the message begilZS streaming out, for example immediately after being placed in the send buffer of the email server coll~pallent 502. If an error occurs when streaming out the message, then a fatal RUl' ehrar is streamed out to the ernall client component SOI in step 1504. The subprocedure then ends.. Lf, when streaming the message, a~~
erxor does not occur, then at step 150.3 a determination is made whether- rrlore messages are in the sot. If so, the process loops back to step 1 SOZ, where the next message is streamed out.
If not, then the sl.lbprocedure ends.
[0125] FIG. 1513 shows a procedure for handling a message set by a mast recent Versloll of an email server- component 502. The steps taken are different dependrng upon whether the emaiI client colzlpanont is a most recent version or a previous version. Steps 1501-I504 are stops taken with a previous version email client component, and are the same as the steps Raving the same reference ntrn~er~als in the preceding paragraph.
[OIZbJ If, at step 1502, an error is found in streaming the message, then a deterz~~ination is made at step 1505 whether the request in eludes a flag, such as FXRecoverMode.. If the request contains the flag, then the email client aompol~zeczt 501 is a most recent version, and step z.r%nr 2?ro.s~

1505 branches to step 1506, where the FXErrorInfo is streamed out to the email client COInponeilt 501. Tlle pIOCe55 Illay tlleil GalltillLie to step 1503. If flee reqLIeSt dae5 Ilat I3lCliIde the flag, tllen step I 505 branches to step 1504, ~.vhere a fatal ROP
ere°or is streamed alit. Tlle subprocedure then ends.
[01 z7] As can be seen, the presence of the flag in the request permits tile streaillillg process to continue by allowing a streaming oLlt of the FXErroI°Info instead of failing and sending a fatal R.OP en'ar. The flag is sent by a most recent version ofan elllail client component 501. Previous versions of email client components do not include the flag, and thLis ail error' results in streaming oLlt a fatal ROP eI-r'or, as described above.
j0128] If desired, ill all alternative embodiment, flee erxor~ illessage (e.g., FXEw'orIilfo}
play be sent out for pal°ticular properties of a message or other data ob"ject, iilstead of folw an entire message, FoI'~ example, FXEr"rorInfo Inay be sent out for the body af~a message, or for an attacllnleilt to a message. Tlle email client component 501 play then syilcllronize oi° copy properties plat are successfully sent WIthoLrt ail en"or', and only tile properties leaving errors are not syilcllronized or copied.
[Ulz9] Sometimes, a message or other' data object may be of'sufficient size that it spoils multiple FXGetBuffer responses. To handle such messages, the email client component 501 inay include rollback logic so that it Inay dispose of any partially received message and then proceed to properly receive further messages after receiving an err'ar message.
[Q~.30] At dines, it may be desirable for all elnaii client component to be provided feedback. regardillg the progress of the copying or synchronization of data objects such as elllail messages.. IIl accordance with ogle aspect of tile present invention, a mast recent version of all email client Component 501 inay indicate that it is capable of handling progress modes, for example by sending a flag, sLICh as PROGRESSTMODE to ail entail server component 50?
when requesting synclnonization or copying of data objects. III response, a most recent version of an email server component 502 may send a variety of information along with messages, such as flee total size of all of the messages, the total number of messages, and total size of carte messages, or any one or combination of tllese.
[0131] For' example, as shown ill FIG: 1GA, for a pr°eviaus version eznail client component 501, ill response to a fast transfer request (1601 arid 1603) far a set of messages, the email client component 501 receives tile messages. In FIG. 1 GA, messages ar'e received in two responses 1604 and 1606.. IIl previous version email Client components 501 that use a fast transfer nlechanisln, a progress indication of the messages being streamed to the client was not provided.

L. YNI 22 ! 059 (01;3~J However, as shown in FIG. 1 GB, is a response 1 G07 to a request for a message set by the email client component, the entail server' component 502 lnay provide a total number of data objects to be transferred, and the total size of all data objects to be transferred. Tllis inforlllation is represented by "Pal(" in FIG. 1 GB, A nlosfi recent version of an email server component 502 may also sLlpply the size of eactl message, indicated by "P,, P~, P3, ..." in FIG.
1 GB. In addition, if desired, the information associated with each rrlessage and with tile entire group of the messages lnay 111Ghrde addltlanal Il7fOrEllatloil 1'egar'dIng Whetl3er eactl meSSage I8 FA.I Or' an aGtLlal enlall nleSSage. In Olle enlbOdnnellt, the infoz~lnatio(a represented by "Pa»" Ill FIG. 1 GB is always sent ill respallse to a fast tratlsfer request, even if zero data objects are transferred, ill order to simplify processing of the data stl°eam.
(OI3.3J All example of a fal-mat for the size and number of all data objects being tl-ansferred IS SIIOWIl 111 the following table.
IucrSyucProgressMode Attribute Name Attribute Type Notes Vet''S1a11 WORD Tlle version of this strLlcture.

{e.g., a 16 bit integer') GAssaGMsgs DWORD The number of FAI
data {e. g., a 32 bit abjects to be transferred.
integer) llTotalAssaGMsgSize QWORD The fatal size of all FAI data {e.g.., a G4 bit objects to be transferred.
integer) cNormalMsgs f.?WOR.D The nuzxllaer of elnail messages to be transferlwed..

IITotalNorlnaIMsgSizeQWOR.D The total size ofall eznail messages to be transferred.

[0134) As can be seen, separate attributes play be defined for tile number of FAI data objects, tile fatal size of all FAI data objects, tile nun lber of email messages to be transferred, and the total size of alI tile email messages to be transferred. Otller~
combinations and additional attr°ibutes may be added to the fbrnlat as desired.

L.lrRd ?? l D59 3.3 [013SJ The followiLig table shows a forrx~at For' the size atyd athel°
infannatian that may be supplied with each message.
IncrSyncProgressModeret-Msg Attribute Name Attribute Type Notes Message Size LONG The size of the next message.

FAI flag BOOL Indicates if the Next message I 5 )~ AL.

[0136) As can be seen, the format inclrldes the size of the next message and whether or not the next n-tessage is FAI.
[01.37] PIGS. 17A and 17B show steps far stI-eaming a message set in accordance with a previous version of the en Mail camporlents, and a mast recent version of the email components, respectively. The steps in FIG. i7A are similar to steps 1501-1503 in FIG. 15A.
For' FIG. 17B, the PROGRESS MODE flag has been sent, for example with a ROP, by a most recent en pail client component 50I. After the tnessage set is prepay°ed at step 1701, a deterlninatian is made whether the flag is pr°esertt. If so, then the progress data totals are sent in step 1702, and the process then proceeds to step 150'?, where the first message is streamed. If the flag is not present, then step I 701 bratoches directly to step 1502.
[0138] After the first message is streamed, the process proceeds to step 1703, where a determination is made if the flag is available. If so, tlaen step 170.3 branches to step 1704, where the per message progress data is streamed. The process then proceeds to step 1503, described earlier. If the flag is not available, step 1703 branches directly to step 150.3.
[01.39] An example of'the stream of data for a most recent server component sending data to a most recent client component tS 5et forth below. The stream ofdata is similar to the stream of data described above, but additionally includes ptags far progress totals data (ptagInerSyncPragressMode), which may have, for example, binary properties..
In addition, for each message, the per message progress data is supplied, far example, as ptagIncrSyncPI°ogressModePerMsg.
PtagIncrSyncProgressMode [PT BINARYI

l.l~Ad 2? I D.59 [Contents as described by table]
ptagMessageListStart PtagTncrSyncProgressMadePerMsg jPT~BINARY]
[Contents as described by table]
ptagMessageStart ptagPrapList ptagSubject [PT~STRING]
"Re: Yaur email"
ptagMessageEnd PtagTncrSyncPragressMadePerMsg [P7.~~BINARY]
[Contents as described by tabJ.e]
ptagMessageStart ptagMessageEnd PtagTncrSyncProgressModePerMsg [PT~BINARY]
[Cantents as described by table]
ptagMessageStart ptagMessageEnd ptagMessageListEnd [U140] In the example shown, the ptags including the progress totals data (ptaglncrSyncProgressMode) and the ptags for the message progress data (ptagTncrSyncProgressModePerMsg) ale located before the list of'Inessages, and before each message, respectively. However, the structure of the streaming of the data objects may be revised so that the pi°ogress data I~laay be included witl1i11 the 1T1e5sa~t~5 Or Wtthlll the message list It is further possible to revise the structure of tile streaming of the data objects in order to eliminate ptags delirrliting messages and/or message ljsts entirely.

1, IiNf ?? I 05 J
[0141) All emall client component receiving the progress data may utilize this data to detel-Imine the progress of synclaronizatiol~l or copying of data objects fron -1 the email server compol~ea~t, and Imay utilize the per message progress data to determine the progress of each individual message. This information may be helpful, for' example, in monitoring real time inforzmation about the pl°ogress of a synchronization.
[(?142] There are several different character sets that may be used for storing an elmail message or other data objects. FaI° example, ASCII is most commonly used for storing English language chal-acters. However', ASCII is not sufficient for' staking character's for ali Iangltages, because it is haserl upon 8-bit characters.. Tllus, ASCII code can be used for only 256 char°avters, Whlcl7 15 enOlrgh fok English but not enough for languages that have mol°e characters. Unicode, on the other hand, is a ellaracter set that uses 1G bits (two bytes) for each character, and therefore is able to include more characters tlran ASCII.
Ul~icode can have 65,536 character°s, and therefore can be used to encode allmosi all the lal~guages of the world, Unicode includes the ASCII character set within it.
[014.3] In genes°aI, pl°eVtOtlS Ver'S10I1S Of elmail cliel~.t GOmponeL3ts SO1 have a designated code page, or character set andlor language associated therewith. Fol°
example, a partlCUlar' ver51011 Of an e111a11 Cllellt GOmpOllent 5Q1 may have a Verrman Code page, and another version may have an ANSI code page. At times, it Imay be desirable for aIa email client component 501 to receive elmails in character sets other thal~ the designated code page. III
accordance with one aspect of the pkesel-It IIIVeIttI011, a most recent client COnIpOIleIlt lmay fOrCe aI1 elmail server C0ITIpOnetlt t0 provide all emalls II1 Unicode. Once the elnaiis are Iweceived by tlae ermail client component 50I, tile Unicode emails Inay be converted to the cliel~t's code page, or may altenmtively be maintained in Unicode format.
[0144] To indicate that an elmail client component 501 calls for emails to be pl°ovided in Unicode, the en-laii client component 501 may, for exalmple, pl°ovide a flag, such as FORCEUNICODE, to the elmail server component 502. The flag may be provided with a request, such as a I20P. If the email server component 502 is a most recent version, the email server component 502 can provide a Unicode version of the email, if available, or can convert email messages in other character sets to Unicode.
[0145] FIG. 20 shows steps for providing a particular' character set for a message in accordance with one aspect of the present invention Beginning at step 2001, the email server' COII7pOllent 502 retrieves a Imessage frOIm itS data store.. At step 2002, a determination is made whether the FORCEUNICODE flag is present. If not, then step 2002 branches to step .2003, wheke the en pail server component 502 provides the email message in the email client component's designated code page, converting if necessary ~.~ ~~~~i< >? ~ (7.5) [0I46] If the F4RCEUNICCDE flag is present, then step 2002 branches to step 2004, where a determination is made whether the message is stored as Unicode. If so, step 2004 branches to step 2005, where the message is provided to the en tail client component S01 in the Unicode character set. If the message is not stored in Unicode, then step 2004 branches to step 2006 where the Iatessage is converted to Unicade, and then the pt°ocess ContIIltteS to step 2005, where the message is provided to the entail client component in Unicode.
[017] All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set fot~th in its entirety herein.
(~148] The use of the terms "a" and "an" and "the" and sin ~ilar referents in the context of describing the invention (especially in the context ofthe following claims) are to be construed to coven botla Lhe singular and the plus°al, unless otherwise indicated herein or clearly contradicted by context. The tenns "comprising," "having," "incItlding," and "colataining" are to be constt~.ted as open-ended teens (i..e., meaning "including, but not limited to,") unless otherwise noted. Recitation of ranges of values herein are merely intended to serve as a shorthand method of refel~r~ing individually to each separate value falling within the range, unless othet~uise indicated herein, and each separate value is incorporated into the specification as if it were individually r°ecited herein. All t?letllodS
desor°ibed herein can be perFormed in any suitable order unless otherwise indicated herein or otherwise clear-Iy contradicted by context.
The use afany and all examples, or exemplary language (e.g., "such as") provided Ixereita, is intended merely to better illuminate the invention and does not pose a limitation on the scope of the invention unless otherwise claimed_ No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.
[0149] Preferred embodiments of this invention are described herein, including the best made known to the inventors for carrying out the invention. Variations of those preferred embodiments may becon3e apparent to those of ordinary skill in the art ttpan reading tJxe foregoing description. The inventors expect skilled artisans to employ such variations as appropriate, and the inventors intend for the invention to be practiced otherwise than as specifically described herein. Accordingly, this invention includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the invention unless otherwise indicated herein or otherwise clearly contradicted by context.

Claims

WHAT IS CLAIMED IS:
1. A computer-readable medium having computer-executable instructions, the instructions comprising:
receiving at an email server component a request for a message, the request comprising an indication that a best message body of the mail is desired;
accessing a data store associated with the email server component and determining the best message body of the message that is available independent of converting the format of available message bodies; and retrieving and returning the best message body without converting the format of the best message body.
2. The computer-readable medium of claim 1, wherein the request comprises a request for synchronization of a folder in which the message is located.
3. The computer-readable medium of claim 1, wherein the request comprises a request for a copy of email messages.
4. The computer-readable medium of claim 1, wherein the indication comprises a flag included with the request.
5. The computer-readable medium of claim 1, wherein determining comprises evaluating available message bodies in accordance with a ranking system.
6. A computer implemented method, comprising:
at an email client component, generating a request for a message, the request comprising an indication that a best message body of the mail is desired; and at an email server component:
in response to the request, accessing a data store associated with the email server component and determining the best message body of the message that is available independent of converting the format of available message bodies, and retrieving and returning the best message body to the email client component without converting the formate of the best message body.

7. The method of claim 6, wherein the request comprises a request for synchronization of a folder in which the message is located.
8. The method of claim 6, wherein the request comprises a request for a copy of email messages.
9. The method of claim 6, wherein the indication comprises a flag included with the request.
10. The method of claim 6, wherein determining comprises evaluating available message bodies in accordance with a ranking system.
11 A data packet embodied on a computer readable medium comprising:
a first data field including a request for an email message; and a second data field including an indication that a best message body of the email message is desired.
12. The data packet of claim 6, wherein the request comprises a request for synchronization of a folder in which the email message is located.
13. The data packet of claim 6, wherein the request comprises a request for a copy of email messages.
14. The data packet of claim 6, wherein the indication comprises a flag included with the request.
15. A data packet embodied on a computer readable medium comprising:
a first data field including a request for a plurality of email data objects;
and a second data field including an indication that at least one property of the email data objects is desired and that an email data object is to be returned if the at least one property is not well defined.
16. The data packet of claim 15, wherein the request comprises a request for synchronization of a folder in which the data objects are located.

17. The data packet of claim 15, wherein the request comprises a request for a copy of data objects.
18. The data packet of claim 15, wherein the indication comprises a flag included with the request, 19. The data packet of claim 15, wherein the at least one property comprises a header far a message.
The data packet of claim 15, wherein the data objects comprise email messages.
21. A computer implemented method, comprising, at an email client component, generating a request far email data objects in a folder, the request including an indication that at least one property of the email data objects is desired;
and at an email server component:
receiving the request, and accessing the folder and email data objects in the folder, and far each email data object in the folder:
if the at least one property is well defined in the email data object, retrieving and returning the at least one property for that data object to the email client component;
and if the at least one property is not well defined for the email data abject, retrieving and returning the data object to the email client component.
22. The method of claim 21, wherein the request comprises a request for synchronization of a folder in which the email data objects are located.
23. The method of claim 21, wherein the request comprises a request for a copy of email messages.
24. The method of claim 21, wherein the indication comprises a flag included with the request.

25. The method of claim 21, wherein the at least on.e property comprises a header for a message.
26. A computer-readable medium having computer-executable instructions, the instructions comprising:
receiving a request for data objects in a folder, the request including an indication that at least one property of the data objects is desired in response to the request and the indication, accessing the folder and data objects in the folder, and for each data object in the folder:
if the at least one property is well defined in the data object, retrieving and returning the at least one property for that data object to the email client component;
and if the at least one property is not well defined for the data object, retrieving and returning the data object to the email client component.
27. The computer-readable medium of claim 26, wherein the request comprises a request for synchronization of a folder in which the data objects are located.
28. The computer-readable medium of claim 26,wherein the request comprises a request for a copy of email messages.
29. The computer-readable medium of claim 26, wherein the indication comprises a flag included with the request.
30. The computer-readable medium of claim 26, wherein the at least one property comprises a header for a message 31. A data packet embodied on a computer readable medium comprising:
a first data field identifying an email client component a second data field including a request for at least one email message; and a third data held including an indication that the email client component desires for email messages to be in Unicode format.
32. The data packet of claim 31, wherein the indication comprises a flag included with the request.

33. The data packet of claim 31, wherein the request comprises a request for synchronization of a folder in which the email data objects are located.
34. The data packet of claim 31. wherein the request comprises a request for a copy of email messages.
35. A computer-readable medium having computer-executable instructions, the instructions comprising receiving, from an email component,a request for at least one email message and an indication that the email client component desires for entail messages to be in Unicode format;
in response to the request and indication, retrieving the at least one message; and for each email message:
if the email message is available in Unicode format, providing the Unicode format to the email client component; and if the email message is not available in Unicode format, converting the email message to Unicode format and providing the Unicode format to the email client component.
36. The computer-readable medium of claim .35, wherein the indication comprises a flag included with the request.
37. The computer-readable medium of claim 35, wherein the request comprises a request for synchronization of a folder in which the email data objects are located 38. The computer-readable medium of claim 35, wherein the request comprises a request for a copy of email messages.
39. A computer-implemented method, comprising:
sending, from an email client component, a request for at least one email message and an indication that the email client component desires for email messages to be in Unicode format;
at an email server Component, in response to receiving the request and indication, retrieving the at least one message; and for each email message:
if the email message is available in Unicode Format, providing the Unicode format to the entail client component; and if the email message is not available in Unicode format, converting the entail message to Unicode Format and providing the Unicode format to the email client component.
40. The method of claim 39, wherein the indication comprises a flag included with the request.
4l. The method Of claim 39, wherein the request comprises a request for synchronization of a folder in which the email data objects are located.
42. The method of claim 39, wherein the request comprises a request for a copy of email messages.