CN1522014A

CN1522014A - 关于电子邮件消息的改进的客户服务器通信的系统和方法

Info

Publication number: CN1522014A
Application number: CNA2003101245169A
Authority: CN
Inventors: Jr; J·R·沃伦; K·弗罗里奇; ��Ǯ��; R·A·利马钱德; N·A·伯尼拉; ��ŵά��; R·R·诺维特斯基; R·E·格雷; ά; A·哈特维尔; B·鲍尔; B·柯蒂斯
Original assignee: Microsoft Corp
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2003-01-03
Filing date: 2003-12-30
Publication date: 2004-08-18
Anticipated expiration: 2023-12-30
Also published as: JP4456877B2; CA2451875C; US7730150B2; MY141361A; AU2003262474A1; RU2342699C2; PL364134A1; AU2009238276B2; EP1435710B1; TW200422903A; EP1435710A2; AU2009238276A1; AU2009238277A1; BR0305965A; US20080126496A1; CA2936856A1; US20040133599A1; CN100435531C; KR101046016B1; AU2009238277B2

Abstract

一种关于改进的客户与服务器通信的系统和方法，更具体地说，一种可以被用于客户与服务器之间的通信的改进的协议(例如，在电子邮件环境中)。为改进的通信提供了许多特点。电子邮件服务器可以提供电子邮件消息所具备的最佳消息主体；如果在整个数据对象内没有明确定义所请求的一个或多个属性，则可以传送该数据对象；可以提供在跟踪下载进展的过程中所使用的进展数据；并且，可以为有错误的数据对象发送错误信息。可以在电子邮件服务器部件处优化电子邮件变化，即使在另一个电子邮件服务器部件处发生过这些电子邮件变化，也是如此。电子邮件服务器可以保存关联的数据暂存器处的文件夹所发生的变化的表格，并可以向预订的电子邮件客户部件通知该表格中所发生的变化。

Description

关于电子邮件消息的改进的客户服务器通信的系统和方法

相关申请的参考

本申请受益于2003年1月3日提交的标题为《关于改进的客户服务器通信的系统和方法》的美国申请(号码为60/437,869，代理人标签号为220635)，该美国申请被包括于此，用作参考。

技术领域

本发明一般涉及计算机网络，更具体地说，涉及用于在客户应用程序与服务器应用程序(例如，电子邮件应用程序)之间进行通信的方法。

背景技术

电子邮件已成为一种重要的通信方法。电子邮件系统通常包括服务器部件(例如，Microsoft Exchange Server)和客户部件(例如，Microsoft Outlook或Microsoft Outlook Express)。这些部件通常是被配置成在计算设备(例如，服务器、PCs、便携式计算机和PDA)上执行的软件应用程序。

为了促进通信，客户和服务器(例如，电子邮件系统的客户部件和服务器部件)经常就通信协议达成一致。该协议提出为通信期间每一方的预期行为进行定义的规则，例如请求和响应的预期次序。成熟、完善的协议具有用于处理意料之外的行为的规则。

随着客户部件和服务器部件的改进，为最终用户分发改进的版本。为了利用新的部件特点和网络特点，经常发明新的通信协议。在安装的服务器部件的基础很重要的情况下，客户部件可能能够经由一套协议与所选择的先前版本的服务器部件进行通信。

有时，较后的协议建立在较早的协议的基础上，而不是全部代替它们。在这种情况下，较后的协议可能由可以被启用或被禁止的协议元素构成，以便模拟较早的协议。同样，在安装的客户部件的基础很重要的情况下，服务器部件可能能够经由某个协议与所选择的先前版本的客户部件进行通信。

本发明提供了这样一种系统和方法。通过这里所提供的本发明的描述，本发明的这些和其他的优点以及额外的发明特点将会一目了然。

发明内容

本发明提供了一种关于改进的客户与服务器通信的系统和方法。更具体地说，本发明针对一种改进的协议，该协议可以被用于客户与服务器之间的通信。本发明与电子邮件服务器环境有特殊的关联，但是，这里所描述的各种特点可以被用于其他的客户网络和服务器网络中。

根据本发明的一个方面，电子邮件客户部件可以向电子邮件服务器部件指出：它有兴趣接收电子邮件消息所具备的最佳消息主体。该电子邮件服务器部件可以接收消息请求，该请求指示：需要该邮件的最佳消息主体。电子邮件服务器部件可以访问与该电子邮件服务器部件有关联的数据暂存器，确定可不依赖转换可用消息主体的格式的消息的最佳消息主体，并且，检索和返回该最佳消息主体，而无须转换该最佳消息主体的格式。照此，减少了电子邮件服务器部件处的处理时间，因为在电子邮件服务器部件处不会发生电子邮件主体的转换。

根据本发明的另一个方面，经关于某个或某套特殊属性(例如，头部)的传送请求，如果这个或这些属性在整个数据对象内没有被明确定义，则电子邮件服务器部件可以传送该数据对象。电子邮件客户部件生成关于文件夹中的数据对象的请求，该请求包括一个指示：需要这些数据对象的至少一个属性。电子邮件服务器部件接收该请求，并访问该文件夹和该文件夹中的数据对象。关于该文件夹中的每个数据对象，如果在该数据对象中明确定义这至少一个属性，则电子邮件服务器部件检索那个数据对象的这至少一个属性，并将其返回到电子邮件客户部件。如果没有为该数据对象明确定义这至少一个属性，则电子邮件服务器部件检索该数据对象，并将其返回到电子邮件客户部件。

根据本发明的另一个方面，电子邮件客户部件可能会强迫电子邮件服务器部件提供采用统一字符编码(Unicode)的电子邮件消息。电子邮件客户部件发送关于至少一个电子邮件消息的请求以及一个指示，该指示指出：电子邮件客户部件希望电子邮件消息采用统一字符编码格式。电子邮件服务器部件响应于该请求和指示的接收，来检索这至少一个消息；并且，关于每个电子邮件消息，如果该电子邮件消息可采用统一字符编码格式，则电子邮件服务器部件将该统一字符编码格式提供给电子邮件客户部件。如果该电子邮件消息没有采用统一字符编码格式，则电子邮件服务器部件将该电子邮件消息转换成统一字符编码格式，并将该统一字符编码格式提供给电子邮件客户部件。

根据本发明的另一个方面，由电子邮件客户部件发送的请求可能没有指出对该请求的响应的尺寸限制，从而如果需要的话，可允许电子邮件服务器部件填充缓冲器。该电子邮件客户部件发送请求内的多个子请求(subrequests)，这每个子请求要求在电子邮件服务器部件处进行操作并包括尺寸信息。响应于每个子请求，如果该尺寸信息包括该电子邮件服务器部件所预期的范围以内的尺寸限制，那么，该电子邮件服务器部件限制对该尺寸限制的响应。如果该尺寸信息包括该电子邮件服务器部件所预期的范围以外的尺寸限制，那么，该电子邮件服务器部件在该尺寸信息中寻找新的尺寸限制。这个新的尺寸限制可能是任意的(例如，“填充可用缓冲器”)。

附图说明

图1是由网络连接的计算机的示意图。

图2是展示被用于执行本发明的实施例的示范计算机系统的示意图。

图3是示意图，描绘了具有电子邮件客户部件和电子邮件服务器部件的多种版本的环境。

图4是协议图表，表现了电子邮件客户部件与电子邮件服务器部件之间的协议谈判程序的一个例子。

图5是示意图，表现了范例电子邮件网络，在该范例电子邮件网络中，电子邮件客户部件和电子邮件服务器部件具有尺寸固定的通信缓冲器。

图6A是协议图表，表现了要求两个请求-响应周期完成快速传送操作的范例协议。

图6B是协议图表，表现了要求单一请求-响应周期完成快速传送操作的范例协议。

图7A是流程图，描绘了用于将电子邮件消息主体发送到电子邮件客户部件的范例程序。

图7B是流程图，描绘了用于根据本发明的一个方面将电子邮件消息主体发送到电子邮件客户部件的程序。

图8A是展示完全项目传送模式的程序表。

图8B是展示头部首先传送模式的程序表。

图8C是展示头部唯一传送模式的程序表。

图8D是展示头部首先传送模式或头部唯一传送模式之例外的程序表。

图9是示意图，表现了正在随时间的推移而改变的电子邮件客户部件的家庭电子邮件服务器部件。

图10是协议图表，表现了用于使电子邮件客户部件与电子邮件服务器部件之间的各个电子邮件文件夹同步的范例协议。

图11A是流程图，描绘了用于优化状态点(stateblob)的一部分的范例程序。

图11B是流程图，描绘了用于根据本发明来优化状态点的一部分的程序。

图12是展示电子邮件文件夹层级的示意图。

图13是协议图表，表现了用于根据本发明的一个方面来使电子邮件消息存储同步并保持这种同步的范例协议。

图14A是协议图表，表现了用于在ROP层次传达错误信息的范例协议。

图14B是协议图表，表现了用于根据本发明的一个方面在每一消息的基础上传达错误信息的范例协议。

图15A是流程图，描绘了用于在ROP层次生成错误信息的程序。

图15B是流程图，描绘了用于根据本发明的一个方面在每一消息的基础上生成错误信息的程序。

图16A是协议图表，表现了用于执行快速传送操作的范例协议。

图16B是协议图表，表现了根据本发明的一个方面在执行快速传送操作的同时提供进展信息的范例协议。

图17A是流程图，描绘了用于流出一组消息的程序。

图17B是流程图，描绘了用于根据本发明的一个方面与进展信息一起流出一组消息的程序。

图18是多个电子邮件客户部件的示意图，由于电子邮件服务器部件处的相同的数据对象的变化，正在通知这多个电子邮件客户部件。

图19A是流程图，描绘了用于通知多个订户的程序。

图19B是流程图，描绘了用于根据本发明的一个方面来通知多个订户的程序。

图20是流程图，描绘了用于根据本发明的一个方面来提供使用所需代码页的电子邮件消息的程序。

具体实施方式

在继续描述本发明的各个实施例之前，现在将对本发明的各个实施例可以在其中得到实践的计算机和联网环境进行描述。虽然未作要求，但是，本发明可以由计算机所执行的程序来加以实施。通常，程序包括执行特殊任务或实施特殊的抽象数据类型的例行程序、对象、部件、数据结构和类似物。如这里所使用的术语“程序”可以意味着一致行动的单一程序模块或多个程序模块。如这里所使用的术语“计算机”包括用电子学方法执行一个或多个程序的任何设备(例如，个人计算机(PCs)、手持设备、多处理器系统、基于微处理器的可编程消费电子设备、网络PCs、小型计算机、写字板PCs、大型计算机、具有微处理器或微控制器、路由器、网关、网络集线器和类似物的消费器具)。本发明也可以被用于分布式计算环境中，在这些环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序可以位于本地记忆存储设备和远程记忆存储设备中。

现在，将参照图1来描述其中可以使用本发明的联网环境的一个例子。该范例网络包括在网络11(由云代表)上彼此进行通信的几台计算机10。网络11可以包括许多众所周知的部件(例如，路由器、网关、网络集线器等)，并且允许计算机10经由有线和/或无线媒体来进行通信。当在网络11上彼此相互作用时，这些计算机中的一台或多台计算机可以作为与其他计算机有关的客户、服务器或同等设备。相应地，即使这里所包含的特殊例子没有提及所有这些类型的计算机，本发明的各个实施例也可以在客户、服务器、同等设备或其组合上得到实践。

参照图2，示出一种计算机的基本配置的一个例子，这里所描述的全部或部分的本发明可以在该计算机上被加以执行。在其最基本的配置中，计算机10通常包括至少一个处理单元14和存储器16。根据本发明的各个实施例，处理单元14执行指令，以完成任务。在执行这类任务的过程中，处理单元14可以将电子信号传输到计算机10的其他部分，并将电子信号传输到计算机10以外的设备，从而产生某种结果。根据计算机10的确切的配置和类型，存储器16可能是易失的(例如，RAM)、非易失的(例如，ROM或快闪存储器)或这两者的某种组合。图2中用虚线18展示了这种最基本的配置。此外，该计算机也可以具有额外的特点/功能性。例如，计算机10也可以包括额外的存储器(可移动的201和不可移动的202)，该额外的存储器包括(但不局限于)磁盘或光盘或磁带。计算机存储介质包括用关于信息(包括计算机可执行指令、数据结构、程序模块或其他数据)存储的任何方法或技术来加以执行的易失和非易失的可移动和不可移动的介质。计算机存储介质包括(但不局限于)RAM、ROM、EEPROM快闪存储器、CD-ROM、数字通用磁盘(DVD)或其他光学存储器、盒式磁带、磁带、磁盘存储器或其他磁性存储设备、或可以被用来存储所需信息并可以由计算机10进行存取的其他任何介质。任何这样的计算机存储介质都可以成为计算机10的一部分。

计算机10最好也包含允许该设备与其他设备进行通信的通信连接205。通信连接是通信介质的一个例子。通信介质通常具体表现计算机可读指令、数据结构、程序模块或调制数据信号(例如，载波或其他传送机制)中的其他数据，并且包括任何信息传递介质。举例来讲(不作限制)，术语“通信介质”包括有线介质(例如，有线网络或直线连接)和无线介质(例如，声音、RF、红外线和其他无线介质)。如这里所使用的术语“计算机可读介质”包括计算机存储介质和通信介质。

计算机10也可以具有输入设备204(例如，键盘、鼠标、笔、语音输入设备、接触式输入设备等)。也可以包括输出设备203(例如，显示器20、扬声器、打印机等)。所有这些设备在该技术领域中众所周知，不需要在这里详细讨论。

本发明针对一种关于改进的客户与服务器通信的系统和方法，更具体地说，是针对一种可以被用于客户与服务器之间的通信的改进的协议。本发明与电子邮件服务器环境有特殊的关联，但是，这里所描述的各种特点可以被用于其他的客户网络和服务器网络中。但是，为方便描述，可参照客户/服务器电子邮件环境来描述本发明。

可以在具有两个或多个版本的客户应用程序或部件以及/或者两个或多个版本的服务器应用程序或部件的客户/服务器环境中执行本发明。为了达到这个目的，图3展示了表现网络电子邮件环境中的客户部件和服务器部件的多个版本的框图。一般而言，对该客户部件和服务器部件进行配置，以便它们向后兼容。也就是说，客户部件能够与新近版本和传统版本的服务器部件进行通信，反之亦然。建立一套协议，以便在这多个版本之间进行通信。这套协议可以组成几个不同的协议，每个协议是自含式的。作为选择，可以具备一套协议部件，并且，使用特殊部件，在该协议集内配置特殊协议。

无论如何，在图3所示的网络电子邮件环境中，最新近版本电子邮件客户部件303使用协议307与最新近版本电子邮件服务器部件306进行最佳通信。但是，最新近的电子邮件服务器部件306也能够使用协议集中的其他协议(例如，图3中的协议308和309)与所选择的先前版本电子邮件客户部件(例如，电子邮件客户部件302和电子邮件客户部件301)进行通信。电子邮件客户部件303也能够使用诸如协议310和311的协议与所选择的先前版本电子邮件服务器部件(例如，电子邮件服务器部件305和电子邮件服务器部件304)进行通信。

通常，如这里所使用的，出于描述本发明的协议的目的，“最新近”的电子邮件(服务器或客户)部件或电子邮件(服务器或客户)部件的最新近版本是了解正在被描述的一个或多个新特点的服务器或客户部件，并且可以利用、执行并/或作用于那些特点。虽然在这整个文档中使用这些术语来描述了解本发明的协议的各个方面的客户部件和服务器部件，但是，这些术语也包括只了解正在被描述的特殊方面的部件，或包括了解多于正在被描述的一个方面的部件。同样，“先前”的电子邮件部件或电子邮件部件的先前版本是不了解并且无法作用于本发明的协议的各个方面的一种部件。

经常使用协议谈判程序，在客户与服务器(例如，最新近版本电子邮件服务器部件306与最新近版本电子邮件客户部件303)之间建立协议。虽然这类协议谈判已知，但是，为了读者的利益，简要描述了电子邮件客户部件401(图4)与电子邮件服务器部件402(也是图4)之间的协议谈判程序。早在电子邮件客户部件401与电子邮件服务器部件402之间的通信对话期间，电子邮件客户部件401将消息403发送到电子邮件服务器部件402，消息403包括(例如)采取客户部件版本特征形式的客户版本信息。电子邮件服务器部件402利用消息404来对消息403作出响应，消息404包括(例如)采取服务器部件版本特征形式的服务器版本信息。

可以用各种方法使用该客户和服务器版本信息，以尝试在电子邮件客户部件401与电子邮件服务器部件402之间建立通信。例如，可以使用版本信息来为继续的通信选择合适的协议，或者用于确定是否可以有进一步的通信。例如，在建立协议的过程中，可以使用版本信息来启用和/或禁止使用特殊的可用协议方面或部件。

电子邮件服务器部件可以并行地接收并处理来自多个电子邮件客户部件的请求。在示出单一客户的情况下，除非另有明确的规定，否则，将只对这些附图和附随的解释进行简化。

本发明的电子邮件网络利用请求和响应交换，在该网络中的客户部件与服务器部件之间传递询问和数据。在实践中，可以通过被用来执行电子邮件网络中的客户与服务器之间的通信的基础通信网络传送机制，来实现协议的性能。例如，在将远程程序调用(RPCs)用作基础通信网络传送机制的电子邮件网络中，与执行较小数量(例如，2KB)的几个远程程序调用相比，执行较大数量(例如，32KB)的单一远程程序调用可能会有效率得多。已知的一种改进这种电子邮件网络中的性能的方法是：缓冲在单一远程程序调用中传输的多个请求和/或响应。

举例而言，图5表现了电子邮件客户部件501与电子邮件服务器部件502之间的请求和响应交换。电子邮件客户部件501和电子邮件服务器部件502都具有尺寸固定的通信缓冲器503、504、505和506。为缓冲器503、504、505和506保留存储区，用于临时保存数据。通过在将缓冲器503的内容传输到缓冲器504之前用一项或多项子请求或远程操作(ROPs)来填充缓冲器503，电子邮件客户部件501开始请求-响应周期。

在每个ROP在缓冲器504中被接收之后，每个ROP由电子邮件服务器部件502按秩序进行处理，并且，对应的结果被写入缓冲器505。每个ROP产生某种结果。该结果可以包括电子邮件客户部件501所请求的数据(例如，一组特殊的电子邮件消息)。电子邮件服务器部件502对缓冲器505进行监控，并且，当它几乎充满时(例如，剩余不到8KB)，电子邮件服务器部件502将任何未被加工的ROPs写入缓冲器505的末端，并将缓冲器505传输到缓冲器506。然后，通过将未被加工的ROPs写入缓冲器503，以便当缓冲器503再次充满时重新提交给电子邮件服务器部件502，电子邮件客户部件501开始新的请求-响应周期。

响应的尺寸平均起来通常大于请求的尺寸。因此，通常将响应缓冲器505和506的尺寸配置成大于请求缓冲器503和504的尺寸。在本发明的一个实施例中，由于请求缓冲器503和504的尺寸是32KB，因此，响应缓冲器505的最佳尺寸曾被确定为96KB，比率是3∶1。在一个实施例中，电子邮件客户部件能够配置缓冲器503、504、505和506中的任何缓冲器的尺寸。

利用缓冲器的一些电子邮件网络(例如，图5中所示的电子邮件网络)可以使用电子邮件客户部件与电子邮件服务器部件之间的快速传送模式。快速传送模式包括客户提出的请求(例如，ROPs)，这些请求被至少分成两类：导致对服务器处的快速传送数据源进行初始化的请求，以及导致将数据从该快速传送数据源有效率地传送给客户的请求。例如，该快速传送数据源可能是数据库表格。该快速传送数据源用作现成的数据暂存器，它可使关于该数据的以后的请求能够获得较少延迟的服务。有时，第二种快速传送模式请求寻求通过明确地规定响应的尺寸(例如，可以将响应的尺寸设置为整个客户接收缓冲器的尺寸减去响应管理费用)来实现有效率的数据传送。

图6A表现了至少具有两个请求-响应周期的快速传送操作。在第一请求601中，ROP(例如，FXPrepare)对服务器502上的快速传送数据源进行初始化。在该服务器处，只处理FXPrepare(即，对该快速传送数据源进行初始化)，并且在第一响应602中返回其结果。在第二请求603中，ROP(例如，FXGetBuffer)要求服务器从该快速数据源那里填充缓冲器505。该服务器将该快速数据源清空，全部放入该缓冲器中，并且在第二响应604中返回该结果。如果在清空该快速数据源之前，电子邮件服务器部件的输出缓冲器505充满，那么，可以请求额外的FXGetBuffer ROPs。

图6B表现了只具有单一请求-响应周期的快速传送操作。在第一请求605中，FXPrepare和FXGetBuffer由电子邮件服务器部件502来进行处理，并且，两项操作的结果在第一响应606中被返回。电子邮件服务器部件502处的FXGetBuffer具有FXPrepare的结果，因为每个缓冲器503、504、505和506的一部分都被明确地定义为共享数据表格。需要减少请求-响应周期的数量，因为这样可以更有效率地传送数据。当缓冲器505太满而无法保存FXGetBufferROP的结果时，可能会发生不只具有单一请求-响应周期的快速传送操作。

将会理解，图6A和6B以及整个本申请中的类似附图中的ROPs是示意性的，这体现在：除非另有特别规定，它们实际上可以由一系列ROPs来执行。

通常，ROP结果的尺寸不同于ROP请求的尺寸。并非总是可以预测ROP结果的尺寸。当使用数据压缩技术来减少ROP结果的尺寸时，要预测ROP结果的尺寸甚至会更困难。若无法预测ROP结果的尺寸，则可以防止手工调整协议，以便将完成特定客户操作所需要的请求-响应周期数量减到最少，从而(例如)确保在单一请求-响应周期内将所有新的消息下载给客户。手工调整协议包括：手工配置协议请求、响应和/或ROPs的次序和/或尺寸。

根据本发明的一个方面，通过规定关键的ROPs(例如，FXGetBuffer)无须预测其结果的尺寸，自动将请求-响应周期的数量减到最少。相反，这类ROPs由电子邮件服务器部件502来进行处理，直到达到缓冲器505(与缓冲器506相同)的极限为止。

举例而言，在包括多个版本的电子邮件服务器部件的环境中，可以为先前版本服务器部件和新近版本服务器部件定义各自的ROPs。这些新近的版本无须预测其结果的尺寸。以下的表格中阐明了这些ROPs的特征：

	用于跟先前版本服务器进行通信的协议可以使用的ROP	用于跟最新近版本服务器进行通信的协议可以使用的ROP
	用于跟先前版本服务器进行通信的协议可以使用的ROP	用于跟最新近版本服务器进行通信的协议可以使用的ROP	ROP ID	FXGetBuffer	FXGetBuffer
多种模式中所使用的参数	所要求的尺寸：服务器必须在其输出缓冲器中保留的尺寸	所要求的尺寸：被设置为超过先前版本所预期的最大值的值，例如，被设置为大于32KB的值。这用信号通知服务器寻找新的尺寸限制参数。	ROP ID	FXGetBuffer	FXGetBuffer
多种模式中所使用的参数	所要求的尺寸：服务器必须在其输出缓冲器中保留的尺寸		新的参数	n/a	尺寸限制：向服务器通知该服务器可以填充其输出缓冲器的上限。

先前版本服务器部件的ROPs在结构上类似于现存的原先技术的ROPs。也就是说，这些ROPs预测并规定必须为保存响应而保留的输出缓冲器(例如，发送缓冲器505)中的尺寸。相比之下，不预测服务器部件的最新近版本的输出缓冲器的规定尺寸，而是将该规定尺寸设置为超过先前版本服务器部件所预期的最大值的值，例如，将该规定尺寸设置为大于32KB的值。输出缓冲器的尺寸被定义为超过该服务器部件所预期的值这个事实用信号通知该服务器部件寻找新的尺寸限制参数，例如，该尺寸限制参数可能是该服务器部件的输出缓冲器的填充。这些特征自动将请求-响应周期的数量减到最少，只是处理这些ROPs的电子邮件服务器部件的复杂性略有提高。

注意，除非有相反的明确规定，否则，以上表格中和整个本申请中的类似表格中所示的参数顺序不一定跟(例如)这些参数由电子邮件客户部件或电子邮件服务器部件在网络上传输或被存储在存储器中的顺序相互关联。此外，为清楚起见，可以省略未改变的参数。

在电子邮件网络中，协议的典型职责之一是：实现在电子邮件客户部件与电子邮件服务器部件之间传送数据对象(例如，电子邮件消息)。这类数据对象的另外的例子包括：电子邮件文件夹，它们可包含电子邮件消息和其他数据对象；以及文件夹关联信息(FAI)数据对象，它们(例如)可包含关于处理电子邮件消息的规则，或定义将如何显示文件夹所包含的数据对象。数据对象对于电子邮件客户部件而言可能是难懂的，也就是说，电子邮件客户部件可能无法解释数据对象的内容。作为选择，数据对象可能由命名属性组成，例如，电子邮件消息可能包括被命名为“到”、“来自”、“主题”、“重要性”、“主体1”、“主体2”、“主体3”、“附件1”、“附件2”等的属性。

电子邮件网络具有一个优点：当数据对象难懂时，数据对象可能由电子邮件网络上的命名属性组成。利用该优点，有可能改善协议性能，因为协议能够只传送数据对象的一部分。有了命名属性，就可允许在不传输整个数据对象的情况下传输该数据对象的特定属性。

例如，电子邮件消息可能由一组头部属性和一组主体属性组成。电子邮件客户部件的需求可能会使协议首先传送头部属性，然后传送主体属性，或根本不传送主体属性。这个特点允许用户在所有消息被整体下载之前观看几个消息的头部信息。通过使用这个特点，客户部件可以获得对带宽利用的更细致的控制，这肯定会实现协议性能。此外，客户部件可以使用这个特点来产生较低带宽利用(例如，可以只为所选择的头部下载主体)，这在低带宽环境中特别合乎需要。

如果将服务器部件配置成在两个分开的请求-响应周期(即，一个用于头部，另一个用于主体)内发送主体属性和头部属性，则协议的性能不一定会提高。例如，如果电子邮件客户部件的需求曾使它同时要求头部属性和主体属性，那么，根据单一请求-响应周期既可检索头部又可检索主体的情况，可能会降低协议的性能。这样，允许数据对象由命名属性组成这个简单的动作本身不足以自动改善协议性能。实现改善的协议性能取决于可以构成数据对象的属性的选择以及协议可以如何使用这些属性。那个选择可能取决于许多因素，这些因素包括最新近和先前版本电子邮件客户部件的需求以及最新近和先前版本电子邮件服务器部件的需求。电子邮件客户部件的例子包括：满足关于不同信息显示的不同等级的紧急性，并遵守电子邮件客户部件用户所设置的参数选择。电子邮件服务器部件的例子包括：有效率地存储和检索数据，并有效率地处理协议请求。

常规原先技术的电子邮件环境利用可能由命名属性构成的数据对象(例如，电子邮件消息；该电子邮件消息可以包括命名属性的头部集的和主体集，以便可以分开请求并/或处理这两个集)。另一个原先技术的例子是一种电子邮件消息，其中，该命名属性的主体集包括(例如)采用多种电子邮件消息格式(例如，纯文本、超文本标记语言(HTML)、rich-text格式(RTF)等)的电子邮件消息主体的多个版本。在这种情况下，原先技术的电子邮件服务器部件可以用许多方法对关于该电子邮件消息的主体的协议请求作出响应。复杂性最低的请求可能会发送该电子邮件消息主体的所有版本，但这个响应可能会导致带宽利用增加。

图7A描绘了一种程序的一部分，先前(原先技术)版本电子邮件服务器部件使用该程序在这种情况中作出响应。在步骤701中，电子邮件服务器部件检验每个电子邮件消息主体的格式。如果这些格式中的一种格式是预定的标准格式(例如，RTF)，那么，该程序进行到步骤703，并且，该标准格式电子邮件消息主体被发送到请求的电子邮件客户部件。如果这些格式中没有一种格式是预定的标准格式，那么，步骤701分支到步骤702，在那里，电子邮件消息主体版本之一被转换成该标准格式。如果只有电子邮件消息主体的单一版本，但该电子邮件消息主体可能不采用协议所要求的标准格式，那么，也可以使用图7A所描绘的子过程(subprocedure)。

图7B描绘了根据本发明的最新近版本电子邮件服务器部件所使用的程序的一部分。在步骤704中，为BEST_BODY标记检验协议请求，该协议请求会导致由电子邮件服务器部件来使用这个子过程。这个例子中的标记和这里所使用的其他标记被用于该电子邮件服务器部件；电子邮件客户部件是最新近的版本，并且想要执行与该标记有关联的功能。可以使用其他指示。例如，如果检测到最新近的电子邮件客户部件，则可以默认地执行该功能。

无论如何，如果没有发现BEST BODY标记，那么，步骤704分支到步骤701，并且如参照图7A所描述的那样继续进行。

如果发现该标记，则该程序进行到步骤705，在那里，选择用于发送到请求的电子邮件客户部件的最佳电子邮件消息主体。如果只有与被请求的电子邮件消息有关联的单一电子邮件消息主体，那么，它是最佳的。如果具有(例如)采用不同格式的几个电子邮件消息主体，那么，电子邮件服务器部件根据(例如)电子邮件消息主体格式(例如，RTF、HTML、纯文本)的预定排列，从它们之中选择最佳的电子邮件消息主体。然后，该程序进行到步骤703，在那里，所选择的电子邮件消息主体被发送到电子邮件客户部件。在这个实施例中，电子邮件客户部件可能能够显示多种电子邮件消息主体格式，从而使电子邮件服务器部件无须将电子邮件消息主体转换成标准格式。此外，如果需要的话，电子邮件客户部件可以将最佳的电子邮件消息主体转换成不同的格式。

由于电子邮件服务器部件无须执行转换电子邮件消息主体的任务，因此，本发明提供了改善的性能。此外，最新近版本电子邮件服务器部件可以对来自先前版本电子邮件客户部件的协议请求作出响应，只是复杂性有适度的提高。

可以使用ROPs来实现对电子邮件服务器部件与电子邮件客户部件之间的电子邮件文件夹的复制。例如，SynchFolder ROP可以提出使文件夹同步的请求。在电子邮件客户部件能够显示非标准电子邮件消息主体格式的情况下，它可以在SynchFolder ROP中设置BEST_BODY标记，以指出电子邮件服务器部件可以从各种可用的电子邮件消息主体之中选择最佳格式，而不是要求服务器返回采用标准格式的电子邮件消息主体。在具有和没有BEST_BODY标记的情况下，电子邮件服务器部件都可以适当地处理ROPs，只是复杂性有适度的提高。用于跟先前版本服务器和最新近版本服务器进行通信的ROPs可以包括(例如)以下表格中所陈述的特征：

	用于跟先前版本服务器进行通信的协议可以使用的ROP	用于跟最新近版本服务器进行通信的协议可以使用的ROP
	用于跟先前版本服务器进行通信的协议可以使用的ROP	用于跟最新近版本服务器进行通信的协议可以使用的ROP	ROP ID	SynchFolder	SynchFolder
新的参数	n/a	BEST DODY标记：如果被设置，则电子邮件服务器部件选择最佳电子邮件消息主体，发送到电子邮件客户部件。不一定要将该电子邮件消息主体转换成预定的标准格式。	ROP ID	SynchFolder	SynchFolder

图8A-8C表现了在电子邮件服务器部件与电子邮件客户部件之间传送一组电子邮件消息的几种不同的现存模式。关于每种模式，每个电子邮件消息具有包括头部集和主体集的命名属性，并且，几个电子邮件消息被包含在文件夹中。图8A展示了完全项目传送模式。该插图表现了正在被传送的第一个电子邮件消息头部801，接下来是第二个电子邮件消息头部803前面的第一个电子邮件消息主体802，然后是第二个电子邮件消息主体804等，直到传送完这组电子邮件消息为止。图8B展示了头部首先传送模式。在这种模式中，先传送第一个电子邮件消息头部805，然后是第二个电子邮件消息头部806等，直到传送完所有电子邮件消息头部为止；直到那时才传送第一个电子邮件消息主体807，然后是第二个电子邮件消息主体808等，直到传送完这组电子邮件消息为止。图8C展示了头部唯一传送模式。如这个名称所暗示的，响应于传送一组电子邮件消息的请求，只传送电子邮件消息头部809。响应于额外的明确请求，将只传送电子邮件消息主体810。在这些模式中的任何模式中，传送序列可能会被(例如)关于特定电子邮件消息主体的较高优先权电子邮件客户部件请求暂时中断。

电子邮件文件夹是传送一组电子邮件消息的请求的目标的一个例子。但是，电子邮件文件夹可以包含除电子邮件消息以外的数据对象。如上所述，经常参照电子邮件消息头部和电子邮件消息主体来定义传送模式(例如，头部首先传送模式和头部唯一传送模式)。在这类传送模式中，如果尝试传送可能没有为其明确定义命名属性的头部集和/或命名属性的主体集的数据对象，则可能会导致协议失败。通过规定可以总是全部而不是部分地传送数据对象(没有为其明确定义命名属性的头部和/或主体集)，本发明的一个方面避免了这种情况。图8D可以用例子展示这个实施例。在这个例子中，电子邮件服务器部件与电子邮件客户部件之间的传送可能采用头部唯一模式。相应地，传送第一个电子邮件消息头部811，然后，数据对象812成为供传送的下一个候选者。没有为数据对象812(例如，FAI)明确定义命名属性的头部集，所以传送整个数据对象。供传送的下一个候选者具有明确定义的命名属性的头部集(即，该候选数据对象拥有被电子邮件客户部件明确定义为属于命名属性的头部集的所有命名属性)，所以只传送电子邮件消息头部813。

执行本发明的这个方面的一种方法的一个例子是通过使用可能被包括在同步ROP(例如，以上所描述的SynchFolder ROP)中的标记(例如，IGNORE_MODE_ON_FAI)。在具有和没有IGNORE_MODE_ON_FAI标记的情况下，电子邮件服务器部件都可以适当地处理ROPs，只是复杂性有适度的提高。ROPs可以包括以下表格中所陈述的特征，以便实现电子邮件服务器部件与电子邮件客户部件之间的电子邮件文件夹的复制：

	用于跟先前版本服务器进行通信的协议可以使用的ROP	用于跟最新近版本服务器进行通信的协议可以使用的ROP
	用于跟先前版本服务器进行通信的协议可以使用的ROP	用于跟最新近版本服务器进行通信的协议可以使用的ROP	ROP ID	SynchFolder	SynchFolder
新的参数	n/a	IGNORE_MODE	ROP ID	SynchFolder	SynchFolder

ON_FAI标记：如果被设置，那么，关于没有定义明确的头部和/或主体集命名属性的数据对象(例如，FAI)，电子邮件服务器部件可能会响应于整个数据对象的传送请求，而不管通行的传送模式如何。

电子邮件消息通常被呈送给一位或多位电子邮件网络用户。如果电子邮件消息被电子邮件服务器部件接受用于存储，则可能认为该电子邮件消息已被传递。电子邮件网络可能具有几个电子邮件服务器部件。通常，电子邮件网络协议具有某种策略，用于限制电子邮件网络用户必须核对新消息的电子邮件服务器部件的数量。普通的例子是家庭服务器策略，该策略规定：被呈送给特定电子邮件网络用户的电子邮件消息将只由一个特定的电子邮件服务器部件(被称作“用户的家庭服务器”)来接受。在这种情况下，当(例如)定期核对新的电子邮件消息或为新的电子邮件消息的通知进行登记时，可以将电子邮件客户部件配置成只考虑该家庭服务器。

图9示出：即使简单的家庭服务器策略例子也可能会错综复杂。在图9所展示的例子中，首先将特定的电子邮件服务器部件901指定为特定电子邮件网络用户的家庭服务器。随着时间的推移，通常由于管理的原因，将该用户的指定家庭服务器改成不同的电子邮件服务器部件903和905。例如，电子邮件服务器部件901、903和905可能在物理上或在逻辑上有所不同，或者是不同的版本。电子邮件客户部件902在时间T0至时间T1内可能只与电子邮件服务器部件901进行通信，随后，电子邮件客户部件904在时间T2之前可能只与电子邮件服务器部件903进行通信，然后，电子邮件客户部件906可能只与电子邮件服务器部件905进行通信。电子邮件客户部件902、904和906可能相同，也可能不同。在时间T2之后，电子邮件服务器部件901和903可能存在，也可能不存在。这些复杂化因素与接下来讨论的电子邮件消息存储器复制有特殊的关系。

电子邮件消息可以由电子邮件服务器部件存储在明确的电子邮件消息存储器中，例如，可以使用众所周知的数据库技术来执行该电子邮件消息存储器。电子邮件服务器部件可能具有一个或多个这样的报文存储器。电子邮件网络用户可能具有家庭报文存储器。若改变家庭报文存储器，则可能会产生与改变家庭服务器的描述内容相同的效果。

一些电子邮件网络协议包括将电子邮件消息存储器的一些部分复制到电子邮件客户部件本地的存储设备的能力。通过将远程电子邮件消息存储器的一些部分复制到本地电子邮件存储设备，可以改善协议性能和/或被察觉的协议性能，例如，这一点可以利用在明确的电子邮件网络用户请求观看所有新的电子邮件消息之前将这些电子邮件消息复制到本地电子邮件存储设备。这种复制也可以提供额外的电子邮件客户部件功能性，例如，可允许电子邮件网络用户在网络连通性中断期间观看电子邮件消息。

在电子邮件网络环境中，简单的复制可能会很快变得效率很低。例如，如果电子邮件服务器部件具有与特定电子邮件网络用户有关联的一个电子邮件消息，那个消息已在该网络用户的客户部件处被加以复制，并且，对那位电子邮件网络用户而言有新的电子邮件消息到达，那么，仍然要求必须响应于简单的复制请求来发送两个电子邮件消息。如果另一个新的电子邮件消息在这两个电子邮件消息复制之后到达，那么，仍然要求现在必须响应于简单的复制请求来发送三个电子邮件消息等。一些电子邮件网络协议已规定电子邮件消息存储器的增量复制，以缓解这个问题。在增量复制中，必须响应于复制请求来只发送在先前成功的增量复制之后发生的电子邮件消息存储器的变化，例如，其中，自从上一次成功的增量复制之后的唯一变化是新的电子邮件消息的到达，于是，只需要响应于增量复制请求来发送这个新的电子邮件消息。

图10表现了规定增量复制的协议的一个更加详细的例子。电子邮件消息存储器可以被再分成各个电子邮件文件夹。每个电子邮件文件夹可以独立于其他电子邮件文件夹而被加以复制，从而规定了对复制过程的更加细致的控制。在这个例子中，增量复制过程被称作“同步”，因为它包括从电子邮件客户部件501到电子邮件服务器部件502以及从电子邮件服务器部件502到电子邮件客户部件501的变化传播。在同步请求1001之后，由电子邮件服务器部件502来处理SynchFolder ROP。该ROP包括文件夹ID参数(未示出)和状态点₀参数。该文件夹ID参数识别是同步请求1001的目标的电子邮件文件夹。该状态点₀参数包含信息，该信息允许电子邮件服务器部件502确定：自从上次使电子邮件文件夹同步之后，它发生了什么变化(如果有的话)。如果请求1001代表电子邮件客户部件501提出的关于目标文件夹的首次同步请求，那么，电子邮件服务器部件502确定：与空的文件夹比较，电子邮件消息存储器中的目标电子邮件文件夹是否已发生变化。在对请求1001的响应1002中，电子邮件服务器部件502将任何变化发送到电子邮件客户部件501，包括已被加入目标文件夹的任何电子邮件消息和/或其他数据对象以及已从目标文件夹中被删除的任何电子邮件消息和/或其他数据对象的清单。电子邮件服务器部件502也创建代表目标文件夹的状态的新的状态点₁，因为在同步之后它将会立即在电子邮件客户部件501上；并且，电子邮件服务器部件502也会在响应1002中发送状态点₁。当电子邮件客户部件501发送关于跟请求1001中相同的文件夹的下一个同步请求1003时，请求1003将会包括曾利用响应1002而被返回的相同的状态点₁，作为参数。如前所述，电子邮件服务器部件502将使用状态点₁中所包含的信息来确定目标文件夹中发生了什么变化(如果有的话)，并且在响应1004中，将那些变化与新近创建的状态点₂一起发回到电子邮件客户部件501。

如果状态点数据对象的尺寸很大，则它可能会对协议性能产生不利的影响，因为它利用(例如)每个电子邮件文件夹同步请求被发送到电子邮件服务器部件并从那里被发送出去。在规定电子邮件文件夹同步的一些电子邮件网络协议中，该状态点可能部分地由一组消息变化ID数据对象构成，这些消息变化ID数据对象识别已被电子邮件客户部件了解的电子邮件消息的变化。当改变的电子邮件消息被传送到电子邮件客户和/或服务器部件时，可以说，电子邮件消息变化已被那个部件了解。

消息变化ID数据对象的一个目标可能会是：在整个电子邮件网络的上下文中，对电子邮件消息的变化进行独特的识别。在采用家庭服务器策略的电子邮件网络中，用户的家庭服务器可能负责使消息变化ID数据对象与以前未见的电子邮件消息变化相关联。例如，家庭服务器可以使用包括服务器ID数据对象和序号的消息变化ID数据对象。服务器ID数据对象可以使用众所周知的技术(例如，全球唯一标识符)，在整个电子邮件网络的上下文中对电子邮件服务器部件进行独特的识别。在这类标识符本身的尺寸很大的情况下，该服务器ID数据对象可以被编入该电子邮件服务器部件所保持的标识符查找表格。该序号可以由(例如)宽度为6个字节、电子邮件服务器部件本地的计数器来提供；只要该电子邮件服务器部件接受供存储的以前未见的电子邮件消息，该序号就可增量。

出于讨论的目的，消息变化ID数据对象可以由(例如)“S₁:1”来代表，其中，“S₁”代表第一个电子邮件服务器部件的服务器ID数据对象，“1”代表序号。例如，一组消息变化ID数据对象可以由“S₁:1，S₁:2，S₁:3”来代表，其中，“S₁:1”、“S₁:2”、“S₁:3”是具有服务器ID S₁的电子邮件服务器部件所使用的连续的消息变化ID数据对象。

在状态点部分地由代表电子邮件客户部件所见的电子邮件消息变化的一组消息变化ID数据对象(“所见消息变化”集)构成的情况下，已开发了为这个集编码的一些技术，以减小其尺寸，例如，“S₁:1，S₁:2，S₁:3，S₁:4”这个集可以被编码为“S₁:1-4”。此外，电子邮件服务器部件可以确保：它所使用的这些序号总是在增加。在那种情况下，不邻接的“所见消息变化”集(例如)“S₁:1，S₁:3，S₁:5，S₁:7”可以被编码为“S₁:1-7”，即，作为包括最小序号和最大序号的范围，而不会损失功能性。

在图9所描绘情况中，“所见消息变化”集可以包括曾经由除当前的家庭服务器(例如，S₃)以外的电子邮件服务器部件(例如，S₁、S₂)创建的消息变化ID数据对象。由当前的家庭服务器创建的消息变化ID数据对象可以被称作“本地消息变化ID”，由其他电子邮件服务器部件创建的消息变化ID数据对象可以被称作“外来消息变化ID”。还没有提供用于跟先前版本电子邮件服务器部件进行通信的电子邮件网络协议，用于在每一电子邮件服务器部件的基础上将不邻接的外来消息变化ID序列优化成包括最小序号和最大序号的范围。以下的表格展示了在本发明的实施例中包括这种优化的好处：

先前版本服务器(当前的家庭服务器S₃)所使用的优化

最新近版本服务器(当前的家庭服务器S₃)所使用的优化

优化之前的“所见消息变化”集	S₁:1，S₁:3，S₁:5，S₁:7S₂:1，S₂:3，S₂:5，S₂:7S₃:1，S₃:3，S₃:5，S₃:7
优化之前的“所见消息变化”集	S₁:1，S₁:3，S₁:5，S₁:7S₂:1，S₂:3，S₂:5，S₂:7S₃:1，S₃:3，S₃:5，S₃:7		优化之后的“所见消息变化”集	S₁:1，S₁:3，S₁:5，S₁:7S₂:1，S₂:3，S₂:5，S₂:7S₃:1-7	S₁:1-7S₂:1-7S₃:1-7

本发明的一个实施例使用包括以下表格中所陈述的特征的ROPs，以便实现电子邮件服务器部件与电子邮件客户部件之间的电子邮件文件夹的同步。电子邮件服务器部件可以执行改进的状态点编码技术，只是复杂性有适度的提高。

	当与先前版本服务器进行通信时，协议可以使用的ROP结果	当与最新近版本服务器进行通信时，协议可以使用的ROP结果
	当与先前版本服务器进行通信时，协议可以使用的ROP结果	当与最新近版本服务器进行通信时，协议可以使用的ROP结果	ROP ID	SynchFolder	SynchFolder
新的模式中所使用的未改变的参数	状态点：不包括不邻接的各组外来消息变化ID数据对象的优化。	状态点：包括不邻接的各组外来消息变化ID数据对象的改进的优化。	ROP ID	SynchFolder	SynchFolder

图11A和图11B描绘了可以分别由先前版本服务器和最新近版本服务器使用的子过程之间的差异，以响应于SynchFoler ROP。图11A表现了步骤1101、1102和1103。在步骤1101中，编制最初的“所见消息变化”集。在步骤1102中，属于本地消息变化ID数据对象的“所见消息变化”集的组成部分被进行优化。在步骤1103中，将被优化的“所见消息变化”集加入状态点数据对象，该状态点数据对象可以利用响应被发送到曾请求同步的电子邮件客户部件。图11B包括额外的步骤1104，该步骤表现了属于外来消息变化ID数据对象的“所见消息变化”集的组成部分，现在利用改进的优化在步骤1103中将“所见消息变化”集加入状态点数据对象，在这之前，这些外来消息变化ID数据对象也正在被进行优化。

通过将电子邮件消息存储器再分成各个电子邮件文件夹，规定了对同步过程的更加细致的控制，但这并没有自动规定改善协议性能，并且，可能会导致协议性能退化。例如，一些协议要求使每个报文存储器文件夹分开同步。每项同步操作通常具有某种管理费用，该管理费用可能会很多。利用状态点数据对象的同步操作是可能具有重大管理费用的操作的一个例子。在使整个报文存储器同步的情况中，与要求较少的同步操作的协议相比，要求使每个报文存储器文件夹分开同步的协议可能会处于不利的地位。

对于电子邮件客户部件而言，使整个报文存储器同步并保持同步是合意的目标。常规的原先技术的电子邮件客户部件一直寻求实现这个目标，即使当它导致对协议性能造成不利的重大影响时，也是如此。本发明的一个方面是：它能够将不利的协议影响减到最小，同时，通过利用深入层级表格来实现这个目标。常规的原先技术的电子邮件服务器部件一直无法提供深入层级表格。

在将电子邮件消息存储器再分成各个电子邮件文件夹的情况下，那些电子邮件文件夹可以被组织到各个层级中。图12表现了电子邮件文件夹层级的一个例子。在图12中，文件夹1204是文件夹1203的子文件夹(subfolder)。文件夹1203又是文件夹1202的子文件夹。文件夹1201是根文件夹。根文件夹不是其他任何文件夹的子文件夹。所有其他的文件夹是根部在文件夹1201处的文件夹层级的组成部分。通常，文件夹层级中的每个文件夹无法直接引用其他每个文件夹。文件夹可能只具有对其子文件夹的直接引用。文件夹也可能直接引用本身是其子文件夹的任何文件夹。在许多情况下，每个文件夹可直接引用的唯一文件夹可能是该层级的根文件夹。

深入层级表格可以包含有关文件夹层级中的每个文件夹的信息。每个文件夹可拥有该深入层级表格中的一行。该深入层级表格中的信息如此，以便可以使用该信息来确定电子邮件文件夹的内容在特定的时期内是否已改变。可以通过简单比较在特定时期开始时所采用的文件夹的行的复制件和在该时期结束时所采用的那个文件夹的行的复制件，来确定该时期内电子邮件文件夹的变化。在一个实施例中，该深入层级表格的每行包括以下各个属性：

属性名称	属性类型	注释
属性名称	属性类型	注释	文件夹ID	FID	FID类型包括全

		球唯一标识符(GUID)和6字节序号。可以使用这个值来对电子邮件网络的上下文中的电子邮件文件夹进行独特的识别。
		球唯一标识符(GUID)和6字节序号。可以使用这个值来对电子邮件网络的上下文中的电子邮件文件夹进行独特的识别。	PR_LOCAL_COMMIT_TIME_MAX	时间戳	在修改文件夹的内容的任何时候，更新这个时间戳。
PR_DELETED_COUNT_TOTAL	QWORD	这个值是曾经从文件夹中被删除的项目总数的计数。	PR_LOCAL_COMMIT_TIME_MAX	时间戳	在修改文件夹的内容的任何时候，更新这个时间戳。

只要改变文件夹的内容，就可以更新深入层级表格中的电子邮件文件夹的行的属性。为了有效率地执行深入层级表格更新，申请者已发现：这有助于对该深入层级表格进行迅速、直接的引用。申请者至少已发现：当尝试访问该深入层级表格时，应该有很少的可预测数量的间接层次。例如，如果将深入层级表格置于文件夹层级中的任意层次，则将不会规定可预测数量的间接层次。在本发明的一个实施例中，由于这个原因，深入层级表格可能与电子邮件网络用户的电子邮件消息存储器文件夹层级的根文件夹有关联。

电子邮件客户部件与电子邮件服务器部件之间的通信可以被分成各个通信对话期。例如，在网络连通性中断期间，可能会在各个对话期之间发生电子邮件消息存储器同步的损失。为了在通信对话期开始时重新建立电子邮件消息存储器同步，用于跟先前版本电子邮件服务器部件进行通信的一些协议为该文件夹层级中的每个文件夹使用过SynchFolder ROP。通常，部分这些文件夹的内容将不会在各个对话期之间已发生变化。具有作为其目标的未改变的文件夹的SynchFolder ROP导致“零同步信号”(null synch)。虽然“零同步信号”不会导致任何文件夹变化被传送到电子邮件客户部件，但是，它仍然具有可能重大的、与其有关联的管理费用(例如，状态点数据对象)。

图13展示了本发明的一个实施例，该实施例通过利用深入层级表格来避免这种“零同步信号”结果。在第一请求1301中，电子邮件客户部件501将请求深入层级表格的ROP(例如，GetHierarchyTable)发送到电子邮件服务器部件502。在第一请求1302中，将该深入层级表格的复制件提供给电子邮件客户部件501。通常，电子邮件客户部件501将会具有该深入层级表格的先前的复制件。通过利用这两个复制件的逐行比较，电子邮件客户部件501可以确定电子邮件服务器部件502上的用户电子邮件消息存储器中的哪些文件夹已发生变化。接下来，使用ROPs(例如，SynchFolder)，只使已改变的那些文件夹同步。可以按必要的需求来重复请求1303和响应1304，以便使改变的文件夹同步。在同步成功之后，可以更新该深入层级表格的电子邮件客户部件的复制件，以便与曾在响应1302中被发送的最近的复制件相匹配。如果电子邮件客户部件501没有该深入层级表格的先前的复制件，那么，具有该最近复制件中的一行的所有文件夹都可以被同步化。

一旦已建立用户的电子邮件消息存储器的同步，就可以通过定期重复以上所描述的对话期开始步骤(即，轮询电子邮件服务器部件)来保持同步，但这种方案也有缺点。例如，轮询时期可能比用户的电子邮件消息存储器的各个变化之间的时期要短得多。在那种情况下，深入层级表格比较中的相对很多的比较将会指出：没有文件夹已发生变化。这类比较实际上是徒劳，所以，可避免这些比较的协议可能会更有效率。

一些电子邮件网络包括电子邮件客户部件预订的一种设备，电子邮件服务器部件通知它(例如)特定电子邮件文件夹的内容何时发生变化。通过为与用户的文件夹层级中的每个文件夹有关联的变化通知创建分开的预订，一些先前版本电子邮件客户部件使用这种设备来保持用户的电子邮件消息存储器的同步。在本发明的一个实施例中，电子邮件客户部件可以为与该深入层级表格有关联的变化通知只创建单一预订。单一预订更有效率，这是因为建立该单一预订所需要的ROPs较少，并且，所消耗的服务器方的资源也较少。

进一步参照图13，当最新近版本电子邮件客户部件501根据本发明的一个方面在与电子邮件服务器部件502的通信对话期开始时使用第一请求1301中的GetHierarchyTable ROP时，自动预订电子邮件客户部件501，以改变与在响应1302中被返回的深入层级表格有关联的通知。当该电子邮件客户部件处的用户的电子邮件消息存储器中的电子邮件文件夹发生变化时，例如，当电子邮件消息被加入该文件夹时，也按以前所描述的那样来更新该深入层级表格。该深入层级表格的变化会引发对电子邮件客户部件501的通知警报1305。该通知警报响应于请求1301所发出的预订，但它不是明确的请求-响应周期的一部分。这样，通过使用如本发明所提供的通知系统，可大大减少电子邮件网络的管理费用。

单一预订可能会导致许多通知。在一个实施例中，使用无连接(connectionless)网络传送机制(例如，“用户数据报协议”/“网际协议”(UDP/IP))来传递该警报，但也可以使用任何合适的网络传送机制。响应于该警报，电子邮件客户部件501将包含ROP(例如，GetNotification)的请求1306发送到电子邮件服务器部件502。在响应1307中，将该深入层级表格的任何改变的行(即与引发过该通知的改变的文件夹相对应的各行)发送到电子邮件客户部件501。然后，电子邮件客户部件501使用ROPs(例如，SynchFolder)，只使已改变的文件夹同步。

可以为与相同的数据对象(例如，相同的电子邮件文件夹)有关联的变化通知预订多个电子邮件客户部件，以便(例如)提供协作功能性。如图18所示，为跟位于电子邮件服务器部件1804上的相同的数据对象(未示出)有关联的变化通知预订电子邮件客户部件1801、1802和1803。电子邮件客户部件1803将ROP 1805发送到导致该数据对象变化的电子邮件服务器部件1804。该变化的结果是：电子邮件服务器部件1804将变化通知1806、1807和1808发出到电子邮件客户部件1801、1802和1803。在识别已改变的数据对象以外，变化通知可以携带很少的信息，以致(例如)电子邮件客户部件可能无法确定它是否曾是引起特定变化的原因。如果该数据对象是(例如)电子邮件文件夹，则变化通知1806、1807和1808可能会导致每个电子邮件客户部件1801、1802和1803为改变的文件夹启动同步。由于电子邮件客户部件1803在这个例子中曾对该变化负责，因此，结果将会是“零同步信号”。

由于前面所讨论的原因，可能需要消除导致“零同步信号”的同步。但是，所描述的通知行为可能不会总是不合乎需要，并且，一些电子邮件客户部件可能会依靠它。本发明的一个方面是：规定电子邮件客户部件能够配置最新近版本电子邮件服务器部件的通知行为，以便改善协议性能，同时提供具有未改变的通知行为的先前版本电子邮件客户部件。

图19A描绘了可以由先前版本电子邮件服务器部件提供的通知行为。图19B描绘了根据本发明的一个方面的可配置的通知行为。如果需要的话，最新近的电子邮件客户部件可以向电子邮件服务器部件指出：例如，通过在图19B所示的例子中为标记(IGNORE_OWN标记)提供请求，它能够执行图19B中的通知行为。

在步骤1901中，从将要被通知的这组订户中选择下一个候选者。在步骤1904中，为IGNORE_OWN标记检验预订。如果该标记不存在，则步骤1904分支到步骤1902，在那里，通知被发送到该候选订户。如果发现该标记，则步骤1904分支到步骤1905，在那里，再次检验预订，以确定该订户是否引发过这个通知。例如，可以通过检验曾经被用来发出预订的对话期的通信对话期标识符(“对话期ID”)，来进行这种确定。例如，对话期ID可以包括全球唯一标识符和6字节序号。也为与其起因有关联的对话期ID检验该通知。如果两者匹配，那么，禁止发行该通知。结果是：曾引起通知的电子邮件客户部件也将不会接收那个通知。然后，如下所述，该子过程进行到步骤1903。

如果订户没有引发过通知，那么，与预订有关联的对话期ID跟与该通知的起因有关联的对话期ID不同，并且，步骤1905分支到步骤1902，在那里，发送该通知。然后，该过程进行到步骤1903，在那里，确定是否将要通知更多的订户。如果将要通知更多的订户，则该子过程返回到步骤1901，否则，这个子过程结束。

如上所述，利用电子邮件消息的超高速缓存的电子邮件客户部件可能会(例如)经由ROP来请求本地客户数据暂存器与电子邮件服务器部件处的可用的数据暂存器之间的消息或其他数据对象的同步。该电子邮件客户部件可能会同样请求将消息从服务器存储器拷贝到客户存储器。不管是这样还是那样，都可以使用快速传送模式来提出该请求。

通常，当要求消息或其他数据(例如，文件)进行同步或拷贝时，该请求(例如，ROP)包括需要进行同步的所有消息的指示。例如，通过利用以上所描述的状态点特点，这个清单可以由电子邮件服务器部件自动编制。关于先前版本(原先技术)电子邮件服务器部件，若ROP请求中的一个消息或数据对象发生错误，则将会引起该请求中的所有项目发生故障。图14A中表现了这个过程，其中，包含ROP(例如，FXPrepare)的请求利用为拷贝或同步所指定的消息ID集而在步骤1401中被加以传输。在电子邮件服务器部件502处设立快速传送机制，并且，在步骤1402中，将快速传送ID传输到电子邮件客户部件501。然后，电子邮件客户部件501通过包含(例如)FXGetBufferROP的请求来请求这些数据对象的拷贝或同步(步骤1403)。当电子邮件服务器部件502尝试打开所请求的消息时，这些消息或其他数据对象中的一个或多个消息或数据对象发生错误。错误的例子包括：消息或数据对象被破坏；服务器失灵；电子邮件服务器部件502被遗忘；或者，为该数据对象检测到病毒。

在发生该错误之后，电子邮件服务器部件502在步骤1404中发送流到电子邮件客户部件501的数据中的致命的ROP错误。照此，同步没有获得成功，消息ID集内的消息没有被同步化或被拷贝，并且，电子邮件客户部件501没有接收该状态点或类似的更新信息。然后，电子邮件客户部件501必须请求在另一个时间对这些数据对象进行同步或拷贝。情况可能会是：如果没有在电子邮件服务器部件502处修改错误，则可能会继续发送错误消息，并且，消息ID集内的消息可能永远不会被同步化或被拷贝。

根据本发明的一个方面，最新近的电子邮件服务器部件可能会发送有关特定数据对象(例如，电子邮件消息)的错误信息，而不是致命的ROP错误，以便只有那个数据对象的同步会失败。即使有错误的消息或其他数据对象被包括在该响应内，这个特点也允许ROP或其他请求内的消息或其他数据对象被加以传输和同步化或被拷贝。

如何处理特定对象错误的一个例子是：最新近的电子邮件服务器部件可以为具有对象错误的数据对象发送数据流中的错误消息。在这个例子中，为方便参考，该错误被称作“FXErrorInfo”。如果需要的话，则如以下进一步的描述，FXErrorInfo可以包括诸如具有该错误的数据对象的消息ID的信息，以及有关该消息为何失灵的额外的信息。

图14B表现了其中在消息M₃中发生错误的一种同步。该错误导致包括消息M₁、FXErrorInfo前面的消息M₂和消息M₄的FXGetBuffer响应1405。该FXErrorInfo信息允许电子邮件客户部件501知道哪个消息有过错误，并且允许电子邮件客户部件501使该响应内所有其他的消息都同步。如果该错误消息FXErrorInfo包括有关该错误的原因的信息，则(例如)可以通过向用户显示错误消息，由该客户部件相应地作用于该信息。

以下的表格表现了FXErrorInfo可以采用的格式的一个例子：

FXErrorInfo

属性名称	属性类型	注释
属性名称	属性类型	注释	版本	WORD	这种结构的版本
错误代码	DWORD		版本	WORD	这种结构的版本
错误代码	DWORD		消息ID	MID	MID类型包括全球唯一标识符和6字节序号。这是曾引起该错误的消息的消息ID。
…	…	可以在这里增加零或多个属性。	消息ID	MID	MID类型包括全球唯一标识符和6字节序号。这是曾引起该错误的消息的消息ID。
…	…	可以在这里增加零或多个属性。	辅助域尺寸	ULONG	遵守该阵列的尺寸。
辅助域	BYTE阵列	用于传达错误细节的未组织的阵列。	辅助域尺寸	ULONG	遵守该阵列的尺寸。

可见，该范例格式包括版本属性、错误代码和消息ID。此外，如果需要的话，可以增加一个或多个属性。另外，如上所述，可以定义辅助域，用于传达错误细节。照此，可以定义属性，用于规定该错误细节(例如，阵列)的域尺寸，并且，可以提供域，该域可能是(例如)用于传达该错误细节的未组织的阵列。如上所述，电子邮件客户部件501可以按需要来处理这些错误细节。

该FXErrorInfo允许第一个响应的同步完成，(例如)从而导致状态点或其他信息被提供给电子邮件客户部件501。由于现在通过消息M₄使该电子邮件客户部件同步，因此，关于同步的下一个请求1406可能会导致具有M₄之后的各个消息(例如，M₅和M₆)的响应1407。

为了指出电子邮件客户部件501是最新近的版本并且因而能够处理FXErrorInfo消息，可以定义标记(例如，FXRecoverMode)，该标记可利用请求同步或拷贝的ROP来加以传输。可以为电子邮件客户部件501使用其他的指示，以便向电子邮件服务器部件502传达：它能够处理该FXErrorInfo消息。

当电子邮件服务器部件502将一个或多个消息或其他数据对象发送到电子邮件客户部件501时，到该电子邮件客户部件的数据流可以被属性标签(例如，ptags)分开或定义。例如，消息清单可以包括关于每个消息的开始消息ptag和结束消息ptag。开始ptag与结束ptag之间可能是属性清单ptag和主题ptag，它们可能具有字符串的属性。该主题ptag的后面可能是该主题本身。可以包括其他的属性标签。

在传输消息的过程中发生错误的情况下，FXErrorInfo可以作为ptag而被提供，并可以具有二进制属性(例如，以上表格所定义的)。以下的数据流的一个例子具有成功的消息和其中发生错误的消息。在发生该错误的情况下，没有为那个特定的消息使用结束消息ptag，并且，ptag FXErrorInfo是那个消息的最后的ptag。

　　ptagMessageListStart

       ptagMessageStart

          ptagPropList

             ptagSubj ect[PT_STRING]

                ″Re：Your email″

                ……

             ptagMessageEnd

             ptagMessageStart

　              ……

　              ptagFXErrorInfo[PT_BINARY]

　                 [Contents as described by table]

　           ptagMessageStart

　　            ……

　　         ptagMessageEnd

　　      ptagMessageListEnd

图15A表现了一些步骤，电子邮件服务器部件502可以利用这些步骤将消息传送到先前版本电子邮件客户部件501。从步骤1501开始，例如，通过将消息集放置在快速传送数据暂存器中，来准备该消息集。在步骤1502中，例如，在被放入电子邮件服务器部件502的发送缓冲器之后，该消息立即开始流出。如果当流出该消息时发生错误，那么，在步骤1504中，使致命的ROP错误流出到电子邮件客户部件501。然后，该子过程结束。如果当流出该消息时没有发生错误，那么，在步骤1503中，确定该消息集中是否有更多消息。如果有，则该过程返回到步骤1502，在那里，使下一个消息流出。如果没有，那么，该子过程结束。

图15B表现了关于电子邮件服务器部件502的最新近的版本处理消息集的程序。根据该电子邮件客户部件是最新近的版本还是先前的版本，所采用的步骤有所不同。步骤1501-1504是在先前版本电子邮件客户部件的情况下采用的步骤，并且，这些步骤等同于在前一段中具有相同的参考数字的步骤。

如果在步骤1502中，在流出消息的过程中发现错误，那么，在步骤1505中确定该请求是否包括标记(例如，FXRecoverMode)。如果该请求包含该标记，那么，电子邮件客户部件501是最新近的版本，并且，步骤1505分支到步骤1506，在那里，使FXErrorInfo流出到电子邮件客户部件501。然后，该过程可以继续进行到步骤1503。如果该请求不包括该标记，那么，步骤1505分支到步骤1504，在那里，使致命的ROP错误流出。然后，该子过程结束。

可见，如果该请求中存在该标记，则可通过流出FXErrorInfo(而不是舍弃并发送致命的ROP错误)，来允许流动过程继续。该标记由电子邮件客户部件501的最新近的版本来发送。先前版本的电子邮件客户部件不包括该标记，这样，如上所述，错误会导致流出致命的ROP错误。

如果需要的话，在选择性实施例中，可以为消息或其他数据对象的特定属性(而不是为整个消息)发出错误消息(例如，FXErrorInfo)。例如，可以为消息的主体，或为消息的附件发出FXErrorInfo。然后，电子邮件客户部件501可以对被无差错地成功发送的属性进行同步或拷贝，只有具有错误的属性没有被同步化或被拷贝。

有时，消息或其他数据对象的尺寸可能足以使它跨越多个FXGetBuffer响应。为了处理这类消息，电子邮件客户部件501可以包括反转逻辑，以便它可以处理任何被局部接收的消息，然后在接收错误消息之后继续适当地接收另外的消息。

有时，可能需要为电子邮件客户部件提供有关数据对象(例如，电子邮件消息)的拷贝或同步的进展的反馈。根据本发明的一个方面，电子邮件客户部件501的最新近的版本可以指出：例如，通过在请求数据对象的同步或拷贝时将标记(例如，PROGRESS MODE)发送到电子邮件服务器部件502，它能够处理进展模式。作为响应，电子邮件服务器部件502的最新近的版本可以发送各种信息以及消息(例如，所有这些消息的总尺寸、消息的总数和每个消息的总尺寸、或这些内容中的任何一个内容或这些内容的组合)。

例如，如图16A所示，关于先前版本电子邮件客户部件501，响应于关于一组消息的快速传送请求(1601和1603)，电子邮件客户部件501接收这些消息。在图16A中，在两个响应1604和1606中接收消息。在使用快速传送机制的先前版本电子邮件客户部件501中，没有提供过正在流到该客户的消息的进展指示。

但是，如图16B所示，在对由该电子邮件客户部件提出的关于消息集的请求的响应1607中，电子邮件服务器部件502可以提供将要被传送的数据对象的总数以及将要被传送的所有数据对象的总尺寸。该信息由图16B中的“P_all”代表。电子邮件服务器部件502的最新近的版本也可以提供由图16B中的“P₁、P₂、P₃、...”表示的每个消息的尺寸。此外，如果需要的话，与每个消息以及整组消息有关联的信息可以包括有关每个消息是FAI还是实际的电子邮件消息的额外信息。在一个实施例中，即使传送零数据对象，也总是响应于快速传送请求来发送由图16B中的“P_all”代表的信息，以便简化该数据流的处理。

以下的表格中表现了关于正在被传送的所有数据对象的尺寸和数量的格式的一个例子。

IncrSyncProgressMode
IncrSyncProgressMode			属性名称	属性类型	注释
版本	WORD(例如，16位整数)	这种结构的版本。	属性名称	属性类型	注释
版本	WORD(例如，16位整数)	这种结构的版本。	cAssocMsgs	DWORD(例如，32位整数)	将要被传送的FAI数据对象的数量。
IITotalAssocMsgSize	QWORD(例如，64位整数)	将要被传送的所有FAI数据对象的总尺寸。	cAssocMsgs	DWORD(例如，32位整数)	将要被传送的FAI数据对象的数量。

cNormalMsgs	DWORD	将要被传送的电子邮件消息的数量。
cNormalMsgs	DWORD	将要被传送的电子邮件消息的数量。	IITotalNormalMsgSize	QWORD	将要被传送的所有电子邮件消息的总尺寸。

可见，可以为FAI数据对象的数量、所有FAI数据对象的总尺寸、将要被传送的电子邮件消息的数量以及将要被传送的所有电子邮件消息的总尺寸定义分开的属性。可以按需要将其他组合和额外的属性加入该格式。

以下的表格表现了尺寸和可以被提供每个消息的其他信息的格式。

IncrSyncProgressModePerMsg
IncrSyncProgressModePerMsg			属性名称	属性类型	注释
消息尺寸	LONG	下一个消息的尺寸。	属性名称	属性类型	注释
消息尺寸	LONG	下一个消息的尺寸。	FAI标记	BOOL	指出下一个消息是否是FAI。

可见，该格式包括下一个消息的尺寸以及下一个消息是否是FAI。

图17A和17B表现了用于分别根据这些电子邮件部件的先前版本和这些电子邮件部件的最新近的版本来流出消息集的步骤。图17A中的步骤类似于图15A中的步骤1501-1503。关于图17B，例如利用ROP，最新近的电子邮件客户部件501已发送PROGRESS_MODE标记。在步骤1701中准备该消息集之后，确定该标记是否存在。如果存在，那么，在步骤1702中发送进展数据总数，然后，该过程进行到步骤1502，在那里，使第一个消息流出。如果该标记不存在，那么，步骤1701直接分支到步骤1502。

在使第一个消息流出之后，该过程进行到步骤1703，在那里，确定是否具备该标记。如果具备，那么，步骤1703分支到步骤1704，在那里，流出每一消息进展数据。然后，如前所述，该过程进行到步骤1503。如果不具备该标记，则步骤1703直接分支到步骤1503。

以下陈述了关于最新近的服务器部件将数据发送到最新近的客户部件的数据流动的一个例子。该数据流动类似于以上所描述的数据流动，但另外包括进展总数数据的ptags(ptagIncrSyncProgressMode)，它们可能具有(例如)二进制属性。此外，关于每个消息，提供每一消息进展数据，例如作为

　　ptagIncrSyncPreogressModePerMsg。

　　    PtagIncrSyncProgressMode[PT_BINARY]

　　       [Contents as described by table]

　　    ptagMessageListStart

　　       PtagIncrSyncProgressModePerMsg[PT_BINARY]

　　           [Contents as described by table]

　　    ptagMessageStart

　　       ptagPropList

　　          ptagSubject[PT_STRING]

　　              ″Re：Your email″

　　       ……

　　   ptagMessageEnd

　　   ptagIncrSyncProgressModePerMsg[PT_BINARY]

　　      [Contents as described by table]

　　   ptagMessageStart

　　       ……

　　   ptagMessageEnd

　　ptagMessageListEnd

在所示的例子中，包括进展总数数据的ptags(ptagIncrSyncProgressMode)和消息进展数据的ptags(ptagIncrSyncProgressModePerMsg)分别位于消息清单之前和每个消息之前。但是，可以修改这些数据对象的流动结构，以便进展数据可以被包括在这些消息或该消息清单内。可以进一步修改这些数据对象的流动结构，以便完全消除为消息和/或消息清单定界的ptags。

接收进展数据的电子邮件客户部件可以利用该数据来确定来自电子邮件服务器部件的数据对象的同步或拷贝的进展，并且可以利用每一消息进展数据来确定每个单独的消息的进展。例如，在监控有关同步的进展的实时信息的过程中，该信息可能会有帮助。

有几个不同的字符集可以被用于存储电子邮件消息或其他数据对象。例如，ASCII最常被用于存储英语字符。但是，ASCII不足以用于存储所有语言的字符，因为它建立在8位字符的基础之上。这样，ASCII代码只可以被用于256个字符，这对于英语而言足够了，但对于具有更多字符的语言而言就不够了。另一方面，统一字符编码是为每个字符使用16个位(两个字节)的字符集，所以，它能够包括比ASCII更多的字符。统一字符编码可以具有65,536个字符，所以，它可以被用来为世界上几乎所有的语言编码。统一字符编码包括其内的ASCII字符集。

一般而言，先前版本的电子邮件客户部件501具有指定的代码页或与其有关联的字符集和/或语言。例如，电子邮件客户部件501的特殊版本可能具有德语代码页，另一个版本可能具有ANSI代码页。有时，电子邮件客户部件501可能需要接收除指定的代码页以外的字符集中的电子邮件。根据本发明的一个方面，最新近的客户部件可能会迫使电子邮件服务器部件提供采用统一字符编码的所有电子邮件。一旦电子邮件客户部件501接收这些电子邮件，就可以将统一字符编码电子邮件转换成该客户的代码页，或者，作为选择，可以用统一字符编码格式来保持统一字符编码电子邮件。

为了指出电子邮件客户部件501要求用统一字符编码来提供电子邮件，例如，电子邮件客户部件501可以将标记(例如，FORCEUNICODE)提供给电子邮件服务器部件502。可以为该标记提供请求(例如，ROP)。如果电子邮件服务器部件502是最新近的版本，则电子邮件服务器部件502可以提供电子邮件的统一字符编码版本(如果有的话)，或者可以将其他字符集中的电子邮件消息转换成统一字符编码。

图20表现了用于根据本发明的一个方面为消息提供特殊字符集的步骤。从步骤2001开始，电子邮件服务器部件502从其数据暂存器中检索消息。在步骤2002中，确定FORCEUNICODE标记是否存在。如果不存在，那么，步骤2002分支到步骤2003，在那里，电子邮件服务器部件502提供电子邮件客户部件的指定代码页中的电子邮件消息，如果必要的话，可进行转换。

如果FORCEUNICODE标记存在，那么，步骤2002分支到步骤2004，在那里，确定该消息是否作为统一字符编码被存储。如果是，则步骤2004分支到步骤2005，在那里，将该消息提供给统一字符编码字符集中的电子邮件客户部件501。如果该消息没有用统一字符编码被加以存储，那么，步骤2004分支到步骤2006，在那里，该消息被转换成统一字符编码；然后，该过程继续进行到步骤2005，在那里，用统一字符编码将该消息提供给电子邮件客户部件。

包括这里所引用的出版物、专利申请和专利的所有参考资料被包括于此，用作参考，如同单独、明确地指出将每个参考资料包括于此，用作参考，并且在这里加以整体陈述。

除非这里另有指示或上下文有明显的抵触，描述本发明的上下文中(尤其在以下权利要求书的上下文中)的术语“一个”(a)、“一个”(an)和“这”(the)以及类似的所指对象的使用将被解释为包括单数和复数。除非另有特别指示，术语“包括”(comprising)、“具有”(having)、“包括”(including)和“包含”(containing)将被解释为开放式术语(即，意味着“包括，但不局限于”)。除非这里另有指示，这里的值的范围的列举仅仅意在用作单独提及在该范围以内的每个个别的值的速记方法；并且，每个个别的值被并入该说明书，好象它在这里被单独列举。除非这里另有指示或上下文有明显的抵触，可以按任何合适的顺序来执行这里所描述的所有方法。除非另有声明，这里所提供的任何和所有的例子或示范语言(比如，“例如”)的使用仅仅意在更好地阐明本发明，而不会限制本发明的范围。不应该将该说明书中的语言解释成：将任何未声明的元件说成是实践本发明所必不可少的。

这里描述了本发明的较佳实施例，包括这些发明者已知的、用于执行本发明的最佳模式。通过阅读前文，掌握该技术领域的普通技能的人会明白那些较佳实施例的变更。这些发明者期望技术娴熟的技工适当地使用这类变更，并且，这些发明者打算用不同于这里特别描述的方式来实践本发明。相应地，适用法规允许：本发明包括被附加于此的权利要求书中所叙述的主题内容的所有修改和相等物。而且，除非这里另有指示或上下文有明显的抵触，本发明包括其所有可能的变更中的上述元件的任何组合。

Claims

1.一种具有计算机可执行指令的计算机可读介质，其特征在于：这些指令包括：

在电子邮件服务器部件处接收关于消息的请求，该请求包括一个指示：需要该邮件的最佳消息主体；

访问与该电子邮件服务器部件有关联的数据暂存器，并确定不依赖转换可用消息主体的格式的消息的最佳消息主体；以及，

检索并返回该最佳消息主体，而无须转换该最佳消息主体的格式。

2.如权利要求1的计算机可读介质，其特征在于，该请求包括关于该消息位于其中的文件夹的同步的请求。

3.如权利要求1的计算机可读介质，其特征在于，该请求包括关于电子邮件消息的复制件的请求。

4.如权利要求1的计算机可读介质，其特征在于，该指示包括与该请求一起被包括的标记。

5.如权利要求1的计算机可读介质，其特征在于，确定包括：根据等级评定系统来评估可用的消息主体。

6.一种计算机执行方法，其特征在于，包括：

在电子邮件客户部件处，生成关于消息的请求，该请求包括一个指示：需要该邮件的最佳消息主体；以及，

在电子邮件服务器部件处：

响应于该请求，

访问与该电子邮件服务器部件有关联的数据暂存器，并确定不依赖转换可用消息主体的格式的消息的最佳消息主体，并且，

检索该最佳消息主体，并将其返回到该电子邮件客户部件，而无须转换该最佳消息主体的格式。

7.如权利要求6的方法，其特征在于，该请求包括关于该消息位于其中的文件夹的同步的请求。

8.如权利要求6的方法，其特征在于，该请求包括关于电子邮件消息的复制件的请求。

9.如权利要求6的方法，其特征在于，该指示包括与该请求一起被包括的标记。

10.如权利要求6的方法，其特征在于，确定包括：根据等级评定系统来评估可用的消息主体。

11.一种被具体表现在计算机可读介质上的数据分组，其特征在于，包括：包括关于电子邮件消息的请求的第一数据区；以及，

包括一个指示的第二数据区，该指示指出：需要该电子邮件消息的最佳消息主体。

12.如权利要求6的数据分组，其特征在于，该请求包括关于该电子邮件消息位于其中的文件夹的同步的请求。

13.如权利要求6的数据分组，其特征在于，该请求包括关于电子邮件消息的复制件的请求。

14.如权利要求6的数据分组，其特征在于，该指示包括与该请求一起被包括的标记。

15.一种被具体表现在计算机可读介质上的数据分组，其特征在于，包括：包括关于多个电子邮件数据对象的请求的第一数据区；以及，

包括一个指示的第二数据区，该指示指出：需要这些电子邮件数据对象的至少一个属性，并且，如果这至少一个属性没有被明确定义，则将会返回电子邮件数据对象。

16.如权利要求15的数据分组，其特征在于，该请求包括关于这些数据对象位于其中的文件夹的同步的请求。

17.如权利要求15的数据分组，其特征在于，该请求包括关于数据对象的复制件的请求。

18.如权利要求15的数据分组，其特征在于，该指示包括与该请求一起被包括的标记。

19.如权利要求15的数据分组，其特征在于，这至少一个属性包括消息的头部。

20.如权利要求15的数据分组，其特征在于，这些数据对象包括电子邮件消息。

21.一种计算机执行方法，其特征在于，包括：

在电子邮件客户部件处，生成关于文件夹中的电子邮件数据对象的请求，该请求包括一个指示：需要这些电子邮件数据对象的至少一个属性；以及，

在电子邮件服务器部件处：

接收该请求，以及，

访问该文件夹和该文件夹中的电子邮件数据对象，并且，关于该文件夹中的每个电子邮件数据对象：

如果在该电子邮件数据对象中明确定义这至少一个属性，则检索那个数据对象的这至少一个属性，并将其返回到该电子邮件客户部件；以及，

如果没有为该电子邮件数据对象明确定义这至少一个属性，则检索该数据对象，并将其返回到该电子邮件客户部件。

22.如权利要求21的方法，其特征在于，该请求包括关于这些电子邮件数据对象位于其中的文件夹的同步的请求。

23.如权利要求21的方法，其特征在于，该请求包括关于电子邮件消息的复制件的请求。

24.如权利要求21的方法，其特征在于，该指示包括与该请求一起被包括的标记。

25.如权利要求21的方法，其特征在于，这至少一个属性包括消息的头部。

26.一种具有计算机可执行指令的计算机可读介质，其特征在于：这些指令包括：

接收关于文件夹中的数据对象的请求，该请求包括一个指示：需要这些数据对象的至少一个属性；

响应于该请求和指示，访问该文件夹和该文件夹中的数据对象，并且，关于该文件夹中的每个数据对象：

如果在该数据对象中明确定义这至少一个属性，则检索那个数据对象的这至少一个属性，并将其返回到该电子邮件客户部件；以及，

如果没有为该数据对象明确定义这至少一个属性，则检索该数据对象，并将其返回到该电子邮件客户部件。

27.如权利要求26的计算机可读介质，其特征在于，该请求包括关于这些数据对象位于其中的文件夹的同步的请求。

28.如权利要求26的计算机可读介质，其特征在于，该请求包括关于电子邮件消息的复制件的请求。

29.如权利要求26的计算机可读介质，其特征在于，该指示包括与该请求一起被包括的标记。

30.如权利要求26的计算机可读介质，其特征在于，这至少一个属性包括消息的头部。

31.一种被具体表现在计算机可读介质上的数据分组，其特征在于，包括：

识别电子邮件客户部件的第一数据区；

包括关于至少一个电子邮件消息的请求的第二数据区；以及，

包括一个指示的第三数据区，该指示指出：该电子邮件客户部件希望电子邮件消息采用统一字符编码格式。

32.如权利要求31的数据分组，其特征在于，该指示包括与该请求一起被包括的标记。

33.如权利要求31的数据分组，其特征在于，该请求包括关于这些电子邮件数据对象位于其中的文件夹的同步的请求。

34.如权利要求31的数据分组，其特征在于，该请求包括关于电子邮件消息的复制件的请求。

35.一种具有计算机可执行指令的计算机可读介质，其特征在于，这些指令包括：

从电子邮件客户部件接收关于至少一个电子邮件消息的请求以及一个指示，该指示指出：该电子邮件客户部件希望电子邮件消息采用统一字符编码格式；

响应于该请求和指示，检索这至少一个消息；并且，关于每个电子邮件消息：

如果该电子邮件消息可采用统一字符编码格式，则将该统一字符编码格式提供给该电子邮件客户部件；以及，

如果该电子邮件消息没有采用统一字符编码格式，则将该电子邮件消息转换成统一字符编码格式，并将该统一字符编码格式提供给该电子邮件客户部件。

36.如权利要求35的计算机可读介质，其特征在于，该指示包括与该请求一起被包括的标记。

37.如权利要求35的计算机可读介质，其特征在于，该请求包括关于这些电子邮件数据对象位于其中的文件夹的同步的请求。

38.如权利要求35的计算机可读介质，其特征在于，该请求包括关于电子邮件消息的复制件的请求。

39.一种计算机执行方法，其特征在于，包括：

从电子邮件客户部件发送关于至少一个电子邮件消息的请求以及一个指示，该指示指出：该电子邮件客户部件希望电子邮件消息采用统一字符编码格式；

在电子邮件服务器部件处，响应于该请求和指示的接收，检索这至少一个消息；并且，关于每个电子邮件消息：

40.如权利要求39的方法，其特征在于，该指示包括与该请求一起被包括的标记。

41.如权利要求39的方法，其特征在于，该请求包括关于这些电子邮件数据对象位于其中的文件夹的同步的请求。

42.如权利要求39的方法，其特征在于，该请求包括关于电子邮件消息的复制件的请求。