Python论坛 - 讨论区
标题：[python-chinese] xmpp ( jabber ) 中文翻译
2005年07月05日 星期二 09:29
run_mei run_mei at 163.com
Tue Jul 5 09:29:43 HKT 2005
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Tue Jul 5 09:29:43 HKT 2005
大家好，我觉得即时通时技术是一个有趣的技术，而xmpp ( jabber )技术是唯一 的开源的协议，它有很多激动人心的特征，我对它有兴趣，但好象没有中文资料， 我想翻译它的英文文档，可是我的英文水平不高，所以我想找人帮我一起来翻译 它，我已经翻译了一点。我想找个地方把它共亨出来，同时请大家帮我将翻译错误 的地方纠正过来。 请问可不可在在www.woodpecker.org上建一个目录存放它。
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2005年07月05日 星期二 09:34
cpunion cpunion at 263.net
Tue Jul 5 09:34:34 HKT 2005
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Tue Jul 5 09:34:34 HKT 2005
http://blog.csdn.net/kunp/ 有人翻译了一些。 刚好在研究。。 run_mei wrote: > 大家好，我觉得即时通时技术是一个有趣的技术，而xmpp ( jabber )技术是唯一 >的开源的协议，它有很多激动人心的特征，我对它有兴趣，但好象没有中文资料， >我想翻译它的英文文档，可是我的英文水平不高，所以我想找人帮我一起来翻译 >它，我已经翻译了一点。我想找个地方把它共亨出来，同时请大家帮我将翻译错误 >的地方纠正过来。 >请问可不可在在www.woodpecker.org上建一个目录存放它。 > >_______________________________________________ >python-chinese list >python-chinese at lists.python.cn >http://python.cn/mailman/listinfo/python-chinese > > > >
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2005年07月05日 星期二 09:37
Zoom Quiet zoom.quiet at gmail.com
Tue Jul 5 09:37:51 HKT 2005
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Tue Jul 5 09:37:51 HKT 2005
呀呀呀！！好想法哪！！ 本来 Wiki 的建立就是给大家一个共同组织文章和代码想法的地方！ 最初就是为了组织翻译 twisted 文档而创建的哪！！ 你随时可以启动此文档项目是也乎！ 我随手先在 http://wiki.woodpecker.org.cn/moin/WoodpeckerDocuments 中启动了 xmpp 协议文档 章节，你可以仿造 http://wiki.woodpecker.org.cn/moin/PyCookbook 先组织原文，然后召集有兴趣的快速翻译是也乎是也乎………… 在 05-7-5，run_mei<run_mei at 163.com> 写道： > 大家好，我觉得即时通时技术是一个有趣的技术，而xmpp ( jabber )技术是唯一 > 的开源的协议，它有很多激动人心的特征，我对它有兴趣，但好象没有中文资料， > 我想翻译它的英文文档，可是我的英文水平不高，所以我想找人帮我一起来翻译 > 它，我已经翻译了一点。我想找个地方把它共亨出来，同时请大家帮我将翻译错误 > 的地方纠正过来。 > 请问可不可在在www.woodpecker.org上建一个目录存放它。 > > _______________________________________________ > python-chinese list > python-chinese at lists.python.cn > http://python.cn/mailman/listinfo/python-chinese > -- [Time is unimportant, only life important!]
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2005年07月05日 星期二 09:41
Zoom Quiet zoom.quiet at gmail.com
Tue Jul 5 09:41:17 HKT 2005
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Tue Jul 5 09:41:17 HKT 2005
Great!! 中国还是有能人的哪！！！！！ 收藏！Blogline 关注之！ 2005/7/5, cpunion <cpunion at 263.net>: > http://blog.csdn.net/kunp/ > 有人翻译了一些。 > 刚好在研究。。 > > run_mei wrote: > > > 大家好，我觉得即时通时技术是一个有趣的技术，而xmpp ( jabber )技术是唯一 > >的开源的协议，它有很多激动人心的特征，我对它有兴趣，但好象没有中文资料， > >我想翻译它的英文文档，可是我的英文水平不高，所以我想找人帮我一起来翻译 > >它，我已经翻译了一点。我想找个地方把它共亨出来，同时请大家帮我将翻译错误 > >的地方纠正过来。 > >请问可不可在在www.woodpecker.org上建一个目录存放它。 > > > >_______________________________________________ > >python-chinese list > >python-chinese at lists.python.cn > >http://python.cn/mailman/listinfo/python-chinese > > > > > > > > > _______________________________________________ > python-chinese list > python-chinese at lists.python.cn > http://python.cn/mailman/listinfo/python-chinese > -- [Time is unimportant, only life important!]
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2005年07月05日 星期二 12:38
wangmm kernellearn at gmail.com
Tue Jul 5 12:38:11 HKT 2005
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Tue Jul 5 12:38:11 HKT 2005
twisted好多连接不能用了啊。 hd的blog也访问不了啦。 不知道在哪里能找到比较完整的信息呢？ On 7/5/05, Zoom Quiet <zoom.quiet at gmail.com> wrote: > Great!! > 中国还是有能人的哪！！！！！ > 收藏！Blogline 关注之！ > > 2005/7/5, cpunion <cpunion at 263.net>: > > http://blog.csdn.net/kunp/ > > 有人翻译了一些。 > > 刚好在研究。。 > > > > run_mei wrote: > > > > > 大家好，我觉得即时通时技术是一个有趣的技术，而xmpp ( jabber )技术是唯一 > > >的开源的协议，它有很多激动人心的特征，我对它有兴趣，但好象没有中文资料， > > >我想翻译它的英文文档，可是我的英文水平不高，所以我想找人帮我一起来翻译 > > >它，我已经翻译了一点。我想找个地方把它共亨出来，同时请大家帮我将翻译错误 > > >的地方纠正过来。 > > >请问可不可在在www.woodpecker.org上建一个目录存放它。 > > > > > >_______________________________________________ > > >python-chinese list > > >python-chinese at lists.python.cn > > >http://python.cn/mailman/listinfo/python-chinese > > > > > > > > > > > > > > _______________________________________________ > > python-chinese list > > python-chinese at lists.python.cn > > http://python.cn/mailman/listinfo/python-chinese > > > > > -- > [Time is unimportant, only life important!] >
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2005年07月05日 星期二 13:34
shhgs shhgs.efhilt at gmail.com
Tue Jul 5 13:34:18 HKT 2005
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Tue Jul 5 13:34:18 HKT 2005
算上我 On 7/5/05, wangmm <kernellearn at gmail.com> wrote: > twisted好多连接不能用了啊。 > hd的blog也访问不了啦。 > 不知道在哪里能找到比较完整的信息呢？ > > On 7/5/05, Zoom Quiet <zoom.quiet at gmail.com> wrote: > > Great!! > > 中国还是有能人的哪！！！！！ > > 收藏！Blogline 关注之！ > > > > 2005/7/5, cpunion <cpunion at 263.net>: > > > http://blog.csdn.net/kunp/ > > > 有人翻译了一些。 > > > 刚好在研究。。 > > > > > > run_mei wrote: > > > > > > > 大家好，我觉得即时通时技术是一个有趣的技术，而xmpp ( jabber )技术是唯一 > > > >的开源的协议，它有很多激动人心的特征，我对它有兴趣，但好象没有中文资料， > > > >我想翻译它的英文文档，可是我的英文水平不高，所以我想找人帮我一起来翻译 > > > >它，我已经翻译了一点。我想找个地方把它共亨出来，同时请大家帮我将翻译错误 > > > >的地方纠正过来。 > > > >请问可不可在在www.woodpecker.org上建一个目录存放它。 > > > > > > > >_______________________________________________ > > > >python-chinese list > > > >python-chinese at lists.python.cn > > > >http://python.cn/mailman/listinfo/python-chinese > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > python-chinese list > > > python-chinese at lists.python.cn > > > http://python.cn/mailman/listinfo/python-chinese > > > > > > > > > -- > > [Time is unimportant, only life important!] > > > > _______________________________________________ > python-chinese list > python-chinese at lists.python.cn > http://python.cn/mailman/listinfo/python-chinese > > >
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2005年07月05日 星期二 13:42
run_mei run_mei at 163.com
Tue Jul 5 13:42:50 HKT 2005
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Tue Jul 5 13:42:50 HKT 2005
好了，我将4篇RFC文档传上去了，其它的我有空再传上去，前2篇我排版排好了， 后2篇我还没有来的及排版，看起来很乱，我会在适当的时候排好。 请大家一起努力吧! Zoom Quiet 写道: >呀呀呀！！好想法哪！！ >本来 Wiki 的建立就是给大家一个共同组织文章和代码想法的地方！ > >最初就是为了组织翻译 twisted 文档而创建的哪！！ > >你随时可以启动此文档项目是也乎！ >我随手先在 >http://wiki.woodpecker.org.cn/moin/WoodpeckerDocuments >中启动了 >xmpp 协议文档 章节，你可以仿造 >http://wiki.woodpecker.org.cn/moin/PyCookbook >先组织原文，然后召集有兴趣的快速翻译是也乎是也乎………… > > > >在 05-7-5，run_mei<run_mei at 163.com> 写道： > > >> 大家好，我觉得即时通时技术是一个有趣的技术，而xmpp ( jabber )技术是唯一 >>的开源的协议，它有很多激动人心的特征，我对它有兴趣，但好象没有中文资料， >>我想翻译它的英文文档，可是我的英文水平不高，所以我想找人帮我一起来翻译 >>它，我已经翻译了一点。我想找个地方把它共亨出来，同时请大家帮我将翻译错误 >>的地方纠正过来。 >>请问可不可在在www.woodpecker.org上建一个目录存放它。 >> >>_______________________________________________ >>python-chinese list >>python-chinese at lists.python.cn >>http://python.cn/mailman/listinfo/python-chinese >> >> >> > > > > >------------------------------------------------------------------------ > >_______________________________________________ >python-chinese list >python-chinese at lists.python.cn >http://python.cn/mailman/listinfo/python-chinese > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20050705/1bdc7a2d/attachment.html
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2005年07月05日 星期二 16:51
shiziliang shizl at bis.com.cn
Tue Jul 5 16:51:46 HKT 2005
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Tue Jul 5 16:51:46 HKT 2005
请问大虾怎么组织？ 你先写个方案，怎么样？ 分析一下文档的规模，和需要的人手数，和修正方案 ----- Original Message ----- From: "run_mei" <run_mei at 163.com> To: <python-chinese at lists.python.cn> Sent: Tuesday, July 05, 2005 9:29 AM Subject: [python-chinese] xmpp ( jabber ) 中文翻译 > 大家好，我觉得即时通时技术是一个有趣的技术，而xmpp ( jabber )技术是唯一 > 的开源的协议，它有很多激动人心的特征，我对它有兴趣，但好象没有中文资料， > 我想翻译它的英文文档，可是我的英文水平不高，所以我想找人帮我一起来翻译 > 它，我已经翻译了一点。我想找个地方把它共亨出来，同时请大家帮我将翻译错误 > 的地方纠正过来。 > 请问可不可在在www.woodpecker.org上建一个目录存放它。 > > _______________________________________________ > python-chinese list > python-chinese at lists.python.cn > http://python.cn/mailman/listinfo/python-chinese > >
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2005年07月05日 星期二 18:00
run_mei run_mei at 163.com
Tue Jul 5 18:00:38 HKT 2005
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Tue Jul 5 18:00:38 HKT 2005
我不是大虾，如果你想帮忙的话请到http://wiki.woodpecker.org.cn/moin/JabberOrg shiziliang 写道: >请问大虾怎么组织？ > >你先写个方案，怎么样？ >分析一下文档的规模，和需要的人手数，和修正方案 > > >----- Original Message ----- >From: "run_mei" <run_mei at 163.com> >To: <python-chinese at lists.python.cn> >Sent: Tuesday, July 05, 2005 9:29 AM >Subject: [python-chinese] xmpp ( jabber ) 中文翻译 > > > > >>大家好，我觉得即时通时技术是一个有趣的技术，而xmpp ( jabber )技术是唯一 >>的开源的协议，它有很多激动人心的特征，我对它有兴趣，但好象没有中文资料， >>我想翻译它的英文文档，可是我的英文水平不高，所以我想找人帮我一起来翻译 >>它，我已经翻译了一点。我想找个地方把它共亨出来，同时请大家帮我将翻译错误 >>的地方纠正过来。 >>请问可不可在在www.woodpecker.org上建一个目录存放它。 >> >>_______________________________________________ >>python-chinese list >>python-chinese at lists.python.cn >>http://python.cn/mailman/listinfo/python-chinese >> >> >> >> > >------------------------------------------------------------------------ > >_______________________________________________ >python-chinese list >python-chinese at lists.python.cn >http://python.cn/mailman/listinfo/python-chinese > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20050705/b806e335/attachment.html
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2005年07月05日 星期二 18:06
shhgs shhgs.efhilt at gmail.com
Tue Jul 5 18:06:10 HKT 2005
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Tue Jul 5 18:06:10 HKT 2005
规模很大，我着手的RFC 3921有5000多行，20000多个单词，算下来要由4万多字，估计要有1个月才能翻出来。 我建议，谁想翻译，就在文档后面签一个名，然后别人暂时不要翻了。 还有，可以先做一个节译，把技术上重要的地方先翻出来，其它的先放一放。 此外，我总觉得WIKI很不方便，我都是在自己的机器上对着txt翻译的，用wiki还要排版，很不爽。 On 7/5/05, shiziliang <shizl at bis.com.cn> wrote: > 请问大虾怎么组织？ > > 你先写个方案，怎么样？ > 分析一下文档的规模，和需要的人手数，和修正方案 > > > ----- Original Message ----- > From: "run_mei" <run_mei at 163.com> > To: <python-chinese at lists.python.cn> > Sent: Tuesday, July 05, 2005 9:29 AM > Subject: [python-chinese] xmpp ( jabber ) 中文翻译 > > > > 大家好，我觉得即时通时技术是一个有趣的技术，而xmpp ( jabber )技术是唯一 > > 的开源的协议，它有很多激动人心的特征，我对它有兴趣，但好象没有中文资料， > > 我想翻译它的英文文档，可是我的英文水平不高，所以我想找人帮我一起来翻译 > > 它，我已经翻译了一点。我想找个地方把它共亨出来，同时请大家帮我将翻译错误 > > 的地方纠正过来。 > > 请问可不可在在www.woodpecker.org上建一个目录存放它。 > > > > _______________________________________________ > > python-chinese list > > python-chinese at lists.python.cn > > http://python.cn/mailman/listinfo/python-chinese > > > > > _______________________________________________ > python-chinese list > python-chinese at lists.python.cn > http://python.cn/mailman/listinfo/python-chinese > > >
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2005年07月05日 星期二 18:09
shhgs shhgs.efhilt at gmail.com
Tue Jul 5 18:09:39 HKT 2005
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Tue Jul 5 18:09:39 HKT 2005
以下是今天翻译的
――――――――――――――――――――――――――――――――――
Network Working Group P. Saint-Andre, Ed.
Request for Comments: 3921 Jabber Software Foundation
Category: Standards Track October 2004
Extensible Messaging and Presence Protocol (XMPP):
Instant Messaging and Presence
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This memo describes extensions to and applications of the core
features of the Extensible Messaging and Presence Protocol (XMPP)
that provide the basic instant messaging (IM) and presence
functionality defined in RFC 2779.
Saint-Andre Standards Track [Page 1]
RFC 3921 XMPP IM October 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Syntax of XML Stanzas . . . . . . . . . . . . . . . . . . . 4
3. Session Establishment . . . . . . . . . . . . . . . . . . . 10
4. Exchanging Messages . . . . . . . . . . . . . . . . . . . . 13
5. Exchanging Presence Information . . . . . . . . . . . . . . 16
6. Managing Subscriptions . . . . . . . . . . . . . . . . . . . 26
7. Roster Management . . . . . . . . . . . . . . . . . . . . . 27
8. Integration of Roster Items and Presence Subscriptions . . . 32
9. Subscription States . . . . . . . . . . . . . . . . . . . . 56
10. Blocking Communication . . . . . . . . . . . . . . . . . . . 62
11. Server Rules for Handling XML Stanzas . . . . . . . . . . . 85
12. IM and Presence Compliance Requirements . . . . . . . . . . 88
13. Internationalization Considerations . . . . . . . . . . . . 89
14. Security Considerations . . . . . . . . . . . . . . . . . . 89
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 90
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 91
A. vCards . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
B. XML Schemas. . . . . . . . . . . . . . . . . . . . . . . . . 93
C. Differences Between Jabber IM/Presence Protocols and XMPP. . 105
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 106
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 106
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 107
1. Introduction
1.1. Overview
The Extensible Messaging and Presence Protocol (XMPP) is a protocol
for streaming XML [XML] elements in order to exchange messages and
presence information in close to real time. The core features of
XMPP are defined in Extensible Messaging and Presence Protocol
(XMPP): Core [XMPP-CORE]. These features -- mainly XML streams, use
of TLS and SASL, and the , , and children
of the stream root -- provide the building blocks for many types of
near-real-time applications, which may be layered on top of the core
by sending application-specific data qualified by particular XML
namespaces [XML-NAMES]. This memo describes extensions to and
applications of the core features of XMPP that provide the basic
functionality expected of an instant messaging (IM) and presence
application as defined in RFC 2779 [IMP-REQS].
Saint-Andre Standards Track [Page 2]
RFC 3921 XMPP IM October 2004
1.2. Requirements
For the purposes of this memo, the requirements of a basic instant
messaging and presence application are defined by [IMP-REQS], which
at a high level stipulates that a user must be able to complete the
following use cases:
作为本文档的基础，基本的IM和"在线应用程序presence application"的要求
刊载在[IMP-REQS]里面。这份文档在大体上规定了用户必须能完成如下的功能。
o Exchange messages with other users
与其它用户交换消息
o Exchange presence information with other users
与其它用户交换在线信息
o Manage subscriptions to and from other users
管理和限制自己或他人的在线信息的发布
o Manage items in a contact list (in XMPP this is called a "roster")
管理通讯录里的资料(XMPP称之为roster)
o Block communications to or from specific other users
切断与他人的通讯
Detailed definitions of these functionality areas are contained in
[IMP-REQS], and the interested reader is directed to that document
regarding the requirements addressed herein.
这些功能的详细定义刊载在[IMP-REQS]里，感兴趣的读者可以自己去看。
[IMP-REQS] also stipulates that presence services must be separable
from instant messaging services; i.e., it must be possible to use the
protocol to provide a presence service, an instant messaging service,
or both. Although the text of this memo assumes that implementations
and deployments will want to offer a unified instant messaging and
presence service, there is no requirement that a service must offer
both a presence service and an instant messaging service, and the
protocol makes it possible to offer separate and distinct services
for presence and for instant messaging.
[IMP-REQS]同时还规定，在线信息的服务必须与及时信息的服务相分离。比方说，
协议必须允许你只使用在线信息，或及时信息服务，当然也可以两个都用。虽然
我们认为真正实现的时候，在线信息和及时信息服务肯定是合二为一的，但是它
也没有强求你一定必须同时提供在线信息合及时信息服务。这个协议完全允许你
提供单独的在线信息或及时信息服务。
Note: While XMPP-based instant messaging and presence meets the
requirements of [IMP-REQS], it was not designed explicitly with that
specification in mind, since the base protocol evolved through an
open development process within the Jabber open-source community
before RFC 2779 was written. Note also that although protocols
addressing many other functionality areas have been defined in the
Jabber community, such protocols are not included in this memo
because they are not required by [IMP-REQS].
注意：虽然基于XMPP的及时信息和在线服务符合[IMP-REQS]的要求，但它并
不是刻意去实现的，因为Jabber开源社区早在RFC 2779发布之前就已经促成了
基本的协议。同时还要指出的是，虽然Jabber社区还为协议设计了很多别的方面
的功能，但由于[IMP-REQS]并没有要求，因此我们这里也就不涉及了。
1.3. Terminology
This memo inherits the terminology defined in [XMPP-CORE].
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14, RFC 2119 [TERMS].
Saint-Andre Standards Track [Page 3]
RFC 3921 XMPP IM October 2004
2. Syntax of XML Stanzas
XML Stanzas的语法
The basic semantics and common attributes of XML stanzas qualified by
the 'jabber:client' and 'jabber:server' namespaces are defined in
[XMPP-CORE]. However, these namespaces also define various child
elements, as well as values for the common 'type' attribute, that are
specific to instant messaging and presence applications. Thus,
before addressing particular "use cases" for such applications, we
here further describe the syntax of XML stanzas, thereby
supplementing the discussion in [XMPP-CORE].
XML stanzas都归在'jabber:client'和'jabber:server'名字空间之下，其基本语义
和常用属性由[XMPP-CORE]定义。除了常用的'type'属性的值之外，这两个名字空间
还定义了很多专供及时信息或在线信息服务的child elements。因此在描述此类应用
程序的"use case"之前，我们先探讨一下XML stanzas的语法，也借此补充一下
[XMPP-CORE]。
2.1. Message Syntax
Message stanzas qualified by the 'jabber:client' or 'jabber:server'
namespace are used to "push" information to another entity. Common
uses in instant messaging applications include single messages,
messages sent in the context of a chat conversation, messages sent in
the context of a multi-user chat room, headlines and other alerts,
and errors.
归在'jabber:client'或'jabber:server'名字空间之下的Message stanzas是用来
向另一个entity"推"信息用的。在IM应用程序里，这种stanzas常用被用于发送"单条
消息(single message)"，在chat环境下发送消息，在多用户的chat room的环境下
发送消息，以及发送headline，警告和错误消息。
2.1.1. Types of Message
The 'type' attribute of a message stanza is RECOMMENDED; if included,
it specifies the conversational context of the message, thus
providing a hint regarding presentation (e.g., in a GUI). If
included, the 'type' attribute MUST have one of the following values:
message stanza的'type'属性是RECOMMENDED的；如果有，它表示这个消息是在怎样
的交谈环境下发出的，因此它也暗示了该怎样显示这条消息(比方说在GUI环境下)。
'type'属性如果有必须(MUST)是下面值里的一个。
o chat -- The message is sent in the context of a one-to-one chat
conversation. A compliant client SHOULD present the message in an
interface enabling one-to-one chat between the two parties,
including an appropriate conversation history.
chat -- 消息是在一对一的chat谈话中发出的。客户端应当(SHOULD)在一个
能让用户进行一对一谈话的界面里提示这条消息，包括交谈的记录。
o error -- An error has occurred related to a previous message sent
by the sender (for details regarding stanza error syntax, refer to
[XMPP-CORE]). A compliant client SHOULD present an appropriate
interface informing the sender of the nature of the error.
error -- 表示先前发送的消息发生了错误(关于stanza的错误的语法，
请参阅[XMPP-CORE])。客户端应当(SHOULD)能告诉发送发错误的性质。
o groupchat -- The message is sent in the context of a multi-user
chat environment (similar to that of [IRC]). A compliant client
SHOULD present the message in an interface enabling many-to-many
chat between the parties, including a roster of parties in the
chatroom and an appropriate conversation history. Full definition
of XMPP-based groupchat protocols is out of scope for this memo.
groupchat -- 这条消息是在多用户交谈环境下发出的(类似[IRC])。客户端
应当(SHOULD)在能允许用户进行多对多谈话的界面里显示这条消息，这其中
应该包括chat room的参与者的roster(名单)，以及适当的谈话记录。基于XMPP
的群组交谈协议超出了本文档的范围。
o headline -- The message is probably generated by an automated
service that delivers or broadcasts content (news, sports, market
information, RSS feeds, etc.). No reply to the message is
expected, and a compliant client SHOULD present the message in an
Saint-Andre Standards Track [Page 4]
RFC 3921 XMPP IM October 2004
interface that appropriately differentiates the message from
standalone messages, chat sessions, or groupchat sessions (e.g.,
by not providing the recipient with the ability to reply).
headline -- 这条消息或许是由某个后台服务生成并发送或广播的(新闻，体育，
市场信息，RSS服务等到)。它不需要用户的回应。客户端应当(SHOULD)在
一个合适的界面下提示这条消息以将其与"standalone message"，"chat session"
和"groupchat session"相区分(比方说用户只能看不能reply)。
o normal -- The message is a single message that is sent outside the
context of a one-to-one conversation or groupchat, and to which it
is expected that the recipient will reply. A compliant client
SHOULD present the message in an interface enabling the recipient
to reply, but without a conversation history.
normal -- 这是一个single message，既不是一对一的交谈，也不是群组交谈，
而且允许接受方回应。客户端应当(SHOULD)在一个能让用户reply的界面里显示
这条消息，但是不要有谈话记录。
――――――――――――――――――――――――――――――――――――
On 7/5/05, shhgs <shhgs.efhilt at gmail.com> wrote:
> 规模很大，我着手的RFC 3921有5000多行，20000多个单词，算下来要由4万多字，估计要有1个月才能翻出来。
>
> 我建议，谁想翻译，就在文档后面签一个名，然后别人暂时不要翻了。
>
> 还有，可以先做一个节译，把技术上重要的地方先翻出来，其它的先放一放。
>
> 此外，我总觉得WIKI很不方便，我都是在自己的机器上对着txt翻译的，用wiki还要排版，很不爽。
>
>
> On 7/5/05, shiziliang <shizl at bis.com.cn> wrote:
> > 请问大虾怎么组织？
> >
> > 你先写个方案，怎么样？
> > 分析一下文档的规模，和需要的人手数，和修正方案
> >
> >
> > ----- Original Message -----
> > From: "run_mei" <run_mei at 163.com>
> > To: <python-chinese at lists.python.cn>
> > Sent: Tuesday, July 05, 2005 9:29 AM
> > Subject: [python-chinese] xmpp ( jabber ) 中文翻译
> >
> >
> > > 大家好，我觉得即时通时技术是一个有趣的技术，而xmpp ( jabber )技术是唯一
> > > 的开源的协议，它有很多激动人心的特征，我对它有兴趣，但好象没有中文资料，
> > > 我想翻译它的英文文档，可是我的英文水平不高，所以我想找人帮我一起来翻译
> > > 它，我已经翻译了一点。我想找个地方把它共亨出来，同时请大家帮我将翻译错误
> > > 的地方纠正过来。
> > > 请问可不可在在www.woodpecker.org上建一个目录存放它。
> > >
> > > _______________________________________________
> > > python-chinese list
> > > python-chinese at lists.python.cn
> > > http://python.cn/mailman/listinfo/python-chinese
> > >
> > >
> > _______________________________________________
> > python-chinese list
> > python-chinese at lists.python.cn
> > http://python.cn/mailman/listinfo/python-chinese
> >
> >
> >
>
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2005年07月05日 星期二 18:52
Zoom Quiet zoom.quiet at gmail.com
Tue Jul 5 18:52:56 HKT 2005
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Tue Jul 5 18:52:56 HKT 2005
可以先使用
{{{
}}}
框住所有的文字，不进行排版哪？？
翻译的内容先有了，排版可以后期进行的哪………………
在 05-7-5，shhgs<shhgs.efhilt at gmail.com> 写道：
> 规模很大，我着手的RFC 3921有5000多行，20000多个单词，算下来要由4万多字，估计要有1个月才能翻出来。
>
> 我建议，谁想翻译，就在文档后面签一个名，然后别人暂时不要翻了。
>
> 还有，可以先做一个节译，把技术上重要的地方先翻出来，其它的先放一放。
>
> 此外，我总觉得WIKI很不方便，我都是在自己的机器上对着txt翻译的，用wiki还要排版，很不爽。
>
>
> On 7/5/05, shiziliang <shizl at bis.com.cn> wrote:
> > 请问大虾怎么组织？
> >
> > 你先写个方案，怎么样？
> > 分析一下文档的规模，和需要的人手数，和修正方案
> >
> >
> > ----- Original Message -----
> > From: "run_mei" <run_mei at 163.com>
> > To: <python-chinese at lists.python.cn>
> > Sent: Tuesday, July 05, 2005 9:29 AM
> > Subject: [python-chinese] xmpp ( jabber ) 中文翻译
> >
> >
> > > 大家好，我觉得即时通时技术是一个有趣的技术，而xmpp ( jabber )技术是唯一
> > > 的开源的协议，它有很多激动人心的特征，我对它有兴趣，但好象没有中文资料，
> > > 我想翻译它的英文文档，可是我的英文水平不高，所以我想找人帮我一起来翻译
> > > 它，我已经翻译了一点。我想找个地方把它共亨出来，同时请大家帮我将翻译错误
> > > 的地方纠正过来。
> > > 请问可不可在在www.woodpecker.org上建一个目录存放它。
> > >
> > > _______________________________________________
> > > python-chinese list
> > > python-chinese at lists.python.cn
> > > http://python.cn/mailman/listinfo/python-chinese
> > >
> > >
> > _______________________________________________
> > python-chinese list
> > python-chinese at lists.python.cn
> > http://python.cn/mailman/listinfo/python-chinese
> >
> >
> >
>
> _______________________________________________
> python-chinese list
> python-chinese at lists.python.cn
> http://python.cn/mailman/listinfo/python-chinese
>
>
>
--
[Time is unimportant, only life important!]
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2005年07月05日 星期二 18:54
Zoom Quiet zoom.quiet at gmail.com
Tue Jul 5 18:54:01 HKT 2005
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Tue Jul 5 18:54:01 HKT 2005
大部头的文章，应该分子页面，章节来分别翻译的， 否则的确非常难以保持翻译的进度………… 在 05-7-5，shhgs<shhgs.efhilt at gmail.com> 写道： > 以下是今天翻译的 > ―――――――――――――――――――――――――――――――――― > > Network Working Group P. Saint-Andre, Ed. > Request for Comments: 3921 Jabber Software Foundation > Category: Standards Track October 2004 > > Extensible Messaging and Presence Protocol (XMPP): > Instant Messaging and Presence > > Status of this Memo > > This document specifies an Internet standards track protocol for the > Internet community, and requests discussion and suggestions for > improvements. Please refer to the current edition of the "Internet > Official Protocol Standards" (STD 1) for the standardization state > and status of this protocol. Distribution of this memo is unlimited. > > Copyright Notice > > Copyright (C) The Internet Society (2004). > > Abstract > > This memo describes extensions to and applications of the core > features of the Extensible Messaging and Presence Protocol (XMPP) > that provide the basic instant messaging (IM) and presence > functionality defined in RFC 2779. > > Saint-Andre Standards Track [Page 1] > > RFC 3921 XMPP IM October 2004 > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > 2. Syntax of XML Stanzas . . . . . . . . . . . . . . . . . . . 4 > 3. Session Establishment . . . . . . . . . . . . . . . . . . . 10 > 4. Exchanging Messages . . . . . . . . . . . . . . . . . . . . 13 > 5. Exchanging Presence Information . . . . . . . . . . . . . . 16 > 6. Managing Subscriptions . . . . . . . . . . . . . . . . . . . 26 > 7. Roster Management . . . . . . . . . . . . . . . . . . . . . 27 > 8. Integration of Roster Items and Presence Subscriptions . . . 32 > 9. Subscription States . . . . . . . . . . . . . . . . . . . . 56 > 10. Blocking Communication . . . . . . . . . . . . . . . . . . . 62 > 11. Server Rules for Handling XML Stanzas . . . . . . . . . . . 85 > 12. IM and Presence Compliance Requirements . . . . . . . . . . 88 > 13. Internationalization Considerations . . . . . . . . . . . . 89 > 14. Security Considerations . . . . . . . . . . . . . . . . . . 89 > 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 90 > 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 91 > A. vCards . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 > B. XML Schemas. . . . . . . . . . . . . . . . . . . . . . . . . 93 > C. Differences Between Jabber IM/Presence Protocols and XMPP. . 105 > Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 106 > Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 106 > Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 106 > Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 107 > > 1. Introduction > > 1.1. Overview > > The Extensible Messaging and Presence Protocol (XMPP) is a protocol > for streaming XML [XML] elements in order to exchange messages and > presence information in close to real time. The core features of > XMPP are defined in Extensible Messaging and Presence Protocol > (XMPP): Core [XMPP-CORE]. These features -- mainly XML streams, use > of TLS and SASL, and the, > of the stream root -- provide the building blocks for many types of > near-real-time applications, which may be layered on top of the core > by sending application-specific data qualified by particular XML > namespaces [XML-NAMES]. This memo describes extensions to and > applications of the core features of XMPP that provide the basic > functionality expected of an instant messaging (IM) and presence > application as defined in RFC 2779 [IMP-REQS]. > > Saint-Andre Standards Track [Page 2] > > RFC 3921 XMPP IM October 2004 > > 1.2. Requirements > > For the purposes of this memo, the requirements of a basic instant > messaging and presence application are defined by [IMP-REQS], which > at a high level stipulates that a user must be able to complete the > following use cases: > > 作为本文档的基础，基本的IM和"在线应用程序presence application"的要求 > 刊载在[IMP-REQS]里面。这份文档在大体上规定了用户必须能完成如下的功能。 > > o Exchange messages with other users > 与其它用户交换消息 > o Exchange presence information with other users > 与其它用户交换在线信息 > o Manage subscriptions to and from other users > 管理和限制自己或他人的在线信息的发布 > o Manage items in a contact list (in XMPP this is called a "roster") > 管理通讯录里的资料(XMPP称之为roster) > o Block communications to or from specific other users > 切断与他人的通讯 > > Detailed definitions of these functionality areas are contained in > [IMP-REQS], and the interested reader is directed to that document > regarding the requirements addressed herein. > > 这些功能的详细定义刊载在[IMP-REQS]里，感兴趣的读者可以自己去看。 > > [IMP-REQS] also stipulates that presence services must be separable > from instant messaging services; i.e., it must be possible to use the > protocol to provide a presence service, an instant messaging service, > or both. Although the text of this memo assumes that implementations > and deployments will want to offer a unified instant messaging and > presence service, there is no requirement that a service must offer > both a presence service and an instant messaging service, and the > protocol makes it possible to offer separate and distinct services > for presence and for instant messaging. > > [IMP-REQS]同时还规定，在线信息的服务必须与及时信息的服务相分离。比方说， > 协议必须允许你只使用在线信息，或及时信息服务，当然也可以两个都用。虽然 > 我们认为真正实现的时候，在线信息和及时信息服务肯定是合二为一的，但是它 > 也没有强求你一定必须同时提供在线信息合及时信息服务。这个协议完全允许你 > 提供单独的在线信息或及时信息服务。 > > Note: While XMPP-based instant messaging and presence meets the > requirements of [IMP-REQS], it was not designed explicitly with that > specification in mind, since the base protocol evolved through an > open development process within the Jabber open-source community > before RFC 2779 was written. Note also that although protocols > addressing many other functionality areas have been defined in the > Jabber community, such protocols are not included in this memo > because they are not required by [IMP-REQS]. > > 注意：虽然基于XMPP的及时信息和在线服务符合[IMP-REQS]的要求，但它并 > 不是刻意去实现的，因为Jabber开源社区早在RFC 2779发布之前就已经促成了 > 基本的协议。同时还要指出的是，虽然Jabber社区还为协议设计了很多别的方面 > 的功能，但由于[IMP-REQS]并没有要求，因此我们这里也就不涉及了。 > > 1.3. Terminology > > This memo inherits the terminology defined in [XMPP-CORE]. > > The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", > "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in BCP > 14, RFC 2119 [TERMS]. > > Saint-Andre Standards Track [Page 3] > > RFC 3921 XMPP IM October 2004 > > 2. Syntax of XML Stanzas > > XML Stanzas的语法 > > The basic semantics and common attributes of XML stanzas qualified by > the 'jabber:client' and 'jabber:server' namespaces are defined in > [XMPP-CORE]. However, these namespaces also define various child > elements, as well as values for the common 'type' attribute, that are > specific to instant messaging and presence applications. Thus, > before addressing particular "use cases" for such applications, we > here further describe the syntax of XML stanzas, thereby > supplementing the discussion in [XMPP-CORE]. > > XML stanzas都归在'jabber:client'和'jabber:server'名字空间之下，其基本语义 > 和常用属性由[XMPP-CORE]定义。除了常用的'type'属性的值之外，这两个名字空间 > 还定义了很多专供及时信息或在线信息服务的child elements。因此在描述此类应用 > 程序的"use case"之前，我们先探讨一下XML stanzas的语法，也借此补充一下 > [XMPP-CORE]。 > > 2.1. Message Syntax > > Message stanzas qualified by the 'jabber:client' or 'jabber:server' > namespace are used to "push" information to another entity. Common > uses in instant messaging applications include single messages, > messages sent in the context of a chat conversation, messages sent in > the context of a multi-user chat room, headlines and other alerts, > and errors. > > 归在'jabber:client'或'jabber:server'名字空间之下的Message stanzas是用来 > 向另一个entity"推"信息用的。在IM应用程序里，这种stanzas常用被用于发送"单条 > 消息(single message)"，在chat环境下发送消息，在多用户的chat room的环境下 > 发送消息，以及发送headline，警告和错误消息。 > > 2.1.1. Types of Message > > The 'type' attribute of a message stanza is RECOMMENDED; if included, > it specifies the conversational context of the message, thus > providing a hint regarding presentation (e.g., in a GUI). If > included, the 'type' attribute MUST have one of the following values: > > message stanza的'type'属性是RECOMMENDED的；如果有，它表示这个消息是在怎样 > 的交谈环境下发出的，因此它也暗示了该怎样显示这条消息(比方说在GUI环境下)。 > 'type'属性如果有必须(MUST)是下面值里的一个。 > > o chat -- The message is sent in the context of a one-to-one chat > conversation. A compliant client SHOULD present the message in an > interface enabling one-to-one chat between the two parties, > including an appropriate conversation history. > > chat -- 消息是在一对一的chat谈话中发出的。客户端应当(SHOULD)在一个 > 能让用户进行一对一谈话的界面里提示这条消息，包括交谈的记录。 > > o error -- An error has occurred related to a previous message sent > by the sender (for details regarding stanza error syntax, refer to > [XMPP-CORE]). A compliant client SHOULD present an appropriate > interface informing the sender of the nature of the error. > > error -- 表示先前发送的消息发生了错误(关于stanza的错误的语法， > 请参阅[XMPP-CORE])。客户端应当(SHOULD)能告诉发送发错误的性质。 > > o groupchat -- The message is sent in the context of a multi-user > chat environment (similar to that of [IRC]). A compliant client > SHOULD present the message in an interface enabling many-to-many > chat between the parties, including a roster of parties in the > chatroom and an appropriate conversation history. Full definition > of XMPP-based groupchat protocols is out of scope for this memo. > > groupchat -- 这条消息是在多用户交谈环境下发出的(类似[IRC])。客户端 > 应当(SHOULD)在能允许用户进行多对多谈话的界面里显示这条消息，这其中 > 应该包括chat room的参与者的roster(名单)，以及适当的谈话记录。基于XMPP > 的群组交谈协议超出了本文档的范围。 > > o headline -- The message is probably generated by an automated > service that delivers or broadcasts content (news, sports, market > information, RSS feeds, etc.). No reply to the message is > expected, and a compliant client SHOULD present the message in an > > Saint-Andre Standards Track [Page 4] > > RFC 3921 XMPP IM October 2004 > > interface that appropriately differentiates the message from > standalone messages, chat sessions, or groupchat sessions (e.g., > by not providing the recipient with the ability to reply). > > headline -- 这条消息或许是由某个后台服务生成并发送或广播的(新闻，体育， > 市场信息，RSS服务等到)。它不需要用户的回应。客户端应当(SHOULD)在 > 一个合适的界面下提示这条消息以将其与"standalone message"，"chat session" > 和"groupchat session"相区分(比方说用户只能看不能reply)。 > > o normal -- The message is a single message that is sent outside the > context of a one-to-one conversation or groupchat, and to which it > is expected that the recipient will reply. A compliant client > SHOULD present the message in an interface enabling the recipient > to reply, but without a conversation history. > > normal -- 这是一个single message，既不是一对一的交谈，也不是群组交谈， > 而且允许接受方回应。客户端应当(SHOULD)在一个能让用户reply的界面里显示 > 这条消息，但是不要有谈话记录。 > ―――――――――――――――――――――――――――――――――――― > > On 7/5/05, shhgs <shhgs.efhilt at gmail.com> wrote: > > 规模很大，我着手的RFC 3921有5000多行，20000多个单词，算下来要由4万多字，估计要有1个月才能翻出来。 > > > > 我建议，谁想翻译，就在文档后面签一个名，然后别人暂时不要翻了。 > > > > 还有，可以先做一个节译，把技术上重要的地方先翻出来，其它的先放一放。 > > > > 此外，我总觉得WIKI很不方便，我都是在自己的机器上对着txt翻译的，用wiki还要排版，很不爽。 > > > > > > On 7/5/05, shiziliang <shizl at bis.com.cn> wrote: > > > 请问大虾怎么组织？ > > > > > > 你先写个方案，怎么样？ > > > 分析一下文档的规模，和需要的人手数，和修正方案 > > > > > > > > > ----- Original Message ----- > > > From: "run_mei" <run_mei at 163.com> > > > To: <python-chinese at lists.python.cn> > > > Sent: Tuesday, July 05, 2005 9:29 AM > > > Subject: [python-chinese] xmpp ( jabber ) 中文翻译 > > > > > > > > > > 大家好，我觉得即时通时技术是一个有趣的技术，而xmpp ( jabber )技术是唯一 > > > > 的开源的协议，它有很多激动人心的特征，我对它有兴趣，但好象没有中文资料， > > > > 我想翻译它的英文文档，可是我的英文水平不高，所以我想找人帮我一起来翻译 > > > > 它，我已经翻译了一点。我想找个地方把它共亨出来，同时请大家帮我将翻译错误 > > > > 的地方纠正过来。 > > > > 请问可不可在在www.woodpecker.org上建一个目录存放它。 > > > > > > > > _______________________________________________ > > > > python-chinese list > > > > python-chinese at lists.python.cn > > > > http://python.cn/mailman/listinfo/python-chinese > > > > > > > > > > > _______________________________________________ > > > python-chinese list > > > python-chinese at lists.python.cn > > > http://python.cn/mailman/listinfo/python-chinese > > > > > > > > > > > > > _______________________________________________ > python-chinese list > python-chinese at lists.python.cn > http://python.cn/mailman/listinfo/python-chinese > > > -- [Time is unimportant, only life important!], and children
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2005年07月05日 星期二 22:34
Bruce Wang number5 at gmail.com
Tue Jul 5 22:34:56 HKT 2005
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Tue Jul 5 22:34:56 HKT 2005
要翻译技术文档，我觉得首先要建立一个glossary, 首先确定类似 Presence, stanza 这些关键词的译法和含义，不然的话每个人翻译出来的结果可能都不尽相同 On 7/5/05, shhgs <shhgs.efhilt at gmail.com> wrote: > 以下是今天翻译的 > ―――――――――――――――――――――――――――――――――― > > > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > 2. Syntax of XML Stanzas . . . . . . . . . . . . . . . . . . . 4 > 3. Session Establishment . . . . . . . . . . . . . . . . . . . 10 > 4. Exchanging Messages . . . . . . . . . . . . . . . . . . . . 13 > 5. Exchanging Presence Information . . . . . . . . . . . . . . 16 > 6. Managing Subscriptions . . . . . . . . . . . . . . . . . . . 26 > 7. Roster Management . . . . . . . . . . . . . . . . . . . . . 27 > 8. Integration of Roster Items and Presence Subscriptions . . . 32 > 9. Subscription States . . . . . . . . . . . . . . . . . . . . 56 > 10. Blocking Communication . . . . . . . . . . . . . . . . . . . 62 > 11. Server Rules for Handling XML Stanzas . . . . . . . . . . . 85 > 12. IM and Presence Compliance Requirements . . . . . . . . . . 88 > 13. Internationalization Considerations . . . . . . . . . . . . 89 > 14. Security Considerations . . . . . . . . . . . . . . . . . . 89 > 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 90 > 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 91 > A. vCards . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 > B. XML Schemas. . . . . . . . . . . . . . . . . . . . . . . . . 93 > C. Differences Between Jabber IM/Presence Protocols and XMPP. . 105 > Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 106 > Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 106 > Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 106 > Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 107 > -- simple is good
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2005年07月06日 星期三 03:26
shhgs shhgs.efhilt at gmail.com
Wed Jul 6 03:26:51 HKT 2005
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Wed Jul 6 03:26:51 HKT 2005
留着不翻 看不懂E文文档很多时候并不是因为术语的问题，而是你看不懂句子的结构，不知道某个多意词该怎么解，或者不知道在哪里断句。我们翻译又不是真正要出版，以自己看懂，别人也看懂为宜。因此我不会太计较全部都翻成中文，相反，不但术语会保留，有时候一些很难翻译的单词，也会保留。 比如streaming xml，翻译成中文是"流化xml"，与其这么翻，还不如直接拿过来，反正同志们都看得懂。 On 7/5/05, Bruce Wang <number5 at gmail.com> wrote: > 要翻译技术文档，我觉得首先要建立一个glossary, 首先确定类似 Presence, stanza > 这些关键词的译法和含义，不然的话每个人翻译出来的结果可能都不尽相同 > > On 7/5/05, shhgs <shhgs.efhilt at gmail.com> wrote: > > 以下是今天翻译的 > > ―――――――――――――――――――――――――――――――――― > > > > > > > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > > 2. Syntax of XML Stanzas . . . . . . . . . . . . . . . . . . . 4 > > 3. Session Establishment . . . . . . . . . . . . . . . . . . . 10 > > 4. Exchanging Messages . . . . . . . . . . . . . . . . . . . . 13 > > 5. Exchanging Presence Information . . . . . . . . . . . . . . 16 > > 6. Managing Subscriptions . . . . . . . . . . . . . . . . . . . 26 > > 7. Roster Management . . . . . . . . . . . . . . . . . . . . . 27 > > 8. Integration of Roster Items and Presence Subscriptions . . . 32 > > 9. Subscription States . . . . . . . . . . . . . . . . . . . . 56 > > 10. Blocking Communication . . . . . . . . . . . . . . . . . . . 62 > > 11. Server Rules for Handling XML Stanzas . . . . . . . . . . . 85 > > 12. IM and Presence Compliance Requirements . . . . . . . . . . 88 > > 13. Internationalization Considerations . . . . . . . . . . . . 89 > > 14. Security Considerations . . . . . . . . . . . . . . . . . . 89 > > 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 90 > > 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 91 > > A. vCards . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 > > B. XML Schemas. . . . . . . . . . . . . . . . . . . . . . . . . 93 > > C. Differences Between Jabber IM/Presence Protocols and XMPP. . 105 > > Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 106 > > Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 106 > > Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 106 > > Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 107 > > > > -- > simple is good > > _______________________________________________ > python-chinese list > python-chinese at lists.python.cn > http://python.cn/mailman/listinfo/python-chinese > > >
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2005年07月06日 星期三 09:31
run_mei run_mei at 163.com
Wed Jul 6 09:31:16 HKT 2005
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Wed Jul 6 09:31:16 HKT 2005
你好，如果你觉得麻烦的话，你可以先发给我，我会在适当的时候将它排版的 shhgs 写道: >以下是今天翻译的 >―――――――――――――――――――――――――――――――――― > > > > >Network Working Group P. Saint-Andre, Ed. >Request for Comments: 3921 Jabber Software Foundation >Category: Standards Track October 2004 > > > Extensible Messaging and Presence Protocol (XMPP): > Instant Messaging and Presence > >Status of this Memo > > This document specifies an Internet standards track protocol for the > Internet community, and requests discussion and suggestions for > improvements. Please refer to the current edition of the "Internet > Official Protocol Standards" (STD 1) for the standardization state > and status of this protocol. Distribution of this memo is unlimited. > >Copyright Notice > > Copyright (C) The Internet Society (2004). > >Abstract > > This memo describes extensions to and applications of the core > features of the Extensible Messaging and Presence Protocol (XMPP) > that provide the basic instant messaging (IM) and presence > functionality defined in RFC 2779. > > > > > > > > > > > > > > > > > > > > > > > > > >Saint-Andre Standards Track [Page 1] > >RFC 3921 XMPP IM October 2004 > > >Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > 2. Syntax of XML Stanzas . . . . . . . . . . . . . . . . . . . 4 > 3. Session Establishment . . . . . . . . . . . . . . . . . . . 10 > 4. Exchanging Messages . . . . . . . . . . . . . . . . . . . . 13 > 5. Exchanging Presence Information . . . . . . . . . . . . . . 16 > 6. Managing Subscriptions . . . . . . . . . . . . . . . . . . . 26 > 7. Roster Management . . . . . . . . . . . . . . . . . . . . . 27 > 8. Integration of Roster Items and Presence Subscriptions . . . 32 > 9. Subscription States . . . . . . . . . . . . . . . . . . . . 56 > 10. Blocking Communication . . . . . . . . . . . . . . . . . . . 62 > 11. Server Rules for Handling XML Stanzas . . . . . . . . . . . 85 > 12. IM and Presence Compliance Requirements . . . . . . . . . . 88 > 13. Internationalization Considerations . . . . . . . . . . . . 89 > 14. Security Considerations . . . . . . . . . . . . . . . . . . 89 > 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 90 > 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 91 > A. vCards . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 > B. XML Schemas. . . . . . . . . . . . . . . . . . . . . . . . . 93 > C. Differences Between Jabber IM/Presence Protocols and XMPP. . 105 > Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 106 > Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 106 > Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 106 > Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 107 > >1. Introduction > >1.1. Overview > > The Extensible Messaging and Presence Protocol (XMPP) is a protocol > for streaming XML [XML] elements in order to exchange messages and > presence information in close to real time. The core features of > XMPP are defined in Extensible Messaging and Presence Protocol > (XMPP): Core [XMPP-CORE]. These features -- mainly XML streams, use > of TLS and SASL, and the, > of the stream root -- provide the building blocks for many types of > near-real-time applications, which may be layered on top of the core > by sending application-specific data qualified by particular XML > namespaces [XML-NAMES]. This memo describes extensions to and > applications of the core features of XMPP that provide the basic > functionality expected of an instant messaging (IM) and presence > application as defined in RFC 2779 [IMP-REQS]. > > > > > > > > >Saint-Andre Standards Track [Page 2] > >RFC 3921 XMPP IM October 2004 > > >1.2. Requirements > > For the purposes of this memo, the requirements of a basic instant > messaging and presence application are defined by [IMP-REQS], which > at a high level stipulates that a user must be able to complete the > following use cases: > > 作为本文档的基础，基本的IM和"在线应用程序presence application"的要求 > 刊载在[IMP-REQS]里面。这份文档在大体上规定了用户必须能完成如下的功能。 > > o Exchange messages with other users > 与其它用户交换消息 > o Exchange presence information with other users > 与其它用户交换在线信息 > o Manage subscriptions to and from other users > 管理和限制自己或他人的在线信息的发布 > o Manage items in a contact list (in XMPP this is called a "roster") > 管理通讯录里的资料(XMPP称之为roster) > o Block communications to or from specific other users > 切断与他人的通讯 > > Detailed definitions of these functionality areas are contained in > [IMP-REQS], and the interested reader is directed to that document > regarding the requirements addressed herein. > > 这些功能的详细定义刊载在[IMP-REQS]里，感兴趣的读者可以自己去看。 > > [IMP-REQS] also stipulates that presence services must be separable > from instant messaging services; i.e., it must be possible to use the > protocol to provide a presence service, an instant messaging service, > or both. Although the text of this memo assumes that implementations > and deployments will want to offer a unified instant messaging and > presence service, there is no requirement that a service must offer > both a presence service and an instant messaging service, and the > protocol makes it possible to offer separate and distinct services > for presence and for instant messaging. > > [IMP-REQS]同时还规定，在线信息的服务必须与及时信息的服务相分离。比方说， > 协议必须允许你只使用在线信息，或及时信息服务，当然也可以两个都用。虽然 > 我们认为真正实现的时候，在线信息和及时信息服务肯定是合二为一的，但是它 > 也没有强求你一定必须同时提供在线信息合及时信息服务。这个协议完全允许你 > 提供单独的在线信息或及时信息服务。 > > Note: While XMPP-based instant messaging and presence meets the > requirements of [IMP-REQS], it was not designed explicitly with that > specification in mind, since the base protocol evolved through an > open development process within the Jabber open-source community > before RFC 2779 was written. Note also that although protocols > addressing many other functionality areas have been defined in the > Jabber community, such protocols are not included in this memo > because they are not required by [IMP-REQS]. > > 注意：虽然基于XMPP的及时信息和在线服务符合[IMP-REQS]的要求，但它并 > 不是刻意去实现的，因为Jabber开源社区早在RFC 2779发布之前就已经促成了 > 基本的协议。同时还要指出的是，虽然Jabber社区还为协议设计了很多别的方面 > 的功能，但由于[IMP-REQS]并没有要求，因此我们这里也就不涉及了。 > >1.3. Terminology > > This memo inherits the terminology defined in [XMPP-CORE]. > > The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", > "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in BCP > 14, RFC 2119 [TERMS]. > > > > > > > >Saint-Andre Standards Track [Page 3] > >RFC 3921 XMPP IM October 2004 > > >2. Syntax of XML Stanzas > > XML Stanzas的语法 > > The basic semantics and common attributes of XML stanzas qualified by > the 'jabber:client' and 'jabber:server' namespaces are defined in > [XMPP-CORE]. However, these namespaces also define various child > elements, as well as values for the common 'type' attribute, that are > specific to instant messaging and presence applications. Thus, > before addressing particular "use cases" for such applications, we > here further describe the syntax of XML stanzas, thereby > supplementing the discussion in [XMPP-CORE]. > > XML stanzas都归在'jabber:client'和'jabber:server'名字空间之下，其基本语义 > 和常用属性由[XMPP-CORE]定义。除了常用的'type'属性的值之外，这两个名字空间 > 还定义了很多专供及时信息或在线信息服务的child elements。因此在描述此类应用 > 程序的"use case"之前，我们先探讨一下XML stanzas的语法，也借此补充一下 > [XMPP-CORE]。 > >2.1. Message Syntax > > Message stanzas qualified by the 'jabber:client' or 'jabber:server' > namespace are used to "push" information to another entity. Common > uses in instant messaging applications include single messages, > messages sent in the context of a chat conversation, messages sent in > the context of a multi-user chat room, headlines and other alerts, > and errors. > > 归在'jabber:client'或'jabber:server'名字空间之下的Message stanzas是用来 > 向另一个entity"推"信息用的。在IM应用程序里，这种stanzas常用被用于发送"单条 > 消息(single message)"，在chat环境下发送消息，在多用户的chat room的环境下 > 发送消息，以及发送headline，警告和错误消息。 > >2.1.1. Types of Message > > The 'type' attribute of a message stanza is RECOMMENDED; if included, > it specifies the conversational context of the message, thus > providing a hint regarding presentation (e.g., in a GUI). If > included, the 'type' attribute MUST have one of the following values: > > message stanza的'type'属性是RECOMMENDED的；如果有，它表示这个消息是在怎样 > 的交谈环境下发出的，因此它也暗示了该怎样显示这条消息(比方说在GUI环境下)。 > 'type'属性如果有必须(MUST)是下面值里的一个。 > > o chat -- The message is sent in the context of a one-to-one chat > conversation. A compliant client SHOULD present the message in an > interface enabling one-to-one chat between the two parties, > including an appropriate conversation history. > > chat -- 消息是在一对一的chat谈话中发出的。客户端应当(SHOULD)在一个 > 能让用户进行一对一谈话的界面里提示这条消息，包括交谈的记录。 > > o error -- An error has occurred related to a previous message sent > by the sender (for details regarding stanza error syntax, refer to > [XMPP-CORE]). A compliant client SHOULD present an appropriate > interface informing the sender of the nature of the error. > > error -- 表示先前发送的消息发生了错误(关于stanza的错误的语法， > 请参阅[XMPP-CORE])。客户端应当(SHOULD)能告诉发送发错误的性质。 > > o groupchat -- The message is sent in the context of a multi-user > chat environment (similar to that of [IRC]). A compliant client > SHOULD present the message in an interface enabling many-to-many > chat between the parties, including a roster of parties in the > chatroom and an appropriate conversation history. Full definition > of XMPP-based groupchat protocols is out of scope for this memo. > > groupchat -- 这条消息是在多用户交谈环境下发出的(类似[IRC])。客户端 > 应当(SHOULD)在能允许用户进行多对多谈话的界面里显示这条消息，这其中 > 应该包括chat room的参与者的roster(名单)，以及适当的谈话记录。基于XMPP > 的群组交谈协议超出了本文档的范围。 > > o headline -- The message is probably generated by an automated > service that delivers or broadcasts content (news, sports, market > information, RSS feeds, etc.). No reply to the message is > expected, and a compliant client SHOULD present the message in an > > > > >Saint-Andre Standards Track [Page 4] > >RFC 3921 XMPP IM October 2004 > > > interface that appropriately differentiates the message from > standalone messages, chat sessions, or groupchat sessions (e.g., > by not providing the recipient with the ability to reply). > > headline -- 这条消息或许是由某个后台服务生成并发送或广播的(新闻，体育， > 市场信息，RSS服务等到)。它不需要用户的回应。客户端应当(SHOULD)在 > 一个合适的界面下提示这条消息以将其与"standalone message"，"chat session" > 和"groupchat session"相区分(比方说用户只能看不能reply)。 > > o normal -- The message is a single message that is sent outside the > context of a one-to-one conversation or groupchat, and to which it > is expected that the recipient will reply. A compliant client > SHOULD present the message in an interface enabling the recipient > to reply, but without a conversation history. > > normal -- 这是一个single message，既不是一对一的交谈，也不是群组交谈， > 而且允许接受方回应。客户端应当(SHOULD)在一个能让用户reply的界面里显示 > 这条消息，但是不要有谈话记录。 >―――――――――――――――――――――――――――――――――――― > >On 7/5/05, shhgs <shhgs.efhilt at gmail.com> wrote: > > >>规模很大，我着手的RFC 3921有5000多行，20000多个单词，算下来要由4万多字，估计要有1个月才能翻出来。 >> >>我建议，谁想翻译，就在文档后面签一个名，然后别人暂时不要翻了。 >> >>还有，可以先做一个节译，把技术上重要的地方先翻出来，其它的先放一放。 >> >>此外，我总觉得WIKI很不方便，我都是在自己的机器上对着txt翻译的，用wiki还要排版，很不爽。 >> >> >>On 7/5/05, shiziliang <shizl at bis.com.cn> wrote: >> >> >>>请问大虾怎么组织？ >>> >>>你先写个方案，怎么样？ >>>分析一下文档的规模，和需要的人手数，和修正方案 >>> >>> >>>----- Original Message ----- >>>From: "run_mei" <run_mei at 163.com> >>>To: <python-chinese at lists.python.cn> >>>Sent: Tuesday, July 05, 2005 9:29 AM >>>Subject: [python-chinese] xmpp ( jabber ) 中文翻译 >>> >>> >>> >>> >>>>大家好，我觉得即时通时技术是一个有趣的技术，而xmpp ( jabber )技术是唯一 >>>>的开源的协议，它有很多激动人心的特征，我对它有兴趣，但好象没有中文资料， >>>>我想翻译它的英文文档，可是我的英文水平不高，所以我想找人帮我一起来翻译 >>>>它，我已经翻译了一点。我想找个地方把它共亨出来，同时请大家帮我将翻译错误 >>>>的地方纠正过来。 >>>>请问可不可在在www.woodpecker.org上建一个目录存放它。 >>>> >>>>_______________________________________________ >>>>python-chinese list >>>>python-chinese at lists.python.cn >>>>http://python.cn/mailman/listinfo/python-chinese >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>python-chinese list >>>python-chinese at lists.python.cn >>>http://python.cn/mailman/listinfo/python-chinese >>> >>> >>> >>> >>> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>python-chinese list >>python-chinese at lists.python.cn >>http://python.cn/mailman/listinfo/python-chinese >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20050706/9be247ef/attachment-0001.html, and children
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2005年07月06日 星期三 10:46
shhgs shhgs.efhilt at gmail.com
Wed Jul 6 10:46:50 HKT 2005
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Wed Jul 6 10:46:50 HKT 2005
RFC 3921的网页怎么变成只读的了？
今天又翻了一点，这样把，以后我就把我翻的东西通过这个列表发出来，run_mei你负责帮我更新。
------------------------------------------------------------------------------------------------------
Network Working Group P. Saint-Andre, Ed.
Request for Comments: 3921 Jabber Software Foundation
Category: Standards Track October 2004
Extensible Messaging and Presence Protocol (XMPP):
Instant Messaging and Presence
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This memo describes extensions to and applications of the core
features of the Extensible Messaging and Presence Protocol (XMPP)
that provide the basic instant messaging (IM) and presence
functionality defined in RFC 2779.
Saint-Andre Standards Track [Page 1]
RFC 3921 XMPP IM October 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Syntax of XML Stanzas . . . . . . . . . . . . . . . . . . . 4
3. Session Establishment . . . . . . . . . . . . . . . . . . . 10
4. Exchanging Messages . . . . . . . . . . . . . . . . . . . . 13
5. Exchanging Presence Information . . . . . . . . . . . . . . 16
6. Managing Subscriptions . . . . . . . . . . . . . . . . . . . 26
7. Roster Management . . . . . . . . . . . . . . . . . . . . . 27
8. Integration of Roster Items and Presence Subscriptions . . . 32
9. Subscription States . . . . . . . . . . . . . . . . . . . . 56
10. Blocking Communication . . . . . . . . . . . . . . . . . . . 62
11. Server Rules for Handling XML Stanzas . . . . . . . . . . . 85
12. IM and Presence Compliance Requirements . . . . . . . . . . 88
13. Internationalization Considerations . . . . . . . . . . . . 89
14. Security Considerations . . . . . . . . . . . . . . . . . . 89
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 90
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 91
A. vCards . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
B. XML Schemas. . . . . . . . . . . . . . . . . . . . . . . . . 93
C. Differences Between Jabber IM/Presence Protocols and XMPP. . 105
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 106
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 106
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 107
1. Introduction
1.1. Overview
The Extensible Messaging and Presence Protocol (XMPP) is a protocol
for streaming XML [XML] elements in order to exchange messages and
presence information in close to real time. The core features of
XMPP are defined in Extensible Messaging and Presence Protocol
(XMPP): Core [XMPP-CORE]. These features -- mainly XML streams, use
of TLS and SASL, and the , , and children
of the stream root -- provide the building blocks for many types of
near-real-time applications, which may be layered on top of the core
by sending application-specific data qualified by particular XML
namespaces [XML-NAMES]. This memo describes extensions to and
applications of the core features of XMPP that provide the basic
functionality expected of an instant messaging (IM) and presence
application as defined in RFC 2779 [IMP-REQS].
XMPP是一种通过将XML elements流化以达到近乎实时地传递消息(message)和在线信息
(presence information)的协议。XMPP的核心功能在(XMPP): Core [XMPP-CORE]中定义。
这些功能――主要包括XML的流化，TLS和SASL的使用，以及像 ,以及
这样的流的子元素――提供给我们一些素材，使我们能创建很多"半实时(near-real-time)"
的应用程序，而这些半实时的应用程序或许会位于应用程序的核心层之上，专门负责发送由程序专用的
XML数据。这份memo讲述的是怎样扩展和使用XMPP的核心功能，而XMPP的核心协议仅涵盖了由RFC
2779[IMP-REQS]定义的，基本的IM和presence application 所应该提供的功能。
1.2. Requirements
For the purposes of this memo, the requirements of a basic instant
messaging and presence application are defined by [IMP-REQS], which
at a high level stipulates that a user must be able to complete the
following use cases:
作为本文档的基础，基本的IM和"在线应用程序presence application"的要求
刊载在[IMP-REQS]里面。这份文档在大体上规定了用户必须能完成如下的功能。
o Exchange messages with other users
与其它用户交换消息
o Exchange presence information with other users
与其它用户交换在线信息
o Manage subscriptions to and from other users
管理和限制自己或他人的在线信息的发布
o Manage items in a contact list (in XMPP this is called a "roster")
管理通讯录里的资料(XMPP称之为roster)
o Block communications to or from specific other users
切断与他人的通讯
Detailed definitions of these functionality areas are contained in
[IMP-REQS], and the interested reader is directed to that document
regarding the requirements addressed herein.
这些功能的详细定义刊载在[IMP-REQS]里，感兴趣的读者可以自己去看。
[IMP-REQS] also stipulates that presence services must be separable
from instant messaging services; i.e., it must be possible to use the
protocol to provide a presence service, an instant messaging service,
or both. Although the text of this memo assumes that implementations
and deployments will want to offer a unified instant messaging and
presence service, there is no requirement that a service must offer
both a presence service and an instant messaging service, and the
protocol makes it possible to offer separate and distinct services
for presence and for instant messaging.
[IMP-REQS]同时还规定，在线信息的服务必须与及时信息的服务相分离。比方说，
协议必须允许你只使用在线信息，或及时信息服务，当然也可以两个都用。虽然
我们认为真正实现的时候，在线信息和及时信息服务肯定是合二为一的，但是它
也没有强求你一定必须同时提供在线信息合及时信息服务。这个协议完全允许你
提供单独的在线信息或及时信息服务。
Note: While XMPP-based instant messaging and presence meets the
requirements of [IMP-REQS], it was not designed explicitly with that
specification in mind, since the base protocol evolved through an
open development process within the Jabber open-source community
before RFC 2779 was written. Note also that although protocols
addressing many other functionality areas have been defined in the
Jabber community, such protocols are not included in this memo
because they are not required by [IMP-REQS].
注意：虽然基于XMPP的及时信息和在线服务符合[IMP-REQS]的要求，但它并
不是刻意去实现的，因为Jabber开源社区早在RFC 2779发布之前就已经促成了
基本的协议。同时还要指出的是，虽然Jabber社区还为协议设计了很多别的方面
的功能，但由于[IMP-REQS]并没有要求，因此我们这里也就不涉及了。
1.3. Terminology
This memo inherits the terminology defined in [XMPP-CORE].
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14, RFC 2119 [TERMS].
2. Syntax of XML Stanzas
XML Stanzas的语法
The basic semantics and common attributes of XML stanzas qualified by
the 'jabber:client' and 'jabber:server' namespaces are defined in
[XMPP-CORE]. However, these namespaces also define various child
elements, as well as values for the common 'type' attribute, that are
specific to instant messaging and presence applications. Thus,
before addressing particular "use cases" for such applications, we
here further describe the syntax of XML stanzas, thereby
supplementing the discussion in [XMPP-CORE].
XML stanzas都归在'jabber:client'和'jabber:server'名字空间之下，其基本语义
和常用属性由[XMPP-CORE]定义。除了常用的'type'属性的值之外，这两个名字空间
还定义了很多专供及时信息或在线信息服务的child elements。因此在描述此类应用
程序的"use case"之前，我们先探讨一下XML stanzas的语法，也借此补充一下
[XMPP-CORE]。
2.1. Message Syntax
Message stanzas qualified by the 'jabber:client' or 'jabber:server'
namespace are used to "push" information to another entity. Common
uses in instant messaging applications include single messages,
messages sent in the context of a chat conversation, messages sent in
the context of a multi-user chat room, headlines and other alerts,
and errors.
归在'jabber:client'或'jabber:server'名字空间之下的Message stanzas是用来
向另一个entity"推"信息用的。在IM应用程序里，这种stanzas常用被用于发送"单条
消息(single message)"，在chat环境下发送消息，在多用户的chat room的环境下
发送消息，以及发送headline，警告和错误消息。
2.1.1. Types of Message
The 'type' attribute of a message stanza is RECOMMENDED; if included,
it specifies the conversational context of the message, thus
providing a hint regarding presentation (e.g., in a GUI). If
included, the 'type' attribute MUST have one of the following values:
message stanza的'type'属性是RECOMMENDED的；如果有，它表示这个消息是在怎样
的交谈环境下发出的，因此它也暗示了该怎样显示这条消息(比方说在GUI环境下)。
'type'属性如果有必须(MUST)是下面值里的一个。
o chat -- The message is sent in the context of a one-to-one chat
conversation. A compliant client SHOULD present the message in an
interface enabling one-to-one chat between the two parties,
including an appropriate conversation history.
chat -- 消息是在一对一的chat谈话中发出的。客户端应当(SHOULD)在一个
能让用户进行一对一谈话的界面里提示这条消息，包括交谈的记录。
o error -- An error has occurred related to a previous message sent
by the sender (for details regarding stanza error syntax, refer to
[XMPP-CORE]). A compliant client SHOULD present an appropriate
interface informing the sender of the nature of the error.
error -- 表示先前发送的消息发生了错误(关于stanza的错误的语法，
请参阅[XMPP-CORE])。客户端应当(SHOULD)能告诉发送发错误的性质。
o groupchat -- The message is sent in the context of a multi-user
chat environment (similar to that of [IRC]). A compliant client
SHOULD present the message in an interface enabling many-to-many
chat between the parties, including a roster of parties in the
chatroom and an appropriate conversation history. Full definition
of XMPP-based groupchat protocols is out of scope for this memo.
groupchat -- 这条消息是在多用户交谈环境下发出的(类似[IRC])。客户端
应当(SHOULD)在能允许用户进行多对多谈话的界面里显示这条消息，这其中
应该包括chat room的参与者的roster(名单)，以及适当的谈话记录。基于XMPP
的群组交谈协议超出了本文档的范围。
o headline -- The message is probably generated by an automated
service that delivers or broadcasts content (news, sports, market
information, RSS feeds, etc.). No reply to the message is
expected, and a compliant client SHOULD present the message in an
interface that appropriately differentiates the message from
standalone messages, chat sessions, or groupchat sessions (e.g.,
by not providing the recipient with the ability to reply).
headline -- 这条消息或许是由某个后台服务生成并发送或广播的(新闻，体育，
市场信息，RSS服务等到)。它不需要用户的回应。客户端应当(SHOULD)在
一个合适的界面下提示这条消息以将其与"standalone message"，"chat session"
和"groupchat session"相区分(比方说用户只能看不能reply)。
o normal -- The message is a single message that is sent outside the
context of a one-to-one conversation or groupchat, and to which it
is expected that the recipient will reply. A compliant client
SHOULD present the message in an interface enabling the recipient
to reply, but without a conversation history.
normal -- 这是一个single message，既不是一对一的交谈，也不是群组交谈，
而且允许接受方回应。客户端应当(SHOULD)在一个能让用户reply的界面里显示
这条消息，但是不要有谈话记录。
An IM application SHOULD support all of the foregoing message types;
if an application receives a message with no 'type' attribute or the
application does not understand the value of the 'type' attribute
provided, it MUST consider the message to be of type "normal" (i.e.,
"normal" is the default). The "error" type MUST be generated only in
response to an error related to a message received from another
entity.
IM application应当支持所有上述message type，如果它收到了一个没有'type'属性的message
或者它看不懂这个'type'属性，那它必须(MUST)将其认做是"normal"的message(也就是说，
"normal"是默认的属性)。"error"只限于(MUST)用来回应与对方发出的message相关的错误。
Although the 'type' attribute is OPTIONAL, it is considered polite to
mirror the type in any replies to a message; furthermore, some
specialized applications (e.g., a multi-user chat service) MAY at
their discretion enforce the use of a particular message type (e.g.,
type='groupchat').
虽然'type'属性是OPTIONAL的，但是最好在回应信息里面附上相同的'type'信息；此外有些专用程序
(比方说多用户的chat service)可以(MAY)根据他们自己的需要，强制使用特定的message type
(比方说type='groupchat')。
2.1.2. Child Elements
As described under extended namespaces (Section 2.4), a message
stanza MAY contain any properly-namespaced child element.
正如我们将在"扩展名字空间"(Section2.4)所讲的，message stanza可以(MAY)包含任意的
"属于适当的名字空间"的child element。
In accordance with the default namespace declaration, by default a
message stanza is qualified by the 'jabber:client' or 'jabber:server'
namespace, which defines certain allowable children of message
stanzas. If the message stanza is of type "error", it MUST include
an child; for details, see [XMPP-CORE]. Otherwise, the
message stanza MAY contain any of the following child elements
without an explicit namespace declaration:
为了与默认的名字空间的声明相一致，默认情况下，message stanza被归到'jabber:client'或
'jabber:server'名字空间下。这两个名字空间定义了一些被认可的message stanza的child。
'error'类型的message stanza必须(MUST)包含 child；具体细节请看[XMPP-CORE]。
除此之外，message stanza可以(MAY)不经声明就使用下列的child elements。
1.
2.
3.
2.1.2.1. Subject
The element contains human-readable XML character data
that specifies the topic of the message. The element MUST
NOT possess any attributes, with the exception of the 'xml:lang'
attribute. Multiple instances of the element MAY be
included for the purpose of providing alternate versions of the same
subject, but only if each instance possesses an 'xml:lang' attribute
with a distinct language value. The element MUST NOT
contain mixed content (as defined in Section 3.2.2 of [XML]).
element包含human-readable的，表示message的标题的XML字符数据。
绝对不能(MUST NOT)包含除'xml:lang'之外的任何属性。为了能提供同一个
subject的多个版本，一个message里面可以(MAY)包含多个 element。但这仅限于
每个都包含'xml:lang'属性，并且其language值都不相同的情形。
绝对不能(MUST NOT)包含mixed content(见Section 3.2.2)
2.1.2.2. Body
The element contains human-readable XML character data that
specifies the textual contents of the message; this child element is
normally included but is OPTIONAL. The element MUST NOT
possess any attributes, with the exception of the 'xml:lang'
attribute. Multiple instances of the element MAY be included
but only if each instance possesses an 'xml:lang' attribute with a
distinct language value. The element MUST NOT contain mixed
content (as defined in Section 3.2.2 of [XML]).
element包含human-readable的，用来表示消息的正文内容的XML字符数据；通常
message都会包含这个child，但它是可选的(OPTIONAL)。 element绝对不能(MUST NOT)
包含除'xml:lang'之外的任何属性。一个message里面可以(MAY)包含多个 element。
但这仅限于每个 都包含'xml:lang'属性，并且其language值都不相同的情形。
绝对不能(MUST NOT)包含mixed content(见Section 3.2.2)
2.1.2.3. Thread
The element contains non-human-readable XML character data
specifying an identifier that is used for tracking a conversation
thread (sometimes referred to as an "instant messaging session")
between two entities. The value of the element is
generated by the sender and SHOULD be copied back in any replies. If
used, it MUST be unique to that conversation thread within the stream
and MUST be consistent throughout that conversation (a client that
receives a message from the same full JID but with a different thread
ID MUST assume that the message in question exists outside the
context of the existing conversation thread). The use of the
element is OPTIONAL and is not used to identify individual
messages, only conversations. A message stanza MUST NOT contain more
than one element. The element MUST NOT possess
any attributes. The value of the element MUST be treated
as opaque by entities; no semantic meaning may be derived from it,
and only exact comparisons may be made against it. The
element MUST NOT contain mixed content (as defined in Section 3.2.2
of [XML]).
element包含非human-readable的XML字符数据。它是一个用于表示两个entity
之间的conversion thread的(有时也被称作"instance messaging session")标识符。
element的值由sender生成，而且每次回复的时候必须(SHOULD)包含在内。如果
用到了它，那么它必须(MUST)与stream里的conversation thread一一对应，而且整个谈话期间
必须保持一致(如果client端收到了同一个JID发出的，但是thread ID不同的message，必须(MUST)
认定这个消息与当前的conversation thread无关。) element是OPTIONAL的，
且不用于标识单个message，它是用来标识conversation的。一个message stanza MUST NOT
包含二个或二个以上的 element。 element MUST NOT包含任何属性。
对entities来说 的值必须(MUST)是不透明的；不能用它来获取任何语义信息，而且只能
对它进行精确地比较。 MUST NOT包含mixed content(Section 3.2.2)
2.2. Presence Syntax
Presence stanzas are used qualified by the 'jabber:client' or
'jabber:server' namespace to express an entity's current network
availability (offline or online, along with various sub-states of the
latter and optional user-defined descriptive text), and to notify
other entities of that availability. Presence stanzas are also used
to negotiate and manage subscriptions to the presence of other
entities.
Presence stanza属于'jabber:client'或'jabber:server'名字空间，它们是用来表示
entity的当前网络可得性(offline还是online，此外后者还有很多sub-state和可选的用户
自定义的叙述性文字)，并且将其通知给其它entities的。Persence stanzas也被用于协商
和管理订阅其它entities的presence信息。
2.2.1. Types of Presence
The 'type' attribute of a presence stanza is OPTIONAL. A presence
stanza that does not possess a 'type' attribute is used to signal to
the server that the sender is online and available for communication.
If included, the 'type' attribute specifies a lack of availability, a
request to manage a subscription to another entity's presence, a
request for another entity's current presence, or an error related to
a previously-sent presence stanza. If included, the 'type' attribute
MUST have one of the following values:
presence stanza的'type'属性是OPTIONAL的。不带'type'属性的presence stanza
是用来通知服务器sender已经上线，并且available for communication。如果有，那么这个
'type'或者用来表示可得性方面的限制，或者用来管理订阅其它用户的presence信息，或者用于
查询其它用户的当前可得性，或者是先前发送的presence stanza出了错。如果有，'type'属性
MUST是下列值中的一个:
o unavailable -- Signals that the entity is no longer available for
communication.
unavailable -- 表示entity不再available for communication了
o subscribe -- The sender wishes to subscribe to the recipient's
presence.
subscribe -- sender希望能订阅recipent的presence信息
o subscribed -- The sender has allowed the recipient to receive
their presence.
subscribed -- 发送方同意让接受方订阅自己的在线信息
o unsubscribe -- The sender is unsubscribing from another entity's
presence.
unsubscribe -- 发送方取消订阅另一方的在线信息
o unsubscribed -- The subscription request has been denied or a
previously-granted subscription has been cancelled.
unsubscribed -- 订阅请求被拒绝或者先前授予的订阅权限被撤销了
o probe -- A request for an entity's current presence; SHOULD be
generated only by a server on behalf of a user.
probe -- 请求entity的当前在线信息；只有(SHOULD)server才能代表用户去生成此类信息。
o error -- An error has occurred regarding processing or delivery of
a previously-sent presence stanza.
error -- 先前发送的presence stanza在处理或投送过程中出现了错误。
For detailed information regarding presence semantics and the
subscription model used in the context of XMPP-based instant
messaging and presence applications, refer to Exchanging Presence
Information (Section 5) and Managing Subscriptions (Section 6).
要想详细了解相关信息，请参阅Section 5 Exchanging Presence Information
和Section 6 Managing Subscriptions。
2.2.2. Child Elements
As described under extended namespaces (Section 2.4), a presence
stanza MAY contain any properly-namespaced child element.
就像Section 2.4的扩展名字空间所说的，presence stanza 可以包含任何
properly-namespaced的child element。
In accordance with the default namespace declaration, by default a
presence stanza is qualified by the 'jabber:client' or
'jabber:server' namespace, which defines certain allowable children
of presence stanzas. If the presence stanza is of type "error", it
MUST include an child; for details, see [XMPP-CORE]. If the
presence stanza possesses no 'type' attribute, it MAY contain any of
the following child elements (note that the child MAY be
sent in a presence stanza of type "unavailable" or, for historical
reasons, "subscribe"):
为了与默认的名字空间的声明保持一致，默认的presence stanza被归在'jabber:client'
或'jabber:server'名字空间之下，这两个名字空间还定义了一些被认可的presence stanza
的children。如果presence stanza是'error'类型的，那么它MUST包含 ；细节请看
[XMPP-CORE]。如果presence stanza没有'type'属性，那么它MAY包含下列child element
(注意， child可以随'unavailable' type的presence stanza或，出于历史原因，
'subscribe' type的presence stanza发出。)
1.
2.
3.
------------------------------------------------------------------------------------------------------
On 7/4/05, run_mei <run_mei at 163.com> wrote:
> 大家好，我觉得即时通时技术是一个有趣的技术，而xmpp ( jabber )技术是唯一
> 的开源的协议，它有很多激动人心的特征，我对它有兴趣，但好象没有中文资料，
> 我想翻译它的英文文档，可是我的英文水平不高，所以我想找人帮我一起来翻译
> 它，我已经翻译了一点。我想找个地方把它共亨出来，同时请大家帮我将翻译错误
> 的地方纠正过来。
> 请问可不可在在www.woodpecker.org上建一个目录存放它。
>
> _______________________________________________
> python-chinese list
> python-chinese at lists.python.cn
> http://python.cn/mailman/listinfo/python-chinese
>
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2005年07月06日 星期三 11:00
shhgs shhgs.efhilt at gmail.com
Wed Jul 6 11:00:13 HKT 2005
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Wed Jul 6 11:00:13 HKT 2005
不好意思，忘了登录了。上次更新的时候没要求登录，这次可能是加了权限了。
已经更新了，用的是最偷懒的 {{{ }}}。不过好像还不难看。
On 7/5/05, shhgs <shhgs.efhilt at gmail.com> wrote:
> RFC 3921的网页怎么变成只读的了？
>
> 今天又翻了一点，这样把，以后我就把我翻的东西通过这个列表发出来，run_mei你负责帮我更新。
>
> ------------------------------------------------------------------------------------------------------
>
>
>
>
>
>
> Network Working Group P. Saint-Andre, Ed.
> Request for Comments: 3921 Jabber Software Foundation
> Category: Standards Track October 2004
>
>
> Extensible Messaging and Presence Protocol (XMPP):
> Instant Messaging and Presence
>
> Status of this Memo
>
> This document specifies an Internet standards track protocol for the
> Internet community, and requests discussion and suggestions for
> improvements. Please refer to the current edition of the "Internet
> Official Protocol Standards" (STD 1) for the standardization state
> and status of this protocol. Distribution of this memo is unlimited.
>
> Copyright Notice
>
> Copyright (C) The Internet Society (2004).
>
> Abstract
>
> This memo describes extensions to and applications of the core
> features of the Extensible Messaging and Presence Protocol (XMPP)
> that provide the basic instant messaging (IM) and presence
> functionality defined in RFC 2779.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Saint-Andre Standards Track [Page 1]
>
> RFC 3921 XMPP IM October 2004
>
>
> Table of Contents
>
> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
> 2. Syntax of XML Stanzas . . . . . . . . . . . . . . . . . . . 4
> 3. Session Establishment . . . . . . . . . . . . . . . . . . . 10
> 4. Exchanging Messages . . . . . . . . . . . . . . . . . . . . 13
> 5. Exchanging Presence Information . . . . . . . . . . . . . . 16
> 6. Managing Subscriptions . . . . . . . . . . . . . . . . . . . 26
> 7. Roster Management . . . . . . . . . . . . . . . . . . . . . 27
> 8. Integration of Roster Items and Presence Subscriptions . . . 32
> 9. Subscription States . . . . . . . . . . . . . . . . . . . . 56
> 10. Blocking Communication . . . . . . . . . . . . . . . . . . . 62
> 11. Server Rules for Handling XML Stanzas . . . . . . . . . . . 85
> 12. IM and Presence Compliance Requirements . . . . . . . . . . 88
> 13. Internationalization Considerations . . . . . . . . . . . . 89
> 14. Security Considerations . . . . . . . . . . . . . . . . . . 89
> 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 90
> 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 91
> A. vCards . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
> B. XML Schemas. . . . . . . . . . . . . . . . . . . . . . . . . 93
> C. Differences Between Jabber IM/Presence Protocols and XMPP. . 105
> Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 106
> Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 106
> Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 106
> Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 107
>
> 1. Introduction
>
> 1.1. Overview
>
> The Extensible Messaging and Presence Protocol (XMPP) is a protocol
> for streaming XML [XML] elements in order to exchange messages and
> presence information in close to real time. The core features of
> XMPP are defined in Extensible Messaging and Presence Protocol
> (XMPP): Core [XMPP-CORE]. These features -- mainly XML streams, use
> of TLS and SASL, and the , , and children
> of the stream root -- provide the building blocks for many types of
> near-real-time applications, which may be layered on top of the core
> by sending application-specific data qualified by particular XML
> namespaces [XML-NAMES]. This memo describes extensions to and
> applications of the core features of XMPP that provide the basic
> functionality expected of an instant messaging (IM) and presence
> application as defined in RFC 2779 [IMP-REQS].
>
> XMPP是一种通过将XML elements流化以达到近乎实时地传递消息(message)和在线信息
> (presence information)的协议。XMPP的核心功能在(XMPP): Core [XMPP-CORE]中定义。
> 这些功能――主要包括XML的流化，TLS和SASL的使用，以及像,以及
> 这样的流的子元素――提供给我们一些素材，使我们能创建很多"半实时(near-real-time)"
> 的应用程序，而这些半实时的应用程序或许会位于应用程序的核心层之上，专门负责发送由程序专用的
> XML数据。这份memo讲述的是怎样扩展和使用XMPP的核心功能，而XMPP的核心协议仅涵盖了由RFC
> 2779[IMP-REQS]定义的，基本的IM和presence application 所应该提供的功能。
>
>
>
>
> 1.2. Requirements
>
> For the purposes of this memo, the requirements of a basic instant
> messaging and presence application are defined by [IMP-REQS], which
> at a high level stipulates that a user must be able to complete the
> following use cases:
>
> 作为本文档的基础，基本的IM和"在线应用程序presence application"的要求
> 刊载在[IMP-REQS]里面。这份文档在大体上规定了用户必须能完成如下的功能。
>
> o Exchange messages with other users
> 与其它用户交换消息
> o Exchange presence information with other users
> 与其它用户交换在线信息
> o Manage subscriptions to and from other users
> 管理和限制自己或他人的在线信息的发布
> o Manage items in a contact list (in XMPP this is called a "roster")
> 管理通讯录里的资料(XMPP称之为roster)
> o Block communications to or from specific other users
> 切断与他人的通讯
>
> Detailed definitions of these functionality areas are contained in
> [IMP-REQS], and the interested reader is directed to that document
> regarding the requirements addressed herein.
>
> 这些功能的详细定义刊载在[IMP-REQS]里，感兴趣的读者可以自己去看。
>
> [IMP-REQS] also stipulates that presence services must be separable
> from instant messaging services; i.e., it must be possible to use the
> protocol to provide a presence service, an instant messaging service,
> or both. Although the text of this memo assumes that implementations
> and deployments will want to offer a unified instant messaging and
> presence service, there is no requirement that a service must offer
> both a presence service and an instant messaging service, and the
> protocol makes it possible to offer separate and distinct services
> for presence and for instant messaging.
>
> [IMP-REQS]同时还规定，在线信息的服务必须与及时信息的服务相分离。比方说，
> 协议必须允许你只使用在线信息，或及时信息服务，当然也可以两个都用。虽然
> 我们认为真正实现的时候，在线信息和及时信息服务肯定是合二为一的，但是它
> 也没有强求你一定必须同时提供在线信息合及时信息服务。这个协议完全允许你
> 提供单独的在线信息或及时信息服务。
>
> Note: While XMPP-based instant messaging and presence meets the
> requirements of [IMP-REQS], it was not designed explicitly with that
> specification in mind, since the base protocol evolved through an
> open development process within the Jabber open-source community
> before RFC 2779 was written. Note also that although protocols
> addressing many other functionality areas have been defined in the
> Jabber community, such protocols are not included in this memo
> because they are not required by [IMP-REQS].
>
> 注意：虽然基于XMPP的及时信息和在线服务符合[IMP-REQS]的要求，但它并
> 不是刻意去实现的，因为Jabber开源社区早在RFC 2779发布之前就已经促成了
> 基本的协议。同时还要指出的是，虽然Jabber社区还为协议设计了很多别的方面
> 的功能，但由于[IMP-REQS]并没有要求，因此我们这里也就不涉及了。
>
> 1.3. Terminology
>
> This memo inherits the terminology defined in [XMPP-CORE].
>
> The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
> "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
> "OPTIONAL" in this document are to be interpreted as described in BCP
> 14, RFC 2119 [TERMS].
>
>
>
>
> 2. Syntax of XML Stanzas
>
> XML Stanzas的语法
>
> The basic semantics and common attributes of XML stanzas qualified by
> the 'jabber:client' and 'jabber:server' namespaces are defined in
> [XMPP-CORE]. However, these namespaces also define various child
> elements, as well as values for the common 'type' attribute, that are
> specific to instant messaging and presence applications. Thus,
> before addressing particular "use cases" for such applications, we
> here further describe the syntax of XML stanzas, thereby
> supplementing the discussion in [XMPP-CORE].
>
> XML stanzas都归在'jabber:client'和'jabber:server'名字空间之下，其基本语义
> 和常用属性由[XMPP-CORE]定义。除了常用的'type'属性的值之外，这两个名字空间
> 还定义了很多专供及时信息或在线信息服务的child elements。因此在描述此类应用
> 程序的"use case"之前，我们先探讨一下XML stanzas的语法，也借此补充一下
> [XMPP-CORE]。
>
> 2.1. Message Syntax
>
> Message stanzas qualified by the 'jabber:client' or 'jabber:server'
> namespace are used to "push" information to another entity. Common
> uses in instant messaging applications include single messages,
> messages sent in the context of a chat conversation, messages sent in
> the context of a multi-user chat room, headlines and other alerts,
> and errors.
>
> 归在'jabber:client'或'jabber:server'名字空间之下的Message stanzas是用来
> 向另一个entity"推"信息用的。在IM应用程序里，这种stanzas常用被用于发送"单条
> 消息(single message)"，在chat环境下发送消息，在多用户的chat room的环境下
> 发送消息，以及发送headline，警告和错误消息。
>
> 2.1.1. Types of Message
>
> The 'type' attribute of a message stanza is RECOMMENDED; if included,
> it specifies the conversational context of the message, thus
> providing a hint regarding presentation (e.g., in a GUI). If
> included, the 'type' attribute MUST have one of the following values:
>
> message stanza的'type'属性是RECOMMENDED的；如果有，它表示这个消息是在怎样
> 的交谈环境下发出的，因此它也暗示了该怎样显示这条消息(比方说在GUI环境下)。
> 'type'属性如果有必须(MUST)是下面值里的一个。
>
> o chat -- The message is sent in the context of a one-to-one chat
> conversation. A compliant client SHOULD present the message in an
> interface enabling one-to-one chat between the two parties,
> including an appropriate conversation history.
>
> chat -- 消息是在一对一的chat谈话中发出的。客户端应当(SHOULD)在一个
> 能让用户进行一对一谈话的界面里提示这条消息，包括交谈的记录。
>
> o error -- An error has occurred related to a previous message sent
> by the sender (for details regarding stanza error syntax, refer to
> [XMPP-CORE]). A compliant client SHOULD present an appropriate
> interface informing the sender of the nature of the error.
>
> error -- 表示先前发送的消息发生了错误(关于stanza的错误的语法，
> 请参阅[XMPP-CORE])。客户端应当(SHOULD)能告诉发送发错误的性质。
>
> o groupchat -- The message is sent in the context of a multi-user
> chat environment (similar to that of [IRC]). A compliant client
> SHOULD present the message in an interface enabling many-to-many
> chat between the parties, including a roster of parties in the
> chatroom and an appropriate conversation history. Full definition
> of XMPP-based groupchat protocols is out of scope for this memo.
>
> groupchat -- 这条消息是在多用户交谈环境下发出的(类似[IRC])。客户端
> 应当(SHOULD)在能允许用户进行多对多谈话的界面里显示这条消息，这其中
> 应该包括chat room的参与者的roster(名单)，以及适当的谈话记录。基于XMPP
> 的群组交谈协议超出了本文档的范围。
>
> o headline -- The message is probably generated by an automated
> service that delivers or broadcasts content (news, sports, market
> information, RSS feeds, etc.). No reply to the message is
> expected, and a compliant client SHOULD present the message in an
> interface that appropriately differentiates the message from
> standalone messages, chat sessions, or groupchat sessions (e.g.,
> by not providing the recipient with the ability to reply).
>
> headline -- 这条消息或许是由某个后台服务生成并发送或广播的(新闻，体育，
> 市场信息，RSS服务等到)。它不需要用户的回应。客户端应当(SHOULD)在
> 一个合适的界面下提示这条消息以将其与"standalone message"，"chat session"
> 和"groupchat session"相区分(比方说用户只能看不能reply)。
>
> o normal -- The message is a single message that is sent outside the
> context of a one-to-one conversation or groupchat, and to which it
> is expected that the recipient will reply. A compliant client
> SHOULD present the message in an interface enabling the recipient
> to reply, but without a conversation history.
>
> normal -- 这是一个single message，既不是一对一的交谈，也不是群组交谈，
> 而且允许接受方回应。客户端应当(SHOULD)在一个能让用户reply的界面里显示
> 这条消息，但是不要有谈话记录。
>
> An IM application SHOULD support all of the foregoing message types;
> if an application receives a message with no 'type' attribute or the
> application does not understand the value of the 'type' attribute
> provided, it MUST consider the message to be of type "normal" (i.e.,
> "normal" is the default). The "error" type MUST be generated only in
> response to an error related to a message received from another
> entity.
>
> IM application应当支持所有上述message type，如果它收到了一个没有'type'属性的message
> 或者它看不懂这个'type'属性，那它必须(MUST)将其认做是"normal"的message(也就是说，
> "normal"是默认的属性)。"error"只限于(MUST)用来回应与对方发出的message相关的错误。
>
> Although the 'type' attribute is OPTIONAL, it is considered polite to
> mirror the type in any replies to a message; furthermore, some
> specialized applications (e.g., a multi-user chat service) MAY at
> their discretion enforce the use of a particular message type (e.g.,
> type='groupchat').
>
> 虽然'type'属性是OPTIONAL的，但是最好在回应信息里面附上相同的'type'信息；此外有些专用程序
> (比方说多用户的chat service)可以(MAY)根据他们自己的需要，强制使用特定的message type
> (比方说type='groupchat')。
>
> 2.1.2. Child Elements
>
> As described under extended namespaces (Section 2.4), a message
> stanza MAY contain any properly-namespaced child element.
>
> 正如我们将在"扩展名字空间"(Section2.4)所讲的，message stanza可以(MAY)包含任意的
> "属于适当的名字空间"的child element。
>
> In accordance with the default namespace declaration, by default a
> message stanza is qualified by the 'jabber:client' or 'jabber:server'
> namespace, which defines certain allowable children of message
> stanzas. If the message stanza is of type "error", it MUST include
> an child; for details, see [XMPP-CORE]. Otherwise, the
> message stanza MAY contain any of the following child elements
> without an explicit namespace declaration:
>
> 为了与默认的名字空间的声明相一致，默认情况下，message stanza被归到'jabber:client'或
> 'jabber:server'名字空间下。这两个名字空间定义了一些被认可的message stanza的child。
> 'error'类型的message stanza必须(MUST)包含 child；具体细节请看[XMPP-CORE]。
> 除此之外，message stanza可以(MAY)不经声明就使用下列的child elements。
>
> 1.
> 2.
> 3.
>
> 2.1.2.1. Subject
>
> The element contains human-readable XML character data
> that specifies the topic of the message. The element MUST
> NOT possess any attributes, with the exception of the 'xml:lang'
> attribute. Multiple instances of the element MAY be
> included for the purpose of providing alternate versions of the same
> subject, but only if each instance possesses an 'xml:lang' attribute
> with a distinct language value. The element MUST NOT
> contain mixed content (as defined in Section 3.2.2 of [XML]).
>
> element包含human-readable的，表示message的标题的XML字符数据。
> 绝对不能(MUST NOT)包含除'xml:lang'之外的任何属性。为了能提供同一个
> subject的多个版本，一个message里面可以(MAY)包含多个 element。但这仅限于
> 每个都包含'xml:lang'属性，并且其language值都不相同的情形。
> 绝对不能(MUST NOT)包含mixed content(见Section 3.2.2)
>
>
> 2.1.2.2. Body
>
> The element contains human-readable XML character data that
> specifies the textual contents of the message; this child element is
> normally included but is OPTIONAL. The element MUST NOT
> possess any attributes, with the exception of the 'xml:lang'
> attribute. Multiple instances of the element MAY be included
> but only if each instance possesses an 'xml:lang' attribute with a
> distinct language value. The element MUST NOT contain mixed
> content (as defined in Section 3.2.2 of [XML]).
>
> element包含human-readable的，用来表示消息的正文内容的XML字符数据；通常
> message都会包含这个child，但它是可选的(OPTIONAL)。 element绝对不能(MUST NOT)
> 包含除'xml:lang'之外的任何属性。一个message里面可以(MAY)包含多个 element。
> 但这仅限于每个都包含'xml:lang'属性，并且其language值都不相同的情形。
> 绝对不能(MUST NOT)包含mixed content(见Section 3.2.2)
>
> 2.1.2.3. Thread
>
> The element contains non-human-readable XML character data
> specifying an identifier that is used for tracking a conversation
> thread (sometimes referred to as an "instant messaging session")
> between two entities. The value of the element is
> generated by the sender and SHOULD be copied back in any replies. If
> used, it MUST be unique to that conversation thread within the stream
> and MUST be consistent throughout that conversation (a client that
> receives a message from the same full JID but with a different thread
> ID MUST assume that the message in question exists outside the
> context of the existing conversation thread). The use of the
> element is OPTIONAL and is not used to identify individual
> messages, only conversations. A message stanza MUST NOT contain more
> than one element. The element MUST NOT possess
> any attributes. The value of the element MUST be treated
> as opaque by entities; no semantic meaning may be derived from it,
> and only exact comparisons may be made against it. The
> element MUST NOT contain mixed content (as defined in Section 3.2.2
> of [XML]).
>
> element包含非human-readable的XML字符数据。它是一个用于表示两个entity
> 之间的conversion thread的(有时也被称作"instance messaging session")标识符。
> element的值由sender生成，而且每次回复的时候必须(SHOULD)包含在内。如果
> 用到了它，那么它必须(MUST)与stream里的conversation thread一一对应，而且整个谈话期间
> 必须保持一致(如果client端收到了同一个JID发出的，但是thread ID不同的message，必须(MUST)
> 认定这个消息与当前的conversation thread无关。) element是OPTIONAL的，
> 且不用于标识单个message，它是用来标识conversation的。一个message stanza MUST NOT
> 包含二个或二个以上的 element。 element MUST NOT包含任何属性。
> 对entities来说的值必须(MUST)是不透明的；不能用它来获取任何语义信息，而且只能
> 对它进行精确地比较。 MUST NOT包含mixed content(Section 3.2.2)
>
> 2.2. Presence Syntax
>
> Presence stanzas are used qualified by the 'jabber:client' or
> 'jabber:server' namespace to express an entity's current network
> availability (offline or online, along with various sub-states of the
> latter and optional user-defined descriptive text), and to notify
> other entities of that availability. Presence stanzas are also used
> to negotiate and manage subscriptions to the presence of other
> entities.
>
> Presence stanza属于'jabber:client'或'jabber:server'名字空间，它们是用来表示
> entity的当前网络可得性(offline还是online，此外后者还有很多sub-state和可选的用户
> 自定义的叙述性文字)，并且将其通知给其它entities的。Persence stanzas也被用于协商
> 和管理订阅其它entities的presence信息。
>
> 2.2.1. Types of Presence
>
> The 'type' attribute of a presence stanza is OPTIONAL. A presence
> stanza that does not possess a 'type' attribute is used to signal to
> the server that the sender is online and available for communication.
> If included, the 'type' attribute specifies a lack of availability, a
> request to manage a subscription to another entity's presence, a
> request for another entity's current presence, or an error related to
> a previously-sent presence stanza. If included, the 'type' attribute
> MUST have one of the following values:
>
> presence stanza的'type'属性是OPTIONAL的。不带'type'属性的presence stanza
> 是用来通知服务器sender已经上线，并且available for communication。如果有，那么这个
> 'type'或者用来表示可得性方面的限制，或者用来管理订阅其它用户的presence信息，或者用于
> 查询其它用户的当前可得性，或者是先前发送的presence stanza出了错。如果有，'type'属性
> MUST是下列值中的一个:
>
> o unavailable -- Signals that the entity is no longer available for
> communication.
>
> unavailable -- 表示entity不再available for communication了
>
> o subscribe -- The sender wishes to subscribe to the recipient's
> presence.
>
> subscribe -- sender希望能订阅recipent的presence信息
>
> o subscribed -- The sender has allowed the recipient to receive
> their presence.
>
> subscribed -- 发送方同意让接受方订阅自己的在线信息
>
> o unsubscribe -- The sender is unsubscribing from another entity's
> presence.
>
> unsubscribe -- 发送方取消订阅另一方的在线信息
>
> o unsubscribed -- The subscription request has been denied or a
> previously-granted subscription has been cancelled.
>
> unsubscribed -- 订阅请求被拒绝或者先前授予的订阅权限被撤销了
>
> o probe -- A request for an entity's current presence; SHOULD be
> generated only by a server on behalf of a user.
>
> probe -- 请求entity的当前在线信息；只有(SHOULD)server才能代表用户去生成此类信息。
>
> o error -- An error has occurred regarding processing or delivery of
> a previously-sent presence stanza.
>
> error -- 先前发送的presence stanza在处理或投送过程中出现了错误。
>
> For detailed information regarding presence semantics and the
> subscription model used in the context of XMPP-based instant
> messaging and presence applications, refer to Exchanging Presence
> Information (Section 5) and Managing Subscriptions (Section 6).
>
> 要想详细了解相关信息，请参阅Section 5 Exchanging Presence Information
> 和Section 6 Managing Subscriptions。
>
> 2.2.2. Child Elements
>
> As described under extended namespaces (Section 2.4), a presence
> stanza MAY contain any properly-namespaced child element.
>
> 就像Section 2.4的扩展名字空间所说的，presence stanza 可以包含任何
> properly-namespaced的child element。
>
> In accordance with the default namespace declaration, by default a
> presence stanza is qualified by the 'jabber:client' or
> 'jabber:server' namespace, which defines certain allowable children
> of presence stanzas. If the presence stanza is of type "error", it
> MUST include an child; for details, see [XMPP-CORE]. If the
> presence stanza possesses no 'type' attribute, it MAY contain any of
> the following child elements (note that the child MAY be
> sent in a presence stanza of type "unavailable" or, for historical
> reasons, "subscribe"):
>
> 为了与默认的名字空间的声明保持一致，默认的presence stanza被归在'jabber:client'
> 或'jabber:server'名字空间之下，这两个名字空间还定义了一些被认可的presence stanza
> 的children。如果presence stanza是'error'类型的，那么它MUST包含；细节请看
> [XMPP-CORE]。如果presence stanza没有'type'属性，那么它MAY包含下列child element
> (注意， child可以随'unavailable' type的presence stanza或，出于历史原因，
> 'subscribe' type的presence stanza发出。)
>
> 1.
> 2.
> 3.
> ------------------------------------------------------------------------------------------------------
>
> On 7/4/05, run_mei <run_mei at 163.com> wrote:
> > 大家好，我觉得即时通时技术是一个有趣的技术，而xmpp ( jabber )技术是唯一
> > 的开源的协议，它有很多激动人心的特征，我对它有兴趣，但好象没有中文资料，
> > 我想翻译它的英文文档，可是我的英文水平不高，所以我想找人帮我一起来翻译
> > 它，我已经翻译了一点。我想找个地方把它共亨出来，同时请大家帮我将翻译错误
> > 的地方纠正过来。
> > 请问可不可在在www.woodpecker.org上建一个目录存放它。
> >
> > _______________________________________________
> > python-chinese list
> > python-chinese at lists.python.cn
> > http://python.cn/mailman/listinfo/python-chinese
> >
>
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2005年07月06日 星期三 11:15
Zoom Quiet zoom.quiet at gmail.com
Wed Jul 6 11:15:42 HKT 2005
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Wed Jul 6 11:15:42 HKT 2005
嘿嘿嘿！ 辛苦了！ 其实进行大型文档翻译，而使用MoinMoin 中蟒早已进行中了, 也有类似的翻译约定，都是直接参考侯老师的， 对页面进行了整理，建议草稿和Wiki 文章分开， 由专人整理，校稿发布，并按照章节分子页面，这样一来，可以进行并行编辑哪………… 在 05-7-6，shhgs<shhgs.efhilt at gmail.com> 写道： > 不好意思，忘了登录了。上次更新的时候没要求登录，这次可能是加了权限了。 > > 已经更新了，用的是最偷懒的 {{{ }}}。不过好像还不难看。 > > On 7/5/05, shhgs <shhgs.efhilt at gmail.com> wrote: > > RFC 3921的网页怎么变成只读的了？ > > > > 今天又翻了一点，这样把，以后我就把我翻的东西通过这个列表发出来，run_mei你负责帮我更新。 > > > > ------------------------------------------------------------------------------------------------------ > > > > > > > > > > > > > > Network Working Group P. Saint-Andre, Ed. > > Request for Comments: 3921 Jabber Software Foundation > > Category: Standards Track October 2004 > > > > > > Extensible Messaging and Presence Protocol (XMPP): > > Instant Messaging and Presence > > > > Status of this Memo > > > > This document specifies an Internet standards track protocol for the > > Internet community, and requests discussion and suggestions for > > improvements. Please refer to the current edition of the "Internet > > Official Protocol Standards" (STD 1) for the standardization state > > and status of this protocol. Distribution of this memo is unlimited. > > > > Copyright Notice > > > > Copyright (C) The Internet Society (2004). > > > > Abstract > > > > This memo describes extensions to and applications of the core > > features of the Extensible Messaging and Presence Protocol (XMPP) > > that provide the basic instant messaging (IM) and presence > > functionality defined in RFC 2779. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Saint-Andre Standards Track [Page 1] > > > > RFC 3921 XMPP IM October 2004 > > > > > > Table of Contents > > > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > > 2. Syntax of XML Stanzas . . . . . . . . . . . . . . . . . . . 4 > > 3. Session Establishment . . . . . . . . . . . . . . . . . . . 10 > > 4. Exchanging Messages . . . . . . . . . . . . . . . . . . . . 13 > > 5. Exchanging Presence Information . . . . . . . . . . . . . . 16 > > 6. Managing Subscriptions . . . . . . . . . . . . . . . . . . . 26 > > 7. Roster Management . . . . . . . . . . . . . . . . . . . . . 27 > > 8. Integration of Roster Items and Presence Subscriptions . . . 32 > > 9. Subscription States . . . . . . . . . . . . . . . . . . . . 56 > > 10. Blocking Communication . . . . . . . . . . . . . . . . . . . 62 > > 11. Server Rules for Handling XML Stanzas . . . . . . . . . . . 85 > > 12. IM and Presence Compliance Requirements . . . . . . . . . . 88 > > 13. Internationalization Considerations . . . . . . . . . . . . 89 > > 14. Security Considerations . . . . . . . . . . . . . . . . . . 89 > > 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 90 > > 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 91 > > A. vCards . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 > > B. XML Schemas. . . . . . . . . . . . . . . . . . . . . . . . . 93 > > C. Differences Between Jabber IM/Presence Protocols and XMPP. . 105 > > Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 106 > > Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 106 > > Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 106 > > Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 107 > > > > 1. Introduction > > > > 1.1. Overview > > > > The Extensible Messaging and Presence Protocol (XMPP) is a protocol > > for streaming XML [XML] elements in order to exchange messages and > > presence information in close to real time. The core features of > > XMPP are defined in Extensible Messaging and Presence Protocol > > (XMPP): Core [XMPP-CORE]. These features -- mainly XML streams, use > > of TLS and SASL, and the, > > of the stream root -- provide the building blocks for many types of > > near-real-time applications, which may be layered on top of the core > > by sending application-specific data qualified by particular XML > > namespaces [XML-NAMES]. This memo describes extensions to and > > applications of the core features of XMPP that provide the basic > > functionality expected of an instant messaging (IM) and presence > > application as defined in RFC 2779 [IMP-REQS]. > > > > XMPP是一种通过将XML elements流化以达到近乎实时地传递消息(message)和在线信息 > > (presence information)的协议。XMPP的核心功能在(XMPP): Core [XMPP-CORE]中定义。 > > 这些功能――主要包括XML的流化，TLS和SASL的使用，以及像, and children , > >以及 这样的流的子元素――提供给我们一些素材，使我们能创建很多"半实时(near-real-time)" > > 的应用程序，而这些半实时的应用程序或许会位于应用程序的核心层之上，专门负责发送由程序专用的 > > XML数据。这份memo讲述的是怎样扩展和使用XMPP的核心功能，而XMPP的核心协议仅涵盖了由RFC > > 2779[IMP-REQS]定义的，基本的IM和presence application 所应该提供的功能。 > > > > > > > > > > 1.2. Requirements > > > > For the purposes of this memo, the requirements of a basic instant > > messaging and presence application are defined by [IMP-REQS], which > > at a high level stipulates that a user must be able to complete the > > following use cases: > > > > 作为本文档的基础，基本的IM和"在线应用程序presence application"的要求 > > 刊载在[IMP-REQS]里面。这份文档在大体上规定了用户必须能完成如下的功能。 > > > > o Exchange messages with other users > > 与其它用户交换消息 > > o Exchange presence information with other users > > 与其它用户交换在线信息 > > o Manage subscriptions to and from other users > > 管理和限制自己或他人的在线信息的发布 > > o Manage items in a contact list (in XMPP this is called a "roster") > > 管理通讯录里的资料(XMPP称之为roster) > > o Block communications to or from specific other users > > 切断与他人的通讯 > > > > Detailed definitions of these functionality areas are contained in > > [IMP-REQS], and the interested reader is directed to that document > > regarding the requirements addressed herein. > > > > 这些功能的详细定义刊载在[IMP-REQS]里，感兴趣的读者可以自己去看。 > > > > [IMP-REQS] also stipulates that presence services must be separable > > from instant messaging services; i.e., it must be possible to use the > > protocol to provide a presence service, an instant messaging service, > > or both. Although the text of this memo assumes that implementations > > and deployments will want to offer a unified instant messaging and > > presence service, there is no requirement that a service must offer > > both a presence service and an instant messaging service, and the > > protocol makes it possible to offer separate and distinct services > > for presence and for instant messaging. > > > > [IMP-REQS]同时还规定，在线信息的服务必须与及时信息的服务相分离。比方说， > > 协议必须允许你只使用在线信息，或及时信息服务，当然也可以两个都用。虽然 > > 我们认为真正实现的时候，在线信息和及时信息服务肯定是合二为一的，但是它 > > 也没有强求你一定必须同时提供在线信息合及时信息服务。这个协议完全允许你 > > 提供单独的在线信息或及时信息服务。 > > > > Note: While XMPP-based instant messaging and presence meets the > > requirements of [IMP-REQS], it was not designed explicitly with that > > specification in mind, since the base protocol evolved through an > > open development process within the Jabber open-source community > > before RFC 2779 was written. Note also that although protocols > > addressing many other functionality areas have been defined in the > > Jabber community, such protocols are not included in this memo > > because they are not required by [IMP-REQS]. > > > > 注意：虽然基于XMPP的及时信息和在线服务符合[IMP-REQS]的要求，但它并 > > 不是刻意去实现的，因为Jabber开源社区早在RFC 2779发布之前就已经促成了 > > 基本的协议。同时还要指出的是，虽然Jabber社区还为协议设计了很多别的方面 > > 的功能，但由于[IMP-REQS]并没有要求，因此我们这里也就不涉及了。 > > > > 1.3. Terminology > > > > This memo inherits the terminology defined in [XMPP-CORE]. > > > > The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", > > "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > > "OPTIONAL" in this document are to be interpreted as described in BCP > > 14, RFC 2119 [TERMS]. > > > > > > > > > > 2. Syntax of XML Stanzas > > > > XML Stanzas的语法 > > > > The basic semantics and common attributes of XML stanzas qualified by > > the 'jabber:client' and 'jabber:server' namespaces are defined in > > [XMPP-CORE]. However, these namespaces also define various child > > elements, as well as values for the common 'type' attribute, that are > > specific to instant messaging and presence applications. Thus, > > before addressing particular "use cases" for such applications, we > > here further describe the syntax of XML stanzas, thereby > > supplementing the discussion in [XMPP-CORE]. > > > > XML stanzas都归在'jabber:client'和'jabber:server'名字空间之下，其基本语义 > > 和常用属性由[XMPP-CORE]定义。除了常用的'type'属性的值之外，这两个名字空间 > > 还定义了很多专供及时信息或在线信息服务的child elements。因此在描述此类应用 > > 程序的"use case"之前，我们先探讨一下XML stanzas的语法，也借此补充一下 > > [XMPP-CORE]。 > > > > 2.1. Message Syntax > > > > Message stanzas qualified by the 'jabber:client' or 'jabber:server' > > namespace are used to "push" information to another entity. Common > > uses in instant messaging applications include single messages, > > messages sent in the context of a chat conversation, messages sent in > > the context of a multi-user chat room, headlines and other alerts, > > and errors. > > > > 归在'jabber:client'或'jabber:server'名字空间之下的Message stanzas是用来 > > 向另一个entity"推"信息用的。在IM应用程序里，这种stanzas常用被用于发送"单条 > > 消息(single message)"，在chat环境下发送消息，在多用户的chat room的环境下 > > 发送消息，以及发送headline，警告和错误消息。 > > > > 2.1.1. Types of Message > > > > The 'type' attribute of a message stanza is RECOMMENDED; if included, > > it specifies the conversational context of the message, thus > > providing a hint regarding presentation (e.g., in a GUI). If > > included, the 'type' attribute MUST have one of the following values: > > > > message stanza的'type'属性是RECOMMENDED的；如果有，它表示这个消息是在怎样 > > 的交谈环境下发出的，因此它也暗示了该怎样显示这条消息(比方说在GUI环境下)。 > > 'type'属性如果有必须(MUST)是下面值里的一个。 > > > > o chat -- The message is sent in the context of a one-to-one chat > > conversation. A compliant client SHOULD present the message in an > > interface enabling one-to-one chat between the two parties, > > including an appropriate conversation history. > > > > chat -- 消息是在一对一的chat谈话中发出的。客户端应当(SHOULD)在一个 > > 能让用户进行一对一谈话的界面里提示这条消息，包括交谈的记录。 > > > > o error -- An error has occurred related to a previous message sent > > by the sender (for details regarding stanza error syntax, refer to > > [XMPP-CORE]). A compliant client SHOULD present an appropriate > > interface informing the sender of the nature of the error. > > > > error -- 表示先前发送的消息发生了错误(关于stanza的错误的语法， > > 请参阅[XMPP-CORE])。客户端应当(SHOULD)能告诉发送发错误的性质。 > > > > o groupchat -- The message is sent in the context of a multi-user > > chat environment (similar to that of [IRC]). A compliant client > > SHOULD present the message in an interface enabling many-to-many > > chat between the parties, including a roster of parties in the > > chatroom and an appropriate conversation history. Full definition > > of XMPP-based groupchat protocols is out of scope for this memo. > > > > groupchat -- 这条消息是在多用户交谈环境下发出的(类似[IRC])。客户端 > > 应当(SHOULD)在能允许用户进行多对多谈话的界面里显示这条消息，这其中 > > 应该包括chat room的参与者的roster(名单)，以及适当的谈话记录。基于XMPP > > 的群组交谈协议超出了本文档的范围。 > > > > o headline -- The message is probably generated by an automated > > service that delivers or broadcasts content (news, sports, market > > information, RSS feeds, etc.). No reply to the message is > > expected, and a compliant client SHOULD present the message in an > > interface that appropriately differentiates the message from > > standalone messages, chat sessions, or groupchat sessions (e.g., > > by not providing the recipient with the ability to reply). > > > > headline -- 这条消息或许是由某个后台服务生成并发送或广播的(新闻，体育， > > 市场信息，RSS服务等到)。它不需要用户的回应。客户端应当(SHOULD)在 > > 一个合适的界面下提示这条消息以将其与"standalone message"，"chat session" > > 和"groupchat session"相区分(比方说用户只能看不能reply)。 > > > > o normal -- The message is a single message that is sent outside the > > context of a one-to-one conversation or groupchat, and to which it > > is expected that the recipient will reply. A compliant client > > SHOULD present the message in an interface enabling the recipient > > to reply, but without a conversation history. > > > > normal -- 这是一个single message，既不是一对一的交谈，也不是群组交谈， > > 而且允许接受方回应。客户端应当(SHOULD)在一个能让用户reply的界面里显示 > > 这条消息，但是不要有谈话记录。 > > > > An IM application SHOULD support all of the foregoing message types; > > if an application receives a message with no 'type' attribute or the > > application does not understand the value of the 'type' attribute > > provided, it MUST consider the message to be of type "normal" (i.e., > > "normal" is the default). The "error" type MUST be generated only in > > response to an error related to a message received from another > > entity. > > > > IM application应当支持所有上述message type，如果它收到了一个没有'type'属性的message > > 或者它看不懂这个'type'属性，那它必须(MUST)将其认做是"normal"的message(也就是说， > > "normal"是默认的属性)。"error"只限于(MUST)用来回应与对方发出的message相关的错误。 > > > > Although the 'type' attribute is OPTIONAL, it is considered polite to > > mirror the type in any replies to a message; furthermore, some > > specialized applications (e.g., a multi-user chat service) MAY at > > their discretion enforce the use of a particular message type (e.g., > > type='groupchat'). > > > > 虽然'type'属性是OPTIONAL的，但是最好在回应信息里面附上相同的'type'信息；此外有些专用程序 > > (比方说多用户的chat service)可以(MAY)根据他们自己的需要，强制使用特定的message type > > (比方说type='groupchat')。 > > > > 2.1.2. Child Elements > > > > As described under extended namespaces (Section 2.4), a message > > stanza MAY contain any properly-namespaced child element. > > > > 正如我们将在"扩展名字空间"(Section2.4)所讲的，message stanza可以(MAY)包含任意的 > > "属于适当的名字空间"的child element。 > > > > In accordance with the default namespace declaration, by default a > > message stanza is qualified by the 'jabber:client' or 'jabber:server' > > namespace, which defines certain allowable children of message > > stanzas. If the message stanza is of type "error", it MUST include > > anchild; for details, see [XMPP-CORE]. Otherwise, the > > message stanza MAY contain any of the following child elements > > without an explicit namespace declaration: > > > > 为了与默认的名字空间的声明相一致，默认情况下，message stanza被归到'jabber:client'或 > > 'jabber:server'名字空间下。这两个名字空间定义了一些被认可的message stanza的child。 > > 'error'类型的message stanza必须(MUST)包含child；具体细节请看[XMPP-CORE]。 > > 除此之外，message stanza可以(MAY)不经声明就使用下列的child elements。 > > > > 1.> > 2. > > 3. > > > > 2.1.2.1. Subject > > > > The element contains human-readable XML character data > > that specifies the topic of the message. Theelement MUST > > NOT possess any attributes, with the exception of the 'xml:lang' > > attribute. Multiple instances of theelement MAY be > > included for the purpose of providing alternate versions of the same > > subject, but only if each instance possesses an 'xml:lang' attribute > > with a distinct language value. Theelement MUST NOT > > contain mixed content (as defined in Section 3.2.2 of [XML]). > > > >element包含human-readable的，表示message的标题的XML字符数据。 > >绝对不能(MUST NOT)包含除'xml:lang'之外的任何属性。为了能提供同一个 > > subject的多个版本，一个message里面可以(MAY)包含多个 element。但这仅限于 > > 每个都包含'xml:lang'属性，并且其language值都不相同的情形。> > 绝对不能(MUST NOT)包含mixed content(见Section 3.2.2) > > > > > > 2.1.2.2. Body > > > > The element contains human-readable XML character data that > > specifies the textual contents of the message; this child element is > > normally included but is OPTIONAL. The element MUST NOT > > possess any attributes, with the exception of the 'xml:lang' > > attribute. Multiple instances of the element MAY be included > > but only if each instance possesses an 'xml:lang' attribute with a > > distinct language value. The element MUST NOT contain mixed > > content (as defined in Section 3.2.2 of [XML]). > > > > element包含human-readable的，用来表示消息的正文内容的XML字符数据；通常 > > message都会包含这个child，但它是可选的(OPTIONAL)。 element绝对不能(MUST NOT) > > 包含除'xml:lang'之外的任何属性。一个message里面可以(MAY)包含多个 element。 > > 但这仅限于每个都包含'xml:lang'属性，并且其language值都不相同的情形。 > > 绝对不能(MUST NOT)包含mixed content(见Section 3.2.2) > > > > 2.1.2.3. Thread > > > > Theelement contains non-human-readable XML character data > > specifying an identifier that is used for tracking a conversation > > thread (sometimes referred to as an "instant messaging session") > > between two entities. The value of theelement is > > generated by the sender and SHOULD be copied back in any replies. If > > used, it MUST be unique to that conversation thread within the stream > > and MUST be consistent throughout that conversation (a client that > > receives a message from the same full JID but with a different thread > > ID MUST assume that the message in question exists outside the > > context of the existing conversation thread). The use of the > >element is OPTIONAL and is not used to identify individual > > messages, only conversations. A message stanza MUST NOT contain more > > than oneelement. The element MUST NOT possess > > any attributes. The value of theelement MUST be treated > > as opaque by entities; no semantic meaning may be derived from it, > > and only exact comparisons may be made against it. The> > element MUST NOT contain mixed content (as defined in Section 3.2.2 > > of [XML]). > > > > element包含非human-readable的XML字符数据。它是一个用于表示两个entity > > 之间的conversion thread的(有时也被称作"instance messaging session")标识符。 > >element的值由sender生成，而且每次回复的时候必须(SHOULD)包含在内。如果 > > 用到了它，那么它必须(MUST)与stream里的conversation thread一一对应，而且整个谈话期间 > > 必须保持一致(如果client端收到了同一个JID发出的，但是thread ID不同的message，必须(MUST) > > 认定这个消息与当前的conversation thread无关。)element是OPTIONAL的， > > 且不用于标识单个message，它是用来标识conversation的。一个message stanza MUST NOT > > 包含二个或二个以上的element。 element MUST NOT包含任何属性。 > > 对entities来说的值必须(MUST)是不透明的；不能用它来获取任何语义信息，而且只能 > > 对它进行精确地比较。MUST NOT包含mixed content(Section 3.2.2) > > > > 2.2. Presence Syntax > > > > Presence stanzas are used qualified by the 'jabber:client' or > > 'jabber:server' namespace to express an entity's current network > > availability (offline or online, along with various sub-states of the > > latter and optional user-defined descriptive text), and to notify > > other entities of that availability. Presence stanzas are also used > > to negotiate and manage subscriptions to the presence of other > > entities. > > > > Presence stanza属于'jabber:client'或'jabber:server'名字空间，它们是用来表示 > > entity的当前网络可得性(offline还是online，此外后者还有很多sub-state和可选的用户 > > 自定义的叙述性文字)，并且将其通知给其它entities的。Persence stanzas也被用于协商 > > 和管理订阅其它entities的presence信息。 > > > > 2.2.1. Types of Presence > > > > The 'type' attribute of a presence stanza is OPTIONAL. A presence > > stanza that does not possess a 'type' attribute is used to signal to > > the server that the sender is online and available for communication. > > If included, the 'type' attribute specifies a lack of availability, a > > request to manage a subscription to another entity's presence, a > > request for another entity's current presence, or an error related to > > a previously-sent presence stanza. If included, the 'type' attribute > > MUST have one of the following values: > > > > presence stanza的'type'属性是OPTIONAL的。不带'type'属性的presence stanza > > 是用来通知服务器sender已经上线，并且available for communication。如果有，那么这个 > > 'type'或者用来表示可得性方面的限制，或者用来管理订阅其它用户的presence信息，或者用于 > > 查询其它用户的当前可得性，或者是先前发送的presence stanza出了错。如果有，'type'属性 > > MUST是下列值中的一个: > > > > o unavailable -- Signals that the entity is no longer available for > > communication. > > > > unavailable -- 表示entity不再available for communication了 > > > > o subscribe -- The sender wishes to subscribe to the recipient's > > presence. > > > > subscribe -- sender希望能订阅recipent的presence信息 > > > > o subscribed -- The sender has allowed the recipient to receive > > their presence. > > > > subscribed -- 发送方同意让接受方订阅自己的在线信息 > > > > o unsubscribe -- The sender is unsubscribing from another entity's > > presence. > > > > unsubscribe -- 发送方取消订阅另一方的在线信息 > > > > o unsubscribed -- The subscription request has been denied or a > > previously-granted subscription has been cancelled. > > > > unsubscribed -- 订阅请求被拒绝或者先前授予的订阅权限被撤销了 > > > > o probe -- A request for an entity's current presence; SHOULD be > > generated only by a server on behalf of a user. > > > > probe -- 请求entity的当前在线信息；只有(SHOULD)server才能代表用户去生成此类信息。 > > > > o error -- An error has occurred regarding processing or delivery of > > a previously-sent presence stanza. > > > > error -- 先前发送的presence stanza在处理或投送过程中出现了错误。 > > > > For detailed information regarding presence semantics and the > > subscription model used in the context of XMPP-based instant > > messaging and presence applications, refer to Exchanging Presence > > Information (Section 5) and Managing Subscriptions (Section 6). > > > > 要想详细了解相关信息，请参阅Section 5 Exchanging Presence Information > > 和Section 6 Managing Subscriptions。 > > > > 2.2.2. Child Elements > > > > As described under extended namespaces (Section 2.4), a presence > > stanza MAY contain any properly-namespaced child element. > > > > 就像Section 2.4的扩展名字空间所说的，presence stanza 可以包含任何 > > properly-namespaced的child element。 > > > > In accordance with the default namespace declaration, by default a > > presence stanza is qualified by the 'jabber:client' or > > 'jabber:server' namespace, which defines certain allowable children > > of presence stanzas. If the presence stanza is of type "error", it > > MUST include anchild; for details, see [XMPP-CORE]. If the > > presence stanza possesses no 'type' attribute, it MAY contain any of > > the following child elements (note that thechild MAY be > > sent in a presence stanza of type "unavailable" or, for historical > > reasons, "subscribe"): > > > > 为了与默认的名字空间的声明保持一致，默认的presence stanza被归在'jabber:client' > > 或'jabber:server'名字空间之下，这两个名字空间还定义了一些被认可的presence stanza > > 的children。如果presence stanza是'error'类型的，那么它MUST包含；细节请看 > > [XMPP-CORE]。如果presence stanza没有'type'属性，那么它MAY包含下列child element > > (注意，child可以随'unavailable' type的presence stanza或，出于历史原因， > > 'subscribe' type的presence stanza发出。) > > > > 1.> > 2. > > 3. > > ------------------------------------------------------------------------------------------------------ > > > > On 7/4/05, run_mei <run_mei at 163.com> wrote: > > > 大家好，我觉得即时通时技术是一个有趣的技术，而xmpp ( jabber )技术是唯一 > > > 的开源的协议，它有很多激动人心的特征，我对它有兴趣，但好象没有中文资料， > > > 我想翻译它的英文文档，可是我的英文水平不高，所以我想找人帮我一起来翻译 > > > 它，我已经翻译了一点。我想找个地方把它共亨出来，同时请大家帮我将翻译错误 > > > 的地方纠正过来。 > > > 请问可不可在在www.woodpecker.org上建一个目录存放它。 > > > > > > _______________________________________________ > > > python-chinese list > > > python-chinese at lists.python.cn > > > http://python.cn/mailman/listinfo/python-chinese > > > > > > > _______________________________________________ > python-chinese list > python-chinese at lists.python.cn > http://python.cn/mailman/listinfo/python-chinese > > > -- [Time is unimportant, only life important!]
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2005年07月06日 星期三 11:20
run_mei run_mei at 163.com
Wed Jul 6 11:20:40 HKT 2005
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Wed Jul 6 11:20:40 HKT 2005
好的，我很乐意做这个。 shhgs 写道: >RFC 3921的网页怎么变成只读的了？ > >今天又翻了一点，这样把，以后我就把我翻的东西通过这个列表发出来，run_mei你负责帮我更新。 > >------------------------------------------------------------------------------------------------------ > > > > > > >Network Working Group P. Saint-Andre, Ed. >Request for Comments: 3921 Jabber Software Foundation >Category: Standards Track October 2004 > > > Extensible Messaging and Presence Protocol (XMPP): > Instant Messaging and Presence > >Status of this Memo > > This document specifies an Internet standards track protocol for the > Internet community, and requests discussion and suggestions for > improvements. Please refer to the current edition of the "Internet > Official Protocol Standards" (STD 1) for the standardization state > and status of this protocol. Distribution of this memo is unlimited. > >Copyright Notice > > Copyright (C) The Internet Society (2004). > >Abstract > > This memo describes extensions to and applications of the core > features of the Extensible Messaging and Presence Protocol (XMPP) > that provide the basic instant messaging (IM) and presence > functionality defined in RFC 2779. > > > > > > > > > > > > > > > > > > > > > > > > > >Saint-Andre Standards Track [Page 1] > >RFC 3921 XMPP IM October 2004 > > >Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 > 2. Syntax of XML Stanzas . . . . . . . . . . . . . . . . . . . 4 > 3. Session Establishment . . . . . . . . . . . . . . . . . . . 10 > 4. Exchanging Messages . . . . . . . . . . . . . . . . . . . . 13 > 5. Exchanging Presence Information . . . . . . . . . . . . . . 16 > 6. Managing Subscriptions . . . . . . . . . . . . . . . . . . . 26 > 7. Roster Management . . . . . . . . . . . . . . . . . . . . . 27 > 8. Integration of Roster Items and Presence Subscriptions . . . 32 > 9. Subscription States . . . . . . . . . . . . . . . . . . . . 56 > 10. Blocking Communication . . . . . . . . . . . . . . . . . . . 62 > 11. Server Rules for Handling XML Stanzas . . . . . . . . . . . 85 > 12. IM and Presence Compliance Requirements . . . . . . . . . . 88 > 13. Internationalization Considerations . . . . . . . . . . . . 89 > 14. Security Considerations . . . . . . . . . . . . . . . . . . 89 > 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 90 > 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 91 > A. vCards . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 > B. XML Schemas. . . . . . . . . . . . . . . . . . . . . . . . . 93 > C. Differences Between Jabber IM/Presence Protocols and XMPP. . 105 > Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 106 > Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 106 > Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 106 > Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 107 > >1. Introduction > >1.1. Overview > > The Extensible Messaging and Presence Protocol (XMPP) is a protocol > for streaming XML [XML] elements in order to exchange messages and > presence information in close to real time. The core features of > XMPP are defined in Extensible Messaging and Presence Protocol > (XMPP): Core [XMPP-CORE]. These features -- mainly XML streams, use > of TLS and SASL, and the, > of the stream root -- provide the building blocks for many types of > near-real-time applications, which may be layered on top of the core > by sending application-specific data qualified by particular XML > namespaces [XML-NAMES]. This memo describes extensions to and > applications of the core features of XMPP that provide the basic > functionality expected of an instant messaging (IM) and presence > application as defined in RFC 2779 [IMP-REQS]. > > XMPP是一种通过将XML elements流化以达到近乎实时地传递消息(message)和在线信息 > (presence information)的协议。XMPP的核心功能在(XMPP): Core [XMPP-CORE]中定义。 > 这些功能――主要包括XML的流化，TLS和SASL的使用，以及像, and children , >以及 这样的流的子元素――提供给我们一些素材，使我们能创建很多"半实时(near-real-time)" > 的应用程序，而这些半实时的应用程序或许会位于应用程序的核心层之上，专门负责发送由程序专用的 > XML数据。这份memo讲述的是怎样扩展和使用XMPP的核心功能，而XMPP的核心协议仅涵盖了由RFC > 2779[IMP-REQS]定义的，基本的IM和presence application 所应该提供的功能。 > > > > >1.2. Requirements > > For the purposes of this memo, the requirements of a basic instant > messaging and presence application are defined by [IMP-REQS], which > at a high level stipulates that a user must be able to complete the > following use cases: > > 作为本文档的基础，基本的IM和"在线应用程序presence application"的要求 > 刊载在[IMP-REQS]里面。这份文档在大体上规定了用户必须能完成如下的功能。 > > o Exchange messages with other users > 与其它用户交换消息 > o Exchange presence information with other users > 与其它用户交换在线信息 > o Manage subscriptions to and from other users > 管理和限制自己或他人的在线信息的发布 > o Manage items in a contact list (in XMPP this is called a "roster") > 管理通讯录里的资料(XMPP称之为roster) > o Block communications to or from specific other users > 切断与他人的通讯 > > Detailed definitions of these functionality areas are contained in > [IMP-REQS], and the interested reader is directed to that document > regarding the requirements addressed herein. > > 这些功能的详细定义刊载在[IMP-REQS]里，感兴趣的读者可以自己去看。 > > [IMP-REQS] also stipulates that presence services must be separable > from instant messaging services; i.e., it must be possible to use the > protocol to provide a presence service, an instant messaging service, > or both. Although the text of this memo assumes that implementations > and deployments will want to offer a unified instant messaging and > presence service, there is no requirement that a service must offer > both a presence service and an instant messaging service, and the > protocol makes it possible to offer separate and distinct services > for presence and for instant messaging. > > [IMP-REQS]同时还规定，在线信息的服务必须与及时信息的服务相分离。比方说， > 协议必须允许你只使用在线信息，或及时信息服务，当然也可以两个都用。虽然 > 我们认为真正实现的时候，在线信息和及时信息服务肯定是合二为一的，但是它 > 也没有强求你一定必须同时提供在线信息合及时信息服务。这个协议完全允许你 > 提供单独的在线信息或及时信息服务。 > > Note: While XMPP-based instant messaging and presence meets the > requirements of [IMP-REQS], it was not designed explicitly with that > specification in mind, since the base protocol evolved through an > open development process within the Jabber open-source community > before RFC 2779 was written. Note also that although protocols > addressing many other functionality areas have been defined in the > Jabber community, such protocols are not included in this memo > because they are not required by [IMP-REQS]. > > 注意：虽然基于XMPP的及时信息和在线服务符合[IMP-REQS]的要求，但它并 > 不是刻意去实现的，因为Jabber开源社区早在RFC 2779发布之前就已经促成了 > 基本的协议。同时还要指出的是，虽然Jabber社区还为协议设计了很多别的方面 > 的功能，但由于[IMP-REQS]并没有要求，因此我们这里也就不涉及了。 > >1.3. Terminology > > This memo inherits the terminology defined in [XMPP-CORE]. > > The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", > "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in BCP > 14, RFC 2119 [TERMS]. > > > > >2. Syntax of XML Stanzas > > XML Stanzas的语法 > > The basic semantics and common attributes of XML stanzas qualified by > the 'jabber:client' and 'jabber:server' namespaces are defined in > [XMPP-CORE]. However, these namespaces also define various child > elements, as well as values for the common 'type' attribute, that are > specific to instant messaging and presence applications. Thus, > before addressing particular "use cases" for such applications, we > here further describe the syntax of XML stanzas, thereby > supplementing the discussion in [XMPP-CORE]. > > XML stanzas都归在'jabber:client'和'jabber:server'名字空间之下，其基本语义 > 和常用属性由[XMPP-CORE]定义。除了常用的'type'属性的值之外，这两个名字空间 > 还定义了很多专供及时信息或在线信息服务的child elements。因此在描述此类应用 > 程序的"use case"之前，我们先探讨一下XML stanzas的语法，也借此补充一下 > [XMPP-CORE]。 > >2.1. Message Syntax > > Message stanzas qualified by the 'jabber:client' or 'jabber:server' > namespace are used to "push" information to another entity. Common > uses in instant messaging applications include single messages, > messages sent in the context of a chat conversation, messages sent in > the context of a multi-user chat room, headlines and other alerts, > and errors. > > 归在'jabber:client'或'jabber:server'名字空间之下的Message stanzas是用来 > 向另一个entity"推"信息用的。在IM应用程序里，这种stanzas常用被用于发送"单条 > 消息(single message)"，在chat环境下发送消息，在多用户的chat room的环境下 > 发送消息，以及发送headline，警告和错误消息。 > >2.1.1. Types of Message > > The 'type' attribute of a message stanza is RECOMMENDED; if included, > it specifies the conversational context of the message, thus > providing a hint regarding presentation (e.g., in a GUI). If > included, the 'type' attribute MUST have one of the following values: > > message stanza的'type'属性是RECOMMENDED的；如果有，它表示这个消息是在怎样 > 的交谈环境下发出的，因此它也暗示了该怎样显示这条消息(比方说在GUI环境下)。 > 'type'属性如果有必须(MUST)是下面值里的一个。 > > o chat -- The message is sent in the context of a one-to-one chat > conversation. A compliant client SHOULD present the message in an > interface enabling one-to-one chat between the two parties, > including an appropriate conversation history. > > chat -- 消息是在一对一的chat谈话中发出的。客户端应当(SHOULD)在一个 > 能让用户进行一对一谈话的界面里提示这条消息，包括交谈的记录。 > > o error -- An error has occurred related to a previous message sent > by the sender (for details regarding stanza error syntax, refer to > [XMPP-CORE]). A compliant client SHOULD present an appropriate > interface informing the sender of the nature of the error. > > error -- 表示先前发送的消息发生了错误(关于stanza的错误的语法， > 请参阅[XMPP-CORE])。客户端应当(SHOULD)能告诉发送发错误的性质。 > > o groupchat -- The message is sent in the context of a multi-user > chat environment (similar to that of [IRC]). A compliant client > SHOULD present the message in an interface enabling many-to-many > chat between the parties, including a roster of parties in the > chatroom and an appropriate conversation history. Full definition > of XMPP-based groupchat protocols is out of scope for this memo. > > groupchat -- 这条消息是在多用户交谈环境下发出的(类似[IRC])。客户端 > 应当(SHOULD)在能允许用户进行多对多谈话的界面里显示这条消息，这其中 > 应该包括chat room的参与者的roster(名单)，以及适当的谈话记录。基于XMPP > 的群组交谈协议超出了本文档的范围。 > > o headline -- The message is probably generated by an automated > service that delivers or broadcasts content (news, sports, market > information, RSS feeds, etc.). No reply to the message is > expected, and a compliant client SHOULD present the message in an > interface that appropriately differentiates the message from > standalone messages, chat sessions, or groupchat sessions (e.g., > by not providing the recipient with the ability to reply). > > headline -- 这条消息或许是由某个后台服务生成并发送或广播的(新闻，体育， > 市场信息，RSS服务等到)。它不需要用户的回应。客户端应当(SHOULD)在 > 一个合适的界面下提示这条消息以将其与"standalone message"，"chat session" > 和"groupchat session"相区分(比方说用户只能看不能reply)。 > > o normal -- The message is a single message that is sent outside the > context of a one-to-one conversation or groupchat, and to which it > is expected that the recipient will reply. A compliant client > SHOULD present the message in an interface enabling the recipient > to reply, but without a conversation history. > > normal -- 这是一个single message，既不是一对一的交谈，也不是群组交谈， > 而且允许接受方回应。客户端应当(SHOULD)在一个能让用户reply的界面里显示 > 这条消息，但是不要有谈话记录。 > > An IM application SHOULD support all of the foregoing message types; > if an application receives a message with no 'type' attribute or the > application does not understand the value of the 'type' attribute > provided, it MUST consider the message to be of type "normal" (i.e., > "normal" is the default). The "error" type MUST be generated only in > response to an error related to a message received from another > entity. > > IM application应当支持所有上述message type，如果它收到了一个没有'type'属性的message > 或者它看不懂这个'type'属性，那它必须(MUST)将其认做是"normal"的message(也就是说， > "normal"是默认的属性)。"error"只限于(MUST)用来回应与对方发出的message相关的错误。 > > Although the 'type' attribute is OPTIONAL, it is considered polite to > mirror the type in any replies to a message; furthermore, some > specialized applications (e.g., a multi-user chat service) MAY at > their discretion enforce the use of a particular message type (e.g., > type='groupchat'). > > 虽然'type'属性是OPTIONAL的，但是最好在回应信息里面附上相同的'type'信息；此外有些专用程序 > (比方说多用户的chat service)可以(MAY)根据他们自己的需要，强制使用特定的message type > (比方说type='groupchat')。 > >2.1.2. Child Elements > > As described under extended namespaces (Section 2.4), a message > stanza MAY contain any properly-namespaced child element. > > 正如我们将在"扩展名字空间"(Section2.4)所讲的，message stanza可以(MAY)包含任意的 > "属于适当的名字空间"的child element。 > > In accordance with the default namespace declaration, by default a > message stanza is qualified by the 'jabber:client' or 'jabber:server' > namespace, which defines certain allowable children of message > stanzas. If the message stanza is of type "error", it MUST include > anchild; for details, see [XMPP-CORE]. Otherwise, the > message stanza MAY contain any of the following child elements > without an explicit namespace declaration: > > 为了与默认的名字空间的声明相一致，默认情况下，message stanza被归到'jabber:client'或 > 'jabber:server'名字空间下。这两个名字空间定义了一些被认可的message stanza的child。 > 'error'类型的message stanza必须(MUST)包含child；具体细节请看[XMPP-CORE]。 > 除此之外，message stanza可以(MAY)不经声明就使用下列的child elements。 > > 1.> 2. > 3. > >2.1.2.1. Subject > > The element contains human-readable XML character data > that specifies the topic of the message. Theelement MUST > NOT possess any attributes, with the exception of the 'xml:lang' > attribute. Multiple instances of theelement MAY be > included for the purpose of providing alternate versions of the same > subject, but only if each instance possesses an 'xml:lang' attribute > with a distinct language value. Theelement MUST NOT > contain mixed content (as defined in Section 3.2.2 of [XML]). > >element包含human-readable的，表示message的标题的XML字符数据。 >绝对不能(MUST NOT)包含除'xml:lang'之外的任何属性。为了能提供同一个 > subject的多个版本，一个message里面可以(MAY)包含多个 element。但这仅限于 > 每个都包含'xml:lang'属性，并且其language值都不相同的情形。> 绝对不能(MUST NOT)包含mixed content(见Section 3.2.2) > > >2.1.2.2. Body > > The element contains human-readable XML character data that > specifies the textual contents of the message; this child element is > normally included but is OPTIONAL. The element MUST NOT > possess any attributes, with the exception of the 'xml:lang' > attribute. Multiple instances of the element MAY be included > but only if each instance possesses an 'xml:lang' attribute with a > distinct language value. The element MUST NOT contain mixed > content (as defined in Section 3.2.2 of [XML]). > > element包含human-readable的，用来表示消息的正文内容的XML字符数据；通常 > message都会包含这个child，但它是可选的(OPTIONAL)。 element绝对不能(MUST NOT) > 包含除'xml:lang'之外的任何属性。一个message里面可以(MAY)包含多个 element。 > 但这仅限于每个都包含'xml:lang'属性，并且其language值都不相同的情形。 > 绝对不能(MUST NOT)包含mixed content(见Section 3.2.2) > >2.1.2.3. Thread > > Theelement contains non-human-readable XML character data > specifying an identifier that is used for tracking a conversation > thread (sometimes referred to as an "instant messaging session") > between two entities. The value of theelement is > generated by the sender and SHOULD be copied back in any replies. If > used, it MUST be unique to that conversation thread within the stream > and MUST be consistent throughout that conversation (a client that > receives a message from the same full JID but with a different thread > ID MUST assume that the message in question exists outside the > context of the existing conversation thread). The use of the >element is OPTIONAL and is not used to identify individual > messages, only conversations. A message stanza MUST NOT contain more > than oneelement. The element MUST NOT possess > any attributes. The value of theelement MUST be treated > as opaque by entities; no semantic meaning may be derived from it, > and only exact comparisons may be made against it. The> element MUST NOT contain mixed content (as defined in Section 3.2.2 > of [XML]). > > element包含非human-readable的XML字符数据。它是一个用于表示两个entity > 之间的conversion thread的(有时也被称作"instance messaging session")标识符。 >element的值由sender生成，而且每次回复的时候必须(SHOULD)包含在内。如果 > 用到了它，那么它必须(MUST)与stream里的conversation thread一一对应，而且整个谈话期间 > 必须保持一致(如果client端收到了同一个JID发出的，但是thread ID不同的message，必须(MUST) > 认定这个消息与当前的conversation thread无关。)element是OPTIONAL的， > 且不用于标识单个message，它是用来标识conversation的。一个message stanza MUST NOT > 包含二个或二个以上的element。 element MUST NOT包含任何属性。 > 对entities来说的值必须(MUST)是不透明的；不能用它来获取任何语义信息，而且只能 > 对它进行精确地比较。MUST NOT包含mixed content(Section 3.2.2) > >2.2. Presence Syntax > > Presence stanzas are used qualified by the 'jabber:client' or > 'jabber:server' namespace to express an entity's current network > availability (offline or online, along with various sub-states of the > latter and optional user-defined descriptive text), and to notify > other entities of that availability. Presence stanzas are also used > to negotiate and manage subscriptions to the presence of other > entities. > > Presence stanza属于'jabber:client'或'jabber:server'名字空间，它们是用来表示 > entity的当前网络可得性(offline还是online，此外后者还有很多sub-state和可选的用户 > 自定义的叙述性文字)，并且将其通知给其它entities的。Persence stanzas也被用于协商 > 和管理订阅其它entities的presence信息。 > >2.2.1. Types of Presence > > The 'type' attribute of a presence stanza is OPTIONAL. A presence > stanza that does not possess a 'type' attribute is used to signal to > the server that the sender is online and available for communication. > If included, the 'type' attribute specifies a lack of availability, a > request to manage a subscription to another entity's presence, a > request for another entity's current presence, or an error related to > a previously-sent presence stanza. If included, the 'type' attribute > MUST have one of the following values: > > presence stanza的'type'属性是OPTIONAL的。不带'type'属性的presence stanza > 是用来通知服务器sender已经上线，并且available for communication。如果有，那么这个 > 'type'或者用来表示可得性方面的限制，或者用来管理订阅其它用户的presence信息，或者用于 > 查询其它用户的当前可得性，或者是先前发送的presence stanza出了错。如果有，'type'属性 > MUST是下列值中的一个: > > o unavailable -- Signals that the entity is no longer available for > communication. > > unavailable -- 表示entity不再available for communication了 > > o subscribe -- The sender wishes to subscribe to the recipient's > presence. > > subscribe -- sender希望能订阅recipent的presence信息 > > o subscribed -- The sender has allowed the recipient to receive > their presence. > > subscribed -- 发送方同意让接受方订阅自己的在线信息 > > o unsubscribe -- The sender is unsubscribing from another entity's > presence. > > unsubscribe -- 发送方取消订阅另一方的在线信息 > > o unsubscribed -- The subscription request has been denied or a > previously-granted subscription has been cancelled. > > unsubscribed -- 订阅请求被拒绝或者先前授予的订阅权限被撤销了 > > o probe -- A request for an entity's current presence; SHOULD be > generated only by a server on behalf of a user. > > probe -- 请求entity的当前在线信息；只有(SHOULD)server才能代表用户去生成此类信息。 > > o error -- An error has occurred regarding processing or delivery of > a previously-sent presence stanza. > > error -- 先前发送的presence stanza在处理或投送过程中出现了错误。 > > For detailed information regarding presence semantics and the > subscription model used in the context of XMPP-based instant > messaging and presence applications, refer to Exchanging Presence > Information (Section 5) and Managing Subscriptions (Section 6). > > 要想详细了解相关信息，请参阅Section 5 Exchanging Presence Information > 和Section 6 Managing Subscriptions。 > >2.2.2. Child Elements > > As described under extended namespaces (Section 2.4), a presence > stanza MAY contain any properly-namespaced child element. > > 就像Section 2.4的扩展名字空间所说的，presence stanza 可以包含任何 > properly-namespaced的child element。 > > In accordance with the default namespace declaration, by default a > presence stanza is qualified by the 'jabber:client' or > 'jabber:server' namespace, which defines certain allowable children > of presence stanzas. If the presence stanza is of type "error", it > MUST include anchild; for details, see [XMPP-CORE]. If the > presence stanza possesses no 'type' attribute, it MAY contain any of > the following child elements (note that thechild MAY be > sent in a presence stanza of type "unavailable" or, for historical > reasons, "subscribe"): > > 为了与默认的名字空间的声明保持一致，默认的presence stanza被归在'jabber:client' > 或'jabber:server'名字空间之下，这两个名字空间还定义了一些被认可的presence stanza > 的children。如果presence stanza是'error'类型的，那么它MUST包含；细节请看 > [XMPP-CORE]。如果presence stanza没有'type'属性，那么它MAY包含下列child element > (注意，child可以随'unavailable' type的presence stanza或，出于历史原因， > 'subscribe' type的presence stanza发出。) > > 1.> 2. > 3. >------------------------------------------------------------------------------------------------------ > >On 7/4/05, run_mei <run_mei at 163.com> wrote: > > >> 大家好，我觉得即时通时技术是一个有趣的技术，而xmpp ( jabber )技术是唯一 >>的开源的协议，它有很多激动人心的特征，我对它有兴趣，但好象没有中文资料， >>我想翻译它的英文文档，可是我的英文水平不高，所以我想找人帮我一起来翻译 >>它，我已经翻译了一点。我想找个地方把它共亨出来，同时请大家帮我将翻译错误 >>的地方纠正过来。 >>请问可不可在在www.woodpecker.org上建一个目录存放它。 >> >>_______________________________________________ >>python-chinese list >>python-chinese at lists.python.cn >>http://python.cn/mailman/listinfo/python-chinese >> >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>python-chinese list >>python-chinese at lists.python.cn >>http://python.cn/mailman/listinfo/python-chinese >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.exoweb.net/pipermail/python-chinese/attachments/20050706/7e7e2df2/attachment-0001.htm
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Zeuux © 2025
京ICP备05028076号