Reference to the URI Spec (RFC3986) should be replaced with IRI Spec (RFC3987)

[egekorkan]

At base term under Thing information model we reference to RFC3986. However, the IRI spec is behind the anyUri term. We should change that reference.

[ektrah]

I'm not entirely sure I can follow this. All WoT bindings define URI schemes, not IRI schemes. The href in a form is therefore a URI reference, not an IRI reference. And the base for the href is a base URI, not a base IRI. Terms in RDF are IRIs, and xsd:anyURI literals do indeed have the syntax of IRIs, but this is unrelated to the URIs used in the protocols. Switching all WoT bindings from URIs to IRIs would make WoT implementations significantly more complicated, since the protocols ultimately send URIs, not IRIs, and there is generally poor support for IRIs in programming languages.

[egekorkan]

thanks @ektrah for the comment. This came up from the review of the OPC UA Binding document where any unicode character is allowed in the URI, in the query parameters to be specific. So we said that our spec actually allows this and then realized the text in the Thing table pointing to RFC3986. That text is kind of informative kind of not. The information model is normative and that is correct (correct as it is IRI). Some thoughts on the practical side:

• I found this w3c wiki, last updated in 2015: https://www.w3.org/International/wiki/IRIStatus
• We can restrict it per protocol to URIs. OPC UA would not restrict it for example. If this is a solution that works for all, we can add a requirement for binding specs to express this.
• I agree that IRIs are not realistic for protocols. Expecting IRI parsing would be quite unrealistic, as you have mentioned.

In all cases, there is a discrepancy in the spec where we reference URI and IRI at the same time for the same field

[egekorkan]

TD Call:

• @lu-zero : URI parsing libraries work with unicode. DNS had problems before with IRIs -> please keep the host part of the href in ASCII. If the Consumer is very capable, it can handle it. Reviewing the RFCs would be needed to pick the suitable one. A profile can restrict this.
• @ektrah : The bindings we have defined use URIs (HTTP, CoAP and BACnet at least). The driver needs to be able to build the request. The ABNF grammar for OPC UA should be understood to comment on this -> Ege to follow up here. The RFC to use should be URI spec, this would imply taking the description in base and applying it to href
• No protocol can say that this is a URI-based protocol and let TDs contain unicode characters.
• The protocol identification happens via the absolute href value. So the href parsing stays protocol-agnostic. Allowing IRIs for href to be IRI requires all implementations to parse IRIs first.
• A drastic variation could be to signal the protocol with another keyword than href -> This breaks the design we took some time ago to have URI for resources
• IRI to URI conversion is specified in IRI spec. This can be a solution too. -> To be proposed to OPC UA WoT Binding Working Group at OPCF.
• We say that all hrefs are IRIs but if you detect one, you should first convert to URI.

[egekorkan]

TD call today:

• IRI parsing becoming URI parsing is a change but any library that does IRI can do URI so no implementation impact.
• The discrepencies are at Thing:base , Link:href , Form:href -> All should be fixed
• In browsers: The href values can be IRIs but what is sent on the wire is always percent encoded. Thus, we should differentiate between what is in the TD document and what is sent on the wire.
• If the URI Scheme part contains non-ASCII characters (e.g. htäp://), we are either forcing all implementations to parse non-ASCII characters or if they fail to parse, they simply don't support the protocol. Here we can give a behavioral remark on how to identify protocols in a TD. Quick test on Firefox: If it does not recognize the protocol, it does a google search with the string, i.e. typing htäp://example.com results in a google search, same as writing coap://example.com. Typing mailto:example.com opens the email client.
• Initial consensus: We do NOT restrict base or href to a URI. They are IRIs in the specification. A TD document is not restricted as well. The request CAN be percent-encoded (more on this). If the Consumer cannot parse the URI scheme or it does not support the protocol it has identified, it behaves in the same way, i.e. fails, "does a search", shows a message.
  • Question to all: Can we restrict all protocols to percent encode on the wire? I guess not. So all protocol bindings MUST assert on this behavioral aspect. For example, Modbus does not even have URIs, just TCP messages and we describe them with a URI in the Modbus binding.

[mahdanoura]

Please look at RFC 3492 which is about Punnycode encoding. It is used to convert Unicode characters to ASCII. Domain names that have non-ASCII characters in a URI are also converted to ASCII using this algorithm, used by the IDNA protocol.

You can test Punnycode here.

Also, I checked the RFC 3987 which is about IRI's. In section 3.1. there is a mapping process defined to convert IRIs to fully conformant URIs. We could maybe reference this in the spec if needed.

[egekorkan]

TD Call today:

• href and base value: It MUST be URI not an IRI. Thus, the reference in the text of the table is correct. If a protocol needs to use international characters, they should encode.
• Table type with XML Schema: TBD . We don't know what to pick in https://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/ or WebIDL . Worst case we can add a note under anyURI in the table.
• What is sent on the wire: This is protocol-specific and can be decoded from the href if there were international characters that were sent on the wire.