UUID URI schemes

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.