Hi Valentyn, Thanks for running the variants. Keeping the target at v7 while compliance changes isolates the separate dependency.
> [VR] An application-specific re-check of compliance=v4 at the effect boundary > closes the case [IS] There is one more ordering worth adding: the executor performs its final compliance check at v4, compliance changes to v5, then the target mutation commits. A plain re-query can still lose that race. For a commit-time guarantee, the mechanism needs to say how compliance changes are ordered against the mutation. That could be one transactional authority, or a reservation that the participating providers actually honor. A freshness bound on an observation doesn't provide that guarantee. If an authority won't participate, the profile should state the weaker guarantee rather than report the conjunction as commit-safe. One WebDAV detail also matters for the comparison: RFC 4918 section 10.4.3 uses AND within a List, but OR across Lists and tagged-list productions. Multiple tagged resources don't automatically express your required conjunction: https://www.rfc-editor.org/rfc/rfc4918.html#section-10.4.3 I don't have a generic cross-provider mechanism in the sources we've discussed that establishes your full commit-time property. I'd keep the wire representation and the commitment rules as separate questions, then test both orderings against each proposed implementation. Could you share the runnable case and its commit? That would give us a common test to compare, including what happens when a prerequisite is revoked after the final read. Best, Iman _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
