Internet Engineering Task Force (IETF) J. Rosenberg
Request for Comments: 5874 jdrosen.net
Category: Standards Track J. Urpalainen
ISSN: 2070-1721 Nokia
May 2010
Internet Engineering Task Force (IETF) J. Rosenberg
Request for Comments: 5874 jdrosen.net
Category: Standards Track J. Urpalainen
ISSN: 2070-1721 Nokia
May 2010
An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources
一种可扩展标记语言（XML）文档格式，用于指示XML配置访问协议（XCAP）资源的更改
Abstract
摘要
This specification defines a document format that can be used to indicate that a change has occurred in a document managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). This format reports which document has changed and its former and new entity tags. It can report the differences between versions of the document, using an XML patch format. It can report existing element and attribute content when versions of an XCAP server document change. XCAP diff documents can be delivered to diff clients using a number of means, including a Session Initiation Protocol (SIP) event package.
本规范定义了一种文档格式，可用于指示由可扩展标记语言（XML）配置访问协议（XCAP）管理的文档中发生了更改。此格式报告已更改的文档及其以前和新的实体标记。它可以使用XML补丁格式报告文档版本之间的差异。当XCAP服务器文档的版本更改时，它可以报告现有的元素和属性内容。XCAP diff文档可以通过多种方式传递给diff客户端，包括会话启动协议（SIP）事件包。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5874.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5874.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您在以下方面的权利和限制：
to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
请参阅本文件。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Structure of an XCAP Diff Document . . . . . . . . . . . . . . 5
4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Example Document . . . . . . . . . . . . . . . . . . . . . . . 11
6. Basic Requirements for a System Exchanging XCAP Diff
Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1. application/xcap-diff+xml MIME Type . . . . . . . . . . . 14
8.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:xcap-diff . . . . . . . . . . . . . 15
8.3. Schema Registration . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Informative Examples . . . . . . . . . . . . . . . . 18
A.1. Indicating Existing, Changed, or Removed Documents . . . . 18
A.2. Indicating Actual Changes of Documents . . . . . . . . . . 21
A.3. Indicating XCAP Component Contents . . . . . . . . . . . . 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Structure of an XCAP Diff Document . . . . . . . . . . . . . . 5
4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Example Document . . . . . . . . . . . . . . . . . . . . . . . 11
6. Basic Requirements for a System Exchanging XCAP Diff
Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1. application/xcap-diff+xml MIME Type . . . . . . . . . . . 14
8.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:xcap-diff . . . . . . . . . . . . . 15
8.3. Schema Registration . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Informative Examples . . . . . . . . . . . . . . . . 18
A.1. Indicating Existing, Changed, or Removed Documents . . . . 18
A.2. Indicating Actual Changes of Documents . . . . . . . . . . 21
A.3. Indicating XCAP Component Contents . . . . . . . . . . . . 23
The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825] is a protocol that allows XCAP clients to manipulate XML documents stored on a server. These XML documents serve as configuration information for application protocols. As an example, resource list [RFC4662] subscriptions (also known as presence lists) allow a SIP client to have a single SIP subscription to a list of users, where the list is maintained on a server. The server will obtain presence for those users and report it back to the SIP client. This application requires the server, called a Resource List Server (RLS), to have access to the list of presentities [RFC2778]. This list needs to be manipulated by XCAP clients so they can add and remove their friends as they desire.
可扩展标记语言（XML）配置访问协议（XCAP）[RFC4825]是一种允许XCAP客户端操作存储在服务器上的XML文档的协议。这些XML文档用作应用程序协议的配置信息。例如，资源列表[RFC4662]订阅（也称为状态列表）允许SIP客户端对用户列表进行单个SIP订阅，其中该列表维护在服务器上。服务器将获取这些用户的状态，并将其报告回SIP客户端。此应用程序要求名为资源列表服务器（RLS）的服务器能够访问现有实体列表[RFC2778]。此列表需要由XCAP客户端进行操作，以便他们可以根据需要添加和删除朋友。
Complexities arise when multiple XCAP clients attempt to simultaneously manipulate a document, such as a presence list. Frequently, an XCAP client will keep a copy of the current list in memory, so it can render it to users. However, if another XCAP client modifies the document, the cached version becomes stale. This modification event must be made known to all clients that have cached copies of the document, so that they can fetch the most recent one.
当多个XCAP客户端试图同时操作文档（如状态列表）时，会出现复杂性。通常，XCAP客户端会在内存中保留当前列表的副本，以便向用户呈现。但是，如果另一个XCAP客户端修改文档，则缓存的版本将过时。必须让所有缓存了文档副本的客户端都知道此修改事件，以便它们能够获取最新的副本。
To deal with this problem, clients can use a Session Initiation Protocol (SIP) [RFC3261] event package [RFC3265] to subscribe to change events [RFC5875] in XCAP documents. This notification needs to indicate the specific resource that changed and how it changed. One solution for the format of such a change notification would be a content indirection object [RFC4483]. Though content indirection can tell a client that a document has changed, it provides it with a MIME Content-ID indicating the new version of the document. The MIME Content-ID is not the same as the entity tag, which is used by XCAP for document versioning. As such, a client cannot easily ascertain whether an indication of a change in a document is due to a change it just made or due to a change another XCAP client made at around the same time. Furthermore, content indirections don't indicate how a document changed; they are only able to indicate that it did change.
为了解决这个问题，客户端可以使用会话启动协议（SIP）[RFC3261]事件包[RFC3265]订阅XCAP文档中的更改事件[RFC5875]。此通知需要指明已更改的特定资源及其更改方式。这种更改通知格式的一种解决方案是内容间接寻址对象[RFC4483]。虽然内容间接寻址可以告诉客户端文档已更改，但它为客户端提供了一个MIME内容ID，指示文档的新版本。MIME内容ID与实体标记不同，后者由XCAP用于文档版本控制。因此，客户机无法轻松确定文档中的更改指示是由于其刚刚进行的更改，还是由于另一个XCAP客户机几乎同时进行的更改。此外，内容间接指示并不表示文档是如何更改的；他们只能表明它确实发生了变化。
To resolve these problems, this document defines a data format that can convey the fact that an XML document managed by XCAP has changed. This data format is an XML document format, called an XCAP diff document. This format reports which document has changed and its former and new entity tags. It can report the differences between versions of the document, using an XML patch format [RFC5261], which indicate how to transform the locally cached XCAP document from the version prior to the change to the version after it. Its intent is to reduce the required overall bandwidth and the number of separate
为了解决这些问题，本文定义了一种数据格式，该格式可以传递由XCAP管理的XML文档已更改的事实。此数据格式是一种XML文档格式，称为XCAP diff文档。此格式报告已更改的文档及其以前和新的实体标记。它可以使用XML修补程序格式[RFC5261]报告文档版本之间的差异，该格式指示如何将本地缓存的XCAP文档从更改前的版本转换为更改后的版本。它的目的是减少所需的总带宽和独立网络的数量
transmissions. It can also report existing element and attribute content when versions of an XML document change at an XCAP server.
传输。当XCAP服务器上的XML文档版本发生更改时，它还可以报告现有的元素和属性内容。
XML documents that are equivalent for the purposes of many applications may differ in their physical representation. Similar to XCAP, the canonical form with comments [W3C.REC-xml-c14n-20010315] of an XML document determines the logical equivalence when this format is used to patch locally cached XCAP documents.
对于许多应用程序来说是等效的XML文档，其物理表示形式可能有所不同。与XCAP类似，xml文档的带有注释[W3C.REC-xml-c14n-20010315]的规范格式决定了使用此格式修补本地缓存的XCAP文档时的逻辑等价性。
The 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 RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的描述进行解释，并指出符合性实施的要求级别。
This specification also defines the following additional terms:
本规范还定义了以下附加术语：
Document: When the term document is used without the "(XCAP) diff" in front of it, it refers to the XCAP document resource about which the XCAP diff document is reporting a change.
文档：当使用术语文档时，前面没有“（XCAP）diff”，它指的是XCAP diff文档报告更改的XCAP文档资源。
Diff document: The XML document defined by this specification that reports on a set of changes in an XCAP document resource. It is delivered from a server to a diff client by a transport that is not defined by this specification.
Diff document：本规范定义的XML文档，用于报告XCAP文档资源中的一组更改。它通过本规范未定义的传输从服务器传送到差异客户端。
XCAP server: A protocol entity that manages XCAP documents and their entity tags. It usually contains an integrated diff notifier.
XCAP服务器：管理XCAP文档及其实体标记的协议实体。它通常包含一个集成的差异通知程序。
Diff notifier: This is the entity of a server that generates XCAP diff documents based on its knowledge of a set of XCAP documents and their changes, and it transmits the generated diff documents to a diff client within a session.
Diff notifier：这是服务器的实体，它根据对一组XCAP文档及其更改的了解生成XCAP Diff文档，并在会话中将生成的Diff文档传输到Diff客户端。
Diff client: A client that consumes XCAP diff documents in order to construct a locally cached document that is equivalent to a specific version of a document resource stored at an XCAP server. It is typically a SIP User Agent (UA) and an XCAP client.
Diff客户端：使用XCAP Diff文档来构造本地缓存文档的客户端，该文档相当于存储在XCAP服务器上的文档资源的特定版本。它通常是SIP用户代理（UA）和XCAP客户端。
XCAP Client: A client that updates and retrieves documents stored at an XCAP server. It can also patch element and attribute content of XCAP documents located at an XCAP server.
XCAP客户端：更新和检索存储在XCAP服务器上的文档的客户端。它还可以修补位于XCAP服务器上的XCAP文档的元素和属性内容。
Locally cached resource: A resource that has typically been downloaded by HTTP from an XCAP server to a diff client. It may have been patched locally by a diff client based on the XCAP diff document information. It is equivalent to a single version in its
本地缓存资源：通常通过HTTP从XCAP服务器下载到diff客户端的资源。它可能已经由diff客户端根据XCAP diff文档信息在本地进行了修补。它相当于一个单独的版本
change history at an XCAP server. Version history of XCAP documents is indicated by HTTP entity tags (ETags).
更改XCAP服务器上的历史记录。XCAP文档的版本历史由HTTP实体标记（ETAG）表示。
ETag: A strong HTTP entity tag whose value is set by an XCAP server. Documents at an XCAP server are updated by XCAP clients. The XCAP server assigns a new ETag value to each document version according to the HTTP specification.
ETag：一个强HTTP实体标记，其值由XCAP服务器设置。XCAP服务器上的文档由XCAP客户端更新。XCAP服务器根据HTTP规范为每个文档版本分配一个新的ETag值。
An XCAP diff document is an XML [W3C.REC-xml-20060816] document that MUST be well-formed and SHOULD be valid. XCAP diff documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying XCAP diff documents and document fragments. The namespace URI for elements defined by this specification is a URN [RFC2141], using the namespace identifier 'ietf' defined by [RFC2648] and extended by [RFC3688]. This URN is:
XCAP diff文档是一个XML[W3C.REC-XML-20060816]文档，它必须格式正确并且应该有效。XCAP diff文档必须基于XML 1.0，并且必须使用UTF-8进行编码。本规范使用XML名称空间来标识XCAP diff文档和文档片段。本规范定义的元素的名称空间URI是URN[RFC2141]，使用[RFC2648]定义的名称空间标识符“ietf”，并由[RFC3688]扩展。这个骨灰盒是：
urn:ietf:params:xml:ns:xcap-diff
urn:ietf:params:xml:ns:xcap-diff
An XCAP diff document begins with the root element tag <xcap-diff>. This element has a single mandatory attribute, "xcap-root". The value of this attribute is the XCAP root URI for the documents in which the changes have taken place. A single XCAP diff document can only represent changes in documents within the same XCAP root. The content of the <xcap-diff> element is a sequence of <document>, <element>, and <attribute> elements followed by any number of elements from other namespaces for the purposes of extensibility. Wherever the XML schema (see Section 4) allows extension elements or attributes, any such unknown content MUST be ignored by the diff client.
XCAP diff文档以根元素标记<XCAP diff>开始。此元素有一个强制属性“xcap root”。此属性的值是发生更改的文档的XCAP根URI。单个XCAP diff文档只能表示同一XCAP根目录中文档的更改。<xcap diff>元素的内容是一系列的<document>、<element>和<attribute>元素，后面是其他名称空间中任意数量的元素，以实现可扩展性。只要XML模式（参见第4节）允许扩展元素或属性，diff客户端就必须忽略任何此类未知内容。
Each <document> element specifies changes in a specific document within the XCAP root. If several <document> elements pinpoint the same specific document, i.e., for example, the full entity tag (ETag) change history is indicated, the corresponding patches MUST be able to be applied in the given XCAP diff document order.
每个<document>元素指定XCAP根目录中特定文档的更改。如果多个<document>元素指向同一特定文档，例如，指示完整实体标记（ETag）更改历史，则必须能够以给定的XCAP diff文档顺序应用相应的修补程序。
Note: This requirement simplifies applications that process XCAP diff documents since there's no need to sort patch instructions when applying them.
注意：这一要求简化了处理XCAP diff文档的应用程序，因为应用它们时不需要对补丁指令进行排序。
The <document> element has one mandatory attribute, "sel", and two optional attributes, "new-etag" and "previous-etag". The "sel" attribute of the <document> element identifies the specific document within the XCAP root for which changes are indicated. Its content MUST be a relative path reference, with the base URI being equal to the XCAP root URI. The "new-etag" attribute provides the entity tag
<document>元素有一个强制属性“sel”，还有两个可选属性“newetag”和“previousetag”。<document>元素的“sel”属性标识XCAP根目录中指示更改的特定文档。其内容必须是相对路径引用，基本URI等于XCAP根URI。“new etag”属性提供实体标记
(ETag) for the document after the application of the changes, assuming the document exists after those changes. The "previous-etag" attribute provides an identifier for the document instance prior to the change. If the change being reported is the removal of a document, only the "previous-etag" MUST be included and the "new-etag" attribute MUST NOT be present. The "new-etag" attribute MUST only exist alone when the document either exists or it was just created (no patch included). Both attributes are present when a patch (or series of XCAP operations) has been applied to the resource. Also, both attributes MAY be used to indicate an ETag change without any document modifications (patches).
（ETag）对于应用变更后的文件，假设这些变更后存在该文件。“previous etag”属性为更改之前的文档实例提供标识符。如果报告的更改是删除文档，则仅必须包含“以前的etag”，并且“新etag”属性不得存在。“new etag”属性只能在文档存在或刚创建时单独存在（不包括修补程序）。当修补程序（或一系列XCAP操作）应用于资源时，这两个属性都存在。此外，这两个属性都可用于指示ETag更改，而无需任何文档修改（补丁）。
The "previous-etag" and "new-etag" need not have been sequentially assigned ETags at the server. An XCAP diff document can indicate changes that have occurred over a series of XCAP operations. The only requirement then is that the sequence of events, when executed serially, will result in the transformation of the document with the ETag "previous-etag" to the one whose ETag is "new-etag". Also, the series of operations do not have to be the same exact series of operations that occurred at the server.
“先前etag”和“新etag”不需要在服务器上按顺序分配etag。XCAP diff文档可以指示在一系列XCAP操作中发生的更改。唯一的要求是，当连续执行事件序列时，将导致将带有ETag“previous ETag”的文档转换为ETag为“new ETag”的文档。此外，操作系列不必与服务器上发生的操作系列完全相同。
Each <document> element contains either a sequence of patching instructions or an indication that the body hasn't semantically changed. The latter means that the document has been assigned a new ETag but its content is unchanged and it is indicated by the <body-not-changed> element. Patching instructions are described by the <add>, <replace>, and <remove> elements. These elements use the corresponding add, replace, and remove types defined in [RFC5261], and define a set of patch operations that can be applied to transform the locally cached document. See [RFC5261] for instructions on how this transformation is effected. The <document> element can also contain elements from other namespaces for the purposes of extensibility. The <add>, <replace>, and <remove> elements allow extension attributes from any namespace.
每个<document>元素要么包含一系列补丁指令，要么表示主体在语义上没有改变。后者意味着文档已被分配了一个新的ETag，但其内容不变，并由<body not changed>元素指示。配线说明由<add>、<replace>和<remove>元素描述。这些元素使用[RFC5261]中定义的相应添加、替换和删除类型，并定义一组可应用于转换本地缓存文档的修补程序操作。有关如何实现此转换的说明，请参见[RFC5261]。出于可扩展性的目的，<document>元素还可以包含来自其他名称空间的元素。<add>、<replace>和<remove>元素允许任何名称空间的扩展属性。
Figure 1 shows <document> element content and how the corresponding resource or metadata changes. In practice, an external document retrieval means HTTP GET requests for target resources. The asterisk character '*' means that a <document> element has child element(s): <add>, <replace>, or <remove>, or alternatively only a <body-not-changed> element. The hyphen character '-' means that the corresponding content (attribute or element) doesn't exist in a <document> element. The 'xxx' and 'yyy' are values of entity tags (ETag) of an XCAP document.
图1显示了<document>元素内容以及相应的资源或元数据是如何变化的。实际上，外部文档检索意味着HTTP GET对目标资源的请求。星号字符“*”表示<document>元素有子元素：<add>、<replace>或<remove>，或者只有<body not changed>元素。连字符“-”表示<document>元素中不存在相应的内容（属性或元素）。“xxx”和“yyy”是XCAP文档的实体标记（ETag）的值。
+-----------+----------+-----------+----------+-------------------+
| previous- | new- | <add> | <body- | locally cached |
| etag | etag | <replace> | not- | XCAP resource/ |
| | | <remove> | changed> | metadata change |
+-----------+----------+-----------+----------+-------------------+
| xxx | yyy | * | - | resource patched, |
| | | | | patch included |
+-----------+----------+-----------+----------+-------------------+
| xxx | yyy | - | - | resource patched, |
| | | | | external document |
| | | | | retrieval |
+-----------+----------+-----------+----------+-------------------+
| xxx | yyy | - | * | only ETag changed |
+-----------+----------+-----------+----------+-------------------+
| - | yyy | - | - | resource created |
| | | | | or exists, |
| | | | | external document |
| | | | | retrieval |
+-----------+----------+-----------+----------+-------------------+
| xxx | - | - | - | resource removed |
+-----------+----------+-----------+----------+-------------------+
+-----------+----------+-----------+----------+-------------------+
| previous- | new- | <add> | <body- | locally cached |
| etag | etag | <replace> | not- | XCAP resource/ |
| | | <remove> | changed> | metadata change |
+-----------+----------+-----------+----------+-------------------+
| xxx | yyy | * | - | resource patched, |
| | | | | patch included |
+-----------+----------+-----------+----------+-------------------+
| xxx | yyy | - | - | resource patched, |
| | | | | external document |
| | | | | retrieval |
+-----------+----------+-----------+----------+-------------------+
| xxx | yyy | - | * | only ETag changed |
+-----------+----------+-----------+----------+-------------------+
| - | yyy | - | - | resource created |
| | | | | or exists, |
| | | | | external document |
| | | | | retrieval |
+-----------+----------+-----------+----------+-------------------+
| xxx | - | - | - | resource removed |
+-----------+----------+-----------+----------+-------------------+
Figure 1: <document> element content / corresponding resource changes
Figure 1: <document> element content / corresponding resource changes
Each <element> element indicates the existing element content of an XCAP document. It has one mandatory attribute, "sel", and optionally, an "exists" attribute and extension attributes from any namespace. The "sel" attribute of the <element> element identifies an XML element of an XCAP document. It is a percent-encoded relative URI following XCAP conventions when selecting elements. The XCAP Node Selector MUST always locate a unique node, the "exists" attribute thus shows whether an element exists or not in the XCAP document. When the "exists" attribute is absent from the <element> element, the indicated element still exists in the XCAP document. The located element exists as a child element of the <element> element. In a corner case where the content of this element cannot be presented for some reason (e.g., the payload is too large) although it exists in the XCAP document, the <element> element MUST NOT have any child nodes.
每个<element>元素表示XCAP文档的现有元素内容。它有一个强制属性“sel”，还可以选择一个“exists”属性和来自任何名称空间的扩展属性。元素的“sel”属性标识XCAP文档的XML元素。它是在选择元素时遵循XCAP约定的百分比编码相对URI。XCAP节点选择器必须始终定位唯一的节点，“exists”属性因此显示XCAP文档中是否存在元素。当<element>元素中没有“exists”属性时，所指示的元素仍然存在于XCAP文档中。定位的元素作为<element>元素的子元素存在。如果由于某种原因（例如，负载太大）无法显示此元素的内容，尽管它存在于XCAP文档中，则<element>元素不得有任何子节点。
As the located XML element is typically namespace qualified, all needed namespace declarations MUST exist within the <xml-diff> document. The possible local namespace declarations within the located element exist unmodified as in the source document, similar to XCAP conventions. Other namespace references MUST be resolved from the context of the <element> or its parent elements. The
由于定位的XML元素通常是命名空间限定的，因此所有需要的命名空间声明都必须存在于<XML diff>文档中。与XCAP约定类似，定位元素中可能的本地名称空间声明未经修改就存在于源文档中。其他命名空间引用必须从<element>或其父元素的上下文中解析。这个
prefixes of qualified names (QNames) [W3C.REC-xml-names-20060816] of XML nodes also remain as they originally exist in the source XCAP document.
xml节点的限定名（QNames）[W3C.REC-xml-names-20060816]的前缀也保持原来在源XCAP文档中的状态。
Each <attribute> element indicates the existing attribute content of an XCAP document. It has one mandatory attribute, "sel", and optionally, an "exists" attribute and extension attributes from any namespace. The "sel" attribute of the <attribute> element identifies an XML attribute of an XCAP document. It is a percent-encoded relative URI following XCAP conventions when selecting attributes. The "exists" attribute indicates whether or not an attribute exists in the XCAP document. When the "exists" attribute is absent from the <attribute> element, the indicated attribute still exists in the XCAP document. The child text node of the <attribute> element indicates the value of the located attribute. Note that if the attribute is namespace qualified, the query parameter of the XCAP URI indicates the attached namespace URI and the prefix in the XCAP source document.
每个<attribute>元素表示XCAP文档的现有属性内容。它有一个强制属性“sel”，还可以选择一个“exists”属性和来自任何名称空间的扩展属性。<attribute>元素的“sel”属性标识XCAP文档的XML属性。它是在选择属性时遵循XCAP约定的百分比编码相对URI。“exists”属性表示XCAP文档中是否存在属性。当<attribute>元素中没有“exists”属性时，指示的属性仍然存在于XCAP文档中。<attribute>元素的子文本节点指示所定位属性的值。请注意，如果该属性是命名空间限定的，则XCAP URI的查询参数将指示附加的命名空间URI和XCAP源文档中的前缀。
Namespaces of the "sel" attribute of the <attribute> and <element> elements MUST also be resolved properly. Section 6.4. of [RFC4825] describes the rules when using namespace prefixes in XCAP Node Selectors. Without a namespace prefix in an element selector, an XCAP Default Document Namespace MUST be applied. The namespace resolving rules of Patch operation elements: <add>, <replace>, and <remove> are described in Section 4.2.1 of [RFC5261].
<attribute>和<element>元素的“sel”属性的名称空间也必须正确解析。第6.4节。[RFC4825]的说明了在XCAP节点选择器中使用名称空间前缀时的规则。如果元素选择器中没有名称空间前缀，则必须应用XCAP默认文档名称空间。[RFC5261]的第4.2.1节描述了修补程序操作元素的命名空间解析规则：<add>、<replace>和<remove>。
The XML Schema for the XCAP diff format.
XCAP diff格式的XML架构。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:xcap-diff"
targetNamespace="urn:ietf:params:xml:ns:xcap-diff"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:xcap-diff"
targetNamespace="urn:ietf:params:xml:ns:xcap-diff"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- include patch-ops -->
<xs:include
schemaLocation="urn:ietf:params:xml:schema:patch-ops"/>
<!-- include patch-ops -->
<xs:include
schemaLocation="urn:ietf:params:xml:schema:patch-ops"/>
<!-- document root -->
<xs:element name="xcap-diff">
<xs:complexType>
<xs:sequence minOccurs="0">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:choice>
<!-- document root -->
<xs:element name="xcap-diff">
<xs:complexType>
<xs:sequence minOccurs="0">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:choice>
<xs:element name="document" type="documentType"/>
<xs:element name="element" type="elementType"/>
<xs:element name="attribute" type="attributeType"/>
</xs:choice>
</xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="xcap-root" type="xs:anyURI" use="required"/>
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
</xs:element>
<xs:element name="document" type="documentType"/>
<xs:element name="element" type="elementType"/>
<xs:element name="attribute" type="attributeType"/>
</xs:choice>
</xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="xcap-root" type="xs:anyURI" use="required"/>
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
</xs:element>
<!-- xcap document type -->
<xs:complexType name="documentType">
<xs:choice minOccurs="0">
<xs:element name="body-not-changed" type="emptyType"/>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:choice>
<xs:element name="add">
<xs:complexType mixed="true">
<xs:complexContent>
<xs:extension base="add">
<xs:anyAttribute processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="remove">
<xs:complexType>
<xs:complexContent>
<xs:extension base="remove">
<xs:anyAttribute processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="replace">
<xs:complexType mixed="true">
<xs:complexContent>
<xs:extension base="replace">
<xs:anyAttribute processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="lax"/>
</xs:choice>
<!-- xcap document type -->
<xs:complexType name="documentType">
<xs:choice minOccurs="0">
<xs:element name="body-not-changed" type="emptyType"/>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:choice>
<xs:element name="add">
<xs:complexType mixed="true">
<xs:complexContent>
<xs:extension base="add">
<xs:anyAttribute processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="remove">
<xs:complexType>
<xs:complexContent>
<xs:extension base="remove">
<xs:anyAttribute processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="replace">
<xs:complexType mixed="true">
<xs:complexContent>
<xs:extension base="replace">
<xs:anyAttribute processContents="lax"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="lax"/>
</xs:choice>
</xs:sequence>
</xs:choice>
<xs:attribute name="sel" type="xs:anyURI" use="required"/>
<xs:attribute name="new-etag" type="xs:string"/>
<xs:attribute name="previous-etag" type="xs:string"/>
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
</xs:sequence>
</xs:choice>
<xs:attribute name="sel" type="xs:anyURI" use="required"/>
<xs:attribute name="new-etag" type="xs:string"/>
<xs:attribute name="previous-etag" type="xs:string"/>
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
<!-- xcap element type -->
<xs:complexType name="elementType">
<xs:complexContent mixed="true">
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any processContents="lax" namespace="##any"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
<xs:attribute name="sel" type="xs:string"
use="required"/>
<xs:attribute name="exists" type="xs:boolean"/>
<xs:anyAttribute processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- xcap element type -->
<xs:complexType name="elementType">
<xs:complexContent mixed="true">
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any processContents="lax" namespace="##any"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
<xs:attribute name="sel" type="xs:string"
use="required"/>
<xs:attribute name="exists" type="xs:boolean"/>
<xs:anyAttribute processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- xcap attribute type -->
<xs:complexType name="attributeType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="sel" type="xs:string"
use="required"/>
<xs:attribute name="exists" type="xs:boolean"/>
<xs:anyAttribute processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!-- xcap attribute type -->
<xs:complexType name="attributeType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="sel" type="xs:string"
use="required"/>
<xs:attribute name="exists" type="xs:boolean"/>
<xs:anyAttribute processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!-- empty type -->
<xs:complexType name="emptyType"/>
</xs:schema>
<!-- empty type -->
<xs:complexType name="emptyType"/>
</xs:schema>
The following is an example of a document compliant to the schema.
下面是一个符合模式的文档示例。
<?xml version="1.0" encoding="UTF-8"?>
<d:xcap-diff xmlns:d="urn:ietf:params:xml:ns:xcap-diff"
xmlns="urn:ietf:params:xml:ns:rls-services"
xcap-root="http://xcap.example.com/root/">
<?xml version="1.0" encoding="UTF-8"?>
<d:xcap-diff xmlns:d="urn:ietf:params:xml:ns:xcap-diff"
xmlns="urn:ietf:params:xml:ns:rls-services"
xcap-root="http://xcap.example.com/root/">
<d:document new-etag="7ahggs"
sel="resource-lists/users/sip:joe@example.com/coworkers"
previous-etag="8a77f8d"/>
<d:document new-etag="7ahggs"
sel="resource-lists/users/sip:joe@example.com/coworkers"
previous-etag="8a77f8d"/>
<d:element sel="rls-services/users/sip:joe@example.com/index/~~
/*/service%5b@uri='sip:marketing@example.com'%5d"
xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
><service uri="sip:marketing@example.com">
<list name="marketing">
<rl:entry uri="sip:joe@example.com"/>
<rl:entry uri="sip:sudhir@example.com"/>
</list>
<packages>
<package>presence</package>
</packages>
</service></d:element>
<d:element sel="rls-services/users/sip:joe@example.com/index/~~
/*/service%5b@uri='sip:marketing@example.com'%5d"
xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
><service uri="sip:marketing@example.com">
<list name="marketing">
<rl:entry uri="sip:joe@example.com"/>
<rl:entry uri="sip:sudhir@example.com"/>
</list>
<packages>
<package>presence</package>
</packages>
</service></d:element>
<d:attribute
sel="rls-services/users/sip:joe@example.com/index/~~/*/service/@uri"
>sip:marketing@example.com</d:attribute>
<d:attribute
sel="rls-services/users/sip:joe@example.com/index/~~/*/service/@uri"
>sip:marketing@example.com</d:attribute>
</d:xcap-diff>
</d:xcap-diff>
This indicates that the document with the URI "http:// xcap.example.com/root/resource-lists/users/sip:joe@example.com/ coworkers" has changed. Its previous entity tag is "8a77f8d" and its new one is "7ahggs", but actual changes are not shown. The <service> element exists in the rls-services "index" document and its full content is shown. Note that the <service> element is attached with a default namespace declaration within the original document. Similarly, "uri" attribute content is shown from the same "index" document as an illustrative example.
这表示URI为“http://xcap.example.com/root/resource-lists/users/sip:joe@example.com/“同事”已经变了。它以前的实体标记是“8a77f8d”，新的实体标记是“7ahggs”，但没有显示实际的更改。<service>元素存在于rls服务“索引”文档中，并显示其全部内容。注意，<service>元素在原始文档中附加了一个默认名称空间声明。类似地，“uri”属性内容显示在同一个“索引”文档中，作为示例。
Documents at an XCAP server are identified by URIs, and updated by XCAP clients with HTTP (PUT and DELETE) methods. The XCAP server assigns a new entity tag value for each document version. An entity tag value is defined by Section 3.11 of RFC 2616 [RFC2616]: "An
XCAP服务器上的文档由URI标识，并由XCAP客户端使用HTTP（PUT和DELETE）方法进行更新。XCAP服务器为每个文档版本分配一个新的实体标记值。实体标记值由RFC 2616[RFC2616]第3.11节定义：“一个
entity tag MUST be unique across all versions of all entities associated with a particular resource". These entity tags are used to protect requests from making overriding changes when multiple XCAP clients update the same XCAP document. An entity tag value can be interpreted as a unique identifier to a specific version of an XCAP document in its change history.
实体标记在与特定资源关联的所有实体的所有版本中必须是唯一的“。当多个XCAP客户端更新同一个XCAP文档时，这些实体标记用于防止请求进行覆盖更改。实体标记值可以解释为更改历史记录中XCAP文档特定版本的唯一标识符。
The entity tag values of XCAP resources also enable a reliable way to update the locally cached XCAP resource copies in an XCAP diff implementation. When a diff client applies XCAP diff document changes, it MUST apply a resource state change only if entity tag values match with octet-by-octet equivalence according to the table defined in Figure 1. If a diff client notices inconsistencies and/or errors when it applies reported resource changes, it SHOULD tear down the session.
XCAP资源的实体标记值还支持在XCAP diff实现中更新本地缓存的XCAP资源副本的可靠方法。当diff客户机应用XCAP diff document changes时，根据图1中定义的表，仅当实体标记值与八位字节等价性匹配时，它才必须应用资源状态更改。如果差异客户端在应用报告的资源更改时注意到不一致和/或错误，它应该中断会话。
State changes of an XCAP document MUST be delivered reliably from a diff notifier to a diff client, and a diff client MUST be able to apply all changes of an XCAP document in the same chronological order that occurred at an XCAP server. When using an unreliable transport with retransmissions, the application protocol used with the XCAP diff MUST ensure that duplicates are dropped. If an XCAP diff delivery is lost, the diff session MUST be torn down. Note that a diff notifier can easily notice a lost notification when a diff client must respond to each XCAP diff delivery.
XCAP文档的状态更改必须从diff通知程序可靠地传递到diff客户端，并且diff客户端必须能够按照XCAP服务器上发生的相同时间顺序应用XCAP文档的所有更改。当使用不可靠的传输进行重传时，与XCAP diff一起使用的应用程序协议必须确保删除重复项。如果XCAP diff传递丢失，则必须中断diff会话。请注意，当diff客户端必须响应每个XCAP diff传递时，diff通知程序可以很容易地注意到丢失的通知。
A diff notifier doesn't necessarily report all of these XCAP document updates with ETags; it MAY skip over some intermediate version of a document, for example, with rapidly changing resources. However, it MUST always report changes consistently to a diff client so that it can properly update the latest state (content and ETag) of its locally cached resources.
diff通知程序不一定用etag报告所有这些XCAP文档更新；它可能跳过文档的某些中间版本，例如，使用快速变化的资源。但是，它必须始终一致地向diff客户端报告更改，以便能够正确地更新其本地缓存资源的最新状态（内容和ETag）。
As an example, an XCAP document is updated by different 'a', 'b', and 'c' versions identified with the same corresponding ETag values in a relatively short period. The first reported notification contains the 'a' "new-tag" information (no "previous-etag" attribute), and the diff notifier decides to skip the update notification identified by the 'b' ETag value. The second notification to a diff client MUST then contain the 'a' "previous-etag" and 'c' "new-etag" values with optional corresponding content changes (from version 'a' to 'c').
例如，XCAP文档在相对较短的时间内由不同的“a”、“b”和“c”版本更新，这些版本用相同的对应ETag值标识。第一个报告的通知包含“a”“new tag”信息（无“previous etag”属性），差异通知程序决定跳过由“b”etag值标识的更新通知。然后，发送给差异客户端的第二个通知必须包含“a”“previous etag”和“c”“new etag”值以及可选的相应内容更改（从版本“a”到“c”）。
Since XCAP documents are typically confidential, diff notifiers MUST obey the XCAP authorization rules. In practice, this means following the read privilege rules of XCAP resources when notifying the authenticated diff clients of changes. Transport SHOULD be secured by encryption.
由于XCAP文档通常是保密的，diff通知者必须遵守XCAP授权规则。实际上，这意味着在通知经过身份验证的diff客户端更改时，遵循XCAP资源的读取权限规则。传输应通过加密进行保护。
Note: This format specification doesn't define how to select the resources whose differences a diff notifier should report. It also doesn't define whether actual content changes should be reported. Typically, however, a diff client starts a session by sending a resource listing request. Then it compares the remote resource listings with locally cached ones, and probably downloads those resources that aren't locally cached or whose entity tags differ. When a diff client receives an XCAP diff with a "previous-etag" value that matches its current cached copy of a document, it can apply the diffs to the cached copy. As it takes some time to download reference documents, and diff notifications appear after actual resource state changes, several round trips may be needed before a full synchronization is achieved, especially with rapidly changing resources.
注意：此格式规范未定义如何选择差异通知程序应报告其差异的资源。它也没有定义是否应该报告实际的内容更改。但是，通常情况下，diff客户端通过发送资源列表请求来启动会话。然后，它将远程资源列表与本地缓存的资源列表进行比较，并可能下载那些未在本地缓存或其实体标记不同的资源。当diff客户端接收到一个XCAP diff，其“previous etag”值与其当前缓存的文档副本相匹配时，它可以将diff应用于缓存的副本。由于下载参考文档需要一些时间，并且实际资源状态更改后会出现差异通知，因此在实现完全同步之前可能需要多次往返，尤其是在资源快速变化的情况下。
XCAP diff documents can include changes from one version of a document to another version. As a consequence, if the document itself is sensitive and requires confidentiality, integrity, or authentication, then the same applies to the XCAP diff format. Therefore, protocols that transport XCAP diff documents must provide sufficient security capabilities for transporting the document itself. Confidential XCAP documents are typically transported using TLS-encrypted (Transport Layer Security) [RFC5246] communication; see RFC 4825 [RFC4825] for further security details.
XCAP diff文档可以包括从文档的一个版本到另一个版本的更改。因此，如果文档本身是敏感的，并且需要保密性、完整性或身份验证，那么XCAP diff格式也是如此。因此，传输XCAP diff文档的协议必须为传输文档本身提供足够的安全功能。机密XCAP文件通常使用TLS加密（传输层安全）[RFC5246]通信进行传输；有关更多安全性详细信息，请参阅RFC 4825[RFC4825]。
When this format is used to report content changes of XCAP documents, all security considerations of RFC 5261 [RFC5261] apply. Very frequent updates of XCAP documents and/or many diff clients per subscribed resource impose a Denial-of-Service attack possibility to the servers processing XCAP diff documents. An efficient patch processing and throttling can, however, decrease the required overall processings and transactions.
当使用此格式报告XCAP文档的内容更改时，RFC 5261[RFC5261]的所有安全注意事项均适用。频繁更新XCAP文档和/或每个订阅资源的许多diff客户端会对处理XCAP diff文档的服务器造成拒绝服务攻击的可能性。但是，有效的补丁处理和节流可以减少所需的总体处理和事务。
The SIP event package framework specified in RFC 3265 [RFC3265] is the most typical use-case for this format. Then, an end-to-end SIP encryption mechanism, such as Secure/Multipurpose Internet Mail Extensions (S/MIME) described in Section 26.2.4 of RFC 3261 [RFC3261], SHOULD be used. If that is not available, it is RECOMMENDED that TLS [RFC5246] be used between elements to provide hop-by-hop authentication and encryption mechanisms as described in Section 26.2.2 ("SIPS URI Scheme") and Section 26.3.2.2 ("Interdomain Requests") of RFC 3261 [RFC3261]. Event packages MAY also have other specific threats that MUST be considered on an application-by-application basis.
RFC 3265[RFC3265]中指定的SIP事件包框架是该格式最典型的用例。然后，应使用端到端SIP加密机制，如RFC 3261[RFC3261]第26.2.4节所述的安全/多用途互联网邮件扩展（S/MIME）。如果不可用，建议在元素之间使用TLS[RFC5246]，以提供RFC 3261[RFC3261]第26.2.2节（“SIPS URI方案”）和第26.3.2.2节（“域间请求”）中所述的逐跳认证和加密机制。事件包还可能具有其他特定威胁，必须逐个应用程序考虑这些威胁。
There are several IANA considerations associated with this specification.
与本规范相关的IANA注意事项有几个。
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: xcap-diff+xml
MIME子类型名称：xcap diff+xml
Mandatory parameters: none
强制参数：无
Optional parameters: Same as the charset parameter application/xml as specified in RFC 3023 [RFC3023].
可选参数：与RFC 3023[RFC3023]中指定的字符集参数application/xml相同。
Encoding considerations: Same as the encoding considerations of application/xml as specified in RFC 3023 [RFC3023].
编码注意事项：与RFC 3023[RFC3023]中指定的application/xml的编码注意事项相同。
Security considerations: See Section 10 of RFC 3023 [RFC3023] and Section 7 of RFC 5874.
安全注意事项：参见RFC 3023[RFC3023]第10节和RFC 5874第7节。
Interoperability considerations: none.
互操作性考虑：无。
Published specification: This document.
已发布规范：本文件。
Applications that use this media type: This document type has been used to support manipulation of resource lists [RFC4826] using XCAP.
使用此媒体类型的应用程序：此文档类型已用于支持使用XCAP操纵资源列表[RFC4826]。
Additional Information:
其他信息：
Magic Number: None
神奇数字：无
File Extension: .xdf
文件扩展名：.xdf
Macintosh file type code: "TEXT"
Macintosh文件类型代码：“文本”
Personal and email address for further information: Jonathan Rosenberg, jdrosen@jdrosen.net
更多信息的个人和电子邮件地址：Jonathan Rosenberg，jdrosen@jdrosen.net
Intended usage: COMMON
预期用途：普通
Author/Change controller: The IETF.
作者/变更控制者：IETF。
8.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:xcap-diff
8.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:xcap-diff
This section registers a new XML namespace, as per the guidelines in [RFC3688].
本节根据[RFC3688]中的指南注册一个新的XML名称空间。
URI: The URI for this namespace is urn:ietf:params:xml:ns:xcap-diff.
URI：此命名空间的URI为urn:ietf:params:xml:ns:xcap-diff。
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
注册人联系人：IETF，简单工作组(simple@ietf.org)，乔纳森·罗森伯格(jdrosen@jdrosen.net).
XML:
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>XCAP Diff Namespace</title>
</head>
<body>
<h1>Namespace for XCAP Diff</h1>
<h2>urn:ietf:params:xml:ns:xcap-diff</h2>
<p>See <a
href="http://www.rfc-editor.org/rfc/rfc5874.txt">RFC5874</a>.</p>
</body>
</html>
END
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>XCAP Diff Namespace</title>
</head>
<body>
<h1>Namespace for XCAP Diff</h1>
<h2>urn:ietf:params:xml:ns:xcap-diff</h2>
<p>See <a
href="http://www.rfc-editor.org/rfc/rfc5874.txt">RFC5874</a>.</p>
</body>
</html>
END
This section registers a new XML schema per the procedures in [RFC3688].
本节根据[RFC3688]中的过程注册一个新的XML模式。
URI: urn:ietf:params:xml:schema:xcap-diff
URI: urn:ietf:params:xml:schema:xcap-diff
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
注册人联系人：IETF，简单工作组(simple@ietf.org)，乔纳森·罗森伯格(jdrosen@jdrosen.net).
The XML for this schema can be found as the sole content of Section 4.
此模式的XML可以作为第4节的唯一内容找到。
The authors would like to thank Pavel Dostal, Jeroen van Bemmel, Martin Hynar, Anders Lindgren, Mary Barnes, Ben Campbell, Francis Dupont, David Harrington, Alexey Melnikov, Dan Romascanu, and Robert Sparks for their valuable comments.
作者要感谢Pavel Dostal、Jeroen van Bemmel、Martin Hynar、Anders Lindgren、Mary Barnes、Ben Campbell、Francis Dupont、David Harrington、Alexey Melnikov、Dan Romascanu和Robert Sparks的宝贵评论。
[W3C.REC-xml-20060816] Paoli, J., Bray, T., Yergeau, F., Maler, E., and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", World Wide Web Consortium FirstEdition REC-xml- 20060816, August 2006, <http:// www.w3.org/TR/2006/REC-xml-20060816>.
[W3C.REC-xml-20060816]Paoli，J.，Bray，T.，Yergeau，F.，Maler，E.，和C.Sperberg-McQueen，“可扩展标记语言（xml）1.0（第四版）”，万维网联盟第一版REC xml-20060816，2006年8月，<http://www.w3.org/TR/2006/REC-xml-20060816>。
[W3C.REC-xml-c14n-20010315] Boyer, J., "Canonical XML Version 1.0", World Wide Web Consortium Recommendation REC-xml-c14n-20010315, March 2001, <http://www.w3.org/TR/2001/ REC-xml-c14n-20010315>.
[W3C.REC-xml-c14n-20010315]Boyer，J.，“规范xml版本1.0”，万维网联盟建议REC-xml-c14n-20010315，2001年3月<http://www.w3.org/TR/2001/ REC-xml-c14n-20010315>。
[W3C.REC-xml-names-20060816] Hollander, D., Layman, A., and T. Bray, "Namespaces in XML 1.0 (Second Edition)", World Wide Web Consortium FirstEdition REC-xml-names-20060816, August 2006, <http://www.w3.org/TR/ 2006/REC-xml-names-20060816>.
[W3C.REC-xml-names-20060816]Hollander，D.，Layman，A.，和T.Bray，“xml 1.0中的名称空间（第二版）”，万维网联盟第一版REC-xml-names-20060816，2006年8月<http://www.w3.org/TR/ 2006/REC-xml-names-20060816>。
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2141]Moats，R.，“瓮语法”，RFC 21411997年5月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[RFC2648]Moats，R.，“IETF文档的URN名称空间”，RFC 26481999年8月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825]Rosenberg，J.，“可扩展标记语言（XML）配置访问协议（XCAP）”，RFC4825，2007年5月。
[RFC5261] Urpalainen, J., "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors", RFC 5261, September 2008.
[RFC5261]Urpalainen，J.，“利用XML路径语言（XPath）选择器的可扩展标记语言（XML）修补程序操作框架”，RFC 52612008年9月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5875] Urpalainen, J. and D. Willis, "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package", RFC 5875, May 2010.
[RFC5875]Urpalainen，J.和D.Willis，“可扩展标记语言（XML）配置访问协议（XCAP）差异事件包”，RFC 5875，2010年5月。
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[RFC2778]Day，M.，Rosenberg，J.，和H.Sugano，“状态和即时信息模型”，RFC 27782000年2月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006.
[RFC4662]Roach，A.，Campbell，B.，和J.Rosenberg，“资源列表的会话启动协议（SIP）事件通知扩展”，RFC 4662，2006年8月。
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[RFC4826]Rosenberg，J.，“用于表示资源列表的可扩展标记语言（XML）格式”，RFC 4826，2007年5月。
[RFC4483] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[RFC4483]Burger，E.“会话初始化协议（SIP）消息中的内容间接寻址机制”，RFC 4483，2006年5月。
These informative examples illustrate basic features of XCAP diff format.
这些信息性示例说明了XCAP diff格式的基本特性。
The following documents exist at an XCAP server (xcap.example.com) with an imaginary "tests" application usage (there's no default document namespace defined in this imaginary application usage).
以下文档存在于一个XCAP服务器（XCAP.example.com）上，该服务器具有一个虚构的“tests”应用程序用法（在这个虚构的应用程序用法中没有定义默认的文档命名空间）。
http://xcap.example.com/tests/users/sip:joe@example.com/index:
http://xcap.example.com/tests/users/sip:joe@example.com/index:
<?xml version="1.0" encoding="UTF-8"?>
<doc id="bar">
<note>This is a sample document</note>
</doc>
<?xml version="1.0" encoding="UTF-8"?>
<doc id="bar">
<note>This is a sample document</note>
</doc>
and then
然后
http://xcap.example.com/tests/users/sip:john@example.com/index:
http://xcap.example.com/tests/users/sip:john@example.com/index:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is another sample document</note>
</doc>
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is another sample document</note>
</doc>
Firstly, an XCAP diff document can indicate what documents exist in a collection. An XCAP diff document may then be:
首先，XCAP diff文档可以指示集合中存在哪些文档。然后，XCAP diff文档可以是：
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<document new-etag="7ahggs"
sel="tests/users/sip:joe@example.com/index"/>
<document new-etag="7ahggs"
sel="tests/users/sip:joe@example.com/index"/>
<document new-etag="terteer"
sel="tests/users/sip:john@example.com/index"/>
<document new-etag="terteer"
sel="tests/users/sip:john@example.com/index"/>
</xcap-diff>
</xcap-diff>
This listing indicates current ETags of existing documents and their relative URIs.
此列表指示现有文档的当前ETag及其相关URI。
Let's say that Joe adds a new document to his collection:
假设Joe向他的收藏中添加了一个新文档：
PUT /tests/users/sip:joe@example.com/another_document HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xml
Content-Length: [XXX]
PUT /tests/users/sip:joe@example.com/another_document HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xml
Content-Length: [XXX]
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is another sample document</note>
</doc>
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is another sample document</note>
</doc>
The requests result header has an HTTP ETag "terteer" for this new document.
对于这个新文档，requests结果头有一个HTTP ETag“terteer”。
Then an XCAP diff document may then indicate only the creation of this single new document:
然后，XCAP diff文档可能仅指示创建此新文档：
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<document new-etag="terteer"
sel="tests/users/sip:joe@example.com/another_document"/>
<document new-etag="terteer"
sel="tests/users/sip:joe@example.com/another_document"/>
</xcap-diff>
</xcap-diff>
A "new-etag" without a "previous-etag" attribute indicates a creation of a new document.
没有“previous etag”属性的“new etag”表示创建了新文档。
Then Joe decides to modify an existing resource:
然后Joe决定修改现有资源：
PUT /tests/users/sip:joe@example.com/another_document HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xml
Content-Length: [XXX]
PUT /tests/users/sip:joe@example.com/another_document HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xml
Content-Length: [XXX]
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a modified document</note>
</doc>
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a modified document</note>
</doc>
The reported new HTTP ETag is "huwiias".
据报道，新的HTTP ETag是“huwiias”。
Then an XCAP diff document may be:
那么XCAP diff文档可能是：
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<document previous-etag="terteer" new-etag="huwiias"
sel="tests/users/sip:joe@example.com/another_document"/>
<document previous-etag="terteer" new-etag="huwiias"
sel="tests/users/sip:joe@example.com/another_document"/>
</xcap-diff>
</xcap-diff>
Both "previous-etag" and "new-etag" attributes signal that a modification has happened to a resource, but actual changes are not shown.
“previous etag”和“new etag”属性都表示资源发生了修改，但未显示实际更改。
Let's say that Joe then removes a document from his collection:
假设Joe从他的收藏中删除了一个文档：
DELETE /tests/users/sip:joe@example.com/another_document HTTP/1.1
Host: xcap.example.com
DELETE /tests/users/sip:joe@example.com/another_document HTTP/1.1
Host: xcap.example.com
This HTTP DELETE request results in the unlinking of the resource, and the XCAP diff may be:
此HTTP DELETE请求导致资源断开链接，XCAP diff可能是：
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<document previous-etag="huwiias"
sel="tests/users/sip:joe@example.com/another_document"/>
<document previous-etag="huwiias"
sel="tests/users/sip:joe@example.com/another_document"/>
</xcap-diff>
</xcap-diff>
Thus, a "previous-etag" without a "new-etag" attribute indicates the removal of a resource.
因此，没有“new etag”属性的“previous etag”表示删除资源。
Secondly, XCAP diff documents are capable of showing actual changes to documents with [RFC5261] patching semantics.
第二，XCAP diff文档能够使用[RFC5261]修补语义显示文档的实际更改。
Now Joe's XCAP client utilizes the XCAP patching capability to add a new element to a document:
现在，Joe的XCAP客户端利用XCAP修补功能向文档中添加新元素：
PUT /tests/users/sip:joe@example.com/index/~~/doc/foo HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xcap-el+xml
Content-Length: [XXX]
PUT /tests/users/sip:joe@example.com/index/~~/doc/foo HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xcap-el+xml
Content-Length: [XXX]
<foo>this is a new element</foo>
<foo>this is a new element</foo>
Since the insertion of the element is successful, Joe's XCAP client receives the new HTTP ETag "fgherhryt3" of the updated "index" document.
由于元素的插入成功，Joe的XCAP客户端将接收更新的“index”文档的新HTTP ETag“fgherhryt3”。
Immediately thereafter, Joe's XCAP client issues another HTTP request (this request could even be pipelined):
紧接着，Joe的XCAP客户端发出另一个HTTP请求（该请求甚至可以通过管道传输）：
PUT /tests/users/sip:joe@example.com/index/~~/doc/bar HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xcap-el+xml
Content-Length: [XXX]
PUT /tests/users/sip:joe@example.com/index/~~/doc/bar HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xcap-el+xml
Content-Length: [XXX]
<bar>this is a bar element
</bar>
<bar>this is a bar element
</bar>
The reported new HTTP ETag of "index" is now "dgdgdfgrrr".
报告的“索引”的新HTTP ETag现在是“DGDFGRRR”。
And then Joe's XCAP client issues yet another HTTP request:
然后Joe的XCAP客户端发出另一个HTTP请求：
PUT /tests/users/sip:joe@example.com/index/~~/doc/foobar HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xcap-el+xml
Content-Length: [XXX]
PUT /tests/users/sip:joe@example.com/index/~~/doc/foobar HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xcap-el+xml
Content-Length: [XXX]
<foobar>this is a foobar element</foobar>
<foobar>this is a foobar element</foobar>
The reported new ETag of "index" is now "63hjjsll".
报告的“索引”新ETag现在是“63hjjsll”。
XCAP diff format document may then indicate these XCAP component changes by:
然后，XCAP diff格式文档可以通过以下方式指示这些XCAP组件更改：
<?xml version="1.0" encoding="UTF-8"?>
<d:xcap-diff xmlns:d="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<?xml version="1.0" encoding="UTF-8"?>
<d:xcap-diff xmlns:d="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<d:document previous-etag="7ahggs3"
sel="tests/users/sip:joe@example.com/index"
new-etag="63hjjsll">
<d:add sel="*"
><foo>this is a new element</foo><bar>this is a bar element
</bar><foobar>this is a foobar element</foobar></d:add>
</d:document>
<d:document previous-etag="7ahggs3"
sel="tests/users/sip:joe@example.com/index"
new-etag="63hjjsll">
<d:add sel="*"
><foo>this is a new element</foo><bar>this is a bar element
</bar><foobar>this is a foobar element</foobar></d:add>
</d:document>
</d:xcap-diff>
</d:xcap-diff>
Note how several XCAP component modifications were aggregated together, and full history information got lost.
请注意，几个XCAP组件修改是如何聚合在一起的，而完整的历史信息丢失了。
Alternatively, the content could have been:
或者，内容可以是：
<?xml version="1.0" encoding="UTF-8"?>
<d:xcap-diff xmlns:d="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<?xml version="1.0" encoding="UTF-8"?>
<d:xcap-diff xmlns:d="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<d:document previous-etag="7ahggs"
sel="tests/users/sip:joe@example.com/index"
new-etag="fgherhryt3">
<d:add sel="*"
><foo>this is a new element</foo></d:add></d:document>
<d:document previous-etag="7ahggs"
sel="tests/users/sip:joe@example.com/index"
new-etag="fgherhryt3">
<d:add sel="*"
><foo>this is a new element</foo></d:add></d:document>
<d:document previous-etag="fgherhryt3"
sel="tests/users/sip:joe@example.com/index"
new-etag="dgdgdfgrrr">
<d:add sel="*"
><bar>this is a bar element
</bar></d:add></d:document>
<d:document previous-etag="fgherhryt3"
sel="tests/users/sip:joe@example.com/index"
new-etag="dgdgdfgrrr">
<d:add sel="*"
><bar>this is a bar element
</bar></d:add></d:document>
<d:document previous-etag="dgdgdfgrrr"
sel="tests/users/sip:joe@example.com/index"
new-etag="63hjjsll">
<d:add sel="*"
><foobar>this is a foobar element</foobar></d:add></d:document>
<d:document previous-etag="dgdgdfgrrr"
sel="tests/users/sip:joe@example.com/index"
new-etag="63hjjsll">
<d:add sel="*"
><foobar>this is a foobar element</foobar></d:add></d:document>
</d:xcap-diff>
</d:xcap-diff>
This shows the full ETag change history of a document, and ETags change chronologically in the reported XML document order.
这将显示文档的完整ETag更改历史记录，并且ETag按报告的XML文档顺序按时间顺序更改。
Lastly, the XCAP diff format can also indicate the existing full contents of XCAP components, i.e., elements or attributes:
最后，XCAP diff格式还可以指示XCAP组件的现有完整内容，即元素或属性：
<?xml version="1.0" encoding="UTF-8"?>
<d:xcap-diff xmlns:d="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<?xml version="1.0" encoding="UTF-8"?>
<d:xcap-diff xmlns:d="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<d:attribute sel="tests/users/sip:joe@example.com/index/~~/doc/@id"
>bar</d:attribute>
<d:attribute sel="tests/users/sip:joe@example.com/index/~~/doc/@id"
>bar</d:attribute>
<d:element sel="tests/users/sip:joe@example.com/index/~~/*/foo"
><foo>this is a new element</foo></d:element>
<d:element sel="tests/users/sip:joe@example.com/index/~~/*/foo"
><foo>this is a new element</foo></d:element>
</d:xcap-diff>
</d:xcap-diff>
Note that the HTTP ETag value of the new document is not shown as it is irrelevant for this use-case.
请注意，新文档的HTTP ETag值没有显示，因为它与此用例无关。
Then Joe's XCAP client removes the "id" attribute:
然后Joe的XCAP客户端删除“id”属性：
DELETE /tests/users/sip:joe@example.com/index/~~/doc/@id HTTP/1.1
Host: xcap.example.com
....
Content-Length: 0
DELETE /tests/users/sip:joe@example.com/index/~~/doc/@id HTTP/1.1
Host: xcap.example.com
....
Content-Length: 0
And the XCAP diff document may then be:
然后，XCAP diff文档可以是：
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<attribute sel="tests/users/sip:joe@example.com/index/~~/doc/@id"
exists="0"/>
<attribute sel="tests/users/sip:joe@example.com/index/~~/doc/@id"
exists="0"/>
</xcap-diff>
</xcap-diff>
This indicates that the subscribed attribute was removed from the document. The element content in this use-case may be discarded from the XCAP diff document, for example, when the size of XCAP diff document would be impractically large to the transport layer.
这表示已从文档中删除订阅的属性。这个用例中的元素内容可以从XCAP diff文档中丢弃，例如，当XCAP diff文档的大小对于传输层来说是不切实际的大时。
Authors' Addresses
作者地址
Jonathan Rosenberg jdrosen.net Monmouth, NJ US
Jonathan Rosenberg jdrosen.net美国新泽西州蒙茅斯
EMail: jdrosen@jdrosen.net
URI: http://www.jdrosen.net
EMail: jdrosen@jdrosen.net
URI: http://www.jdrosen.net
Jari Urpalainen Nokia Itamerenkatu 11-13 Helsinki 00180 Finland
芬兰赫尔辛基乌尔帕莱宁诺基亚伊塔梅伦卡图11-13 00180
Phone: +358 7180 37686
EMail: jari.urpalainen@nokia.com
Phone: +358 7180 37686
EMail: jari.urpalainen@nokia.com