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.

REQUEST

DCP request messages are used to initiate transactions.   They are made up of a request line, followed by message headers and then an optional entity  body.  The structure of the request message follows:

Syntax

REQUEST LINE

The DCP request line is the first part of a request message.  It includes an optional method operator, request method, URI and DCP version.   The semantics for the request line follow.

Syntax

REQUEST METHOD OPERATOR

The request method operator is used to enhance the behavior of a request method.  The presence of an exclamation mark "!" in the first token of a request line indicates that the set of characters to the left of the exclamation mark forms a method operator.  This operator is applied against the request method that follows the exclamation mark and modifies the normal behavior of the request method.

Syntax

REQUEST METHOD

The DCP request method is used to indicate the purpose of a request.  It is applied to the resource referenced by the DCP request URI in the request line.

Syntax

REQUEST URI

The DCP request indicates the resource to which the request method in the request line are to be applied.  The DCP request URI is a Uniform Resource Identifier that has been extended to support devices modeled as objects.

Syntax

The two options for request URI are dependent on the nature of the request.

The dcpUrl form is only allowed when the request is being made to a proxy (or intermediary). The proxy is requested to forward the request and return the response. The proxy may forward the request on to another proxy or directly to the target specified by the dcpUrl. In order to avoid request loops, a proxy must be able to recognize all of its target names, including any aliases, local variations, and the numeric IP address. 

Example: Request Line with absolute DCP URL

GET DCP://x10.domain.com/X10(AC=1,HC=A).Power DCP/1.0

The most common form of the DCP request URI is that used to identify a resource on a target. In this case, only the absDcpPath of the URI is transmitted. 

Example: Request Line with absolute DCP Path

GET X10(AC=1,HC=A).Power DCP/1.0

Note: The absDcpPath cannot be empty; if none is present in the original URI, it must be given as "/" (the target root).

The DCP request URI is transmitted as an encoded string, where some characters may be escaped using the ' "%"  hex hex ' encoding defined by RFC 1738. The target must decode the DCP request URI to properly interpret the request.


REQUEST HEADER FIELDS

Request header fields allow the initiator to pass additional information about the request, and about the initiator itself, to the target. These fields act as request modifiers, with semantics equivalent to the parameters on a programming language method (procedure) invocation.

Request header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields may be given the semantics of request header fields if all parties in the communication recognize them to be request header fields. Unrecognized header fields are treated as entity header fields.

Syntax

© 2000 Chris Armbruster