UUIDs (related to GUIDs) are used frequently in computing applications. If you don't know these by name, you will probably recognize the 128-bit value in the format in which it is typically rendered:
7673868d-231e-490d-9c4f-19288e7e668d
This is just an example value--these are usually generated on demand to uniquely identify an object. In WS-Discovery and DPWS, UUIDs are recommended as a way to uniquely identify devices, services, clients, and even individual messages.
Although the process for generating UUIDs is well-understood, there is a lot of inconsistency in how they are renedered in Web Services messages. In most cases, these UUIDs are used as URIs, which means we have to supply a scheme (such as "urn:uuid:"--"http:" is another scheme) in addition to the URI content (the UUID).
It's common to see two URI schemes used to describe UUIDs: "uuid:" and "urn:uuid:" So the example UUID above would be either uuid:7673868d-231e-490d-9c4f-19288e7e668d or urn:uuid:7673868d-231e-490d-9c4f-19288e7e668d, depending on which scheme is used. Here's the difference between the two:
- urn:uuid: is described by RFC 4122 as the correct scheme for rendering a UUID. RFC 4122 is referenced in DPWS, and is a well-accepted way to generate UUIDs in Web Services messages.
- uuid: is common but non-standard. It's often used in specifications developed before RFC 4122 was available; both UPnP and WS-Discovery use uuid:, since both were published before RFC 4122. Unfortunately, uuid: does not conform to any standard.
There are cases where uuid: is explicitly required (UPnP is one of them) but in all other cases, you should consider whether urn:uuid: is a better alternative. In most Web Services applications, urn:uuid: is preferred--in fact, WSDAPI does additional validation on urn:uuid:-scheme URIs that it does not perform on uuid:-scheme URIs.
So if you're implementing DPWS on your own, or are generating UUIDs to pass into WSDAPI, please use the urn:uuid: form whenever possible.
