On 12/04/2017 11:45 PM, Thiago Macieira wrote:
> On Monday, 4 December 2017 19:10:53 PST Gregg Reynolds wrote:
>> Sorry about previous message. New phone
>>
>> Anyway, hmmm. If that is the case what is the point of certification?
>> Nobody asks a web server for that kind of certification, it all just works.
>> Is there anything to certification beyond marketing?
>
> You're thinking like a software developer.
>
> All USB devices are certified before they can use that trident logo. WiFi
> devices are certified before they can use the logo. Bluetooth devices are
> certified before they can use the stylised B logo.
Too-simplistic view: certification is for instances, not for classes :)
You need a fully instantiated device for the certification to make
sense, source code which can be compiled 2^10 different ways does not.
> The logo is a bit of information for end users that the device has been
> tested
> to conform to the specification.
>
> Here's what OCF hasn't decided on yet: what happens to things that are pure
> software? If I download an application for my router, does the app get a logo?
Don't know if this is of interest to anyone else, but:
I can say from my time working on OCF certification that the intent was
always for app cert to be possible. I was never sure if there would be a
lot of market for it (won't speak for anyone else on that, just my
opinion). If I'm building, say, smart lightbulbs that I want to exist
in an OCF network, I want those certified, but my app that controls my
lightbulbs is just an addon - I give it away to help people use the
bulbs I sell, but I don't generate any direct revenue from it, and I
might not have a lot of interest in dealing with other aspects of the
OCF protocols that don't relate to running those lightbulbs. Maybe I'm
lazy. But an awful lot of "embedded" product makers have seemed to be
lazy in just this way in the past. What is the value of the cert mark
for an app? People will take it anyway, because it's the one thing that
knows specifically about those bulbs. (very simplistic view I know,
verifying the app does OCF security correctly may well turn out to be
worth proving to people with a cert mark).
Consider the logistical problems of certifying:
(a) for a device acting in a server role, you poke it with a variety of
correct and incorrect REST instructions, and the specification says how
it should respond. The test tool is the initiator of interactions so
this is easy. For a client role, where the client is the initiator, how
do you convince it to initiate a structured set of different queries so
you can validate it is doing the right thing in all cases? Maybe there's
a code path in the app that does something wrong, but that path is not
taken during testing, so you don't see it during the cert run. The
vendor knows how to measure code coverage during their own tests, but
the OCF cert tool has no chance of making that determination without app
knowledge and some API help.
(b) the cert model depends on a clearly described state that has been
tested and it is that precise config that is granted use of the mark.
Anyone who has apps on their phone knows they tend to change - a lot.
Would each new version require a test at a 3rd party lab (with
associated costs)? If not, which ones would? (there's some verbiage on
that in the members-only cert policies. I guess time will tell if that
flies).
(c) apps have to run "everywhere" to be useful, where everywhere
includes some set from {Android, iOS, Windows} if it's going to be on a
phone, maybe more if it will run on other hosts too. Is each one of
those a separate app to be certified?
_______________________________________________
iotivity-dev mailing list
[email protected]
https://lists.iotivity.org/mailman/listinfo/iotivity-dev
