5.3 Activation for Syndicated Feed Reception
26.1503GPPProtocols and codecsRelease 17Syndicated Feed Reception (SFR) within 3GPP environmentsTS
5.3.1 Introduction
Reception activation procedures of OMA DCD [5] are re-used to activate optimized reception of syndicated feeds.
5.3.2 Activation triggered by the client
5.3.2.1 Activation to a default SFR server.
The SFR enabled Feed Reader is configured to a default SFR server. See section 5.1 of [5] and perform the activation to that SFR server. Details of the activation parameters are described in section 5.3.2.3
5.3.2.2 Discovery of a new SFR server via URI scheme
The SFR enabled Feed Reader shall be able to identify whether this feed is an SFR feed or a legacy ATOM/RSS feed. The syndicated feed URI follows a predefined URI scheme in order to identify the SFR server and provide relevant connection parameters associated with the SFR server. If such a feed URI is identified the SFR enabled Feed Reader uses the SFR parameters contained in the URI scheme to send an activation request to the SFR server.
Example of flow:
Figure 3: Discovery of a new SFR server via URI scheme
In order for SFR enabled Feed Reader to connect to a new SFR server the following parameters shall be included in the URI (based on DCD-3 connection profile see Section 8.1.2 of [5]):
– SFR server address: address (URL) of the SFR server with which the SFR enabled Feed Reader should activate.
– Proxy: address (IP address or hostname) of the proxy that should be used for communications with SFR server. This parameter may be omitted if no proxy is required to connect to the SFR server.
– Data connection details: Additional bearer-network-specific connection details e.g. APN, data connection username/password, etc. This parameter may be omitted if no additional data connection details are required to connect to the SFR server.
Example of SFR URI:
<http://www.SFR.org/abcTopNews ? server-address=’10.24.122.26:8080′ >
Upon reception of these parameters, the SFR enabled Feed Reader shall send an activation request message as specified in section 7.1.3.1 of [5] to the server address retrieved as part of the URI parameters. Once the SFR enabled Feed Reader activation is complete, an SFR enabled Feed Reader sends registration and channel subscription request(s), as specified in [5].
The SFR enabled Feed Reader may combine all 3 requests into a single request using multipart HTTP requests. With this approach the assumption is that authentication (basic, digest, or TLS) associated with activation request is sufficient to facilitate registration and subscription combined into the single transaction with activation. In other words, as registration and subscription requests are bundled with authenticated activation request there’s no need to send session ID with these requests.
Details of the activation process are described in 5.3.2.3
5.3.2.3 Activation process
Each SFR enabled Feed Reader must perform at least once the "Activation for Syndicated Feed Reception" procedure as defined in this section before using any other syndicated feed optimization procedure.
Figure 4: Activation and registration Procedure
The procedure uses a subset of OMA DCD procedures, namely the Client Activation (defined in section 7.1.3.1 of [5]) and the Application Registration (defined in section 7.1.3.3 of [5]) procedures. Client activation procedure and application registration procedure are separate transactions to allow an OMA DCD like implementation of syndicated feed reception.
Information Elements (IE) of the ClientActivationRequest Message:
– Device-ID: Optional in OMA DCD and SFR.
– Version: The Version IE is mandatory in OMA DCD and SFR. The Version shall take the value "SFR1.0".
Information Elements of the ClientActivationResponse Message
– Session-ID: Conditional in OMA DCD and SFR. The SFR server provides the Session-ID in case of successful client activation. The "Session-ID" is used in subsequent transactions with the SFR server.
Information Elements of the ApplicationRegistrationRequest message:
– Session-ID: Mandatory in OMA DCD. The Session-ID value is provided during ClientActivationResponse. Usage for SFR is mandatory.
– Application-Profile including the channel-selection-metadata: Mandatory in DCD. Relevant subset of DCD metadata for SFR is defined in section 5.7.
Information Elements of the ApplicationRegistrationResponse message:
– Session-ID: Mandatory in OMA DCD and SFR.
– Message-ID: Mandatory in OMA DCD and SFR.
– Channel-Guide including general-channel-metadata: Mandatory in OMA DCD and SFR. Relevant subset of the general channel metadata for SFR is defined in section 5.7.
The activation procedure may include authentication and authorization transactions. Authentication and Authorization shall follow "HTTP Digest Authentication" as defined in section 10.1.1.2 of [5].
The SFR enabled Feed Reader may combine multiple requests (ClientActivationRequest, ApplicationRegistrationRequest and ChannelSubscriptionRequest (see section 5.4) into a single request using multipart HTTP requests. With this approach the assumption is that authentication (basic, digest, or TLS) associated with activation request is sufficient to facilitate registration and subscription combined into the single transaction with activation. In other words, as registration and subscription requests are bundled with authenticated activation request there’s no need to send session ID with these requests.
5.3.2.4 Deactivation process
The deactivation process can be initiated by the SFR enabled Feed Reader or by the SFR server.
The process for SFR enabled Feed Reader initiated deactivation process is specified in section 7.1.3.2 of [5] and the information elements contained in the ClientDeactivationRequest and ClientDeactivationResponse messages are specified in section 7.1.3.2.1 of [5]
The process for SFR server initiated deactivation process is specified in section 7.1.3.2.2 of [5].
5.3.3 Activation triggered by the network
Upon discovery of an external feed, the SFR enabled Feed Reader is provided with a feed URI. The SFR enabled Feed Reader shall be able to identify whether this feed is associated with a new SFR server.
The SFR enabled Feed Reader fetches the feed URI and provides the SFR UAProf parameters as part of the request. Upon reception of such parameters, the SFR server initiates the activation process with the SFR enabled Feed Reader.
The SFR enabled Feed Reader shall pass the UAProf with the following SFR extensions when sending the HTTP GET discovery request message to the feed URI.
Attribute = SFR Version
Attribute = DeviceID
Figure 5: Activation triggered by the network
Upon receipt of the extended UAProf, the new SFR server shall send to the SFR enabled Feed Reader a RequestForClientActivation message as specified in section 7.1.3.1.2 of [5]. This is followed by a ClientActivationRequest and ClientActivationResponse as specified in section 5.3.2.3. Upon completion of the activation process the SFR enabled Feed Reader registration and channel subscription request as specified in sections 7.1.3.3 and 7.1.3.7 of [5] are issued.
The SFR enabled Feed Reader may combine all 3 requests into a single request using multipart HTTP requests. With this approach the assumption is that authentication (basic, digest, or TLS) associated with activation request is sufficient to facilitate registration and subscription combined into the single transaction with activation. In other words, as registration and subscription requests are bundled with authenticated activation request there’s no need to send session ID with these requests.
Information Elements (IE) of the RequestForClientActivation Message:
If the feed is available at an SFR server with which the SFR enabled Feed Reader is configured with; the RequestForClientActivation message shall contain only the dcd-3-connection-profile-name parameter specified in section 7.1.3.1.2 of [5] shall be used.
If the feed is available at a new SFR server, the RequestForClientActivation message shall only contain the dcd-3-connection-profile parameters specified in section 7.1.3.1.2 of [5].
Information Elements (IE) of the SFR enabled Feed Reader registration and channel subscription request messages are specified in sections 5.2.2 and 5.3.2.3.