RFID Device Definition for Web Services on Devices

The following terms have special meaning relating to conformance, and so are always indicated in all capital letters:

• MUST - This word, or the term "REQUIRED", means that the definition is an absolute requirement of the specification.
  
  
• MUST NOT - This phrase means that the definition is an absolute prohibition of the specification.
  
  
• SHOULD - This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
  
  
• SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
  
  
• MAY - This word, or the adjective "OPTIONAL", means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product, while another vendor may omit the same item. An implementation that does not include a particular option MUST be prepared to interoperate with another implementation that does include the option, though perhaps with reduced functionality. An implementation that does include a particular option MUST be prepared to interoperate with another implementation that does not include the option.
  
  

This document uses the terminology defined in the Devices Profile for Web Services [DEVICE], such as: operation, device description, and argument.

Throughout this document, single quotes (‘) are used around literal string and integer values in running text, but not in tables. The single quotes are not part of the values. Double quotes (“) are used around words in running text to indicate special English meanings. Element names and argument names are italicized, and operation names are in bold type.

The Device Type is defined as: “RfidDeviceType”.

• All RFID devices must advertise the RfidDeviceType type, regardless of whether they support DPWS or any proprietary protocols or legacy protocols.
  
  
• All RFID devices that support DPWS metadata must also advertise the dpws:Device type.
  
  
• All RFID devices that support a proprietary protocol MAY advertise a proprietary type (e.g., contoso:UHF). The proprietary type MUST be an empty WebService portType. Each such portType SHOULD have an associated URL scheme. Ex: contoso.tcp://192.168.0.1.
  
  

As specified by [DISCOVERY] as part of the discovery process, a device presents an EndPointReference. This specification further restricts this EndPointReference to have only a stable identifier. We refer to the stable identifier as a “DeviceId”. [DISCOVERY] recommends that the DeviceId be a “urn:uuid:” scheme URI.

For devices that host legacy services but do not use DPWS metadata, their [WS-Discovery] types MUST include the empty WebService portTypes. One or more URL schemes maybe associated with each empty WebService portType. The URL scheme used to advertise each location is one of the URL schemes that is associated with the empty WebService portType.

For devices that host legacy services and use DPWS metadata, use the same types/Address mechanism as in the previous point, but also generate a UUID and ServiceID for each legacy service.