I agree with Andrew's assessment that there are two issues being
intertwined. For the first, so far I haven't seen a use case that
needed some context that couldn't easily be handled on the task itself
(as Andrew suggested via two different means). Thus, for now, I don't
see the first issue requiring any spec changes to fully support SIP
using this spec.
For the second issue (locking strategy), I also agreed that given the
broad range of users of this spec (from simple apps to quite complex),
I don't think at this point in the lifecycle of the spec we can
realistically expect to properly address this issue. For now, I think
the best approach is that suggested by Andrew, leave locking to the
task submitter.