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
clause 5.3.2.3
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:
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
clause 5.3.2.3.
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 clause 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 clause 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
clause 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.
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].