The “WindowsUri” protocol is a means of abstracting a subscription for a simple URI string. Windows will subscribe to this type in order to register with the driver that Windows is interested in receiving URIs that the user may be interested in launching.
- The driver MUST return the URI string as a NULL-terminated UTF-16LE encoded string for “WindowsUri” subscribers.
- The driver MUST treat the input payload of “WindowsUri” publications as a UTF-16LE encoded string. The driver MUST safely accept either NULL-terminated or NON-NULL-terminated inputs.
- If the proximity technology is advertised as NFC, then the driver MUST treat subscriptions for the “WindowsUri” Type as equivalent to a subscription for the URI payload within an “NDEF:wkt.U” or “NDEF:wkt.Sp” message.
- The driver MUST also match a “WindowsUri” subscription with the URI payload within an “NDEF:wkt.Sp” message. All subscriptions to “NDEF:wkt.Sp” MUST be filled with the full payload of a “NDEF:wkt.Sp” message. If the NDEF message contains both a smart poster and a non-nested URI record, the URI record must be ignored.
- The driver MUST return only the URI string PAYLOAD of this message to subscribers of this type. The driver MUST NOT return the full NDEF message to subscribers of this type.
- If the proximity technology is advertised as NFC, then the driver MUST encapsulate the payload of each “WindowsUri” publication within NDEF messages as specified in [NFC URI].
- The provider MAY support other compatible schemes as well.
This is a special type of WindowsUri publication that allows a URI to be written to any writeable tag.
- The common “*:WriteTag” requirements described elsewhere apply.
- The above “WindowsUri” publication requirements also apply to “WindowsUri:WriteTag” publications.