3.7 Social Presence Information / 社交呈现信息

3.7.1 Feature description / 功能描述

3.7.1.1 Social Presence definition / 社交呈现定义

Social presence is seen as a piece of information for buddies to let them know about what you are doing, your mood, status, and so on. The user is given the possibility to publish personal data, which configures the users Social Presence Information, or “personal profile”.
社交呈现被视为一个信息，让好友让他们知道你在做什么，你的心情，地位等等。 用户被给予发布个人数据的可能性，其配置用户社交呈现信息或“个人简档”。

As an illustration, the group of contacts with whom a presence relationship is established can be seen as the closest contacts of a certain user (friends, family, colleagues, and so on.).
作为说明，与其建立存在关系的联系人组可以被视为特定用户（朋友，家人，同事等）的最接近的联系人。

Social Presence Information (included in the personal profile) does not replace the legacy contact’s vCard in the address book of the user (for example. the contact name and other contact details shall not be impacted).
社交呈现信息（包含在个人资料中）不会替换用户通讯录中的旧有联系人的vCard（例如，联系人姓名和其他联系人详细信息不受影响）。

The Social Presence Information shall be controlled by the end user and easily configurable.
社交呈现信息应由最终用户控制并且易于配置。

Having established a Social Presence Relationship with a certain contact, the Social Presence Information shall be visible from the Enhanced Address Book (EAB). It should also be visible from other places on the device, like for example the communications log, or message folders.
在与某个联系人建立了社交呈现关联之后，社交呈现信息将从增强的地址簿（EAB）中可见。 它也应该从设备上的其他位置可见，例如通信日志或消息文件夹。

3.7.1.2 Service Fundamentals / 服务基础

In the EAB, the contact information is extended with social presence information and foresees the following attributes:
在EAB中，联系信息随社交呈现信息而扩展，并且预见以下属性：

• Availability, indicates the user’s (un)willingness to communicate,
  可用性，指示用户的（非）通信意愿，
• Portrait icon, depicting the user (e.g. a photo or image provided by the contact himself)
  描绘用户的肖像图标（例如，由联系人自己提供的照片或图像）
• Free text, including textual note and possibility to add emoticons (automatic translation of some specific characters into smileys)
  自由文本，包括文本注释和添加表情符号的可能性（将某些特定字符自动翻译成表情符号）
• Favourite link, to publish hypertext link of personal and/or favourite site
  喜欢的链接，发布个人和/或喜爱的网站的超文本链接
• Timestamp, date of the last update of the profile, generated automatically.
  时间戳，配置文件上次更新的日期，自动生成。
• Geolocation, depicts the user location
  地理位置，描述用户位置

The attributes Availability, Portrait icon and Favourite link are profiled from the standards bringing a new user experience.
属性可用性，肖像图标和喜爱的链接从标准剖析，带来了新的用户体验。

The Availability allows a user to inform a contact that they are currently in a situation when it is possible/not possible to communicate.
可用性允许用户通知联系人他们当前处于可能/不可能通信的情况。

The Availability is controlled fully by the user and not automatically switched on or off.
可用性由用户完全控制，不会自动打开或关闭。

With the portrait icon, it is possible to publish a photo or an icon, which is shown in the EAB of the user’s contacts. This is a new user experience while a user has full control of the portrait displayed at his contacts. Within RCS the size and dimension of the photo is specified.
使用纵向图标，可以发布照片或图标，其显示在用户的联系人的EAB中。 这是一种新的用户体验，而用户完全控制在他的联系人处显示的肖像。 在RCS内，照片的大小和尺寸是指定的。

The favourite link attribute allows sharing additional social presence information. Such a link can point to e.g. a blog.
收藏链接属性允许共享附加的社交呈现信息。这样的链接可以指向例如博客的地址。

With geolocation, two RCS users are able to see where they are located and share this information with each other.
利用地理定位，两个RCS用户能够看到它们位于何处并且彼此共享该信息。

Authorisation to share social presence is based on the symmetry principle.
共享社交呈现的授权是基于对称原理。

If sharing of social presence is accepted after invitation, both parties will see each other’s presence attributes. If social presence sharing is terminated by one of both parties, both parties will end seeing each other’s social presence attributes.
如果在邀请之后接受社交呈现的共享，则双方将看到彼此的呈现属性。 如果社交呈现共享由双方之一终止，则双方将终止看到彼此的社交呈现属性。

When a social presence relationship with a contact is set up from one device (e.g. the broadband client on PC) this relationship will also be visible on the other devices of the user (e.g. a mobile device).
当从一个设备（例如，PC上的宽带客户端）建立与联系人的社交呈现关系时，该关系也将在用户的其他设备（例如，移动设备）上可见。

The RCS invitation experience is improved with a personalized invitation. For easy identification of invitations coming from contacts not yet registered in the user’s address book, it is possible to define a nickname to be used in presence invitations.
通过个性化邀请改进RCS邀请体验。 为了容易识别来自尚未在用户的地址簿中注册的联系人的邀请，可以定义在呈现邀请中使用的昵称。

By choosing whether or not the contact is a VIP contact (see section 3.7.1.4.9), it will be possible to choose for a contact with which social presence is shared whether updates to that contact’s social presence information should be reflected in (near) real time or whether those updates should be retrieved through some low frequency polling for them.
通过选择联系人是否为VIP联系人（参见第3.7.1.4.9节），可以选择与其共享社交呈现的联系人是否应实时更新该联系人的社交呈现信息（附近 ）或者是否应该通过对它们的一些低频轮询来检索这些更新。

3.7.1.3 Social presence attributes / 社交呈现属性

3.7.1.3.1 Availability status / 可用状态

A user will be able to set the state of Availability status (as part of Social Presence Information)
用户将能够设置可用性状态的状态（作为社交呈现信息的一部分）

There are two possible states that can be selected by the user, from their RCS Client:
用户可以从他们的RCS客户端选择两种可能的状态：

1. State#1. From the RCS Client, the user can set Availability status information as state#1. This state is informative and means that user is available and willing to communicate. The way state#1 is displayed to the user is implementation dependent, and subject to own Service Provider policies.
   状态＃1。 从RCS客户端，用户可以将可用性状态信息设置为状态＃1。 这种状态是信息性的，意味着用户可用并愿意沟通。 状态＃1向用户显示的方式取决于实现，并受自身的服务提供商策略的限制。
2. State#2. From the RCS Client, the user can set Availability status information as state#2. This state is informative and means that the user is unavailable or not willing to communicate (e.g. busy) and will probably not respond to any incoming calls or messages. The way state#2 is displayed to the user is implementation dependent, and subject to own service provider policies.
   状态＃2。 从RCS客户端，用户可以将可用性状态信息设置为状态＃2。 这种状态是信息性的，意味着用户不可用或不愿意通信（例如忙），并且可能不响应任何来电或消息。 向用户显示状态＃2的方式是依赖于实现的，并且受自身的服务提供商策略的限制。

These states are informative. When a user sets Availability status information as state#1 or state#2 from the RCS Client, the user still has the possibility to make outbound communications (e.g. calls/messages) and receive inbound communications (e.g. calls/messages).
这些状态是信息性的。 当用户从RCS客户端设置可用性状态信息为状态＃1或状态＃2时，用户仍然可以进行出站通信（例如呼叫/消息）和接收入站通信（例如呼叫/消息）。

The Availability status information has a permanent nature. It remains unchanged until the user decides to modify it (as state#1 or state#2) from their RCS client
可用性状态信息具有永久性。 它保持不变，直到用户决定从其RCS客户端修改它（作为状态＃1或状态＃2）

The Availability status information is not linked with any particular user’s network connectivity situation (e.g. temporary loss of network connectivity, device switched off).
可用性状态信息不与任何特定用户的网络连接性情况链接（例如，网络连接的临时丢失，设备关闭）。

The RCS device and the Presence Server shall support the availability status feature.
RCS设备和存在服务器应支持可用性状态功能。

3.7.1.3.2 Favourite Link / 喜欢的链接

One of the attributes in the Social Presence Information allows the user to add or update one hypertext link, which (when selected) may redirect, for instance, to an extension of the user’s Social Presence Information (for example a mobile blog).
社交呈现信息中的属性之一允许用户添加或更新一个超文本链接，其（当被选择时）可以例如重定向到用户的社交呈现信息的扩展（例如移动博客）。

The user shall be able to edit the hypertext link (expressed as a Uniform Resource Identifier as defined in [RFC2396]).
用户应能够编辑超文本链接（表示为[RFC2396]中定义的统一资源标识符）。

A clickable link is displayed in a detailed view mode of the Social Presence Information, where shared information about the user (portrait icon, free text and URI) can be seen in larger size than in the EAB itself (list mode).
在社交呈现信息的详细视图模式中显示可点击的链接，其中可以以比EAB本身（列表模式）更大的尺寸来看见关于用户的共享信息（肖像图标，自由文本和URI）。

When the user edits a new hypertext link, those contacts, which the user has established a Social Presence Relationship with, are notified, that is a visual change of value of favourite link attribute, for example when the user updates their portrait icon or free text.
当用户编辑新的超文本链接时，已经与用户建立了社交呈现关系的那些联系人会得到通知，这是喜爱的链接属性值的视觉变化，例如，用户更新了他们的肖像图标或自由文本。

When a user clicks on the link of a presence-enriched contact, the appropriate native handler for linked content (for example browser) shall be launched.
当用户点击增强呈现的联系人的链接时，将启动用于链接内容的适当的本地处理程序（例如浏览器）。

When the user closes the handler, they return automatically to the presence enriched contact’s detailed view mode of the Social Presence Information, from where the handler was launched.
当用户关闭处理程序时，他们自动返回到增强呈现的联系人的社交呈现信息的详细视图模式，与处理程序被启动时一样。

A revoked contact shall not be able to click on the hypertext link. However, please note that there are no restrictions that prevent the watcher from being able to save the URI in their browser and further access to this URI.
撤销的联系人不能点击超文本链接。 但是，请注意，没有限制来阻止观察者能够保存在他们的浏览器中的URI和进一步访问这个URI。

It is possible to display a “user friendly” label for the favourite link instead of the actual URI. Instead of displaying the URI the RCS user can display a personal label. The maximum size of characters is 200 characters.
可以为喜爱的链接显示“友好的”标签而不是实际的URI。RCS用户可以显示个人标签来代替显示URI。 标签最大为200个字符。

3.7.1.3.3 Geolocation information / 地理位置信息

Geolocation information is a combination of declarative text always manually edited/updated by the user; and/or coordinate information (x, y) that is displayed on a map.
地理位置信息是声明性文本的组合，该文本总是由用户手动编辑/更新的; 和/或在地图上显示的坐标信息（x，y）。

The maximum character size of declarative location text information the end-user can enter shall not exceed 200 characters.
最终用户可以输入的声明性位置文本信息的最大字符大小不得超过200个字符。

Time Zones can be shared as part of geolocation information, allowing users to view what the local time is at their friend’s location.
时区可以作为地理位置信息的一部分进行共享，允许用户查看他们朋友所在位置的当地时间。

A provisioning parameter can be set in the network by Service Providers to control the maximum time the published location information will be considered to be valid (for example, one month).
可以由服务提供商在网络中设置配置参数，以控制公布的位置信息的最大有效时间（例如，一个月）。

The user must be able to delete his location information (empty text field, no position on map).
用户必须能够删除他的位置信息（空文本字段，在地图上没有位置）。

Location information must be interoperable between RCS clients no matter how users choose to update their information. For example, if User A has updated his location on a map (with x, y coordinates) and User B (authorised contact) is using RCS clients without a map feature (and only supporting declarative text), they must still be able to view User A’s location as a intelligible text, using the declarative text information (if available), not as raw x, y information.
无论用户如何选择更新他们的信息，位置信息必须在RCS客户端之间是可互操作的。 例如，如果用户A在地图（具有x，y坐标）上更新了他的位置，而用户B（授权联系人）正在使用没有地图功能（并且只支持声明性文本）的RCS客户端，他们仍然能够使用声明性文本信息（如果可用）以可理解的文本方式查看用户A的位置，而不是原始x，y信息。

To avoid excessive traffic on the network due to very frequent location updates, it is recommended that a provisioning parameter can be set in the network to remotely set a minimum duration between updates sent from the client/device.
为了避免由于非常频繁的位置更新而导致的网络上的过量流量，建议在网络中设置配置参数以远程地设置从客户端/设备发送的更新之间的最小持续时间。

The geolocation feature can be provided on non-GPS (Global Positioning System) enabled devices.
可以在启用非GPS（全球定位系统）的设备上提供地理定位功能。

3.7.1.4 Social Presence Authorisation / 社交呈现授权

RCS users shall feel confident in publishing their Social Presence Information, and be guaranteed that their privacy is respected. Therefore, mechanisms are defined below that allow users to accept/reject an invitation to establish a Social Presence Relationship, since this may imply sharing certain potentially private information, such as portrait icon or free text.
RCS用户应该放心的发布他们的社交媒体信息，并保证他们的隐私受到尊重。 因此，下面定义允许用户接受/拒绝建立社交呈现关系的邀请的机制，因为这可能意味着共享某些潜在的私人信息，诸如肖像图标或自由文本。

3.7.1.4.1 Social Presence Information sharing request principles / 社交呈现信息共享请求原则

Reactive authorisation shall be used, that is when User A invites User B to share Social Presence Information, User B receives an authorisation request.
应使用反作用授权，即当用户A邀请用户B共享社交呈现信息时，用户B接收授权请求。

When receiving an invitation to share Social Presence Information from User A, User B can:
当接收到来自用户A的共享社交呈现信息的邀请时，用户B可以：

• Accept the invitation.
  接受邀请。
• Ignore the invitation, which requires an explicit action by User B.
  忽略邀请，需要用户B执行明确操作。
• Block User A from sending more invitations.
  阻止用户A发送更多邀请。
• Not answer, that is do nothing with that request.
  不回应，即是对该请求什么也不做。

Invitation to share Social Presence Information automatically implies the authorisation of the requesting user, that is, when User A invites User B to share Social Presence Information, User A automatically authorises User B to see their Social Presence Information.
邀请共享社交呈现信息自动意味着请求用户的授权，即当用户A邀请用户B共享社交呈现信息时，用户A自动授权用户B查看他们的社交呈现信息。

If User A’s MSISDN is associated with a contact in User B’s address book, the name given to that contact shall be displayed within the invitation to share Social Presence Information.
如果用户A的MSISDN与用户B的通讯录中的联系人相关联，则给予该联系人的名称将显示在共享社交呈现信息的邀请中。

Symmetric authorisation shall be used. The publication of Social Presence Information shall be bidirectional.
应使用对称授权。 社交呈现信息的发布应是双向的。

User A shall not receive any notification whether User B has not answered, blocked or ignored their invitation to share Social Presence Information.
用户A不会收到任何通知，无论用户B是否不回应，阻止或忽略他们共享社交呈现信息的邀请。

Once a Social Presence Relationship has been established, the user can stop that relationship via the following action:
一旦建立了社交呈现关系，用户可以通过以下操作停止该关系：

• Revoke the Social Presence Relationship.
  撤销社交呈现关系。

3.7.1.4.2 Accept / 接受

If User B accepts User A’s invitation to share Social Presence Information, User A will see User B’s Social Presence Information, and User B will see User A’s Social Presence Information.
如果用户B接受用户A的共享社交呈现信息的邀请，则用户A将看到用户B的社交呈现信息，并且用户B将看到用户A的社交呈现信息。

If User A is not an existing contact in User B’s address book, it shall be facilitated that User B stores the contact details of User A in their address book.
如果用户A不是用户B的通讯录中的现有联系人，则应当方便用户B将用户A的联系细节存储在他们的通讯录中。

3.7.1.4.3 Ignore / 忽略

If User B ignores User A’s invitation to share Social Presence Information, neither User A nor User B shall be able to see each other’s Social Presence Information.
如果用户B忽略用户A的共享社交呈现信息的邀请，则用户A和用户B都不能够看到彼此的社交呈现信息。

Ignoring an invitation to share Social Presence Information shall not mean blocking the contact that has sent the invitation, i.e. it shall still be possible to receive more invitations from that contact.
忽略分享社交呈现信息的邀请不应意味着阻止已发送邀请的联系人，即，仍然可以从该联系人接收更多邀请。

If User B ignores User A’s invitation to share Social Presence Information but later, User B decides to share their Social Presence Information with User A, then it is not necessary that a new authorisation request is issued to User A. User B, by adding User A to their EAB completes the symmetric authorisation process. As a result, User A and User B will be seeing each other’s Social Presence Information.
如果用户B忽略用户A的共享社交呈现信息的邀请，但是稍后，用户B决定与用户A共享他们的社交呈现信息，则不需要向用户A发出新的授权请求。用户B，通过添加用户 A到他们的EAB完成对称授权过程。 结果，用户A和用户B将看到彼此的社交呈现信息。

3.7.1.4.4 Block (refuse to receive any further invitation) / 阻止（拒绝接收任何进一步的邀请）

In order not to receive more invitations from a certain contact, the user shall be given the possibility to add that contact to a list of blocked contacts (blacklist).
为了不收到来自某个联系人的更多邀请，用户应该能够将该联系人添加到被阻止的联系人列表（黑名单）。

The blocking mechanism shall be transparent to the blocked user, that is, if User B blocks User A, User A shall never be notified that he/she has been blocked by User B.
阻止机制对被阻止的用户是透明的，也就是说，如果用户B阻止用户A，则用户A不会被通知他/她已被用户B阻止。

The possibility shall be given to remove a certain contact from the blacklist, i.e. User B shall be able to see in their EAB that User A has been blocked and to remove them from the blacklist.
应该给出从黑名单中移除某个联系人的可能性，即用户B应该能够在他们的EAB中看到用户A已被阻止并将其从黑名单中移除。

3.7.1.4.5 Not answer (pending invitation) / 不应答（待处理邀请）

If User B does not answer User A’s invitation to share Social Presence Information, the invitation shall be in a pending state, for which an action is expected by User B.
如果用户B没有回答用户A的共享社交呈现信息的邀请，则邀请将处于待定状态，等待用户B的下一步动作。

Pending invitations to share Social Presence Information with User A, for which an answer has not yet been provided, shall be accessible for User B, so that User B can choose to answer the invitation that is Accept, Ignore or Block.
用户A共享社交呈现信息的待定邀请，在尚未提供答案的情况下，对于用户B是可访问的，使得用户B可以选择回答接受，忽略或阻止该邀请。

Subsequent invitations (from User A to User B) replaces User A's initial invite, and function as a reminder for User B that a corresponding action (on their part) regarding the invitation to share SPI is required. That is, User B needs to choose an option
随后的邀请（从用户A到用户B）将替换用户A的初始邀请，并且这一功能用作对用户B的提醒，用户B对关于共享SPI的邀请必须做出相应动作（在他们的部分上）。 也就是说，以下选项中，用户B需要选择一个

• Accept, / 接受，
• Ignore, or / 忽略，或
• Block. / 阻止。

3.7.1.4.6 Revoke / 撤消

Once a Social Presence Relationship has been established, the possibility shall be given to stop the sharing of Social Presence Information with a certain contact, while at the same time removing your Social Presence Information from that contact’s EAB.
一旦建立了社交呈现关系，就应该给予停止与某个联系人共享社交呈现信息的可能性，停止同时从该联系人的EAB中删除您的社交呈现信息。

If User A revokes the Social Presence Relationship with User B, both users shall not receive any further updates of their Social Presence Information, according to the symmetry principle.
如果用户A撤销与用户B的社交呈现关系，则根据对称原则，两个用户将不会接收到他们的社交呈现信息的任何进一步更新。

When User A revokes the Social Presence Relationship with User B, User B shall no longer be displayed as a presence enriched contact.
当用户A撤消与用户B的社交呈现关系时，用户B不再被显示为存在增强呈现的联系人。

User B’s Social Presence Information shall not be shown to User A
用户B的社交呈现信息不向用户A显示

Only User B’s contact details (vCard) shall remain visible in User A’s address book (for example name, MSISDN, e-mail, and so on.
只有用户B的联系方式（vCard）在用户A的通讯簿中保持可见（例如姓名，MSISDN，电子邮件等）。

If User A revokes the Social Presence Relationship with User B, User B shall no longer have access to User A’s Social Presence Information.
如果用户A撤销与用户B的社交呈现关系，则用户B将不再能够访问用户A的社交呈现信息。

Before actually performing the revoke, User A shall see a notification alert in the client informing him about consequences of this action. These are:
在实际执行撤销之前，用户A将在客户端看到通知警报，通知他此操作的后果。 这些是：

• User A’s Social Presence Information will be removed from User B’s EAB, so User B will notice the revoke after a certain period of time (for example several hours/days)
  用户A的社交呈现信息将从用户B的EAB中移除，因此用户B将在一段时间（例如几小时/天）后注意到撤销，
• It will be possible for User A and User B to invite each other again.
  用户A和用户B可以再次相互邀请。

After a Social Presence Relationship has been revoked for a given period of time (for example several hours/days), both users can reinitiate the process of Social Presence Authorisation, that is User A shall be able to invite User B to share Social Presence Information and vice versa.
在社交呈现关系已经被撤销超过给定时间段（例如几小时/天）之后，两个用户可以重新启动社交呈现授权的过程，即，用户A将能够邀请用户B共享社交呈现信息，反之亦然。

It must be noted that User A may immediately re-invite User B to share Social Presence Information.
必须注意的是，用户A可以立即重新邀请用户B共享社交呈现信息。

If User A deletes User B’s vCard from their address book, all contact information is deleted from User A’s address book. If a Social Presence Relationship between User A and User B exists at the moment of deleting the contact, this relationship shall be revoked.
如果用户A从他们的地址簿中删除用户B的vCard，则从用户A的地址簿中删除该联系人的所有信息。 如果在删除联系人时存在用户A和用户B之间的社交呈现关系，则该关系将被撤销。

3.7.1.4.7 Personalised Invitation / 个性化邀请

To improve RCS invitation experience with a personalised invitation and to ease identification of invitations coming from contacts not yet registered in the user’s address book, a nickname feature is provided:
为了改进具有个性化邀请的RCS邀请体验，并且简化来自尚未在用户的地址簿中注册的联系人的邀请的识别，提供昵称特征：

• If the terminal supports configuring a nickname, the user can choose a “nickname” with limited size (recommendation: 20 characters, this size can be set as a provisioning parameter). This nickname is provided in all future invitations to share presence, until it is changed. The maximum number of characters an invitee can view is 200 (this limitation is proposed to ensure interoperability for invitee, regardless of the number of characters implemented by the service provider).
  如果终端支持配置昵称，则用户可以选择有限大小的“昵称”（建议：20个字符，此大小可以设置为配置参数）。 此昵称在未来所有邀请中提供，以便共享在线状态，直到更改为止。 被邀请者可以查看的最大字符数为200（提议此限制是为了确保被邀请者的互操作性，而不管服务提供商实现的字符数）。
• The invitee, if they do not have the inviter information in their address book, can now see both MSISDN and the nickname of the inviter.
  被邀请者，如果他们在他们的地址簿中没有邀请者信息，现在可以看到MSISDN和邀请者的昵称。
• The nickname is stored permanently to be used for every invitation. Users have the ability to change it every time they send an invitation.
  昵称将被永久存储并可用于每个邀请。 用户每次发送邀请时都可以更改它。
• The nickname does not replace the registered name of a contact already present in the recipient’s address book.
  昵称不会替换已存在于收件人通讯录中的联系人的注册名称。

Security: it is noted that through the use of the nickname, it is possible to “impersonate” someone. However, that “impersonation” is limited in scope since the inviting user remains identified by his MSISDN and the fact that the feature is only used for MSISDNs that are not already stored in the recipient’s address book.
安全性：可以注意到通过使用昵称，可以“假冒”某人。 然而，“假冒”在范围上是有限的，因为邀请用户仍然由他的MSISDN识别，以及该特征仅用于尚未存储在接收者的地址簿中的MSISDN这一事实。

3.7.1.4.8 Geolocation authorisation / 地理位置授权

Two users should be able to see where they are located and share this information with each other and they would keep the control over this information:
两个用户应该能够看到他们所在的位置并且彼此共享该信息，并且他们将保持对该信息的控制：

• No specific invitation process for location.
  位置信息没有的特定邀请过程。
• When and if a user chooses (by opt-in) to update their location for the first time, by default, users do not share their location information with all their contacts authorised for social presence.
  当用户首次选择（通过选择加入）更新其位置时，默认情况下，用户不会与其所有获准参与社交呈现的联系人共享他们的位置信息。
• Users have the ability to manually choose contacts with whom they wish to share location information.
  用户能够手动选择他们希望与其共享位置信息的联系人。
• Even if a user is not sharing location information with one of their authorised contacts, that does not prevent them from viewing that contact’s location information.
  即使用户不与他们的授权联系人之一共享位置信息，也不会阻止他们查看该联系人的位置信息。

Once User A has accepted User B as an RCS authorised contact, User B will be able to see the geolocation information of User A (displayed with a text or a map, or both of them) and all updates of that information.
一旦用户A接受用户B作为RCS授权联系人，用户B将能够看到用户A的地理位置信息（用文本或地图或两者显示）以及该信息的所有更新。

When a given RCS user (User A) is willing to share Social Presence with another user, User A shall be able to control in the invitation process for sharing Social Presence whether sharing of their location information with this other user is authorised or not.
当给定的RCS用户（用户A）愿意与另一个用户共享社交呈现时，用户A将能够在用于共享社交呈现的邀请过程中控制是否与该其他用户共享他们的位置信息是否被授权。

3.7.1.4.9 VIP contacts / VIP联系人

As the number of SPI enabled contacts increases in the user’s address book, the amount of information that the user receives in the mobile phone will increase making it more difficult to differentiate useful information from noise. In addition, the RCS users will not want to share the same Social Presence Information with all their contacts.
随着用户的地址簿中SPI使能的联系人的数量增加，用户在移动电话中接收的信息量将增加，使得更难以区分有用信息和噪声。 此外，RCS用户不想与他们的所有联系人共享相同的社交呈现信息。

The selection of certain contacts as Very Important Person (VIP) contacts will allow the end user to specify which contacts are the most important ones.
将某些联系人选择为非常重要的人（VIP）联系人将允许最终用户指定哪些联系人是最重要的联系人。

The user should be able to differentiate the contacts, which they share SPI with, between important and unimportant contact. The user shall receive real time notification of status changes from VIP contacts.
用户应该能够在重要和不重要的联系人之间区分它们与之共享SPI的联系人。 用户应从VIP联系人接收状态更改的实时通知。

The user will be able to choose from the contacts to set them as VIP contacts. The user will then only receive real time notifications of the social presence information from the contacts set as VIP contacts (probably with a phone buzz or light, or via an idle screen widget and so on). The contacts that are not set as VIP contacts will still be updated in the EAB, but not in real time, therefore, the user is made aware of the new social presence information when they browse the EAB.
用户将能够从联系人中进行选择以将其设置为VIP联系人。 然后，用户将仅从被设置为VIP联系人的联系人接收社交呈现信息的实时通知（可能具有电话嗡嗡声或光，或者通过空闲屏幕小部件等）。 未设置为VIP联系人的联系人将仍然在EAB中更新，但不是实时地更新，因此，当他们浏览EAB时，用户被告知新的社交呈现信息。

3.7.1.5 Example Use Cases / 示例用例

3.7.1.5.1 Social Presence Information Use Cases / 社交呈现信息使用案例

3.7.1.5.1.1 Invite Contacts to Share Social Presence /

Figure 81: Invite Contacts to Share Social Presence / 图81：邀请联系人分享社交呈现

Authorisation to share social presence is based on the symmetry principle. If sharing of social presence is accepted after invitation, both parties will see each other’s presence attributes. If social presence sharing is terminated by one of both parties, both parties will end seeing each other’s social presence attributes.
共享社交呈现的授权是基于对称原理。如果在邀请之后接受社交呈现的共享，则双方将看到彼此的呈现属性。 如果社交呈现共享由双方之一终止，则双方将终止看到彼此的社交呈现属性。

It is possible to share with an invitation for social presence a nickname if the invited party does not have the inviting party’s phone number in the device.
如果被邀请方在设备中没有邀请方的电话号码，则可以与社交呈现的邀请共享昵称。

3.7.1.5.1.2 Allow Contacts to obtain Location Information / 允许联系人获取位置信息

Figure 82: Share Location / 图82：共享位置

This service allows users to show where they are through the RCS EAB and view where their friends are as free text and/or on a map.
此服务允许用户通过RCS EAB显示他们在哪里，并以自由文本和/或在地图的方式查看他们的朋友所在位置。

NOTE: If the contact that is updated but not in the VIP group, the information (Richard Aitken in the use case) in their VIP group may not be seen immediately. They will only see it when either their client polls for updates of the non-VIP contacts or when they request for an update of the non-VIP contacts themselves. The user may even miss the update altogether if there is another update before the status of the non-VIP contacts is retrieved.
注意：如果位置更新的联系人不在VIP组中，则其VIP组中的信息（用例中的Richard Aitken）可能不会立即显示。 只有当他们的客户端轮询非VIP联系人的更新，或者他们请求更新非VIP联系人时，他们才会看到。 如果在检索非VIP联系人的状态之前存在另一更新，则用户甚至可能错过更新。

3.7.1.5.1.3 Availability / 可用性

Figure 83: Availability / 图83：可用性

NOTE: If the contact that is updated is not part of the VIP group of the user the updated SPI (Richard Aitken’s in the use case) may not be seen immediately. They will only see it when either their client polls for updates of the non-VIP contacts or when they request for an update of the non-VIP contacts themselves. The user may even miss the update altogether if there is another update of the availability status before the status of the non-VIP contacts is retrieved.
注意：如果更新的联系人不是用户的VIP组的一部分，则用户可能不会立即看到更新的SPI（用例中的Richard Aitken）。 他们只有当客户端轮询非VIP联系人的更新或者他们请求更新非VIP联系人信息时才会看到。 如果在检索非VIP联系人的状态之前存在可用性状态的另一更新，则用户甚至可能错过更新。

3.7.1.5.1.4 Free Text / 自由文本

Figure 84: Free Text / 图84：自由文本

NOTE: If the contact that is updated is not part of the VIP group of the user, the updated SPI (Richard Aitken’s in the use case) may not be seen immediately. They will only see it when either their client polls for updates of the non-VIP contacts or when they request for an update of the non-VIP contacts themselves. The user may even miss the update altogether if there is another update before the status of the non-VIP contacts is retrieved.
注意：如果更新的联系人不是用户的VIP组的一部分，则用户可能不会立即看到更新的SPI（用例中的Richard Aitken）。 他们只有当客户端轮询非VIP联系人的更新或者他们请求更新非VIP联系人时才会看到。 如果在检索非VIP联系人的状态之前存在另一更新，则用户甚至可能错过更新。

3.7.1.5.1.5 Portrait Icon Exchange / 头像图标交换

Figure 85: Portrait Icon Exchange / 图85：头像图标交换

NOTE: If the contact that is updated is not part of the VIP group of the user the updated SPI (Richard Aitken’s in the use case) may not be seen immediately. They will only see it when either their client polls for updates of the non-VIP contacts or when they request for an update of the non-VIP contacts themselves. The user may even miss the update altogether if there is another update before the status of the non-VIP contacts is retrieved.
注意：如果更新的联系人不是用户的VIP组的一部分，则可能不会立即看到更新的SPI（用例中的Richard Aitken）。 他们只有当客户端轮询非VIP联系人的更新或者他们请求更新非VIP联系人时才会看到。 如果在检索非VIP联系人的状态之前存在另一更新，则用户甚至可能错过更新。

3.7.1.5.1.6 Who Can I Invite? / 我可以邀请谁？

New user wants to invite their friends to share social presence.
新用户想邀请他们的朋友分享社交呈现。

• User A goes to their RCS enhanced address book.
  用户A转到他们的RCS增强的地址簿。
• User A traverses through the list of contacts and sees that User B is also an RCS user that supports the SPI service based on the capability discovery mechanism defined in section 2.6.
  用户A遍历联系人列表，并且基于第2.6节中定义的能力发现机制，看到用户B也是支持SPI服务的RCS用户。
• User A decides to send an invitation to share Social Presence Information to User B.
  用户A决定发送邀请以向用户B共享社交呈现信息。

3.7.1.5.2 Personalised Invitation with a Nickname / 带有昵称的个性化邀请

3.7.1.5.2.1 User A invites User B and fills out their Nickname. User A is present in User B’s address book / 用户A邀请用户B并填写其昵称。 用户A出现在用户B的通讯录中

• When User B receives the invitation, it is the contact name entered in User A’s v-card that is used, not the nickname.
  当用户B接收到邀请时，使用的是用户A的v-card中输入的联系人姓名，而不是昵称。
• For example, User B can read “<User A v-card name> <MSISDN> wants to share presence information with you.”
  例如，用户B可以读取“<用户A v-card名称> <MSISDN>要与您共享呈现信息”。

3.7.1.5.2.2 User A invites User B and fills out their Nickname. User B has not created a contact card for User A in their address book

• When User B receives the invitation, the nickname is used to present the invitation to User B
  当用户B接收到邀请时，昵称用于向用户B呈现邀请
  • For example, User B can read “<User A nickname> <MSISDN> wants to share presence information with you.”
    例如，用户B可以读取“<用户A昵称> <MSISDN>要与您共享在线信息”。
• If User B accepts the invitation, a contact card is created. User A’s nickname can be used to reference the contact card in User B’s address book.
  如果用户B接受邀请，则创建联系人卡片。 用户A的昵称可用于引用用户B的通讯录中的联系人卡片。

3.7.1.5.3 Geolocation / 地理位置

3.7.1.5.3.1 Manual Free Text / 手动自由文本

• User A set his location manually (for example, I am in Paris).
  用户A手动设置他的位置（例如，我在巴黎）。
• User B sees that User A is in Paris.
  用户B看到用户A在巴黎。

3.7.1.5.3.2 Manual Position on a Map / 手动在地图上的位置

• User A decides to update their current location. User A drags and drops a pin on a map and then confirms the position. Even though User A is located in Paris, France, they select New York as a location on the map.
  用户A决定更新其当前位置。 用户A在地图上拖放一个图钉，然后确认位置。 即使用户A位于法国巴黎，他们也选择纽约作为地图上的位置。
• User B receives a notification.
  用户B接收通知。
• User B sees that User A is in New York.
  用户B看到用户A在纽约。

3.7.1.5.3.3 Semi-Automatic Filling / 半自动填充

User A decides to edit their current location status. User A selects the location update button, and their location is automatically filled in the dedicated field used to enter their location.
用户A决定编辑其当前位置状态。 用户A选择位置更新按钮，并且他们的位置被自动填充在用于输入他们的位置的专用字段中。

3.7.1.5.3.4 Fully Automatic Opt-In Mode / 全自动选择模式

User A decides that they want their authorised contacts to be informed regarding their position on a regular basis (period to be defined), they click on the “authorise my contacts to view my location” button (opt in). If they decide to end this broadcast they always have the ability to opt out through the same button.
用户A决定希望他的经授权的联系人定期被通知他的位置（要定义的时间段），需要他点击“授权我的联系人查看我的位置”按钮（选择加入）。 如果他决定结束这个广播，总是可以通过同一个按钮退出。

In all cases, User B (authorised contact in User A’s address book) is notified as he would be notified of other presence information, such as status text.
在所有情况下，用户B（作为用户A的地址簿中的授权联系人）将被通知，如同他将被通知诸如状态文本等其他存在信息一样。

3.7.1.5.3.5 Blocking an Authorised Contact from Viewing Location / 阻止授权联系人查看位置

• User A and B are authorised RCS contacts who have updated their location information.
  用户A和B是已更新其位置信息的授权RCS联系人。
• User A decides to hide their location from User B, while still sharing it with his other authorised contacts.
  用户A决定对用户B隐藏他的位置，但同时仍与他的其他授权联系人共享位置。
• User A goes to his location settings currently set to “Share my location with all my authorised contacts” to “Prevent some authorised contacts from viewing my location”.
  用户A转到他当前的位置设置，将“与我的所有授权联系人共享我的位置”设置为“防止一些授权的联系人查看我的位置”。
• User A adds User B in the list of contacts blocked from viewing their location.
  用户A在被阻止查看其位置的联系人列表中添加用户B.
• User B does not see User A’s location information anymore.
  用户B不再看到用户A的位置信息。
• User A still sees User B’s location.
  用户A仍然看到用户B的位置。

3.7.1.5.4 VIP Contacts / VIP联系人

3.7.1.5.4.1 User sets a contact as a VIP / 用户将联系人设置为VIP

User A is an RCS user.
用户A是RCS用户。
User B is an RCS user.
用户B是RCS用户。
User A and User B had established a Social Presence Information sharing relationship.
用户A和用户B建立了社交呈现信息共享关系。

Call Flow:
呼叫流程：

• User A sets User B Contact as a VIP contact in their address book.
  用户A将用户B联系人设置为他们的通讯录中的VIP联系人。
• User B changes their Social Presence Information.
  用户B改变他们的社交呈现信息。
• User A receives an active notification (phone buzz or light, idle screen widget) about the change.
  用户A接收关于改变的活动通知（电话蜂鸣或光，空闲屏幕小部件）。

3.7.1.5.4.2 User sets a contact as a non-VIP / 用户将联系人设置为非VIP

User A is an RCS user.
用户A是RCS用户。
User B is an RCS user.
用户B是RCS用户。
User A and User B had established a Social Presence Information sharing relationship.
用户A和用户B建立了社交呈现信息共享关系。
User A had previously set User B as a VIP contact.
用户A先前将用户B设置为VIP联系人。

Call Flow:
呼叫流程：

• User A sets User B Contact as a non-VIP contact in their address book.
  用户A在他的地址簿中将用户B设置为非VIP联系人。
• User B changes their Social Presence Information.
  用户B改变他的社交呈现信息。
• User A does not receive any active notification about the change but if they access later their EAB and browse to the User B contact, the EAB will display the changed information.
  用户A未收到有关更改的任何活动通知，但如果他以后访问其EAB并浏览到用户B联系人，EAB将显示更改的信息。

3.7.2 Interaction with other RCS features / 与其他RCS功能的交互

Social Presence information in the device is linked with the local address book available in the device:
设备中的社交呈现信息与设备中可用的本地地址簿相链接：

The social information elements of a contact in an RCS device are, from user interface point of view, associated (as an extension of other address book contact information) with the contact entry of the address book.
RCS设备中的联系人的社交信息元素从用户界面的角度来看与地址簿的联系人条目相关联（作为其他地址簿联系人信息的扩展）。

This correlation is local:
这种相关性是本地的：

• Local contact information may be synchronised with a Network address book
  本地联系人信息可以与网络地址簿同步
• Extended presence information is obtained through the Network Presence enabler.
  通过网络呈现使能器获得扩展呈现信息。

3.7.3 High Level Requirements / 高级别要求

3-7-1 An RCS user with broadband access shall be able to access the Enhanced Address Book, supporting all the social presence features.
3-7-1 具有宽带接入的RCS用户应能够访问增强型地址簿，支持所有的社交呈现功能。
3-7-2 A broadband access client should support Social Presence Authorisation.
3-7-2 宽带接入客户端应支持社交呈现授权。
3-7-3 The presentity shall be able to edit the Social Presence Information from any of the devices he/she has and shall see the changes from every device he/she has.
3-7-3 存在体应能够从他/她拥有的任何设备编辑社交呈现信息，并且应当从他/她拥有的每个设备看到改变。
3-7-4 Social Presence Information shall be handled in such a way that the latest update is presented to the watching user's client.
3-7-4 社交呈现信息应以最新更新呈现给观看用户的客户端的方式处理
3-7-5 The invitation to share Social Presence Information shall be shown in all of the presentity’s devices.
3-7-5 共享社交媒体信息的邀请应显示在所有在线实体的设备中
3-7-6 The presentity shall be able to authorise watchers from any of the devices they have
3-7-6 存在体应能够从拥有的任何设备上授权给观察者
3-7-7 If a certain setting may limit the user experience provided to the end user, this information should be clearly shown in the user interface. In addition this allows the user to be aware of this limit while interacting with the service (for example, maximum number of characters to be included in the free text of the Social Presence Information, or maximum size of a file to be transferred).
3-7-7 如果某个设置可能限制提供给最终用户的用户体验，则该信息应该清楚地显示在用户界面中。 此外，这允许用户在与服务交互时知道该限制（例如，要包括在社交呈现信息的自由文本中的最大字符数，或要传送的文件的最大大小）。
3-7-8 The User shall be able to share location information as social presence information with his/her authorised contacts.
3-7-8 用户应能够与他/她的授权联系人共享位置信息作为社交呈现信息。
3-7-9 The User shall be able to define a list of contacts blocked from viewing his/her location information, within his list of authorised contacts for presence.
3-7-9 用户应能够在其授权联系人列表中定义阻止查看他/她的位置信息的联系人列表。
3-7-10 The User shall be able to specify their location through manual or automatic modes, as free text or as coordinates on a map.
3-7-10 用户应能够通过手动或自动模式指定其位置，如自由文本或地图上的坐标。
3-7-11 The User shall be able to de-activate automatic updates or delete their location information at any time, to protect their privacy.
3-7-11 用户应能够随时取消激活自动更新或删除其位置信息，以保护他们的隐私。
3-7-12 The User shall be able to share location information even if he/she is using a non- GPS device
3-7-12 即使用户使用非GPS设备，用户也能够共享位置信息
3-7-13 The Service Provider shall be able to limit the frequency of automatic updates to avoid network overload.
3-7-13 服务提供商应能限制自动更新的频率，以避免网络过载。
3-7-14 The RCS user shall be able to set an expiration date for location information.
3-7-14 RCS用户应能够设置位置信息的到期日期。
3-7-15 The User shall be able to define a nickname transmitted to his contacts when sending invitations, in addition to the MSISDN.
3-7-15 除了MSISDN，用户还能够定义发送邀请时发送给他的联系人的昵称。
3-7-16 The User shall be able to change that nickname at any time, especially before sending invitations.
3-7-16 用户可以随时更改昵称，尤其是在发送邀请之前。
3-7-17 The Service Provide shall be able to specify the maximum length of the nickname.
3-7-17 服务提供者应能够指定昵称的最大长度。
3-7-18 The Nickname shall never automatically replace the existing registered name of a contact in the invitation recipient’s phonebook.
3-7-18 昵称永远不会自动替换邀请收件人电话簿中联系人的现有注册名称。
3-7-19 The User shall be able to specify a text label displayed in lieu of the personal URL.
3-7-19 用户应能够指定显示的文本标签来代替个人URL。
3-7-20 The User shall be able to change the URL label at any time.
3-7-20 用户应能随时更改URL标签。
3-7-21 Void.
3-7-21 空。
3-7-22 An RCS user shall be able to set a contact as a VIP contact.
3-7-22 RCS用户应能够将联系人设置为VIP联系人。
3-7-23 An RCS user shall be able to unset a contact as VIP.
3-7-23 RCS用户应能够撤消联系人为VIP。
3-7-24 When a VIP contact updates his Social Presence Information the user shall get a real time notification of the change and it shall be displayed on the RCS client (phone buzz or light indication, idle screen widget).
3-7-24 当VIP联系人更新其社交呈现信息时，用户将得到实时通知的更改，并且它将显示在RCS客户端上（电话蜂鸣或指示灯，空闲屏幕窗口小部件）。
3-7-25 When a non-VIP contact updates their Social Presence Information, the user shall not be notified in real time about the changed status. The RCS client shall keep that information up to date (but not in real time) so the contact information is updated when the user browses the EAB.
3-7-25 当非VIP联系人更新其社交呈现信息时，不会实时通知用户更改的状态。 RCS客户端应保持该信息是最新的（但不是实时的），以便在用户浏览EAB时更新联系信息。
3-7-26 The update mechanism for updating non VIP contacts shall be a periodic polling mechanism from the RCS client resulting in an aggregated notification from the network. The update period shall be configured by the RCS Service Provider by parameter.
3-7-26 更新非VIP联系人的更新机制应是来自RCS客户端的周期性轮询机制，从而产生来自网络的聚合通知。 更新周期应由RCS服务提供商通过参数配置。
3-7-27 In addition, an RCS user shall be able to manually request an update of all the non- VIP contacts.
3-7-27 此外，RCS用户应能够手动请求更新所有非VIP联系人。

3.7.4 Technical Realisation / 技术实现

3.7.4.1 Network architecture of Presence enabler in RCS / 在RCS中的呈现启用器的网络体系结构

Figure 86: Overall Architecture of Presence as a part of RCS / 图86：作为RCS的一部分的整体架构

Figure 87: RCS Presence Architecture / 图87：RCS呈现架构

Presence and capability architecture in RCS is based on [Presence].
RCS中的呈现和能力体系结构基于[Presence]。

Users share their Social Presence Information (“Presence Enhanced Address Book”).
用户共享他们的社交呈现信息（“呈现增强的地址簿”）。

• Implemented using the Presence SIMPLE protocol
  使用Presence SIMPLE协议实现

Users share their communication capability information (“Capability Enhanced Address Book”).
用户共享其通信能力信息（“能力增强的地址簿”）。

• Can be implemented using the Presence SIMPLE protocol (see section 2.6.1.2).
  可以使用Presence SIMPLE协议实现（见第2.6.1.2节）。

According to [PRD-IR.65], the interworking connection should be carried out via IMS core systems. There is, therefore, no requirement to interface Presence Servers directly.
根据[PRD-IR.65]，互通连接应通过IMS核心系统进行。 因此，不需要直接连接Presence服务器。

Optimisation of Presence & XDM enabler according to work in OMA PAG working group has to be taken into account as a very important design principle. It is also important to notice potential issues such as battery drain in the terminal caused by the general always- on functionality and the number of Presence & capability updates.
根据OMA PAG工作组的工作，优化Presense和XDM使能器必须作为一个非常重要的设计原则被考虑在内。 注意到潜在的问题也很重要，举例来说，终端中的电池消耗可能由于由一般的常驻后台功能和Presence及能力更新次数太多造成。

Generally, the Shared XDMS (XDM server) as defined in [XDM1.1_AD] shall be used for storing all presence-related lists, for example, the list of subscribed contacts (“buddy” list) and the presence authorisation lists. In this way, the RCS client only needs to operate on lists in Shared XDMS, and initially set the documents in RLS (Resource List Server) XDMS and Presence XDMS.
通常，如[XDM1.1_AD]中定义的共享XDMS（XDM服务器）将用于存储所有呈现相关列表，例如订阅的联系人列表（“好友”列表）和呈现授权列表。 这样，RCS客户端只需要对共享XDMS中的列表进行操作，并且最初在RLS（资源列表服务器）XDMS和在线状态XDMS中设置文档。

3.7.4.2 Presence Data Model / 呈现数据模型

3.7.4.2.1 Overview / 概述

Implementation guidelines for the size/length of Presence information elements given in [PRESENCEIG] should be followed.
应遵循[PRESENCEIG]中给出的呈现信息元素的大小/长度的实施指南。

The following sections illustrate the details of the Person and Device parts of the Presence Data Model. The Service part of the model has been described in section 2.6.1.2.5.
以下部分说明了Presence数据模型的Person和Device部分的详细信息。 模型的服务部分已在第2.6.1.2.5节中描述。

3.7.4.2.2 Person / 个人

Table 45: Presence data model attributes / 表45：呈现数据模型属性

NOTE1: “Willingness” is sometimes indicated in a client as “Availability”. However, since it is managed by the user themselves and does not imply that communication is not possible within OMA specifications, this is considered as willingness. Availability indicates that on a technical level communication will be possible. Service Availability and Willingness are study items for later releases.
注意1：“意愿”有时在客户端中表示为“可用性”。 然而，由于它由用户自己管理，并且在OMA规范内并不暗示着不可能进行通信，因此这被认为是意愿。 可用性表示在技术水平上通信将是可能的。 服务可用性和意愿是更新版本的研究项目。

NOTE2: The priority of 0.8 for the link was included to allow including links with higher priority in some future RCS release.
注2：链路的优先级0.8被包括在内，以允许具有较高优先级的链路在将来的某个RCS版本中被包括在内。

3.7.4.2.2.1 Willingness / 意愿

The RCS client will include in the presence document an OMA <overriding-willingness> element as specified in [Presence2.0_DDS] with the <basic> sub-element set to “closed” when the user has indicated that he’s not willing to communicate. Otherwise, if willingness is enabled, the published presence document will indicate a value of “open” for the <basic> sub-element of <overriding-willingness>.
RCS客户端将在呈现文档中包括在[Presence2.0_DDS]中指定的OMA <overriding-willingness>元素，当用户已经指示他不愿意通信时，将<basic>子元素设置为“closed”。 否则，如果启用意愿，则发布的呈现文档指示将为<overriding-willingness>的<basic>子元素设置“open”值。

3.7.4.2.2.2 Icon / 图标

The icon shall have following characteristics:
图标应具有以下特点：

Table 46: Characteristics of the icon / 表46：图标的特性

NOTE1: Fixing the icon document name will ensure that for RCS usage, a single icon is stored in the network and no unnecessary resources are required for the storage of multiple icons. Without this, the situation could occur that multiple icons are stored without possibility to manage them after a switch to a new client. Furthermore, the fixing of the icon name will allow clients that are aware of the SIP URI of their contact to build the URI needed for the retrieval of the icon even if the contact is offline.
注意：修复图标文档名称将确保对于RCS使用，网络中仅存储单个图标，并且不需要那些不必要的资源来存储多个图标。 如果不是这样，可能会出现多个图标在切换到新客户端后无法管理的情况。 此外，固定图标名称将允许知道他们的联系人SIP URI的客户端构建用于检索图标所需的URI，即使在联系人离线的情况下。

NOTE2: 200KB is not a mandatory size. It is only defined as a maximum and smaller sizes are acceptable
注2：200KB不是强制大小。 它只被定义为最大值，更小的尺寸是可以接受的

The other parameters are fixed to allow the client implementations to know what to expect.
其他参数是固定的，以允许客户端实现知道预期什么。

3.7.4.2.2.3 Location Information / 位置信息

RCS clients shall not include a “from” attribute in the <place-type> and <time-offset> elements. RCS clients shall ignore it when received. RCS clients shall provide an "until" attribute in those elements and set it as specified in section 3.7.4.3.2.4.2.
RCS客户端不应在<place-type>和<time-offset>元素中包含“from”属性。 RCS客户端将在接收时忽略它。 RCS客户端应在这些元素中提供一个“until”属性，并按第3.7.4.3.2.4.2节的规定进行设置。

RCS clients shall not include the optional description attribute in the <time-offset> element as this overlaps with the Location Type. RCS clients shall ignore it when received.
RCS客户端不应在<time-offset>元素中包含可选描述属性，因为它与位置类型重叠。 RCS客户端将在接收时忽略它。

The geographical information will be provided as geographic coordinates. As specified for the “Geographical Location” building block in [Presence2.0_DDS], encoding will use the <geopriv>-><location-info> and <geopriv>-><usage-rules> elements.
地理信息将作为地理坐标提供。 如[Presence2.0_DDS]中的“地理位置”构建块所指定，编码将使用<geopriv>-><location-info>和<geopriv>-><usage-rules>元素。

The mandatory <usage-rules> element shall contain only a "retention-expiry" element as RCS clients will request the watchers to follow the default handling for the other rules. The RCS client shall set the "retention-expiry" as specified in section 3.7.4.3.2.4.2.
强制的<usage-rules>元素应该只包含“retention-expiry”元素，因为RCS客户端将请求观察者遵循其他规则的默认处理。 RCS客户端应设置3.7.4.3.2.4.2节中规定的“retention-expiry”。

The <location-info> published by an RCS presence source will contain geographical information using the GML (Geography Markup Language) 3.1.1 Feature Schema (see [GML3.1.1]) which is the mandatory format to be used in the <location-info> element. The civic location format shall not be used by RCS presence sources and location information encoded in that way will be ignored by RCS clients when received.
由RCS呈现源发布的<location-info>将使用GML（地理标记语言）3.1.1中的特征模式（见[GML3.1.1]）来包含地理信息，这是用在<location-info>元素中的规定的格式。 公民位置格式不应被RCS呈现源使用，并且以这种方式编码的位置信息在被接收时将被RCS客户端忽略。

RCS presence sources will within the <location-info> element represent an exact position by providing a GML <point> element and an inaccurate position as a <circle> element, both referring to the EPSG::4326 spatial reference schema as described in [RFC5491]. The coordinates of either the centre of this circle or the exact position will be represented with a single GML <pos> element with the actual coordinates as value. The radius of the circle will be represented in meters, which will be indicated by setting the unit of measure attribute of the radius element to the value of EPSG::9001 as described in [RFC5491]. An RCS client shall ignore any other type of data provided in the <location-info> element.
RCS呈现源将在<location-info>元素内，通过提供一个GML <point>元素和一个不准确位置，组成一个<circle>元素来表示精确位置，两者都指的是EPSG::4326空间参考模式，如[RFC5491]所描述。 该圆的中心或精确位置的坐标将由单个GML <pos>元素表示，其中实际坐标为该<pos>元素的值。 圆的半径将以米表示，这将通过将radius元素的测量单位属性设置为EPSG::9001的值来声明，如[RFC5491]中所述。 RCS客户端应忽略<location-info>元素中提供的任何其他类型的数据。

The European Petroleum Survey Group (EPSG) format requires that the coordinate representation is defined by the coordinate supplier. RCS presence sources will always provide the coordinates in WGS 84 (latitude, longitude) decimal notion as described in [RFC5491], providing the latitude and longitude as “double”-encoded decimal numbers (as specified in [GML3.1.1]) representing the degrees, separated by a space starting with the latitude. Negative values represent Southern and Western hemisphere respectively.
欧洲石油勘测集团（EPSG）格式要求坐标表示由坐标供应商定义。 RCS呈现源将总是提供WGS 84（纬度，经度）十进制小数的坐标，如[RFC5491]中所述，纬度和经度将以“双”编码十进制数（如[GML3.1.1]中所指定）形式提供以表示度数，用以纬度开头的空格分隔。 负值分别代表南半球和西半球。

3.7.4.2.3 Service / 服务

See section 2.6.1.2.5.
参见第2.6.1.2.5节。

3.7.4.2.4 Device / 设备

The Device part of presence is out of scope for RCS.
呈现中关于设备的部分超出了RCS的范围。

3.7.4.2.5 Example Document / 示例文档

The above leads to following example document:
以上导致以下示例文档：

<?xml version=”1.0” encoding=”UTF-8”?>
<presence xmlns=”urn:ietf:params:xml:ns:pidf”
    xmlns:op=”urn:oma:xml:prs:pidf:oma-pres”
    xmlns:opd=”urn:oma:xml:pde:pidf:ext”
    xmlns:opd11=”urn:oma:xml:pde:pidf:ext:1.1”
    xmlns:pdm=”urn:ietf:params:xml:ns:pidf:data-model”
    xmlns:rpid=”urn:ietf:params:xml:ns:pidf:rpid”
    xmlns:gp=”urn:ietf:params:xml:ns:pidf:geopriv10”
    xmlns:caps="urn:ietf:params:xml:ns:pidf:caps"
    xmlns:gml="http://www.opengis.net/gml"xmlns:gs="http://www.opengis.net/pidflo/1.0" entity=”tel:+1234578901”>
<tuple id="a2">
  <status><basic>open</basic></status>
  <op:service-description>
    <op:service-id>org.3gpp.urn:urn-7:3gpp-service.ims.icsi.mmtel</op:service-id>
    <op:version>1.0</op:version>
  </op:service-description>
  <caps:servcaps>
    <caps:audio>true</caps:audio>
    <caps:duplex>
      <caps:supported>
        <caps:full/>
      </caps:supported>
    </caps:duplex>
  </caps:servcaps>
  <contact>tel:+1234578901</contact>
</tuple>
<tuple id=”a1”>
  <status><basic>open</basic></status>
  <op:service-description>
    <op:service-id>org.3gpp.cs-videotelephony</op:service-id>
    <op:version>1.0</op:version>
  </op:service-description>
  <contact>tel:+1234578901</contact>
</tuple>
<tuple id=”a12”>
  <status><basic>open</basic></status>
  <op:service-description>
    <op:service-id>org.gsma.videoshare</op:service-id>
    <op:version>1.0</op:version>
  </op:service-description>
  <contact>tel:+1234578901</contact>
</tuple>
<tuple id=”a123”>
  <status><basic>open</basic></status>
  <op:service-description>
    <op:service-id>org.gsma.videoshare</op:service-id>
    <op:version>2.0</op:version>
  </op:service-description>
  <contact>tel:+1234578901</contact>
</tuple>
<tuple id=”a132”>
  <status><basic>open</basic></status>
  <op:service-description>
    <op:service-id>org.openmobilealliance:IM-Session</op:service-id>
    <op:version>1.0</op:version>
  </op:service-description>
  <contact>tel:+1234578901</contact>
</tuple>
<pdm:person id=”a1233”>
  <op:overriding-willingness>
    <op:basic>open</op:basic>
  </op:overriding-willingness>
  <rpid:status-icon opd:etag=”26362”>http://xcap.gsma.org/xcap-ap/service/org.openmobilealliance.pres-content/users/sip:[email protected]/oma_status-icon/rcs_status_icon</rpid:status-icon>
  <opd11:link opd11:label=”my blog” opd11:priority=”0.8”>http://example.com/~alice</opd11:link>
  <rpid:place-type opd:until=”2009-11-28T21:00:00Z”>
    <rpid:other>Herentals, Belgium</rpid:other>
  </rpid:place-type>
  <rpid:time-offset opd:until=”2009-11-28T21:00:00Z”>+120</rpid:time-offset>
  <gp:geopriv>
    <gp:location-info>
      <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
        <gml:pos>51.1644 4.7880</gml:pos>
        <gs:radius uom="urn:ogc:def:uom:EPSG::9001">10</gs:radius>
      </gs:Circle>
    </gp:location-info>
    <gp:usage-rules>
      <gp:retention-expiry>2009-11-28T21:00:00Z</gp:retention-expiry>
    </gp:usage-rules>
  </gp:geopriv>
  <pdm:note>I’ll be PAG</pdm:note>
</pdm:person>
</presence>

Table 47: Example Presence Document / 表47：呈现文档示例

3.7.4.3 Presentity Side Handling / 呈现体一侧的处理

3.7.4.3.1 Publication Methods / 发布方法

3.7.4.3.1.1 Overview / 概述

An RCS client publishes its presence information using two different methods:
RCS客户端使用两种不同的方法发布其呈现信息：

1. SIP PUBLISH requests.
   SIP PUBLISH请求。
2. Permanent Presence State Publication (that is, a permanent document maintained through XCAP).
   永久呈现状态发布（即通过XCAP维护的永久文件）。

The method to be used depends on the information to be published: SIP PUBLISH requests are used for following data:
要使用的方法取决于要发布的信息：SIP PUBLISH请求用于以下数据：

• Service Capabilities.
  服务能力。

Permanent Presence State publication applies to the following attributes of Social Presence Information:
永久性呈现状态发布适用于社交呈现信息的以下属性：

• Portrait icon.
  肖像图标。
• Free text.
  自由文本。
• Favourite link.
  喜欢的链接。
• Willingness (that is the overriding-willingness element).
  意愿（即上位意愿元素）。
• Location Information.
  位置信息。

3.7.4.3.1.2 Permanent Presence State Publication / 永久呈现状态发布

The RCS Client shall support Permanent Presence State publication by manipulating the Permanent Presence State via an XDMC using the permanent presence state application as defined in [Presence2.0_TS]. An RCS client shall update the permanent presence state document in such a way that elements in the document that are not changed or are even unknown to the RCS client (for example, because they were included by a client supporting a future RCS release), are not altered. To avoid inconsistencies between attributes and the actual element value, unknown attributes of changed elements shall be removed from the updated document.
RCS客户端将使用[Presence2.0_TS]中定义的永久呈现状态应用，通过XDMC操纵永久呈现状态来支持永久呈现状态的发布。 RCS客户端应当以这样的方式更新永久呈现状态文档，即是：对于文档中没有改变或者对于RCS客户端甚至是未知的元素（例如，因为它们被支持未来RCS版本的客户端包括在内），不改变这些元素。 为了避免属性和实际元素值之间的不一致，应该从更新的文档中删除更改的元素的未知属性。

This can be achieved both through a direct, conditional update of only the changed element itself or through a retrieval of the complete document followed by a client local update of the changed elements. This update should then be used in a conditional replace request for the entire permanent presence state document. The choice between both methods is left to client implementation and could depend on the amount of updated elements. In both cases, whenever the document is modified any expired information will be removed (for example Location Information with an “until” attribute indicating a time in the past).
这既可以通过仅对改变的元素本身的一种直接而有条件的更新，也可以通过检索完整文档后对改变的元素进行客户端本地更新，这样的两种方式来实现。 接下来应该在对整个永久呈现状态文档的条件替换请求中使用该更新。 两种方法之间的选择是由客户端实现，可能取决于更新的元素的数量。 在这两种情况下，每当文档被修改时，将删除任何过期的信息（例如：具有指示过去时间的“until”属性的位置信息）。

The RCS Presence Server shall use the Permanent Presence State as input for Presence Information processing. RCS Presence Server should subscribe/fetch the permanent presence state document from Presence XDM when applying the composition policy.
RCS呈现服务器将使用永久呈现状态作为存在信息处理的输入。 当应用组合策略时，RCS Presence服务器应从Presence XDM订阅/获取永久呈现状态文档。

3.7.4.3.2 Presence Information Handling / 呈现信息处理

3.7.4.3.2.1 Willingness / 意愿

At the presentity side, the RCS client will always include an <overriding-willingness> element in the permanent presence document. This element will have a <basic> sub- element set to either “open” or “closed” depending on what was indicated by the user as his current status. If willingness is disabled through the provisioning parameter, no “<overriding- willingness>” element will be included in the permanent presence document.
在呈现体方，RCS客户端将始终在永久呈现文档中包括<overriding-willingness>元素。 该元素将具有被设置为“open”或“closed”的<basic>子元素，这取决于用户对他的当前状态的声明。 如果通过配置参数禁用意愿，则不会将“<overriding-willingness>”元素包括在永久呈现文档中。

3.7.4.3.2.2 Status Icon / 状态图标

The status icon shall be stored, updated, deleted and retrieved according to the OMA Presence and XDM 2.0 procedures. For the storage itself, the Presence Content XDMS as defined in [Presence_Content] shall be used including the application usage and document type that it introduces. RCS will only make use of the Presence Content XDMS for the storage of the status icon. Therefore the usage as defined in section 5.1.12.1 of [Presence_Content] is the only one that is applicable including all its associated restrictions. After storing, updating or deleting the icon, the presentity’s client should publish an updated presence document including the etag attribute in the <status-icon> element as described in [Presence2.0_DDS] in sections 7.11.1.3 and 7.20.
状态图标应根据OMA Presence和XDM 2.0过程进行存储，更新，删除和检索。 对于存储本身，应使用[Presence_Content]中定义的Presence Content XDMS，包括其引入的应用程序使用和文档类型。 RCS将仅使用Presence Content XDMS来存储状态图标。 因此，[Presence_Content]的第5.1.12.1节中定义的用法是唯一适用的，包括其所有相关限制。 在存储，更新或删除图标之后，呈现实体的客户端应该在第7.11.1.3和7.20节中的[Presence2.0_DDS]中描述的<status-icon>元素中发布包括etag属性的更新后的呈现文档。

3.7.4.3.2.3 Link

The RCS client will limit the length of the label 200 characters.
RCS客户端将标签的长度限制为200个字符。

3.7.4.3.2.4 Location / 位置

# 3.7.4.3.2.4.1 Ending Location Information Sharing / 结束位置信息共享

When the user indicates that they do not want to share their location information with the contacts allowed to see their information anymore, the client can fulfil this request by removing the location information from the Permanent Presence State document.
当用户指示他们不想与允许再次看到他们的信息的联系人共享他们的位置信息时，客户端可以通过从永久呈现状态文档中移除位置信息来满足该请求。

# 3.7.4.3.2.4.2 Managing Location Information / 管理位置信息

An RCS presence source is not required to include all location elements specified in section 3.7.4.2.2.3 in the permanent presence state document (that is, all elements are optional to be provided).
RCS呈现源不需要包括在永久呈现状态文档中的第3.7.4.2.2.3节中指定的所有位置元素（即，所有元素都是可选的）。

The length of the descriptive text that the RCS client includes in the Permanent Presence State document shall not be longer than 200 characters.
RCS客户端在永久呈现状态文档中包括的描述性文本的长度不得超过200个字符。

The maximum time a location update remains available to watchers is controlled by a Service Provider provisioning setting. RCS presence sources will set the "until" attribute and the "retention-expiry" element (see section 3.7.4.2.2.3) in accordance to this provisioning setting (that is, set it to the current time increased with the value of the setting). Furthermore, RCS presence sources shall remove expired location information from the published presence document and from any locally cached copy of that document whenever they update other elements in the document.
位置更新对于观察者保持可用的最大时间由服务提供商配置设置控制。 RCS存在源将根据此设置值设置“until”属性和“retention-expiry”元素（参见第3.7.4.2.2.3节） （即，将其设置为随设置值增加的当前时间）。 此外，每当RCS存在源更新文档中的其他元素时，它将从已发布的呈现文档和该文档的任何本地缓存的副本中删除过期的位置信息。

Clients offering the user the choice to provide an inaccurate position to their contacts (for example, city level or even country level) can do so by providing a CircleByCenterPoint element instead of an exact position using coordinates and text reflecting this inaccuracy (for example, the city centre instead of the exact street). Whether the client does this and how it determines the position of the centre, the radius and the text value (that is, the <place-type> element) that will be shared, is considered to be client implementation and thus out-of-scope for RCS.As an option to the user, clients may also offer the possibility to regularly update their position without user intervention. Whether or not this is done is again considered to be a client implementation issue and thus out-of-scope for RCS.
客户端为用户提供这样一种选择，向他们的联系人提供不准确的位置（例如，城市级别甚至国家级别），这种选择可以通过CircleByCenterPoint元素而不是使用坐标和文字的精确位置（例如， 城市中心，而不是准确的街道）来反映这种不精确。 不管客户端是否这样做以及如何确定中心的位置，将被共享的半径和文本值（即，<place-type>元素）被认为是由客户端来实现，因此而超出RCS的范围。作为用户的可选项，客户端还可以提供在没有用户干预的情况下定期更新其位置的可能性。 是否完成该功能也被认为是客户端的实现问题，因此而超出RCS的范围。

3.7.4.3.2.5 Nickname / 昵称

The application/watcherinfo+xml body in the watcher information notification may contain a display name for the watcher in the display-name attribute as specified in [RFC3858]. In this case, if the telephone number that is derived from the (SIP or tel) URI that is provided for that watcher is not found in the phone book of the client, the RCS client will include the display name in notifications shown to the user. At the same time, it will always include the watcher’s telephone number to minimise the risk of false identifications.
观察者信息通知中的application/watcherinfo+xml主体可以包含在[RFC3858]中指定的display-name属性中的观察者的显示名称。 在这种情况下，如果在客户端的电话簿中没有找到从为该观察者提供的（SIP或tel）URI派生的电话号码，则RCS客户端将在向用户显示的通知中包括显示名称 。 同时，它将始终包括观察者的电话号码，以最小化假标识的风险。

If no display name is received (for example, because the subscription is initiated from an RCS Release 2 network), the client shall only present the E.164 number to the user.
如果没有接收到显示名称（例如，因为订阅是从RCS Release 2网络发起的），客户端将只向用户呈现E.164号码。

If the watcher’s telephone number is found in the phone book, behaviour shall be as specified in section 2.5 (that is, the received display name shall not be used, but rather the information that is part of the phone book).
如果在电话簿中发现观察者的电话号码，则行为应如第2.5节所规定（即，不应使用接收的显示名称，而是作为电话簿的一部分的信息）。

An RCS client shall be able to deal with display names up until a maximum length of 200 characters.
RCS客户端应能够处理显示名称，最大长度为200个字符。

3.7.4.3.3 Multidevice Handling / 多设备处理

If one of the user’s clients changes the (shared) permanent presence state document, the other clients of the user will receive the update as part of a presence notification which will contain information about their own presentity. Such an update will be received immediately when the client is online at the time of the changes. If this is not the case, the client will receive the update when it comes online. Clients shall take the updated social presence information into account and update the presence information that they store locally in the client accordingly. To get the notifications that are necessary to provide this behaviour, the client shall include the own identity in the “rcs” list which is part of the Shared XDMS’s “resource-lists” document (see section 2.14.1).
如果用户的客户端之一改变（共享的）永久呈现状态文档，则用户的其他客户端将接收更新，作为将包含关于他们自己的呈现体的信息的存在通知的一部分。 当客户端在更新时上线，将立即收到此更新。 如果不是这样，客户端将在其上线时接收更新。 客户端应考虑更新的社交呈现信息，并相应地更新他们在客户端本地存储的呈现信息。 要获得提供此行为所必需的通知，客户端应在“rcs”列表中包含自己的身份，该列表是共享XDMS的“resources-lists”文档的一部分（请参阅第2.14.1节）。

When a user decides that they do not want to receive a certain service on one of their secondary devices (see section 2.9.1.4), the client on the given secondary device will not indicate the capability for that service in the services section of the presence document if such a capability is defined for the service (see section 2.6.1.2.5).
当用户决定不想在其辅助设备之一上接收某个服务（参见第2.9.1.4节）时，给定辅助设备上的客户端将不会在呈现的服务部分中声明支持该服务的能力，即使面向该服务的能力是支持的（见第2.6.1.2.5节）。

3.7.4.4 Watcher Side Handling / 观察者一侧的处理

When presence information of a presentity is requested by a watcher a SUBSCRIBE request is initiated (event package ‘presence’) according to [Presence]. The watcher should be able to use the tel URI to identify the presentity, see section 2.5.

The support of RLS is mandatory for the clients and servers. Client shall conform to section 5.2.2.1 of the technical specification of [PRESENCE] and in addition to section 5.7.1 and 5.8 in [PRESENCEIG], section 5.1 in [XDMIG] and section 5.1.6 in [RLSXDM]. The XML documents shall follow the templates following later in this section.

3.7.4.4.1 Caching Presence Information

The caching of presence information is a client procedure.

The RCS client must be able to locally store the most up-to-date presence information (that have been received through notifications) of all of the user's contacts. This locally stored information must be handled as a persistent cache (that is the data shall not be erased when the terminal is switched-off).

3.7.4.4.2 Presence Information Handling

3.7.4.4.2.1 General Processing Rules to Facilitate Forwards Compatibility

To maintain enough flexibility and not to impose potentially sub-optimal technical choices on future RCS releases, the presence parsing for social presence information in an RCS client should be sufficiently robust. Therefore the following guidelines should be taken into account in RCS presence parsing:

• Unknown or unsupported elements could be present in the document. In that case they should be ignored.
• When using RLS subscriptions, information could be contained on presentities that were not known to be part of the presence list (for example because the list was updated by another client or application). If the unexpected presentity is a known contact, the client should treat this contact as being presence enabled (see section 3.7.4.4.4) and try to retrieve an updated presence list from the network (see section 2.14.2).
• The Watcher shall follow the procedures defined in section 6.2 "Default Watcher Processing" of [Presence2.0_DDS].

3.7.4.4.2.2 Willingness

The client will interpret any “” element included/not included in the received presence document(s) as specified in section 3.7.4.2.2.

3.7.4.4.2.3 Status Icon

The link to the status icon that is received in the presence document of the contact will be processed as described in [Presence2.0_TS] section 5.2.5.3. When the etag attribute of the status-icon element does not match that of the cached icon, the client will download the updated icon. To do that it will handle the link that it received in the presence document as defined in [XDM2.0_Core] section 6.1.1.1 and more specifically the third paragraph: it will replace the XCAP root part of the link with the own XCAP root of the watcher. After downloading the icon, the RCS client shall cache it along with the etag to be able to process future notifies on the status of the contact as defined in [Presence2.0_TS] section 5.2.5.3.

3.7.4.4.2.4 Link

If an RCS client receives a document containing multiple elements, then it shall only consider the one with the highest priority and use that as the value of the element in the processing.

An RCS watcher shall be able to deal with labels with a length of maximum 200 characters.

3.7.4.4.2.5 Location Information

It is considered to be a client implementation decision how received location information from a contact will be handled (for example, display only the text, use an individual map for each contact and so on. This is thus considered to be out of scope for RCS. Clients should at least provide a means to display any descriptive text (that is, the content of the element) that they might receive.

An RCS client should take into account that a received presence document might not contain location information (for example, because the presence source does not provide it or privacy was enabled).

An RCS client shall be able to deal with place-type information with a length of maximum 200 characters.

An RCS client shall not display to the user information contained in location elements for which the "until" attribute (for the and elements) or the element (for the geolocation information) indicate a time in the past. Furthermore it shall not cache the expired information locally any longer.

3.7.4.4.3 Nickname Handling

If the user has provided a nickname, an RCS client shall include it as the display name as part of the identity information provided in the P-Preferred-Identity and From header field of the SIP SUBSCRIBE request used when subscribing to the user’s Resource List Server (RLS) document. The RCS client shall ensure that the length of the used display name is not larger than the maximum size that was provisioned by the Service Provider.

3.7.4.4.4 Multidevice Handling

For the most part the watcher functionality on the different clients of the same user can function independently of each other. Only with the authorisation there might be some interaction as this may trigger unexpected notifications (see section 3.7.4.5.7). An RCS client of this release will provide compatibility with clients of future RCS releases acting as one or more of the other devices of the user. To achieve this it will display the presence information provided in a presence notification if it refers to a known contact, regardless of whether that contact can be found in the “rcs”, “rcs_basic_spi_only”, “rcs_poll” or “rcs_poll_basic_spi_only” lists of the Shared XDMS’s “resource-lists” document (see section 3.7.4.5.2).

3.7.4.5 Subscriptions and Authorization

3.7.4.5.1 Overview

Presence invitations are subject to reactive authorisation to guarantee user privacy. This will allow the invited user (presentity) to accept, block or ignore an invitation to establish a presence relationship.

The presence authorisation for basic social presence information shall be symmetric. This means the inviting user automatically authorises the invited user to see their basic social presence information. The invited user by accepting the presence invitation request both authorises the inviting user to see their basic social presence information and subscribes to the inviting users presence information.

The RCS presentity shall be able to configure the presence authorisation rules, which require the support in the RCS client and in the RCS Presence Server of [PresenceXDM]. The RCS client shall store a presence authorisation document that follows [PresenceXDM] and the template rules described in section 5.8 in [PRESENCEIG].

In order for a presentity to be able to authorise the subscription of a watcher, the presentity needs to know which watcher(s) are trying to subscribe to the presence of the presentity. The RCS client and the Presence Server shall thus support section 5.3.1 and 5.4.4 of [Presence].

When the subscription is authorised successfully, the Presence Server sends the presentity’s presence document to the watcher by using the NOTIFY method as defined in [Presence]. The format of the presence notification follows the Presence Data Model as describe above and it contains the information the watcher is allowed to see according to the configured presence rules.

The contacts with whom the RCS user share presence information can be defined as either VIP contacts or non-VIP contacts (see section 3.7.1.4.9). For VIP contacts, presence information changes are received in real time, using a subscription to the corresponding “VIP contacts” buddy list in RLS. For non-VIP contacts the client will poll the corresponding “non-VIP contacts” list in RLS to retrieve presence information changes.

Contrary to the general concept for basic social presence information sharing the authorisation for location information is not necessarily mutual: User A can get the location information from User B without having to provide his location information. Furthermore, the user can control whether the information that he/she is capable of sharing social presence information is public or not.

3.7.4.5.2 XML Document Structure

The Presence XDMS shall contain the following authorisation rules following, where possible, the recommendations in [PRESENCEIG]:

• ”allow own” rule – allows subscriptions to own presence data
• ”confirm unlisted” rule – allows reactive authorisation for contacts not yet allowed or blocked
• ”blocked contacts” – contains those contacts that the user has blocked (points to ”blocked contacts” list in Shared XDMS)
• ”granted contacts” rule – will be used as the rule to provide all social presence information (that is, the Basic Social Presence Information and geolocation information)
• “basic_spi_only_granted_contacts” rule – will be used by the contacts with whom no location information is being shared.

The RLS XDMS shall for an RCS user contain two entries; one referencing the “oma_buddylist” list and one referencing the “rcs_poll_buddylist” list, both in Shared XDMS for which the template is described in section 2.14.1. The service URI referencing the “oma_buddylist” allows subscribing with one RLS subscription to the presence information of both the VIP contacts with whom only social presence information is shared and those VIP contacts that are also allowed to see the location information. The RCS client will at start-up subscribe to changes to this list by issuing a SUBSCRIBE request to the RLS targeting this list with an expire value >0 (pre-configured in client).

In addition to information on the VIP contacts, the service URI referencing the “rcs_poll_buddylist” (see section 2.14.1 for the template) allows the RCS client with one subscription request to retrieve presence information also from the non-VIP contacts with whom only social presence information is shared and those non-VIP Contacts that are also allowed to see the location information. The RCS client will, only on user request or also on regular basis issue a “poll” SUBSCRIBE (that is with expires=0) to this list to obtain the presence information for the contacts in this list.

The maximum amount of poll operations on the non-VIP Contacts buddy list during a certain time period can in the client be configured subject to Service Provider policies (see Annex A).

The Shared XDMS (see section 2.14.1 for the template) shall contain the following lists that are used for presence and are provided and managed by the RCS client:

• “rcs” list: This list includes all VIP contacts with which basic Social Presence and location information is shared. Commonly referred in RCS from both the “oma_buddylist” and “oma_grantedcontacts” lists as the contacts that are allowed to see your presence are also your buddies (symmetric).
  To provide the behaviour described in section 3.7.4.3.3, the “rcs” list will contain the own identity of the user. The client shall not allow the user to remove that entry.
• “rcs_basic_spi_only” list: This list includes all VIP contacts with which only basic Social Presence information is shared. Commonly referred in RCS from both the “oma_buddylist” and “rcs_basic_spi_only_granted_contacts” lists as the contacts that are allowed to see your presence are also your buddies (symmetric).
• “rcs_poll” list: This list includes all non-VIP contacts with which basic Social Presence and location information is shared. Commonly referred in RCS from both the “rcs_poll_buddylist” and “oma_grantedcontacts” lists as the contacts that are allowed to see your presence are also your buddies (symmetric). As a difference with the “rcs” list, the “rcs_poll” list will not contain the own identity of the user.
• “rcs_poll_basic_spi_only” list: This list includes all non-VIP contacts with which only basic Social Presence information is shared. Commonly referred in RCS from both the “rcs_poll_buddylist” and “rcs_basic_spi_only_granted_contacts” lists as the contacts that are allowed to see your presence are also your buddies (symmetric).
• “oma_buddylist” list: Contains a reference to the “rcs” and the “rcs_basic_spi_only” lists where the actual VIP Contacts (or buddies) are stored. The “oma_buddylist” is explicitly used from the RLS document.
• “rcs_poll_buddylist” list: Contains a reference to the “rcs_poll” and the “rcs_poll_basic_spi_only” lists where the actual non-VIP Contacts are stored. The “rcs_poll_buddylist” is explicitly used from the RLS document.
• “oma_grantedcontacts” list: This list includes all contacts you have authorised to see your basic social presence and location information. Contains a reference to the “rcs” and “rcs_poll” lists.
• “rcs_basic_spi_only_grantedcontacts” list: This list includes all contacts you have authorised to see only your basic social presence information. Contains a reference to the “rcs_basic_spi_only” and the “rcs_poll_basic_spi_only” lists
• “oma_blockedcontacts” list: Contains a reference to the “rcs_blockedcontacts” list where the actual permanently blocked contacts are stored and to the “rcs_revokedcontacts” list with the revoked users that are temporarily being blocked.
• “rcs_blockedcontacts” list: Contains all permanently blocked contacts
• “rcs_revokedcontacts” list: Contains all revoked contacts that are currently being blocked.

NOTE1: The “rcs_revokedcontacts” list is not intended to be shown to the end user. It is managed automatically.

NOTE2: A contact should only be in one of the lists used for presence. To ensure this, the RCS client shall check the other lists for an occurrence of the contact when adding it to a list. If the contact occurs somewhere else, the client will remove that entry. A contact will always be added to the new list before being removed from the old one. This applies both when removing a presence relation (see section 3.7.4.5.4) and when changing a contact from being a VIP Contact to a being a non-VIP Contact or vice versa (see section 3.7.4.5.6).

For RCS, the template definitions below will be used for the different XDM documents related to presence subscriptions and authorisations.

Presence XDMS:
AUID: org.openmobilealliance.pres-rules
Document name: pres-rules
Template

<?xml version="1.0" encoding="UTF-8" ?>
<cr:ruleset xmlns:ocp="urn:oma:xml:xdm:common-policy" xmlns:op="urn:oma:xml:prs:pres-rules" xmlns:pr="urn:ietf:params:xml:ns:pres-rules" xmlns:cr="urn:ietf:params:xml:ns:common-policy">
  <cr:rule id="wp_prs_allow_own">
    <cr:conditions>
      <cr:identity>
        <cr:one id="tel:+1234578901" /> </cr:identity>
    </cr:conditions>
    <cr:actions>
      <pr:sub-handling>allow</pr:sub-handling>
    </cr:actions>
    <cr:transformations>
      <pr:provide-services>
        <pr:all-services/> </pr:provide-services>
      <pr:provide-persons>
        <pr:all-persons/> </pr:provide-persons>
      <pr:provide-devices>
        <pr:all-devices/> </pr:provide-devices>
      <pr:provide-all-attributes/> </cr:transformations>
  </cr:rule>
  <cr:rule id="wp_prs_unlisted">
    <cr:conditions>
      <ocp:other-identity/> </cr:conditions>
    <cr:actions>
      <pr:sub-handling>confirm</pr:sub-handling>
    </cr:actions>
  </cr:rule>
  <cr:rule id="wp_prs_grantedcontacts">
    <cr:conditions>
      <ocp:external-list>
        <ocp:entry anc="http://xcap.gsma.org/resource- lists/users/sip:[email protected]/index/~~/resource- lists/list%5B@name=%22oma_grantedcontacts%22%5D" /> </ocp:external-list>
    </cr:conditions>
    <cr:actions>
      <pr:sub-handling>allow</pr:sub-handling>
    </cr:actions>
    <cr:transformations>
      <pr:provide-services>
        <pr:all-services/> </pr:provide-services>
      <pr:provide-persons>
        <pr:all-persons/> </pr:provide-persons>
      <pr:provide-devices>
        <pr:all-devices/> </pr:provide-devices>
      <pr:provide-all-attributes/> </cr:transformations>
  </cr:rule>
  <cr:rule id="rcs_basic_spi_only_grantedcontacts">
    <cr:conditions>
      <ocp:external-list>
        <ocp:entry anc="http://xcap.gsma.org/resourcelists/users/sip:[email protected]/index/~~/resourcelists/list%5B@name=%22rcs_basic_spi_only_grantedcontacts%22%5D" /> </ocp:external-list>
    </cr:conditions>
    <cr:actions>
      <pr:sub-handling>allow</pr:sub-handling>
    </cr:actions>
    <cr:transformations>
      <pr:provide-services>
        <pr:all-services/> </pr:provide-services>
      <pr:provide-persons>
        <pr:all-persons/> </pr:provide-persons>
      <pr:provide-devices>
        <pr:all-devices/> </pr:provide-devices>
      <pr:provide-note>true</pr:provide-note>
      <pr:provide-status-icon>true</pr:provide-status-icon>
      <pr:provide-unknown-attribute ns="urn:oma:xml:pde:pidf:ext:1.1" name="link"> true </pr:provide-unknown-attribute>
      <op:provide-willingness>true</op:provide-willingness>
      <pr:provide-unknown-attribute ns="urn:oma:xml:prs:pidf:oma-pres" name="service-description"> true </pr:provide-unknown-attribute>
    </cr:transformations>
  </cr:rule>
  <cr:rule id="wp_prs_blockedcontacts">
    <cr:conditions>
      <ocp:external-list>
        <ocp:entry anc="http://xcap.gsma.org/resourcelists/users/sip:[email protected]/index/~~/resourcelists/list%5B@name=%22oma_blockedcontacts%22%5D" /> </ocp:external-list>
    </cr:conditions>
    <cr:actions>
      <pr:sub-handling>block</pr:sub-handling>
    </cr:actions>
  </cr:rule>
</cr:ruleset>

Table 48: Presence Rules Template

NOTE: If the client is configured to use a presence based capability discovery (as described in section 2.6.1.2, the rcs_allow_services_anonymous rule described in Table 18 should be included in this template.

RLS XDMS: AUID: rls-services Document name: index Template:

<?xml version="1.0" encoding="UTF-8" ?>
<rls-services xmlns="urn:ietf:params:xml:ns:rls-services">
  <service uri="sip:[email protected];pres-list=rcs">
    <resource-list>http://xcap.gsma.com/services/resourcelists/users/sip:[email protected]/index/~~/resourcelists/list%5B@name=%22oma_buddylist%22%5D</resource-list>
    <packages>
      <package>presence</package>
    </packages>
  </service>
  <service uri="sip:[email protected];pres-list=rcs_poll">
    <resource-list>http://xcap.gsma.com/services/resourcelists/users/sip:[email protected]/index/~~/resourcelists/list%5B@name=%22rcs_poll_buddylist%22%5D</resource-list>
    <packages>
      <package>presence</package>
    </packages>
  </service>
</rls-services>

Table 49: Presence RLS Template

NOTE: The lists in the Shared XDMS and the general procedures on the handling of XDM requests and the creation of the documents are described in section 2.14.

3.7.4.5.3 Client Procedures, Initiation of Presence Sharing

When initiating a presence sharing request, the inviting user’s RCS client adds the invited user’s URI to the “rcs” list in Shared XDMS according to the procedures in [Shared-XDM].

When the invited user receives a notification to establish a presence relation, the user can either:

1. Accept the invitation, whereas the RCS client of the invited user adds the inviting User’s URI to the “rcs” list in Shared XDMS (see section 2.14.1) according to the procedures in [SHARED-XDM].
2. Block the invitation, whereas the RCS client of the invited user adds the inviting User’s URI to the “rcs_blockedcontacts” list in Shared XDMS (see section 2.14.1) according to the procedures in [SHARED-XDM].
3. Ignore the invitation, whereas the RCS client of the invited user removes the presence sharing invitation.
4. Not answer the invitation. The presence sharing invitation is pending in the client until either “accepted” (case 1), “blocked” (case 2) or “ignored” (case 3). In the signalling, there is no difference from the “ignore” case.

3.7.4.5.4 Client Procedures, Removal of Presence Sharing

When the user decides to end the presence relationship with one of their contacts, they have to use the revoke option on their device. This triggers a notification to the user as defined in section 3.7.1.4.6 asking for confirmation. When this is confirmed, the client will put the user on the “rcs_revokedcontacts” list, subsequently remove the user from the “rcs” or “rcs_basic_spi_only”, “rcs_poll” or “rcs_poll_basic_spi_only” list and remove the contact’s presence information from the cache as defined in section 3.7.4.4.1. When putting an entry for the contact in the “rcs_revokedcontacts” list the client includes a last modified attribute that indicates the current time in UTC.

When a client notices it has been blocked by a contact with whom Social Presence was shared (that is the RLS notify indicates the subscription is in state “terminated” and the reason indicates “rejected”), it will remove the contact from the “rcs” or “rcs_basic_spi_only”, “rcs_poll” or “rcs_poll_basic_spi_only” list and remove the contact’s cached presence information. Note that for a non-VIP contact (in the “rcs_poll” or “rcs_poll_basic_spi_only” list) there could be a delay in the detection of this change.

All clients will process the “rcs_revokedcontacts” list periodically and remove those contacts that have been included in the list for a sufficiently long period already (for example several days). For that they will compare the last-modified attribute of the entries to the current time. Both the interval at which the list is checked (REVOKE TIMER) and the period that a contact should remain in this list (REVOKE TIMER) is a Service Provider configurable client parameter defined in Annex A.

With regards to the communication capabilities both clients should fall back to the procedures as defined in section 2.6 for sharing of capabilities between contacts not sharing social presence information.

3.7.4.5.5 Conditional Event Notification

The support of conditional event notification is strongly recommended for the clients (i.e. Watcher and Watcher Information Subscriber) and for the servers (i.e. Presence Server and RLS) to optimize presence traffic at UNI and NNI.

An RCS client should support subscription with conditional event notification, as defined in section 5.2.6 and section 5.3.2 of [Presence2.0_TS].

An RCS RLS should support subscription with conditional event notification, as defined in section 5.2 of [Presence2.0_RLS_TS].

An RCS Presence Server should support notification with conditional event notification, as defined in section 5.5.3.8, 5.5.3.9 and 5.5.4.2 of [Presence2.0_TS].

An RCS RLS should support notification with conditional event notification, as defined in section 5.4 of [Presence2.0_RLS_TS].

3.7.4.5.6 Client Procedures, managing of VIP and non-VIP Contacts

When the user decides to change a user from being a VIP Contact to being a non-VIP Contact (or vice versa) the client will first add the user’s URI to the target list and after this, remove the user’s URI from the list where it was previously stored. That is, when changing a user from being a VIP Contact to a non-VIP Contact, the client will first add the user’s URI to the “rcs_poll” (if previously in the “rcs” list) or “rcs_poll_basic_spi_only” list (if previously in the “rcs_basic_spi_only” list) and then remove the URI from the “rcs” or “rcs_basic_spi_only” list respectively. When changing a user from being a non-VIP Contact to a VIP Contact, the client will first add the user’s URI to the “rcs” list (if previously in the “rcs_poll” list) or “rcs_basic_spi_only” list (if previously in the “rcs_poll_basic_spi_only” list) and then remove the URI from the “rcs_poll” or “rcs_poll_basic_spi_only” list respectively.

3.7.4.5.7 Multidevice Handling

Any negative effects of XDM document changes in a multidevice context are countered through the XDM document handling as it is described in section 2.14.2.

Several situations should be dealt with:

• The user owning multiple clients is invited by a contact to share social presence information.
  All the user’s active clients will receive watcher information notifications both when the contact subscribes for the user’s social presence information (subscription entering the “pending” state) and when the user accepts or blocks the “invitation” on one of their clients (subscription going out of the “pending” state). When the user accepts the invitation on one of their clients, the other clients will also start receiving the social presence information of the contact.
• The user owning multiple clients invites a contact to share social presence information from one of their clients.
  In this case their other clients will receive presence notifications indicating that a subscription to the contact entered the pending state and notifications including the other user’s social presence information when the contact accepted the “invitation”. If the contact blocks the “invitation”, there will be presence notifications to all the user’s clients indicating that the subscription was terminated. The clients shall use these unexpected notifications as triggers to update the locally stored copy of the Shared XDMS’s “resource-lists” document if they cache that kind of information locally.
• The user revokes the presence sharing with a contact from one of their clients. Again his other clients that are online will receive unexpected presence notifications indicating that the subscription to the contact’s social presence information was terminated. If they cache the information in the Shared XDMS’s “resource-lists” document locally, they shall use this notification as a trigger to verify that the information is still up-to-date.
  Changes are done while the client was offline. A client that caches the information in the Shared XDMS’s “resource-lists” document locally should check whether that document has changed when it comes online. Therefore, this will not cause any issues.
• The user owning multiple clients changes a contact from being a VIP contact to being non-VIP contact from one of their clients. His other clients that are online will receive unexpected presence notifications indicating that the subscription to the contact’s social presence information was terminated. If they cache the information in the Shared XDMS’s “resource-lists” document locally, they shall use this notification as a trigger to verify that the information is still up-to-date.
• The user owning multiple clients changes a contact from being a non-VIP contact to being a VIP contact from one of their clients. In this case, their other clients will receive presence notifications indicating that a subscription to the contact has been created and notifications including the other user’s social presence information. Again, the clients shall use these unexpected notifications as triggers to update the locally stored copy of the Shared XDMS’s “resource-lists” document if they cache that kind of information locally.

3.7.4.6 RLS Server Handling

3.7.4.6.1 Nickname Handling

A RLS server supporting RCS shall include any display name it received in the P-Asserted- Identity and From headers of the RLS subscription in the corresponding header of the related backend subscriptions that it sends to the Presence Server.

3.7.4.7 Presence Server Handling

3.7.4.7.1 Nickname Handling

A Presence Server supporting RCS shall include any display name it received in the P- Asserted-Identity header field of a presence subscription in the display-name attribute of any entry related to that subscription in the application/watcherinfo+xml body that is sent to the clients of the served RCS presentity that was the target of the subscription. If the P- Asserted-Identity header field does not contain any display name, the display name provided in the From header field of the subscription will be used, if any.

3.7.4.8 XDM Server Handling

3.7.4.8.1 Status Icon

In the network the retrieval of the information referred to by the link to the status icon will be realised in an architecture as described in [XDM1.1_AD] with the addition of the Cross- Network Proxies and XDM-8 and NNI-1 interfaces defined in [XDM2.0_AD]. The required functionality of the Cross-Network Proxy is limited to the authorisation, data transfer and routing of XCAP functionalities. The routing of search requests is not applicable to RCS. For RCS the supported protocols on the NNI-1 interface are limited to XCAP, “limited XQuery over HTTP” is not supported.

At the functionality level, this means that the identity provided by the Aggregation Proxy is not only shared on the XDM-4 and enabler specific reference points between the Aggregation Proxy and the Enabler specific XDMS as it is described in [XDM1.1_Core] section 6.4.1, but also on the XDM-8 and NNI-1 interfaces as it is described in [XDM2.0_Core] section 5.1.3. The Integrity and Confidentiality protection of [XDM1.1_Core] section 6.4.2 is extended to the NNI-1 interface as it is described in [XDM2.0_Core] section 5.1.4. Furthermore in addition to the functionality described in [XDM1.1_Core], the Aggregation Proxy shall route requests to the Cross-Network proxy as it is described in [XDM2.0_Core] section 6.3.1.1 and route the Cross-Network Proxy’s responses back to the XDM client. The procedures for routing requests to the search proxy that are described in [XDM2.0_Core] section 6.3.1.1 are not applicable for RCS. Finally the functionality of the Cross-Network Proxy as it is described in [XDM2.0_Core] section 6.5 and subsections shall be supported with the exception of all functionality related to the routing of Search Requests and Search Responses.

3.7.5 NNI and IOT considerations

The NNI interfaces for SPI sharing shall behave according to the procedures described in section 2.12 and the documents it refers to.

3.7.6 Implementation guidelines and examples

3.7.6.1 SPI transaction handling

Initiator side

1. An RCS user that wants to Share SPI with a contact selects the contact entry in their local enriched address book.
2. They select in the menu “share” (if available, that is the contact has the SPI service capability) the function “Share Social Presence” and can see by using the SPI general menu the SPI status associated with the contact (“idle”, “pending” “activated”, “terminated”)

3. This SPI general menu, depending on the SPI status, enables them to invite the contact to share SPI with following options

   • “VIP contact”: YES / NO (default NO)

   • “Authorise Location Sharing”: YES / NO (default NO)

     NOTE: at any moment, for these 2 options, when the SPI status becomes “active”, the general Share SPI menu offers the user the possibility to change their choices

   • “Nickname” text field: free user text

4. Then the user can follow the SPI status evolution the SPI status by selecting the contact and activating the SPI general menu
   • “pending”: the contact has not yet accepted to share SPI with them
   • “active”: the contact has accepted to share SPI with them
   • “terminated”: The contact, after acceptation, has decided to revoke sharing Presence Information

Callee side

1. The RCS user is triggered by a pop up SPI menu that a distant user has invited them to share their Social Presence Information
   • If the user already has a contact entry for the inviting user in the local address book, then the name assigned to the contact entry in the local address book of the user appears in this SPI menu
   • If the user is not present in the local address book, then the “nickname” of the inviting user (if any provided) and their E.164 address appear in the menu instead

2. The SPI pop up menu proposes allows actions through buttons and fields to be filled

   • “Accept”: YES/NO
   • “VIP contact”: YES / NO (default NO)
   • “Authorise Location Sharing”: YES / NO (default NO)

     NOTE: at any moment, for the latter 2 options, when the SPI status becomes “active” the general Share SPI menu offers the user the possibility to change their choice

3. Then the user can follow the SPI status evolution by selecting the contact and activating the SPI general menu

   • “active”
   • “terminated”: The contact, after acceptation, has decided to revoke sharing Presence Information

SPI status “active”

At any moment, in the “active state” the user can choose for a contact selected in the address book:

• To modify SPI sharing parameters: VIP contact, Geolocation Sharing authorisation
• To revoke SPI sharing

3.7.6.2 Availability handling

The user can choose how they appear to their contacts: “Available” or “Not Available”.

3.7.6.3 Free Text handling

The user enters some free text possibly including emoticons. They are blocked when the length of the text reaches the limit fixed by the Service Provider.

3.7.6.4 Icon handling

The user is asked to choose an image in the local file system of the device from a sub set of the images that are candidate to be part of the user SPI (filter based on file size).

3.7.6.5 URL label

The user is asked to enter a URL and an associated free text. The user may be assisted by the application to enter the information.

3.7.6.6 Geolocation handling

In a manual mode, user manually picks a position (x, y) on a map or user requests for an update of their position (x, y) information. Then, geolocation information is given by RCS client towards authorised enriched contacts as soon as it has been made available on the RCS client by the user.

In automatic mode, update of location coordinate information (x, y) is automatically made and given to the authorised enriched contacts on a regular basis.

Manual mode and automatic mode are further detailed below.

3.7.6.6.1 Display Modes

Three displays modes are possible:

1. Text: a user is located and the result is given to their authorised enriched contacts under a declarative text format (Paris, La Défense). The declarative text is always manually edited by the user.
2. Map: a user is located and the result is given as coordinate information (x, y) to his authorised enriched contacts and displayed under a map format. When the user is displayed as a dot on a map, their location information can also be displayed as text in other screens. For example, if a user has updated his location to a position in the centre of London on a map, some screens without a map may display his location using the declarative text edited by the user (for example, “London, UK”).
3. A combined display of text and a map

3.7.6.6.2 Update Information

Declarative location text information is always manually edited/updated by the user.

The Geolocation information update regarding coordinate information (x, y) can be either:

• Manual
  • The user can select their location manually on a map, by either entering text that is then processed to provide location (as coordinate information [x,y]) on a map (for example Google Maps) or, for example, by dragging and dropping a “pin” on a map to the desired location. This user-chosen location can be different from the user’s actual location.
  • Triggering their actual current location (based, for example, on a GPS signal from the device or a mobile network-based location). For example, they click on the location update button, and coordinate information (x,y) is automatically filled)
• Automatic
• (User A decides that they want their authorised contacts to be informed regarding their coordinate position (x,y) on a regular basis). Location coordinate information (x, y), and any update is automatically made and given to authorised enriched contacts on a regular basis.

Other recommendations for implementation from the end user’s perspective (these are only meant as examples and not actual specifications):

• For Fully Automatic update, the user shall be able to choose the level of accuracy for their location
  • Country
  • City
  • Street (most accurate location)
• In addition to having a map displayed per contact inside the address book (at -1 or -2 navigation levels), there might be the possibility to have a consolidated map with all contact location information (within the scope defined : country, city or street). The starting position of the map is the user’s current position, if available. See also section 3.10.