- From: Eyal Sela (ISOC-IL) <eyal@isoc.org.il>
- Date: Mon, 13 Aug 2012 16:30:55 +0300
- To: Frederick.Hirsch@nokia.com
- Cc: robin@berjon.com, richt@opera.com, public-device-apis@w3.org
- Message-ID: <CAMb6=s3BvR6f+8L1BWGwh2Xg0Ei4Lys0QXZXzn=5Yp-YU0RZOQ@mail.gmail.com>
Hello, I'd consider adding a short paragraph that explains: 1. The concept of 'discovery protocols' 2. The fact that only user agents will need to implement the API to communicate using a protocol *that is already implemented by the peripheral devices*. Eyal Sela | Project Manager, Technology Committee & the Israeli W3C office On Mon, Aug 6, 2012 at 3:17 PM, <Frederick.Hirsch@nokia.com> wrote: > > +1, also indication of any threats and assumptions that the reader should be aware of. > > regards, Frederick > > Frederick Hirsch > Nokia > > > > On Aug 6, 2012, at 6:48 AM, ext Robin Berjon robin@berjon.com > wrote: > > > On Aug 3, 2012, at 20:00 , Rich Tibbett wrote: > >> I'm not a huge fan of Individual Security and Privacy Consideration sections in specs. It's Important to tackle these things by design and include security as part of the defined algorithms. Having said that, if the group thinks this is a good idea then we can add something along those lines. > > > > There are two aspects to take into account here. One is designing security right into the technology's model and not bolting it on in a separate section (that might not get implemented). The other is catering to readers who might not give a rat's hind about discovery in JS but who want to do a security review of the spec. Those are the people for whom a dedicate security section can be useful. I think it can be a short affair, perhaps a couple paragraphs stating that security blah can be found in sections foo. > > > > -- > > Robin Berjon - http://berjon.com/ - @robinberjon > > > > > >
Received on Monday, 13 August 2012 13:31:59 UTC