跳到主要内容

5. 操作考虑 (Operational Considerations)

  1. CTL 和其它非图形字符难以在用户界面中表示, 最好避免使用.

  2. 虽然 list-wildcard 字符 ("%" 和 "*") 在 mailbox 名称中有效, 但由于会与通配符解释冲突, 这类 mailbox 名称很难与 LIST 和 LSUB 命令一起使用.

RFC 3501 IMAPv4 March 2003

  1. 通常会保留一个字符 (由服务器实现决定), 用于分隔层级中的各级.

  2. 两个字符 "#" 和 "&" 按约定具有含义, 除非用于该约定, 否则应避免使用.

5.1.1. Mailbox 层级命名 (Mailbox Hierarchy Naming)​

如果需要导出层级式 mailbox 名称, mailbox 名称 MUST 采用从左到右的层级结构, 并使用单个字符分隔层级. 单个名称中的所有层级都使用相同的层级分隔字符.

5.1.2. Mailbox 命名空间命名约定 (Mailbox Namespace Naming Convention)​

按约定, 任何以 "#" 开头的 mailbox 名称的第一个层级元素标识该名称剩余部分的 "namespace".这使得区分不同类型的 mailbox stores 成为可能, 每种 mailbox store 都有自己的 namespace.

例如, 提供访问 USENET newsgroups 的实现 MAY 使用 "#news" namespace, 将 USENET newsgroup namespace 与其它 mailboxes 的 namespace 分隔开. 因此, comp.mail.misc newsgroup 的 mailbox 名称会是 "#news.comp.mail.misc", 而名称 "comp.mail.misc" 可以指代另一个对象 (例如用户的私有 mailbox).

5.1.3. Mailbox 国际化命名约定 (Mailbox International Naming Convention)​

按约定, IMAP4rev1 中的国际化 mailbox 名称使用 [UTF-7] 中描述的 UTF-7 编码修改版来指定. Modified UTF-7 也可能可用于实现本协议早期版本的服务器.

在 modified UTF-7 中, 除 "&" 外的可打印 US-ASCII 字符表示其自身; 即八位组值为 0x20-0x25 和 0x27-0x7e 的字符. 字符 "&" (0x26) 由两个八位组序列 "&-" 表示.

所有其它字符 (八位组值 0x00-0x1f 和 0x7f-0xff) 都以 modified BASE64 表示, 并在 [UTF-7] 基础上进一步修改为使用 "," 代替 "/".Modified BASE64 MUST NOT 用于表示任何可表示自身的可打印 US-ASCII 字符.

RFC 3501 IMAPv4 March 2003

"&" 用于切换到 modified BASE64, "-" 用于切换回 US-ASCII.不存在从 BASE64 到 US-ASCII 的隐式切换, 并且不允许空切换 (在 BASE64 中的 "-&"; 注意在 US-ASCII 中 "&-" 表示 "&"). 但是, 所有名称都从 US-ASCII 开始, 并且 MUST 以 US-ASCII 结束; 也就是说, 以非 ASCII ISO-10646 字符结尾的名称 MUST 以 "-" 结尾.

这些修改的目的是纠正 UTF-7 的以下问题:

  1) UTF-7 使用 "+" 字符进行切换; 这与 mailbox 名称中 "+" 的常见用法冲突, 尤其是 USENET newsgroup 名称.

  2) UTF-7 的编码是 BASE64, 它使用 "/" 字符; 这与 "/" 作为常用层级分隔符的用法冲突.

  3) UTF-7 禁止未编码地使用 "\"; 这与 "\" 作为常用层级分隔符的用法冲突.

  4) UTF-7 禁止未编码地使用 "~"; 这与某些服务器中 "~" 作为 home directory 指示符的用法冲突.

  5) UTF-7 允许使用多个替代形式表示同一 string; 特别是, 可打印 US-ASCII 字符可以用编码形式表示.

  虽然 modified UTF-7 是一种约定, 但它对服务器处理任何嵌入 "&" 字符的 mailbox 名称确立了某些要求. 特别是, 服务器实现 MUST 保留 modified UTF-7 名称中 modified BASE64 部分的精确形式, 并将该文本视为区分大小写, 即使名称在其它方面不区分大小写或会进行大小写折叠.

  服务器实现 SHOULD 验证作为 CREATE 参数使用且嵌入 "&" 字符的任何 mailbox 名称满足以下条件: 使用正确的 modified UTF-7 语法, 没有多余切换, 并且没有在 modified BASE64 中编码任何可表示自身的可打印 US-ASCII 字符. 但是, 客户端实现 MUST NOT 依赖服务器执行此验证, 并且 SHOULD NOT 尝试创建嵌入 "&" 字符的 mailbox 名称, 除非该名称符合 modified UTF-7 语法.

  导出不遵循 modified UTF-7 约定的 mail store 的服务器实现, MUST 将任何包含非 ASCII 字符或 "&" 字符的 mailbox 名称转换为 modified UTF-7.

RFC 3501 IMAPv4 March 2003

       例如, 下面是一个混合 English, Chinese 和 Japanese 文本的 mailbox 名称:
       ~peter/mail/&U,BTFw-/&ZeVnLIqe-

       例如, string "&Jjo!" 不是有效的 mailbox 名称, 因为它在 "!" 之前没有包含切换回 US-ASCII 的标记. 正确形式是 "&Jjo-!".string "&U,BTFw-&ZeVnLIqe-" 不被允许, 因为它包含多余切换. 正确形式是 "&U,BTF2XlZyyKng-".

5.2. Mailbox 大小和消息状态更新 (Mailbox Size and Message Status Updates)​

服务器可以在任何时候发送客户端未请求的数据. 有时, 这种行为是 REQUIRED.例如, 服务器以外的 agents MAY 向 mailbox 添加消息 (例如新消息投递), 更改 mailbox 中消息的 flags (例如多个 agents 同时访问同一 mailbox), 甚至从 mailbox 中移除消息. 如果在处理命令期间观察到 mailbox 大小变化, 服务器 MUST 自动发送 mailbox 大小更新. 服务器 SHOULD 自动发送消息 flag 更新, 而不要求客户端显式请求这些更新.

为了防止同步错误, 对服务器向客户端通知消息移除存在特殊规则; 更多细节见 EXPUNGE response 的描述. 特别是, 不允许发送会减少 mailbox 中消息数量的 EXISTS response; 只有 EXPUNGE response 可以做到这一点.

无论客户端在记住服务器数据方面作出何种实现决策, 客户端实现 MUST 记录 mailbox 大小更新. 它 MUST NOT 假定初始 mailbox 选择之后的任何命令都会返回 mailbox 大小.

5.3. 没有命令正在进行时的响应 (Response when no Command in Progress)​

服务器实现允许在没有命令正在进行时发送 untagged response (EXPUNGE 除外). 发送此类响应的服务器实现 MUST 处理流量控制方面的考虑. 具体而言, 它们 MUST 要么 (1) 验证数据大小不超过底层传输的可用窗口大小, 要么 (2) 使用非阻塞写入.

RFC 3501 IMAPv4 March 2003

5.4. 自动注销计时器 (Autologout Timer)​

如果服务器有不活动自动注销计时器, 该计时器的持续时间 MUST 至少为 30 分钟. 在该间隔内收到客户端的 ANY 命令 SHOULD 足以重置自动注销计时器.

5.5. 多个命令正在进行 (Multiple Commands in Progress)​

客户端 MAY 在不等待某个命令的完成结果响应的情况下发送另一个命令, 但须遵守歧义规则 (见下文) 和底层数据流的流量控制约束. 类似地, 服务器 MAY 在当前命令处理完成前开始处理另一个命令, 但须遵守歧义规则. 但是, 任何命令续行请求响应和命令续行 MUST 在发起任何后续命令之前协商完成.

例外情况是, 某个命令会影响其它命令的结果, 从而产生歧义. 如果会产生歧义, 客户端 MUST NOT 在不等待的情况下发送多个命令. 如果服务器检测到可能的歧义, 它 MUST 按客户端给出的顺序将命令执行到完成.

最明显的歧义示例是某个命令会影响另一个命令的结果, 例如对一条消息 flags 的 FETCH 和对同一条消息 flags 的 STORE.

不明显的歧义出现在允许 untagged EXPUNGE response 的命令中 (FETCH, STORE 和 SEARCH 以外的命令), 因为 untagged EXPUNGE response 可能使后续命令中的序列号失效. 对于 FETCH, STORE 或 SEARCH 命令, 这不是问题, 因为服务器被禁止在这些命令中任何一个正在进行时发送 EXPUNGE responses.因此, 如果客户端发送 FETCH, STORE 或 SEARCH 以外的任何命令, 它 MUST 在发送带有消息序列号的命令前等待完成结果响应.

注意: UID FETCH, UID STORE 和 UID SEARCH 是不同于 FETCH, STORE 和 SEARCH 的命令. 如果客户端发送 UID 命令, 它必须在发送带有消息序列号的命令前等待完成结果响应.