Formatting (MS Word) Guidelines(Delete This Section Before Publication)

Formatting (MS Word) Guidelines(Delete this Section before publication)

NEVER use direct formatting (i.e. direct changes to font type, size, style (bold/italic), etc.)!
Use only the predefined Styles that come with this template.
Use the “Formatting in use” view (a.k.a. “Show”) within the “Style and Formatting” task bar which is accessible via the “Format”->”Styles and Formatting” menu.
Direct formatting will cause non-standard Styles to be created. If this occurs, the new Style will be displayed in the “Style and Formatting” task bar.
Avoid creating new Styles. The Styles that are defined should be sufficient. Using only the defined Styles creates greater uniformity among specifications.
The predefined Styles are:

MS Word Style / Usage
Appendix 1-4 / Appendix header
arch / Identifiers/names/values defined by the UPnP Device Architecture
Body Text / Primary textof the document i.e. all text not formatted with another style
Body Text+ Indent1 / Indented variation Body Text
Bold / Adds“bold” formatting toany other style.

Bullet tList

/ Bullet lists
Code / Machine readable examples e.g. programming code, XML, etc.
Figure / Embedded figures.
Figure Title / Title of an embedded figure
forum / Identifiers/names/values defined by the UPnP Working Committees
Head / Header for auto-generated sections such as the Table of Content, etc.
Heading 1-4 / Section headers within the main part of the document i.e. not an appendix.
Hyperlink / URLs
In-line Guidance – 8 pt / Guidance to the author for how to fill in this template. Should be replaced
In-line Guidance: Variable font / Author guidance embedded in another font style.applied in another font style.
Italic / Adds “italic” formatting to any other style.
Normal / Basis for all other styles – DO NOT USE DIRECTLY. Use BodyText instead.
Note / Notation to the reader of the final specification.
SCPD / SCPD template.
Subtitle / Top subtitle field within the spec header – DO NOT USE ELSEWHERE
Subtitle Bottom / Bottom subtitle field in the spec header - DO NOT USEELSEWHERE
Table / An embedded table.
Table Header – Column / Column headerswithin a table
Table Header – Subcolumn / Header of a subcolumn (i.e. a nested column) within table
Table Header – Subcolumn Group / Header of a group of subcolumns within a table
Table Paragraph / Text within an embedded table
Table Title / Title of an embedded table
Title / Title of this spec within the spec header – DO NOT USE ELSEWHERE
Underline / Adds “underlining” to any other style.
vendor / Identifiers/names/values to be defined each vendors

Since changes to the ‘Normal’ Style are inherited by the other Styles, it is strongly recommended to avoid the ‘Normal’ Style but use ‘BodyText’ instead.
It is recommended to check regularly that the ‘Normal’ Style is not used.

Word has several types of Styles. The appearance of a piece of text is usually governed by the superimposing of these different types of Styles. Think of the different types of Styles as layers that can be applied to the same piece of text.
Character Styles: Group characteristics that apply at the character level.
Paragraph Styles:Group characteristics that apply at the paragraph level.
List Styles: Group characteristics of (bulleted) lists.
Table Styles: Group characteristics of tables.
Make fields and bookmarks permanently visible while editing (Tools->Options->View). The brackets indicate which text belongs to the bookmark. This helps in unintentionally bookmarking large chunks of text which then unintentionally show up when referenced.

EditingGuidelines (Delete this Section before publication)

Device Architecture defined entities MUST be formatted using style arch.
Working Committee defined entities (state variables, actions, etc.) MUST be formatted using style forum.
Constants defined in a Service document (allowed value lists, etc.) MUST be formatted using style forum and enclosed in double quotes.
Examples: “PLAYING”, “STOPPED”
Vendor defined entities (state variables, actions, etc.) MUST be formatted using style vendor.
Action names MUST be followed by empty parentheses.
Examples: PrepareForConnection(), Stop(), Play()
State variables and actions defined in other Service documents MUST be preceded by the full service name followed by a double colon.
Examples: AVTransport::Play(), ConnectionManager::ConnectionComplete()
References to sections MUST use active hyperlinks. In general, they MUST be of the form:
Section <paragraph number>, “<paragraph text>”

Appendix <paragraph number>, “<paragraph text>”.

The second part (“<paragraph text>”) MAY be omitted when the reference occurs in tables.

Examples: Section 1.1, “Introduction” and Section 2.6.1.6, “Effect on Device State”

Document MUST comply with RFC2119 (MUST, MAY, …).

In-line guidance is provided throughout the template. In-line guidance is formatted using the In-Line Guidance style. The <COMMENT> tag is used to provide textual guidance. The <SECTION> tag is used as a selector mechanism, based on a condition that is expressed as an attribute of the <SELECT> tag. For example, the following construction indicates that “Section text A” MUST be included in the document text as long as the document version is < 1.00. Once the document reaches version 1.00, “Section text B” MUST be included instead of “Section Text A.”

<SELECT cond="docVersion<1.00">

Section text A

</SELECT>

<SELECT cond="docVersion=1.00">

Section text B

</SELECT>

</SECTION>

All in-line guidance comments and marks MUST be removed from the document before publication.
This document makes extensive use of Bookmarks and Fields. They can be made visible (bookmarks appear in brackets [...], fields appear grey shaded) from the Tools->Options->View menu.
Note: When editing bookmarked text, make sure to stay within the confines of the brackets.

ServiceType:V Service

For UPnP™ Version 1.0

<COMMENT: Choose the appropriate Status level, depending on the development stage of the specification.Consult the Technical Committee Naming Conventions for the meaning of the levels. />

Date: Month DD, YYYY

<COMMENT: example: January 01, 2006/>

Service Template Version: 2.00

This Proposed Service is being made available to UPnP Members pursuant to Section 2.1(c)(ii) of the UPnP Membership Agreement for review and comment by Members to the UPnP Steering Committee regarding the Steering Committee's consideration of the Proposed Service as a Standardized Service. Pursuant to Section 3.1 of the UPnP Membership Agreement, Member has limited rights to use or reproduce the Proposed Service during the comment period and only in furtherance of this review and comment. All such use is subject to all of the provisions of the UPnP Membership Agreement.

THE UPNP FORUM TAKES NO POSITION AS TO WHETHER ANY INTELLECTUAL PROPERTY RIGHTS EXIST IN THE PROPOSED SERVICES, IMPLEMENTATIONS OR IN ANY ASSOCIATED TEST SUITES. THE PROPOSED SERVICES, STANDARDIZED SERVICES, IMPLEMENTATIONS AND ANY ASSOCIATED TEST SUITES ARE PROVIDED "AS IS" AND "WITH ALL FAULTS". THE UPNP FORUM MAKES NO WARRANTIES, EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE WITH RESPECT TO THE PROPOSED SERVICES, STANDARDIZED SERVICES, IMPLEMENTATIONS AND ASSOCIATED TEST SUITES INCLUDING BUT NOT LIMITED TO ALL IMPLIED WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE, OF REASONABLE CARE OR WORKMANLIKE EFFORT, OR RESULTS OR OF LACK OF NEGLIGENCE.

</SELECT>

This Standardized DCP has been adopted as a Standardized DCP by the Steering Committee of the UPnP Forum, pursuant to Section 2.1(c)(ii) of the UPnP Membership Agreement. UPnP Forum Members have rights and licenses defined by Section 3 of the UPnP Membership Agreement to use and reproduce the Standardized DCP in UPnP Compliant Devices. All such use is subject to all of the provisions of the UPnP Membership Agreement.

THE UPNP FORUM TAKES NO POSITION AS TO WHETHER ANY INTELLECTUAL PROPERTY RIGHTS EXIST IN THE STANDARDIZED DCPS. THE STANDARDIZED DCPS ARE PROVIDED "AS IS" AND "WITH ALL FAULTS". THE UPNP FORUM MAKES NO WARRANTIES, EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE WITH RESPECT TO THE STANDARDIZED DCPS, INCLUDING BUT NOT LIMITED TO ALL IMPLIED WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE, OF REASONABLE CARE OR WORKMANLIKE EFFORT, OR RESULTS OR OF LACK OF NEGLIGENCE.

</SELECT>

</SECTION>

Authors[1] / Company
<Author Name>
<COMMENT: Format is "First name" "Last Name";include "(Chair)", "(Vice-Chair)", "(Co-Chair)" or "(Editor)" suffix as appropriate/> / <Official Company Name>
<COMMENT: Table is ordered alphabetically, according to Company Name./>

Contents

Formatting (MS Word) Guidelines (Delete this Section before publication)......

Head......

Editing Guidelines (Delete this Section before publication)......

Contents......

List of Tables......

List of Figures......

1Overview and Scope......

1.1Introduction......

1.2Change Log......

1.3Notation......

1.3.1Data Types......

1.4Vendor-defined Extensions......

1.5References......

1.5.1Normative References......

1.5.2Informative References......

2Service Modeling Definitions (Normative)......

2.1Service Type......

2.2Terms and Abbreviations......

2.2.1Abbreviations......

2.2.2Terms......

2.3ServiceType Service Architecture......

2.4State Variables......

2.4.1State Variable Overview......

2.4.2StateVariableName1

2.4.3StateVariableName2

2.4.4StateVariableName3

2.4.5A_ARG_TYPE_VariableTypeName1

2.5Eventing and Moderation......

2.5.1Eventing of StateVariableName3

2.5.2Table 26: Relationships among State Variables......

2.6Actions......

2.6.1ActionName1()

2.6.2ActionName2()

2.6.3Relationships Between Actions......

2.6.4Error Code Summary......

2.7Service Behavioral Model......

2.7.1State Diagrams......

3Theory of Operation (Informative)......

4XML Service Description......

Appendix A.Title (Normative | Informative)

List of Tables

Table Title

Table 11:...... Change Log

Table 21:...... Abbreviations

Table 22:...... State Variables

Table 23: ...... allowedValueList for the StateVariableName1 state variable

Table 24:...... allowedValueRange for theStateVariableName2 state variable

Table 25:...... Eventing and Moderation

2.5.2Table 26: Relationships among State Variables......

Table 27:...... Actions

Table 28:...... Arguments for ActionName1()

Table 29:...... Error Codes for ActionName1()

Table 210:...... Error Code Summary

Table A1:...... Example

Table A2:...... Example

List of Figures

Figure 31:...... <WC TO COMPLETE CAPTION TEXT>.

Figure 32:...... <WC TO COMPLETE CAPTION TEXT>.

Figure A1:...... <WC TO COMPLETE>.

Figure A2:...... <WC TO COMPLETE>.

1Overview and Scope

This service definition is compliant with the UPnP Device Architecture version 1.0. It defines a service type referred to herein as ServiceType service.

1.1Introduction

The ServiceType service is a UPnP service that allows control points to WC TO COMPLETE. This service provides control points with the following functionality:

WC TO COMPLETE.

...

This service does not provide the following functionality:

WC TO COMPLETE.

...

1.2Change Log

Table 11:Change Log

Date / Version / Editor / Description

</SELECT>

<COMMENT: Delete Change Log from the 1.00 specification./>

</SELECT>

</SECTION>

1.3Notation

In this document, features are described as Required, Recommended, or Optional as follows:

The key words “MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “SHALL NOT,” “SHOULD,” “SHOULD NOT,” “RECOMMENDED,” “MAY,” and “OPTIONAL” in this specification are to be interpreted as described in [RFC 2119].

In addition, the following keywords are used in this specification:

PROHIBITED – The definition or behavior is an absolute prohibition of this specification. Opposite of REQUIRED.

CONDITIONALLY REQUIRED – The definition or behavior depends on a condition. If the specified condition is met, then the definition or behavior is REQUIRED, otherwise it is PROHIBITED.

CONDITIONALLY OPTIONAL – The definition or behavior depends on a condition. If the specified condition is met, then the definition or behavior is OPTIONAL, otherwise it is PROHIBITED.

These keywords are thus capitalized when used to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.

Strings that are to be taken literally are enclosed in “double quotes”.
Words that are emphasized are printed in italic.
Keywords that are defined by the UPnP Working Committee are printed using the forum character style.
Keywords that are defined by the UPnP Device Architecture are printed using the arch character style.
A double colon delimiter, “::”, signifies a hierarchical parent-child (parent::child) relationship between the two objects separated by the double colon. This delimiter is used in multiple contexts, for example: Service::Action(), Action()::Argument, parentProperty::childProperty.

1.3.1Data Types

This specification uses data type definitions from two different sources. The UPnP Device Architecture defined data types are used to define state variable and action argument data types [DEVICE]. The XML Schema namespace is used to define property data types [XML SCHEMA-2].

For UPnP Device Architecture defined Boolean data types, it is strongly RECOMMENDED to use the value “0” for false, and the value “1” for true. The values “true”, “yes”, “false”, or “no” MAY also be used but are NOT RECOMMENDED. The values “yes” and “no” are deprecated and MUST NOT be sent out by devices but MUST be accepted on input.

For XML Schema defined Boolean data types, it is strongly RECOMMENDED to use the value “0” for false, and the value “1” for true. The values “true”, “yes”, “false”, or “no” MAY also be used but are NOT RECOMMENDED. The values “yes” and “no” are deprecated and MUST NOT be sent out by devices but MUST be accepted on input.

1.4Vendor-defined Extensions

Whenever vendors create additional vendor-defined state variables, actions or properties, their assigned names and XML representation MUST follow the naming conventions and XML rules as specified in [DEVICE], Section 2.5, “Description: Non-standard vendor extensions”.

1.5References

1.5.1Normative References

This section lists the normative references used in this specification and includes the tag inside square brackets that is used for each such reference:

COMMENT: Adjust following references as appropriate

The format is as follows:

REFERENCE ::= "[" name "] – "TITLE "," AUTHOR "," DATE "\n"

"Available at:" AVAILABLE "\n"

("Latest version available at:"LATEST "\n")*

Where,

AVAILABLE is a URL to the document as it was at the time the reference was created/updated

LATEST is a URL pointing to the latest editorial update of the document. This URL MUST NOT point to documents that contain more than editorial updates.

Below are examples.

[UPNPDATASTR] – Advanced Data Structures for UPnP, version 1.0, UPnP Forum, DRAFT.
Available at:
Latest version available at:

[DEVICE] – UPnP Device Architecture, version 1.0, UPnP Forum, June 13, 2000.
Available at:
Latest version available at:

[ISO 8601] – Data elements and interchange formats – Information interchange -- Representation of dates and times, International Standards Organization, December 21, 2000.
Available at: ISO 8601:2000.

[RFC 2119] – IETF RFC 2119, Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, 1997.
Available at:

[RFC 3339] – IETF RFC 3339, Date and Time on the Internet: Timestamps, G. Klyne, Clearswift Corporation, C. Newman, Sun Microsystems, July 2002.
Available at:

[XML] – Extensible Markup Language (XML) 1.0 (Third Edition), François Yergeau, Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, eds., W3C Recommendation, February 4, 2004.
Available at:

[XML SCHEMA-2] – XML Schema Part 2: Data Types, Second Edition, Paul V. Biron, Ashok Malhotra, W3C Recommendation, 28 October 2004.
Available at:

</COMMENT>

1.5.2Informative References

This section lists the informative references that are provided as information in helping understand this specificatio:

COMMENT: Adjust following references as appropriate – AV is provided as an example>

[AVARCH] – AVArchitecture:1, UPnP Forum, June 25, 2002.
Available at:
Latest version available at:

</COMMENT>

2Service Modeling Definitions (Normative)

2.1Service Type

The following service type identifies a service that is compliant with this specification:

urn:schemas-upnp-org:service:ServiceType:V

ServiceType service is used herein to refer to this service type.

2.2Terms and Abbreviations

2.2.1Abbreviations

Table 21:Abbreviations

<COMMENT Adjust following table as appropriate – AV is provided as an example, WC may remove CDS, EPG, SRS

Abbreviation / Description
CDS / ContentDirectory Service.
EPG / Electronic Program Guide.
SRS / ScheduledRecording Service.

</COMMENT>

2.2.2Terms

2.2.2.1CDS object

An object in a ContentDirectory service metadata hierarchy; that is: item or container.

2.2.2.2User Channel

A User Channel is a ContentDirectory service object that exposes the (continuous) content stream of a particular broadcast channel. Usually, the actual channel that the User Channel exposes is determined by the user through some device-specific interaction. Examples are: manual programming of a number of channel presets; invoking of the auto-scan functionality of a device; predefined fixed channel assignments by the device manufacturer.

2.2.2.3<WC TO COMPLETE>

WC TO COMPLETE>.

</COMMENT>

2.3ServiceType Service Architecture

<COMMENT: Provide a detailed overview of the service architecture and its basic functionality./>

This service WC TO COMPLETE>.

2.4State Variables

<COMMENT: Provide a high-level introduction of the state variables i.e. describe the types of device state that are exposed. The subsections below describe the specific details of individual state variables./>

Thestate variablesWC TO COMPLETE>.

Note: For first-time reader, it may be more insightful to read the theory of operations first and then the action definitions before reading the state variable definitions.

2.4.1State Variable Overview

Table 22:State Variables

Variable Name / R/O[1] / Data Type / Reference
StateVariableName1 / R / string / See Section 2.4.2
StateVariableName2 / O / ui4 / See Section2.4.3
StateVariableName3 / CR[2] / string (XML fragment) / See Section 2.4.4
... / ... / ... / ...
A_ARG_TYPE_VariableTypeName1 / R / ui4 / See Section 2.4.5

2.4.2StateVariableName1

<COMMENT: Insert a short 1-2 lines description of this state variable here./>