Meeting minutes
Minutes
https://
EK: Minutes from Wednesday are approved
Quick Schedule
URI vs IRI
<Ege> w3c/
EK: Issue come out of an OPC-UA discussion
<Ege> https://
EK: the URI schema for OPC-UA contains s= meaning a string
… protocol allows any string which is UTF8 encoded
… technically possible
… can contain German Umlaut or Japanese characters
… we noticed discrepancy
… we reference RFC3986
… anyURI is IRI
… both are in normative tables and we have some conflict
KH: in href we say IRU and not URI
EK: Correct
… I think W3C review asked us to use IRI
… but correct, there is a discrepancy
… IRI parsing not common in code basis
… I found https://
EK: We can restrict it per protocol to URIs
LB: Would it be enough to point IRI RFC
… saying non ASCII characters are allowed
… most parsing libraries do work with unicode
… main problem is weird escaping
… DNS had problems with IRI
… we could restrict strings to UTF8
EK: IRI handling in specific parts only?
LB: yes, but sounds more profile worthy
… we should review the RFCs
… and pick the one that fits our target
… TD should give freedom
… profile can restrict
KH: We want address resources on the Web
… we should use Web standards
… we can choose URL, IRI etc
… no matter of taste
… it is about protocol
… protocol driver (HTTP, CoAP) needs to know
… so far URI standard is used
… value in href field (or base field) use URI
<luca_barbato> Related specifications: https://
KH: w.r.t. to OPC-UA I need to see the ABNF grammar
EK: Document is open to members
… not sure if it contains ABNF
KH: There should be something
… saying URI or IRI
… you cannot say URI standard and put unicode characters in query string
LB: We can make it extra flexible
… field is UTF8 string and offload it to protocol
KH: This cannot work
… because of base
EK: True
… unless we indicate in a different way the protocol
KH: We could get rid of base and href ...
… and come upo with a combined string per protocol
… but it creates major problems
MN: hypermedia concept claim does no longer make sense also
LB: Easiest thing is to pick the right definittion of href
… additional field for anything we cannot support
KH: I would go with URI
… no huge problem, I think we need a pragmatic solution
… for base is correct
… for href it should be used URI also (currently not the case)
LB: Uniform to URI
KH: Yes, it should be always been URI
… there are options to support unicode in URI
… we need to better understand the OPC-UA requirements
EK: IRI to URI is in RFC?
KH: Yes, there is a conversion algorithm
… UTF8 bytes to percentage encoding
DP: the OPCUA binding requires percentage encoding
EK: Not sure
KH: We need to check we (or OPCUA) violate the standard
EK: Let's look at the OPC spec
KH: Next week Wed I cannot join, I can join Thursday
EK: Thanks!
<egekorkan> w3c/
Common definitions
w3c/
EK: I started the exercise to extend the examples
EK: examples at line 454
… recommendedTDs
… e.g., change from default contentType JSON to cbor etc
… or Modbus with all parameters
… multi IP addresses
… local vs public security
EK: Do you see more useful examples?
… to test this new method
… will show it tomorrow in more details
… please provide feedback in PR
… in PR I summarized also some of my findings
Bindings
<egekorkan> github.com/w3c/wot-binding-templates/pull/446
<egekorkan> w3c/
EK: realized some mistakes
… no proper rendering for Modbus
… the same stupid error appeared more often
… I also updated the authors
… same change everywhere expect Modbus with more changes
… I will wait a bit for feedback
KH: Wonder why S has been removed in general
EK: We started off with S and changed later on
… due to W3C feedback
KH: I see
KH: IANA uses plural and W3C seems to use singular
[adjourned]