| 07:55 | <MikeSmith> | anybody have a clue how I can get a URL for whatever the latest version of https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-04.html is? |
| 07:55 | <MikeSmith> | e.g., if I just use https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses it redirects to https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-04.txt |
| 07:56 | <annevk> | MikeSmith: I'd use https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses, but yeah, it'll redirect |
| 07:58 | <MikeSmith> | annevk: thanks yeah but that redirects to the faux-HTML version |
| 07:58 | <MikeSmith> | which is better than the plain text version at least |
| 07:59 | <MikeSmith> | I think I’ll just use https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html and ignore all the IETF versions |
| 08:00 | <annevk> | MikeSmith: I think the IETF one is likely better as it'll have forward links if the draft gets adopted by an IETF WG and such |
| 08:00 | <annevk> | MikeSmith: unless this moves out of the IETF |
| 08:02 | <MikeSmith> | annevk: well https://tools.ietf.org/id/draft-yasskin-http-origin-signed-responses-04.html doesn’t have any forward links |
| 08:03 | <MikeSmith> | so I guess you mean it’s best to cite https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses |
| 08:03 | <annevk> | MikeSmith: right |
| 08:03 | <MikeSmith> | OK, yeah will do that |
| 10:49 | <annevk> | hsivonen: I guess I'm showing my ignorance here, but how would Swift encode U+0000 if strings are terminated by 0x00? |
| 10:50 | <annevk> | hsivonen: https://forums.swift.org/t/string-s-abi-and-utf-8/17676 doesn't talk about this |
| 11:01 | <Ms2ger> | annevk, I don't know if this is the case, but they may store the length as well, so you could have { length: 3, data: "a\0b\0" } |
| 11:06 | <annevk> | Ms2ger: but then it's not a normal C-string is it? |
| 11:07 | <Ms2ger> | Did they say that it was? |
| 11:07 | <annevk> | Ms2ger: "By maintaining nul-termination in our storage, interoperability with C is basically free: we just use our pointer." |
| 11:08 | <Ms2ger> | I don't know that disagrees with my hypothetical implementation, but I know nothing about Swift, so I'm going to stop here :) |
| 14:24 | <annevk> | mkwst: https://github.com/whatwg/html/issues/4175 is what I was contemplating yesterday, more concretely |
| 16:59 | <hsivonen> | annevk: the way XPCOM strings do it is that if you have U+0000 in the string and try to use C interop, C sees the string only up to the U+0000. |
| 17:09 | <annevk> | hsivonen: aka security fun |
| 23:15 | <MikeSmith> | annevk: Domenic is there a plan/issue to un-monkey-patch the Feature Policy spec? https://wicg.github.io/feature-policy/#integration-with-html If there’s not already an issue, should I open one? |
| 23:17 | <MikeSmith> | oh I now see https://wicg.github.io/feature-policy/#issue-3778ddf4 |
| 23:17 | <MikeSmith> | > Monkey-patching! As soon as we know that this is the direction we wish to pursue, upstream all of this. |
| 23:17 | <MikeSmith> | ... but I don’t find any corresponding github issue |
| 23:19 | <Domenic> | MikeSmith: worth opening something. I think a lot of it was already integrated in https://github.com/whatwg/html/pull/3287 , so maybe that section just needs to go away? |
| 23:38 | <Domenic> | annevk: ping on https://github.com/whatwg/html/pull/4105 |