[MS-GRVWDPP]:
Wide Area Network Device Presence Protocol (WAN DPP)
Intellectual Property Rights Notice for Open Specifications Documentation
Technical Documentation. Microsoft publishes Open Specifications documentation (“this documentation”) for protocols, file formats, data portability, computer languages, and standards support. Additionally, overview documents cover inter-protocol relationships and interactions.
Copyrights. This documentation is covered by Microsoft copyrights. Regardless of any other terms that are contained in the terms of use for the Microsoft website that hosts this documentation, you can make copies of it in order to develop implementations of the technologies that are described in this documentation and can distribute portions of it in your implementations that use these technologies or in your documentation as necessary to properly document the implementation. You can also distribute in your implementation, with or without modification, any schemas, IDLs, or code samples that are included in the documentation. This permission also applies to any documents that are referenced in the Open Specifications documentation.
No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation.
Patents. Microsoft has patents that might cover your implementations of the technologies described in the Open Specifications documentation. Neither this notice nor Microsoft's delivery of this documentation grants any licenses under those patents or any other Microsoft patents. However, a given Open Specifications document might be covered by the Microsoft Open Specifications Promise or the Microsoft Community Promise. If you would prefer a written license, or if the technologies described in this documentation are not covered by the Open Specifications Promise or Community Promise, as applicable, patent licenses are available by contacting .
Trademarks. The names of companies and products contained in this documentation might be covered by trademarks or similar intellectual property rights. This notice does not grant any licenses under those rights. For a list of Microsoft trademarks, visit
Fictitious Names. The example companies, organizations, products, domain names, email addresses, logos, people, places, and events that are depicted in this documentation are fictitious. No association with any real company, organization, product, domain name, email address, logo, person, place, or event is intended or should be inferred.
Reservation of Rights. All other rights are reserved, and this notice does not grant any rights other than as specifically described above, whether by implication, estoppel, or otherwise.
Tools. The Open Specifications documentation does not require the use of Microsoft programming tools or programming environments in order for you to develop an implementation. If you have access to Microsoft programming tools and environments, you are free to take advantage of them. Certain Open Specifications documents are intended for use in conjunction with publicly available standards specifications and network programming art and, as such, assume that the reader either is familiar with the aforementioned material or has immediate access to it.
Revision Summary
Date / Revision History / Revision Class / Comments4/4/2008 / 0.1 / New / Initial Availability
6/27/2008 / 1.0 / Major / Revised and edited the technical content
10/6/2008 / 1.01 / Editorial / Revised and edited the technical content
12/12/2008 / 1.02 / Editorial / Revised and edited the technical content
7/13/2009 / 1.03 / Major / Revised and edited the technical content
8/28/2009 / 1.04 / Editorial / Revised and edited the technical content
11/6/2009 / 1.05 / Editorial / Revised and edited the technical content
2/19/2010 / 2.0 / Minor / Updated the technical content
3/31/2010 / 2.01 / Editorial / Revised and edited the technical content
4/30/2010 / 2.02 / Editorial / Revised and edited the technical content
6/7/2010 / 2.03 / Editorial / Revised and edited the technical content
6/29/2010 / 2.04 / Editorial / Changed language and formatting in the technical content.
7/23/2010 / 2.05 / Minor / Clarified the meaning of the technical content.
9/27/2010 / 2.05 / None / No changes to the meaning, language, or formatting of the technical content.
11/15/2010 / 2.05 / None / No changes to the meaning, language, or formatting of the technical content.
12/17/2010 / 2.05 / None / No changes to the meaning, language, or formatting of the technical content.
3/18/2011 / 2.6 / Minor / Clarified the meaning of the technical content.
6/10/2011 / 2.6 / None / No changes to the meaning, language, or formatting of the technical content.
1/20/2012 / 3.0 / Major / Significantly changed the technical content.
4/11/2012 / 3.0 / None / No changes to the meaning, language, or formatting of the technical content.
7/16/2012 / 3.0 / None / No changes to the meaning, language, or formatting of the technical content.
10/8/2012 / 3.0 / None / No changes to the meaning, language, or formatting of the technical content.
2/11/2013 / 3.0 / None / No changes to the meaning, language, or formatting of the technical content.
7/30/2013 / 3.0 / None / No changes to the meaning, language, or formatting of the technical content.
11/18/2013 / 3.0 / None / No changes to the meaning, language, or formatting of the technical content.
2/10/2014 / 3.0 / None / No changes to the meaning, language, or formatting of the technical content.
4/30/2014 / 3.0 / None / No changes to the meaning, language, or formatting of the technical content.
7/31/2014 / 3.0 / None / No changes to the meaning, language, or formatting of the technical content.
10/30/2014 / 3.0 / None / No changes to the meaning, language, or formatting of the technical content.
6/23/2016 / 3.0 / None / No changes to the meaning, language, or formatting of the technical content.
Table of Contents
1Introduction
1.1Glossary
1.2References
1.2.1Normative References
1.2.2Informative References
1.3Protocol Overview (Synopsis)
1.3.1Messages
1.3.2Example Message Flow
1.4Relationship to Other Protocols
1.5Prerequisites/Preconditions
1.6Applicability Statement
1.7Versioning and Capability Negotiation
1.8Vendor-Extensible Fields
1.9Standards Assignments
2Messages
2.1Transport
2.2Message Syntax
2.2.1Publish for WAN DPP 4.1
2.2.2Publish for WAN DPP 5.0
2.2.3Subscribe for WAN DPP 4.1
2.2.4Subscribe for WAN DPP 5.0
2.2.5Unsubscribe for WAN DPP 4.1
2.2.6Unsubscribe for WAN DPP 5.0
2.2.7Notify for WAN DPP 4.1
2.2.8Notify for WAN DPP 5.0
2.2.9Noop for WAN DPP 4.1
2.2.10Noop for WAN DPP 5.0
2.2.11VersionRejected for WAN DPP 4.1
2.2.12VersionRejected for WAN DPP 5.0
3Protocol Details
3.1Common Details
3.1.1Abstract Data Model
3.1.2Timers
3.1.3Initialization
3.1.4Higher-Layer Triggered Events
3.1.5Message Processing Events and Sequencing Rules
3.1.6Timer Events
3.1.7Other Local Events
3.1.7.1Open WAN DPP Session
3.2Publishing Client Details
3.2.1Abstract Data Model
3.2.2Timers
3.2.3Initialization
3.2.4Higher-Layer Triggered Events
3.2.4.1Application Requires its Presence Information Published
3.2.4.2Application Closes
3.2.5Message Processing Events and Sequencing Rules
3.2.5.1Receiving a VersionRejected Message
3.2.5.2Receiving a WAN DPP message
3.2.6Timer Events
3.2.7Other Local Events
3.2.7.1WAN DPP Session Closed
3.2.7.2Presence Information Changed
3.3Subscribing Client Details
3.3.1Abstract Data Model
3.3.2Timers
3.3.3Initialization
3.3.4Higher-Layer Triggered Events
3.3.4.1Application Requires Presence Information for a Device
3.3.4.2Application No Longer Requires Presence Information for a Device
3.3.5Message Processing Events and Sequencing Rules
3.3.5.1Receiving a Notify Message
3.3.5.2Receiving a VersionRejected Message
3.3.6Timer Events
3.3.7Other Local Events
3.3.7.1WAN DPP Session Opened
3.3.7.2WAN DPP Session Closed
3.4Presence Server Details
3.4.1Abstract Data Model
3.4.2Timers
3.4.3Initialization
3.4.4Higher-Layer Triggered Events
3.4.4.1Request to Issue Notify Message
3.4.5Message Processing Events and Sequencing Rules
3.4.5.1Receiving a Publish Message
3.4.5.2Receiving a Subscribe Message
3.4.5.3Receiving an Unsubscribe Message
3.4.5.4Receiving a Notify Message
3.4.5.5Receiving a VersionRejected Message
3.4.5.6Receiving a Noop Message
3.4.6Timer Events
3.4.7Other Local Events
3.4.7.1WAN DPP Session from Client Terminated
4Protocol Examples
4.1Separate Publisher and Subscriber Roles
4.2Simultaneous Publishing and Subscribing
4.3Clients Utilizing Separate Presence Servers Using WAN DPP 4.1
4.4Messages
4.4.1Publish for WAN DPP 4.1
4.4.2Subscribe for WAN DPP 4.1
4.4.3Unsubscribe for WAN DPP 4.1
4.4.4Notify for WAN DPP 4.1
4.4.5Publish for WAN DPP 5.0
4.4.6Subscribe for WAN DPP 5.0
4.4.7Unsubscribe for WAN DPP 5.0
4.4.8Notify for WAN DPP 5.0
5Security
5.1Security Considerations for Implementers
5.2Index of Security Parameters
6Appendix A: Product Behavior
7Change Tracking
8Index
1Introduction
This document specifies the Wide Area Network Device Presence Protocol (WAN DPP). This protocol is used by clients and servers to enable clients to discover and acquire the presence information of other cooperating devices. WAN DPP is a message-based protocol that requires a network transport that guarantees reliable and ordered delivery.
The WAN DPP protocol supports the following capabilities:
Client publication of its presence information to a server.
Subscription to presence information.
Server notification of published presence information to subscribing clients.
This document specifies the following:
How messages are encapsulated on the wire, common data types, and requirements in section 2.
Protocol details, including client and server details, in section 3.
Protocol examples in section 4.
Security considerations for implementers in section 5.
Product Behavior in appendix A.
Sections 1.5, 1.8, 1.9, 2, and 3 of this specification are normative. All other sections and examples in this specification are informative.
1.1Glossary
This document uses the following terms:
ASCII: The American Standard Code for Information Interchange (ASCII) is an 8-bit character-encoding scheme based on the English alphabet. ASCII codes represent text in computers, communications equipment, and other devices that work with text. ASCII refers to a single 8-bit ASCII character or an array of 8-bit ASCII characters with the high bit of each character set to zero.
big-endian: Multiple-byte values that are byte-ordered with the most significant byte stored in the memory location with the lowest address.
connection: A link between two devices that uses the Simple Symmetric Transport Protocol (SSTP). Each connection can support one or more SSTP sessions.
device: A client or server computer that uses a device URL to identify itself as an endpoint (5) for synchronizing account data.
device URL: A unique identifier for a client device, as described in [RFC3986].
empty string: A string object or variable that is initialized with the value "".
Internet Protocol version 4 (IPv4): An Internet protocol that has 32-bit source and destination addresses. IPv4 is the predecessor of IPv6.
Internet Protocol version 6 (IPv6): A revised version of the Internet Protocol (IP) designed to address growth on the Internet. Improvements include a 128-bit IP address size, expanded routing capabilities, and support for authentication (2) and privacy.
little-endian: Multiple-byte values that are byte-ordered with the least significant byte stored in the memory location with the lowest address.
network address translation (NAT): The process of converting between IP addresses used within an intranet, or other private network, and Internet IP addresses.
notify: The process of sharing presence information with subscribed client devices by using the Wide Area Network Device Presence Protocol (WAN DPP).
presence: A status indicator on a client device that is transmitted by using the Wide Area Network Device Presence Protocol (WAN DPP).
presence information: A set of metadata for a client device, including IP address, port, and connection status.
presence server: A protocol server that uses Wide Area Network Device Presence Protocol (WAN DPP) to communicate presence information for client devices and to process both publish and subscribe messages from client devices.
publish: The process of posting presence information from a client device to a presence server by using the Wide Area Network Device Presence Protocol (WAN DPP).
session: A unidirectional communication channel for a stream of messages that are addressed to one or more destinations. A destination is specified by a resource URL, an identity URL, and a device URL. More than one session can be multiplexed over a single connection.
Simple Symmetric Transport Protocol (SSTP): A protocol that enables two applications to engage in bi-directional, asynchronous communication. SSTP supports multiple application endpoints (5) over a single network connection between client nodes.
subscribe: The process of registering to receive updates about presence information for client devices. The updates are delivered by using Wide Area Network Device Presence Protocol (WAN DPP).
Transmission Control Protocol (TCP): A protocol used with the Internet Protocol (IP) to send data in the form of message units between computers over the Internet. TCP handles keeping track of the individual units of data (called packets) that a message is divided into for efficient routing through the Internet.
MAY, SHOULD, MUST, SHOULD NOT, MUST NOT: These terms (in all caps) are used as defined in [RFC2119]. All statements of optional behavior use either MAY, SHOULD, or SHOULD NOT.
1.2References
Links to a document in the Microsoft Open Specifications library point to the correct section in the most recently published version of the referenced document. However, because individual documents in the library are not updated at the same time, the section numbers in the documents may not match. You can confirm the correct section numbering by checking the Errata.
1.2.1Normative References
We conduct frequent surveys of the normative references to assure their continued availability. If you have any issue with finding a normative reference, please contact . We will assist you in finding the relevant information.
[MS-GRVSSTP] Microsoft Corporation, "Simple Symmetric Transport Protocol (SSTP)".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997,
1.2.2Informative References
[MS-GRVHENC] Microsoft Corporation, "HTTP Encapsulation of Simple Symmetric Transport Protocol (SSTP)".
1.3Protocol Overview (Synopsis)
The Wide Area Network Device Presence Protocol (WAN DPP) supports the publication and discovery of presence information for client devices. WAN DPP uses Simple Symmetric Transport Protocol (SSTP) as its transport, as described in [MS-GRVSSTP]. This specification defines WAN DPP versions 4.1 and 5.0.
WAN DPP uses a publish-subscribe model where clients publish their device information to WAN DPP servers and subscribe to WAN DPP servers for the published device information of specified devices. WAN DPP servers notify subscribed clients of updates to published presence information.
Device URLs identify WAN DPP client devices. Each WAN DPP client is assigned to a presence server. The mechanism for determining device URLs and presence servers is application-dependent and is outside the scope of this document.
Device presence information consists of a client device’s online status, the TCP port number and IP addresses on which the client device listens for SSTP messages, and other information that can be used by peer clients to determine connectivity.
The WAN DPP system involves the following roles:
A publishing client that sends its device presence information to a presence server.
A subscribing client that subscribes to device presence information stored on a presence server.
A presence server that stores publishingclients’ presence information and notifies subscribing clients of updates to this information.
Any WAN DPP device can implement any combination of these roles.
These roles are associated with WAN DPP messages, as described in the following sections.
1.3.1Messages
WAN DPP messages are as follows:
Publish – This message is sent from a client to a server to post device presence information.
Subscribe – This message is sent to a server to request device presence information for specific devices that publish their online status on the server.
Unsubscribe – This message is sent to a server, instructing the server to stop sending Notify messages for a device to which the client previously subscribed.
Notify – This message is sent from a presence server in response to a subscription message, providing presence information for the requested devices. Whenever the presence information for a device changes, the server sends Notify messages.
Noop– This message is sent from a client to a server. It has no purpose relevant to WAN DPP.
VersionRejected – This message is sent from a server to a client to support protocol version negotiation.
1.3.2Example Message Flow
The following diagram illustrates a basic WAN DPP message flow between two client devices and a presence server, where Client 2 sends a Subscription to the presence server requesting the published device presence information of Client 1.
Figure 1: WAN DPP Message Flow
1.4Relationship to Other Protocols
WAN DPP depends upon the underlying application-level SSTP protocol on client and server devices. The SSTP protocol guarantees message delivery and preserves the order of WAN DPP messages.
WAN DPP uses Simple Symmetric Transport Protocol (SSTP) as its transport, as described in [MS-GRVSSTP]. The session capabilities of SSTP enable WAN DPP to establish bi-directional communications between a client and a presence server. All messages sent from the client to the presence server flow over one SSTP session; messages from the presence server to the client flow over another session. The SSTP application layer transport can be encapsulated in a standard HTTP connection over port 80/TCP, as described in [MS-GRVHENC].
The following diagram shows the underlying messaging and transport stack used by the protocol:
Figure 2: This protocol in relation to other protocols
1.5Prerequisites/Preconditions
WAN DPP requires client devices to be assigned a presence server and a Device URL by a higher-level application or protocol.
1.6Applicability Statement
Presence servers collect and store the device addresses and online status of published clients. Applications can use WAN DPP to exchange presence information between devices.
1.7Versioning and Capability Negotiation
This document covers versioning issues in the following areas:
Supported Transports: WAN DPP uses SSTP as its transport.
Protocol Versions: For an established SSTP connection which is using SSTP version 1.5, as determined by the SSTP active connection Version state variable described in [MS-GRVSSTP], WAN DPP Version 4.1 is used. For an SSTP connection using SSTP 1.6, WAN DPP Version 5.0 is used.
Security and Authentication Methods: WAN DPP relies on SSTP for security and authentication, as described in [MS-GRVSSTP].
Capability Negotiation: WAN DPP supports limited version negotiation using the VersionRejected message described in section 3.
1.8Vendor-Extensible Fields
None.
1.9Standards Assignments
None.
2Messages
2.1Transport
WAN DPP messages are sent over SSTP sessions between two devices. SSTP sessions depend on an established SSTP connection. Because each SSTP session carries messages in only one direction, two sessions are required for bi-directional exchange. Creating an SSTP session requires three parameters: ResourceURL, IdentityURL, and DeviceURL. WAN DPP sessions are created using specific values for these parameters. For more details about opening SSTP connections and sessions, see [MS-GRVSSTP].
For any session opened to a presence server<1>:
The ResourceURL MUST be "grooveWanDPP".
The IdentityURL MUST be an empty string.