| 04:18 | <MikeSmith> | does Subresource Integrity define a protocol? |
| 04:19 | <MikeSmith> | or else whatever it does define, what specific technical term would be approprite to describe it? |
| 04:19 | <MikeSmith> | the abstract just says, “This specification defines a mechanism” |
| 04:19 | <MikeSmith> | mechanism |
| 04:20 | <MikeSmith> | in contrast the CSP spec says, “This document defines a policy language” |
| 06:06 | <annevk> | MikeSmith: feature 😛 |
| 10:33 | <MikeSmith> | annevk: Yeah I am beginning to realize it's futile to try to classify specs into discrete types |
| 11:57 | <annevk> | MikeSmith: we don't really have sufficient understanding of what we're doing for that |
| 22:40 | <MikeSmith> | annevk: yeah it was not my idea to try to classify them to begin with. I was asked to look into creating some guidance for testing based on spec types. |
| 22:42 | <MikeSmith> | Anyway after talking with foolip I think it still makes some sense to trying to give testing guidance based on spec features but instead based on identifiable things like, Does the spec define interfaces (using WebIDL)? Does the spec define new HTTP headers or new HTTP header values? Does the spec define new elements, attributes, or attribute values? |
| 22:43 | <MikeSmith> | etc |