Peter Saint-Andre
2018-05-02 20:44:08 UTC
Here is a bit more feedback on the URN namespace for device identifiers:
1. Let's drop the pointer to RFC 3406, which was obsoleted by RFC 8141.
2. The text about not expecting these URNs to be resolved, and about not
using r-components from RFC 8141, seems appropriate.
3. As to q-components (RFC 8141, Section 2.3.2), I don't see a need for
passing parameters to devices identified by DEV URNs, so the text about
not using q-components also seems appropriate. However, I'm curious if
other folks know of scenarios where this functionality might be useful.
4. What about f-components? Consider these examples from the spec:
urn:dev:ow:264437f5000000ed_humidity # The laundry sensor's
# humidity part
urn:dev:ow:264437f5000000ed_temperature # The laundry sensor's
# temperature part
The fact that these are "parts" of a sensor makes me wonder if using
f-components would be better:
urn:dev:ow:264437f5000000#ed_humidity
urn:dev:ow:264437f5000000#ed_temperature
5. The organization-defined identifiers (Section 4.3) concern me. I've
seen many unregistered, invalid URN "namespaces" (e.g., "urn:cisco:foo"
while I was at Cisco). This is a bad idea all around, yet I expect that
many people will take the easy way out. Can we strike this section from
the spec and recommend use of the urn:example namespace (BCP 183)?
Peter
1. Let's drop the pointer to RFC 3406, which was obsoleted by RFC 8141.
2. The text about not expecting these URNs to be resolved, and about not
using r-components from RFC 8141, seems appropriate.
3. As to q-components (RFC 8141, Section 2.3.2), I don't see a need for
passing parameters to devices identified by DEV URNs, so the text about
not using q-components also seems appropriate. However, I'm curious if
other folks know of scenarios where this functionality might be useful.
4. What about f-components? Consider these examples from the spec:
urn:dev:ow:264437f5000000ed_humidity # The laundry sensor's
# humidity part
urn:dev:ow:264437f5000000ed_temperature # The laundry sensor's
# temperature part
The fact that these are "parts" of a sensor makes me wonder if using
f-components would be better:
urn:dev:ow:264437f5000000#ed_humidity
urn:dev:ow:264437f5000000#ed_temperature
5. The organization-defined identifiers (Section 4.3) concern me. I've
seen many unregistered, invalid URN "namespaces" (e.g., "urn:cisco:foo"
while I was at Cisco). This is a bad idea all around, yet I expect that
many people will take the easy way out. Can we strike this section from
the spec and recommend use of the urn:example namespace (BCP 183)?
Peter