Internet Engineering Task Force (IETF) R. Shekh-Yusef
Request for Comments: 7082 Avaya
Category: Informational M. Barnes
ISSN: 2070-1721 Polycom
December 2013
Internet Engineering Task Force (IETF) R. Shekh-Yusef
Request for Comments: 7082 Avaya
Category: Informational M. Barnes
ISSN: 2070-1721 Polycom
December 2013
Indication of Conference Focus Support for the Centralized Conferencing Manipulation Protocol (CCMP)
指示对集中式会议操作协议（CCMP）的会议焦点支持
Abstract
摘要
The Centralized Conferencing Manipulation Protocol (CCMP) document (RFC 6503) defines a way for a client to discover a conference control server that supports CCMP. However, it does not define a way for a client involved in a conference to determine if the conference focus supports CCMP. This information would allow a CCMP-enabled client that joins a conference using SIP to also register for the Centralized Conferencing (XCON) conference event package and take advantage of CCMP operations on the conference.
集中式会议操纵协议（CCMP）文档（RFC 6503）定义了客户端发现支持CCMP的会议控制服务器的方法。但是，它没有为参与会议的客户机定义确定会议焦点是否支持CCMP的方法。此信息将允许使用SIP加入会议的启用CCMP的客户端也注册集中式会议（XCON）会议事件包，并利用会议上的CCMP操作。
This document describes two mechanisms, depending upon the need of the User Agent (UA), to address the above limitation. The first mechanism uses the Call-Info header field, and the second mechanism defines a new value for the "purpose" header field parameter in the <service-uris> element in the SIP conferencing event package.
本文档描述了两种机制，这取决于用户代理（UA）的需要，以解决上述限制。第一种机制使用Call Info header字段，第二种机制在SIP会议事件包的<service uris>元素中为“purpose”header字段参数定义一个新值。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7082.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7082.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Solutions .......................................................3
2.1. Call-Info ..................................................3
2.2. Service URI Purpose ........................................4
3. Overall Process .................................................5
4. Security Considerations .........................................5
5. IANA Considerations .............................................6
5.1. Call-Info Purpose Registration .............................6
5.2. URI Purpose Registration ...................................6
6. Acknowledgments .................................................6
7. Normative References ............................................7
Appendix A. Other Approaches Considered ............................9
A.1. Feature Tag ................................................9
A.2. Conference URI Purpose .....................................9
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Solutions .......................................................3
2.1. Call-Info ..................................................3
2.2. Service URI Purpose ........................................4
3. Overall Process .................................................5
4. Security Considerations .........................................5
5. IANA Considerations .............................................6
5.1. Call-Info Purpose Registration .............................6
5.2. URI Purpose Registration ...................................6
6. Acknowledgments .................................................6
7. Normative References ............................................7
Appendix A. Other Approaches Considered ............................9
A.1. Feature Tag ................................................9
A.2. Conference URI Purpose .....................................9
RFC 5239 [RFC5239] defines a framework for Centralized Conferencing (XCON), which allows participants to exchange media in a centralized unicast conference. The framework also outlines a set of conferencing protocols for building advanced conferencing applications.
RFC 5239[RFC5239]定义了一个集中式会议（XCON）框架，允许参与者在集中式单播会议中交换媒体。该框架还概述了一组用于构建高级会议应用程序的会议协议。
The Centralized Conferencing Manipulation Protocol (CCMP) [RFC6503] allows authenticated and authorized users to create, manipulate, and delete conference objects. Operations on conferences include adding and removing participants and changing their roles, as well as adding and removing media streams and associated end points.
集中式会议操作协议（CCMP）[RFC6503]允许经过身份验证和授权的用户创建、操作和删除会议对象。会议上的操作包括添加和删除参与者以及更改他们的角色，以及添加和删除媒体流和相关端点。
CCMP defines a way for an XCON-aware client to discover whether a conference control server supports CCMP. However, it does not define a way for a SIP client involved in a conference to determine if the conference focus [RFC4353] supports CCMP. Knowing that a focus supports CCMP would allow a SIP client (that is also XCON aware) that joins a conference using SIP-based conferencing [RFC4579] to also register for the XCON conference event package [RFC6502] and take advantage of CCMP operations on the conference.
CCMP定义了一种XCON感知客户端发现会议控制服务器是否支持CCMP的方法。然而，它并没有为参与会议的SIP客户端定义确定会议焦点[RFC4353]是否支持CCMP的方法。知道focus支持CCMP将允许使用基于SIP的会议[RFC4579]加入会议的SIP客户端（也支持XCON）也注册XCON会议事件包[RFC6502]，并利用会议上的CCMP操作。
This document describes two options to address the above limitation, depending on the need of the User Agent (UA). The first option uses the Call-Info [RFC3261] header, which is suitable for application servers that need to discover if a UA supports CCMP. The second option defines a new value for the "purpose" header field parameter in the <service-uris> element in the SIP conferencing event package [RFC4575] that is suitable for a UA that would typically subscribe to the conference event package.
根据用户代理（UA）的需要，本文档描述了解决上述限制的两个选项。第一个选项使用Call Info[RFC3261]报头，该报头适用于需要发现UA是否支持CCMP的应用程序服务器。第二个选项为SIP会议事件包[RFC4575]中的<service uris>元素中的“purpose”头字段参数定义了一个新值，该值适用于通常订阅会议事件包的UA。
Appendix A has a brief description of other options that we considered as possible solutions. Those other options were not selected, however, because the options described in this document better address the problem we are trying to solve.
附录A简要说明了我们认为可能的解决方案。但是，没有选择其他选项，因为本文档中描述的选项更好地解决了我们试图解决的问题。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This section defines two mechanisms that can be used by a SIP UA to discover whether the conference that a client has joined, per the SIP signaling procedures defined in [RFC4579], supports CCMP. Specifically, the mechanisms allow the client to know that the URI representing the conference focus, as defined in [RFC4579], is an XCON-URI as defined in [RFC6501].
本节定义了两种机制，SIP UA可使用这两种机制，根据[RFC4579]中定义的SIP信令过程，发现客户端加入的会议是否支持CCMP。具体地说，这些机制允许客户端知道代表会议焦点的URI（如[RFC4579]中所定义）是[RFC6501]中所定义的XCON-URI。
This approach uses the Call-Info header in various requests and responses.
这种方法在各种请求和响应中使用Call Info报头。
The Call-Info header consists of two parts: a URI and a "purpose" header field parameter. The URI provides the XCON-URI of the conference focus, and a new value for the "purpose" header field parameter indicates that the conference focus supports CCMP.
Call Info标头由两部分组成：URI和“purpose”标头字段参数。URI提供会议焦点的XCON-URI，“目的”标头字段参数的新值表示会议焦点支持CCMP。
While the XCON-URI by itself should be enough to indicate that the conference focus supports CCMP, the "purpose" header field parameter with a value of 'ccmp' provides an easier way for a UA that does not use the conference event package to discover that the conference focus supports CCMP, without parsing the URI.
虽然XCON-URI本身应足以表明会议焦点支持CCMP，但值为“CCMP”的“目的”标头字段参数为不使用会议事件包的UA提供了一种更简单的方法来发现会议焦点支持CCMP，而无需解析URI。
The Call-Info header, with the XCON-URI and the "purpose" header field parameter with the 'ccmp' value, can be used with any INVITE request or response and with a response to an OPTIONS request.
Call Info报头带有XCON-URI和带有“ccmp”值的“purpose”报头字段参数，可用于任何INVITE请求或响应以及对OPTIONS请求的响应。
This approach would be suitable for a UA, e.g., an application server that acts as a Back-to-Back User Agent (B2BUA), that is interested in discovering that a conference focus supports CCMP but does not use the XCON conference event package [RFC6502]. In this case, the application could use the OPTIONS request and discover CCMP support from the response.
这种方法适用于UA，例如，充当背对背用户代理（B2BUA）的应用服务器，该应用服务器有兴趣发现会议焦点支持CCMP，但不使用XCON会议事件包[RFC6502]。在这种情况下，应用程序可以使用选项请求并从响应中发现CCMP支持。
This approach would also be suitable for a conference focus that initiates an INVITE request to a SIP UA to add a participant to a conference, as it would allow the conference focus to indicate that it supports CCMP with the INVITE request sent to the UA.
该方法还适用于发起对SIP UA的INVITE请求以向会议添加参与者的会议焦点，因为它将允许会议焦点通过向UA发送INVITE请求来指示它支持CCMP。
The advantage of this approach is the ability to discover that a conference focus supports CCMP, without subscribing to the XCON event package [RFC6502]. The disadvantage is the need, in some cases, for an extra request, i.e., an additional OPTIONS request, to discover that a conference focus supports CCMP.
这种方法的优点是能够发现会议焦点支持CCMP，而无需订阅XCON事件包[RFC6502]。缺点是，在某些情况下，需要额外的请求，即额外的选项请求，以发现会议焦点支持CCMP。
This approach defines an additional URI 'purpose' of 'ccmp' associated with a <service-uris> element in the SIP conferencing event package. The XCON-URI for the conference is included in the 'uri' element, per the following example:
此方法定义了与SIP会议事件包中的<service uris>元素关联的“ccmp”的附加URI“purpose”。根据以下示例，会议的XCON-URI包含在“URI”元素中：
<service-uris>
<entry>
<uri>XCON:conf1@example.com</uri>
<purpose>ccmp</purpose>
</entry>
</service-uris>
<service-uris>
<entry>
<uri>XCON:conf1@example.com</uri>
<purpose>ccmp</purpose>
</entry>
</service-uris>
The advantage of this approach is that it uses an existing mechanism for extending the <purpose> field of the <service-uris> element in the conferencing event package [RFC4353]. The disadvantage is that it requires the client to subscribe to the conference event package.
这种方法的优点是，它使用现有机制来扩展会议事件包[RFC4353]中<service URI>元素的<purpose>字段。缺点是它需要客户端订阅会议事件包。
This approach would be suitable for a SIP UA that would typically subscribe to the conference event package. Knowing that a conference supports CCMP allows a SIP UA that is XCON aware to make use of the CCMP operations and allows it to subscribe to the XCON event package [RFC6502] to get additional information related to the conference.
这种方法将适用于通常订阅会议事件包的SIP UA。知道会议支持CCMP允许知道XCON的SIP UA使用CCMP操作，并允许其订阅XCON事件包[RFC6502]，以获得与会议相关的附加信息。
CCMP capability is discovered using the two methods described in Section 2. The order in which the two methods are tried depends on whether an implementation subscribes to the conference event package by default.
使用第2节中描述的两种方法发现CCMP能力。尝试这两种方法的顺序取决于默认情况下实现是否订阅会议事件包。
A UA implementation that subscribes to the conference event package can examine the conference description to see if a URI with <purpose>ccmp</purpose> is specified (Section 2.2). An implementation that does not subscribe to the conference event package can perform an OPTIONS query when connecting to the conference server. UAs MUST NOT attempt both methods with the same server.
订阅会议事件包的UA实现可以检查会议描述，以查看是否指定了带有<purpose>ccmp</purpose>的URI（第2.2节）。未订阅会议事件包的实现可以在连接到会议服务器时执行选项查询。UAs不得在同一台服务器上尝试这两种方法。
Conference servers MUST reflect the same information using both discovery channels. A server MUST indicate CCMP support through the conference event package if and only if it indicates support through the Call-Info header in OPTIONS responses. This prevents the need for UAs to try both methods.
会议服务器必须使用两个发现通道反映相同的信息。当且仅当服务器通过选项响应中的Call Info报头指示支持时，服务器必须通过会议事件包指示CCMP支持。这就避免了UAs尝试这两种方法的需要。
This document defines no new headers or data elements; it reuses existing headers and data elements. CCMP already allows a client the ability to discover if a conference server supports CCMP, using a DNS mechanism as defined in [RFC6503] Section 12.4.
本文件未定义新的标题或数据元素；它重用现有的头和数据元素。CCMP已经允许客户端使用[RFC6503]第12.4节中定义的DNS机制发现会议服务器是否支持CCMP。
Thus, the solution options defined in this document do not introduce any new security threats.
因此，本文档中定义的解决方案选项不会引入任何新的安全威胁。
This specification adds a new predefined value "ccmp" for the "purpose" header field parameter of the Call-Info header field. This modifies the registry header field parameters and parameter values by adding this RFC as a reference to the line for header field "Call-Info" and parameter name "purpose":
本规范为Call Info header字段的“purpose”header字段参数添加了一个新的预定义值“ccmp”。通过添加此RFC作为对标题字段“Call Info”和参数名称“purpose”行的引用，修改注册表标题字段参数和参数值：
Header Field: Call-Info
标题字段：呼叫信息
Parameter Name: purpose
参数名称：用途
Predefined Values: yes
预定义值：是
Reference: [RFC3261] [RFC5367] [RFC6910] [RFC6993] [RFC7082]
参考文献：[RFC3261][RFC5367][RFC6910][RFC6993][RFC7082]
This specification adds a new predefined value "ccmp" to the "URI Purposes" subregistry, which defines XML elements to be encoded in the conference event package [RFC4575].
本规范向“URI用途”子区域添加了一个新的预定义值“ccmp”，该子区域定义了要在会议事件包[RFC4575]中编码的XML元素。
This modifies the registry as follows:
这将修改注册表，如下所示：
Value: ccmp
值：ccmp
Description: The URI can be used to indicate that the conference focus supports CCMP.
描述：URI可用于指示会议焦点支持CCMP。
Reference: [RFC7082]
参考文献：[RFC7082]
The authors would like to thank Alan Johnston, Robert Sparks, Cullen Jennings, Glenn Parsons, Ben Campbell, Barry Leiba, Spencer Dawkins, Sean Turner, Pete Resnick, and Adrian Farrel for their careful review and feedback.
作者要感谢Alan Johnston、Robert Sparks、Cullen Jennings、Glenn Parsons、Ben Campbell、Barry Leiba、Spencer Dawkins、Sean Turner、Pete Resnick和Adrian Farrel的仔细审查和反馈。
Special thanks to Adam Roach for his thorough review, comments, and suggestions. Special thanks also to Richard Barnes for his review and for the text he provided for Section 3 of this document.
特别感谢亚当·罗奇的全面回顾、评论和建议。还特别感谢Richard Barnes对本文件第3节的审查和提供的文本。
[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月。
[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月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[RFC4353]Rosenberg，J.，“会话启动协议（SIP）会议框架”，RFC 4353，2006年2月。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4575]Rosenberg，J.，Schulzrinne，H.，和O.Levin，Ed.，“会议状态的会话启动协议（SIP）事件包”，RFC 45752006年8月。
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006.
[RFC4579]Johnston，A.和O.Levin，“会话发起协议（SIP）呼叫控制-用户代理会议”，BCP 119，RFC 4579，2006年8月。
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, June 2008.
[RFC5239]Barnes，M.，Boulton，C.，和O.Levin，“集中会议的框架”，RFC 5239，2008年6月。
[RFC5367] Camarillo, G., Roach, A., and O. Levin, "Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)", RFC 5367, October 2008.
[RFC5367]Camarillo，G.，Roach，A.，和O.Levin，“会话启动协议（SIP）中包含资源列表的请求订阅”，RFC 5367，2008年10月。
[RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, March 2012.
[RFC6501]Novo，O.，Camarillo，G.，Morgan，D.，和J.Urpalainen，“集中会议的会议信息数据模型（XCON）”，RFC 65012012年3月。
[RFC6502] Camarillo, G., Srinivasan, S., Even, R., and J. Urpalainen, "Conference Event Package Data Format Extension for Centralized Conferencing (XCON)", RFC 6502, March 2012.
[RFC6502]Camarillo，G.，Srinivasan，S.，Even，R.，和J.Urpalainen，“集中会议的会议事件包数据格式扩展（XCON）”，RFC 65022002，2012年3月。
[RFC6503] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, "Centralized Conferencing Manipulation Protocol", RFC 6503, March 2012.
[RFC6503]Barnes，M.，Boulton，C.，Romano，S.，和H.Schulzrinne，“集中式会议操纵协议”，RFC65032012年3月。
[RFC6910] Worley, D., Huelsemann, M., Jesske, R., and D. Alexeitsev, "Completion of Calls for the Session Initiation Protocol (SIP)", RFC 6910, April 2013.
[RFC6910]Worley，D.，Huelsemann，M.，Jeske，R.，和D.Alexetsev，“会话启动协议（SIP）呼叫的完成”，RFC 69102013年4月。
[RFC6993] Saint-Andre, P., "Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)", RFC 6993, July 2013.
[RFC6993]Saint Andre，P.，“会话启动协议（SIP）中呼叫信息报头字段的即时消息和存在目的”，RFC 6993，2013年7月。
The following two options were considered as possible solutions but were not selected because the options described in this document better address the problem we are trying to solve.
以下两个选项被视为可能的解决方案，但未被选择，因为本文档中描述的选项可以更好地解决我们试图解决的问题。
This approach defines a feature parameter 'ccmp' to indicate that a SIP dialog belongs to a conference that supports CCMP. The use of feature parameters in Contact header fields to describe the characteristics and capabilities of a UA is described in the User Agent Capabilities document [RFC3840].
这种方法定义了一个功能参数“ccmp”，以指示SIP对话框属于支持ccmp的会议。用户代理能力文档[RFC3840]中描述了在联系人标题字段中使用特征参数来描述UA的特征和能力。
The conference focus behavior regarding the handling of the 'ccmp' feature is the same as the behavior for the handling of the 'isfocus' feature parameter. In session establishment, a conference focus MUST include the 'ccmp' feature parameter in the Contact header field unless the conference focus wishes to hide the fact that it is a conference focus.
关于处理“ccmp”功能的会议焦点行为与处理“isfocus”功能参数的行为相同。在会话建立过程中，会议焦点必须在联系人标题字段中包含“ccmp”功能参数，除非会议焦点希望隐藏它是会议焦点的事实。
The advantages of this approach are a one-step discovery of the conference focus and its support for the 'ccmp' feature and the fact that it can be used in response to an OPTIONS request, and that it enables the discovery of the 'ccmp' capability by any network element that does not need the conference event package. The disadvantage is the definition of a new feature parameter.
这种方法的优点是一步发现会议焦点及其对“ccmp”功能的支持，以及它可用于响应选项请求的事实，并且它允许任何不需要会议事件包的网元发现“ccmp”功能。缺点是定义了一个新的特征参数。
This approach defines an additional URI 'purpose' of 'ccmp' associated with a 'conf-uris' element in the SIP conferencing event package.
此方法定义了与SIP会议事件包中的“conf uris”元素关联的“ccmp”的附加URI“purpose”。
ccmp: Indicates that the conference focus represented by this URI supports 'ccmp'; this in turn allows a client to use CCMP to manipulate the conference. This URI MUST be an XCON-URI as defined in the XCON data model specification [RFC6501].
ccmp：表示此URI表示的会议焦点支持“ccmp”；这反过来又允许客户端使用CCMP操纵会议。此URI必须是XCON数据模型规范[RFC6501]中定义的XCON-URI。
<conf-uris>
<entry>
<uri>XCON:conf1@example.com</uri>
<display-text>whatever</display-text>
<purpose>ccmp</purpose>
</entry>
</conf-uris>
<conf-uris>
<entry>
<uri>XCON:conf1@example.com</uri>
<display-text>whatever</display-text>
<purpose>ccmp</purpose>
</entry>
</conf-uris>
The advantage of the SIP conference event package options is the use of an existing mechanism for extending the <purpose> field of the <service-uris> or <conf-uris> elements. The disadvantage is the requirement that the client register for the conference event package.
SIP会议事件包选项的优点是使用现有机制来扩展<service uri>或<conf uris>元素的<purpose>字段。缺点是要求客户端注册会议事件包。
Authors' Addresses
作者地址
Rifaat Shekh-Yusef Avaya 250 Sidney Street Belleville, Ontario Canada
Rifaat Shekh Yusef Avaya 250 Sidney Street Belleville，加拿大安大略省
Phone: +1-613-967-5267
EMail: rifaat.ietf@gmail.com
Phone: +1-613-967-5267
EMail: rifaat.ietf@gmail.com
Mary Barnes Polycom TX US
玛丽·巴恩斯美国宝利通公司
EMail: mary.ietf.barnes@gmail.com
EMail: mary.ietf.barnes@gmail.com