WoT Profile – 25 May 2022

Meeting minutes

Minutes review

<kaz> May-11

Lagally: minutes are approved

Agenda

Lagally: we have some carry overs

Explainer

<kaz> PR 199 - Profile Explainer

<kaz> merged

Issue 200

Issue 184

<kaz> Issue 184 - Check RFC assertions / only single keyword per assertion

<kaz> merged

Issue 183 about privacy considerations

<kaz> Issue 183 - New Section: Privacy Considerations

McCool: it would be better if it is in the end of the document
… we can do a pr to move them
… this is not how we do it elsewhere
… it is a good place to start

Lagally: then let's merge it

Lagally: I will do an editorial cleanup

<kaz> (PR 206 merged, and Issue 183 closed)

Lagally: Issue 182 can be also closed since we merged that PR

Lagally: I will reopen it since we need to move it to another section

Issue 200

<kaz> Issue 200 - Revisit length limits

Lagally: td angle is fit to all, device which does not want limits, consumers which need reasonable limits

Lagally: I have done some homework and looked at databases

Ege: why taking data limits of databases

Lagally: databases have published limits

Lagally: programming languages as well

Ege: we will need to pick a side and that can be politically wrong since we would be biased

Lagally: I think we should take the common maximum

Lagally: Also, we can make a logical thing and say that no id need to be more than 128 bytes

Sebastian: these links are pointing to specific implementations

Sebastian: We also do not know what the limits can be in the future

Sebastian: so I do not understand why we need these limits, a TD should not overwhelm that

Lagally: databases will confuse the values if they exceed a certain length

McCool: we need to look at the implementations and take the common denominator

McCool: we have to look at the different fields and their values

McCool: we should consider different database products

Ege: how will we pick the top 10, the most deployed?

McCool: yes we can take that

Lagally: let's ask her

McCool: we should think of community adoption and limit ourselves to what currently exists

Kaz: I tend to agree with Sebastian, WoT itself does not have any limits. Limitations are caused by the other parts, e.g., existing implementations and related external frameworks. So we should be clear about the distinction within the Profile spec if we need to describe the limitation. Also how to deal with the relationship with the existing external frameworks should be discussed by the Binding Templates from my viewpoint.

<Mizushima> +1 kaz

Ege: what are limiting? TD length, key length or value of the key?

McCool: key length is a valid point, affordance names can be very long

Lagally: I think we should target all of them

Lagally: let's come up with concrete proposals

McCool: let's start with the use cases, what is constraining

Ege: I think we need to be specific with what we are looking at

Lagally: so we have databases, data formats, UI renderers, programming languages

Kaz: having this kind of survey of existing IoT frameworks is fine, but actual data from those external frameworks will come into WoT via Binding Templates. So I think we need to think about how to deal with limitation information (and transfer the information to the core WoT building blocks) within Binding Templates as well.