Will this spec accept a pull request?

[domenic]

We're updating structured clone to work better in whatwg/html#2421. In particular there are now explicit serialize/deserialize steps which make it clearer that you can e.g. write the serialization results to disk (important for IndexedDB uses). We'll be updating IndexedDB as well.

However this spec seems to have gone to REC and has no link to an editors draft. So I'm not sure if sending a pull request is a good use of my time here. If there's no way of seeing an up-to-date editor's draft, then maybe our best solution is to add a monkey patch in HTML and hope people remember to look at HTML for the definition of structured cloning web crypto objects.

Let me know what you think. /cc @sleevi @annevk

[sleevi]

@domenic

See the thread at https://lists.w3.org/Archives/Public/public-web-security/2017Feb/0000.html with W3C staff advice

[sleevi]

Also Twitter exchange - https://twitter.com/annevk/status/829392356902371328

[sleevi]

To the question at hand: If this spec doesn't accept Pull Requests, then it seems necessary to fork the spec to one that will, since we know there's work undone, or that things will change. I'm not sure the process points involved with accepting PRs into this repository, with respect to W3C, so I'm hoping @plehegar can advise on accepting editorial text in the absence of a W3C WG sponsoring it. I do hope the answer is "Keep accepting PRs to this repository", however, and separately figure out how to publish updates consistent with that process.

[domenic]

Thanks, that makes sense. I was indeed about to tag in @plehegar to get clarity on what the path here is.

Forking does sound like a reasonable avenue if the process constraints us here (as it seems to according to those threads). Even if we just fork to someone/webcrypto and then make sure all browsers and spec databases are aware that they should be reading/linking to someone.github.io/webcrypto instead of the /TR/ version, that would go a long way.

[mwatson2]

Last I heard, @wseltzer was looking into a new home for WebCrypto work, possibly the WebSec IG. I would think it would make sense to retain this repo - since this is where people are most likely to look and where the issue - independent of where the "official" home of the work is.

[plehegar]

this repo should continue to evolve, independently of the W3C constraints imho. Regarding webcrypto, we've been looking at fixing the maintenance issue btw. It would be nice if #180 could be accepted btw.

[plehegar]

Btw, the current stopgap solution is to move the spec into WICG so it can involved on its own. Re editor's link from the REC, we can update the REC to add the link.

[mwatson2]

Ok, I will cut a new ED, merge #180 and review the other issues. Probably not until the first week in April, though, unless there is some urgency ?

[domenic]

No urgency for my incoming PR; early April is a fine timeline. Thanks so much @plehegar and @mwatson2 for helping to work something out here.

[js-choi]

@plehegar commented on Mar 22, 2017:

Btw, the current stopgap solution is to move the spec into WICG so it can involved on its own. Re editor's link from the REC, we can update the REC to add the link.

Are there still plans to move WebCrypto into the WICG? (Cf. #165 and #166, merged in late 2016.)

[mwatson2]

I’m not aware of any plans, but I am aware of the significant backlog of maintenance issues. Now would be a good time to discuss proposals / preferences for a way forward. ...Mark

…

Sent from my iPhone

On Jan 9, 2018, at 6:55 AM, J. S. Choi ***@***.***> wrote: Are there still plans to move WebCrypto into WICG? (Cf. #165 and #166, merged in late 2016.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[plehegar]

In case this got missed: Process 2018 does allow W3C to republish a Recommendation with substantive changes even without a Working Group. See
https://w3c.github.io/transitions/nextstep.html?shortname=WebCryptoAPI

[plehegar]

the short answer to the original question is yes.