Content for  TS 33.128  Word version:  18.6.0

The IRI-POI present in the RCS Server shall generate xIRIs to report the establishment, modification and release of RCS Sessions. There are multiple types of RCS Sessions that shall be reported:

• Standalone SIP Sessions:
  • Large Message Mode CPM Standalone Messages (see clause 7.13.3.4.2).
• CPM Sessions which can be broken down into:
  • 1-to-1 Chat sessions (see clause 7.13.3.4.3).
  • Group Chat sessions.

When reporting sessions established to transfer a Large Message Mode RCS Standalone Message, the rCSSessionType parameter shall be set to "LargeMessageStandalone". When reporting a CPM 1-to-1 Session, the rCSSessionType parameter shall be set to "1to1Chat".

The IRI-POI present in the RCS server shall generate an xIRI containing an RCSCapabilityDiscovery when the IRI-POI present in the RCS server detects that an RCS target has received RCS service capabilities for his contact(s) or has sent capabilities to a contact. Accordingly, the IRI-POI in the RCS server generates the xIRI when any of the following events is detected:

• The RCS server receives a SIP OPTIONS request sent by a target which contains the capabilities of the target in the Contact header.
• The RCS server returns a SIP response with the response code is 200, 480, 408, 404 or 604 for a SIP OPTIONS request sent by the target.
• The RCS server receives a SIP OPTIONS request for the target which contains the capabilities of the target's contact in the Contact header.
• The RCS server returns a SIP response for a SIP OPTIONS request received from a target's contact.
• The RCS server sends a SIP NOTIFY request to the target with the Event header set to "presence.winfo". The SIP NOTIFY request contains the RCS state and RCS capabilities of a target's contact.
• The RCS server receives a SIP SUBSCRIBE request from a target's contact with the Event header set to "presence.winfo".
• The RCS server receives a SIP PUBLISH request from the target to initially announce, update and remove RCS capabilities.

Depending on the RCS event being reported and the implementation, location information may be present in the headers of one or more protocol layers, the body of one or more protocol layers, or both. In all cases, if content is authorised, location information present in the content portion of a user generated payload shall not be redacted. When location is not authorised, all location information shall be redacted from the encapsulated RCS payload prior to its delivery over LI_HI2. As such, when location is not authorised, the MDF2 and, optionally, the IRI-POIs in the RCS Server, the supporting IMS elements, and any RCS file transfer elements shall be provisioned with the payload modifications detailed in the subclauses below. Additionally, if the location present in the RCS payload is the location of the non-target party, and this information is not authorised, the location shall be redacted. If an implementation has location information in other portions of the payload, when the location is included the appropriate modifications shall be made to the encapsulated payload in addition to those specified below prior to the delivery of the message over LI_HI2.

If the geopriv element of presence information is considered to be location, the Content-Type of any body part at any layer of the RCS message is "application/pidf+xml", and if the presence information contains a geopriv element, the character data of each element within each location-info element shall be overwritten with the zero character such that the length of the element does not change.

In some cases, the information that would normally be present in the P-Access-Network-Info or Cellular-Network-Info headers of a SIP message is sent as implementation specific headers within the CPIM headers. In this case, these headers shall be redacted as described in clause 7.12.9.2 when the delivery of P-Access-Network-Info or Cellular-Network-Info is not authorised.

In some cases portions of an encapsulated RCS payload may contain communications content. Unless otherwise specified, all communications content shall be redacted from the encapsulated payload prior to its delivery over LI_HI2. As such, the MDF2 and, optionally, the IRI-POIs in the RCS Server, the supporting IMS elements, and any RCS file transfer elements shall be provisioned with the payload modifications detailed in the subclauses below. If an implementation has communications content in other portions of the payload, the appropriate modifications shall be made to the encapsulated payload in addition to those specified below prior to the delivery of the message over LI_HI2.

If the Content-Type of any body part at any layer of the RCS message is "text" or any of the subtypes of "text", the contents of that body part shall be overwritten with the space character in the original encoding such that the length of the body remains unchanged.

If the delivery of the content of the Subject header is unauthorised, each character of the field-value of the Subject header of any body part of any layer of the RCS message shall be replaced with a space.

If the delivery of Geolocation PUSH messages is unauthorised, if the Content-Type of any body part at any layer of the RCS message is "application/vnd.gsma.rcs-ft-http+xml":

• the value of the label attribute of the data element of the rcspushlocation element shall be overwritten with the "space" character such that the length of the attribute does not change.
• the value of the id attribute of the data element of the rcspushlocation element shall be overwritten with the "space" character such that the length of the attribute does not change.
• the character data of each element within each location-info element shall be overwritten with the zero character such that the length of the element does not change.

If the delivery of the URL of a file being transferred is not authorised, if the Content-Type of any body part at any layer of the RCS message is "application/vnd.gsma.rcs-ft-http+xml":

• the value of any url attribute of the data element of the file-info element shall be overwritten with the "space" character such that the length of the attribute does not change.