Device Control Protocol Specification (DCP)
 an Internet Protocol for Controlling Devices

CONTENTS

Up
Introduction
Conventions
Parameters
Fundamentals
Message Format
Requests
Responses
Entities
Request Methods
Reserved Objects
Status Codes
Headers
Session Management
Authentication
Security
XML DTD

 

[ Back ] [ Next ]

 

 

 

 

Click Here to visit the home page belonging to the creator of DCP and get access to other downloads, including a white paper on forward compatible design for the Internet.

SESSION MANAGEMENT

DCP makes use of special request header fields and response status codes for managing sessions.  Sessions may be managed explicitly and implicitly, friendly and unfriendly, and as an initiator or as a target.  The semantics for the various methods of opening and closing sessions follow.

Opening Sessions

Explicit Open:

  1. Either party makes a  request against the other.  The request must carry the Session message header with a value of  "Open" and, optionally, the Session-ID message header with a valid uniqueId. 

  2. The target responds with a 200 OK or 201 OK, Pending status code followed by the Session-ID message header.  

    • If the request had a valid uniqueId, then the target must assign the same uniqueId to the Session-ID message header and process the transaction. 

    • If there was not a valid uniqueId present, then the Target must assign one and process the transaction. The target may associate the transaction with an already active session. 

    • If the request had a valid uniqueId that corresponds to an active session between the two resources then the target must associate the request with the session (rather than opening a new session) and process the transaction.  

Note: If for any reason the target wishes to refrain from processing the transaction because of the uniqueId identified by the Session-ID message header in the request or due to an inability to open a session, the 402 Session Error response status code should be used.

Implicit Open:

  1. Either party initiates a request against the other which does not include Session message header.

  2. The target responds with a 200 OK or 201 OK, Pending status code followed by the Session-ID message header. 

    • If the request did not include a valid uniqueId, then the target must create a session, assign a uniqueId to the Session-ID message header and processes the transaction.  The target may associate the transaction with an already active session.

    • If the request included a valid uniqueId that does not correspond to an active session, then the target must create a session, assign the unrecognized uniqueId to the Session-ID message header and process the transaction.

    • If the request included a valid uniqueId that corresponds to an active session, then the target must associate the request with the session (rather than opening a new session) and process the transaction. 

Note: If for any reason the target wishes to refrain from processing the transaction because of the uniqueId identified by the Session-ID message header in the request or due to an inability to open a session, the 402 Session Error response status code should be used.

 
Closing Sessions

Friendly Close as an Initiator:

  1. Either party makes a request against the other followed by the Session message header with a value of  "Closing" and the Session-ID message header with corresponding uniqueId.

  2. The target responds as follows:

Friendly Close as a Target:

Note: There is not a friendly method for closing a session as a target.  However, after the target completes a transaction, it may generate a request against the other party and close the session in a friendly manner as an initiator.  

Unfriendly Close as an Initiator:

  1. Either party makes a request against the other followed by the Session message header with a value of  "Closed" and the Session-ID message header with corresponding uniqueId.

  2. The target processes a transaction and responds with a 200 OK,  201 OK, Pending or 203 Release status code followed by the Session-ID message header with corresponding uniqueId. 

Unfriendly Close as a Target:

  1. The target processes a transaction and responds to a request with the 203 Release status code followed by the Session-ID message header with corresponding uniqueId.

    Note: The target may assume that unfriendly closes are acceptable etiquette in the following situations:

  2. The initiator should consider that the session is closed after the transaction is complete.

 

Session Etiquette

Initiator Guidelines (these are not requirements):

  1. For saving target resources: 

    • When an initiator does not wish to keep a session open after a transaction, the request should contain the Session message header with a value of "Closing".

  2.  For cooperating with the target:

    • When a response includes a 203 Release status code, the initiator should treat the session as closed.

    • When a response includes a 202 Keep-Alive status code as a result of a friendly initiator close, the initiator should keep the session open. 

  3. For being friendly:

    • When an initiator "times-out" an idle session, it should perform a friendly initiator close.

  4. For being straight-forward:

Target Guidelines (these are not requirements):

  1. For saving initiator resources:  

  2. For cooperating with the  initiator:

    • When requests include the Session message header with a value of "Open", the target should assume that the initiator wishes to keep the session open after the transaction.

    • When requests include the Session message header with a value of "Close" or "Closing", the target should assume that the initiator wishes to close  the session after the transaction.

  3.  For being friendly:

  4. For being straight-forward:

    • Targets should use the appropriate response status code to appropriately represent their needs in conjunction with the Session-ID message header with corresponding uniqueId.

© 2000 Chris Armbruster