...
- Danny Bernstein
- Aaron Birkland
- Jared Whiklo
- Bethany Seeger
- Christopher Johnson
- Peter Eichman
- Carrick Rogers
- Andrew Woods
- Esmé Cowles
- Bram Hauer
- Ben Pennell
- Joe Harrington
- David Wilcox
Agenda
Update from "Alignment to Spec" sprint
- Epic in Jira:
Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2582 - Versioning and Auth design subgroup: Versioning /- Authorization Design
- Breaking changes policy, tickets:
Jira server DuraSpace JIRA jqlQuery filter=14303 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
- Epic in Jira:
- Preservation specification
- Modeshape 5.4 upgrade:
Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2581 - Next fcrepo 4.7 maintenance release
: question about supported typesJira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2585 - Wrapping up fcrepo-import-export-verify: https://github.com/fcrepo4-labs/fcrepo-import-export-verify/pull/48
- Status of "in-flight" tickets
...
- Item 1.a-b Aaron Birkland: alignment to spec sprint
- started this week
- tasks based on delta doc
- well into process
- open questions about memento + WebAC
- determine difference between spec and current implementation
- what issues need to be raised to broader community
- Bethany Seeger: design issue: how do we deal with versioning in ACLs?
- don't have many use cases yet
- (wiki page) Versioning /- Authorization Design
- soliciting use cases and other feedback
- Bethany & Ben: making JIRA tickets today
- how do DELETEs affect versions?
- delete is optional in the spec
- is delete required? does a delete delete all versions of a resource
- Ben Pennell: issues posted back to spec group
- current spec confusing with regards to creating new versions
- Andrew Woods: proposal: do not support individual ACLs for Mementos; all Mementos share the same ACL
- Peter Eichman: only use case is if the original version of a resource has sensitive info, made public after scrubbing, but original resource shouldn't be exposed
- solution is to create a new resource not a version for scrubbing
- Aaron Birkland: ACL for a resource, within the ACL have Authz rules for different mementos
- Andrew Woods: mementos are immutable
- Aaron Birkland: spec doesn't require a triple on the resource
- Link header is used for ACL discovery
- do you have to freeze the value of the Link header when you make a memento?
- Andrew Woods: we should put a stake in the ground; shall we extend immutability to its Link header?
- Andrew Woods: possible model: memento gets ACL from its LDPCv container; if none should we default to global default or defaults to walking up the tree
- Bethany Seeger: LDPCv++, allows different authz rules on resource vs. public
- Aaron Birkland: need to engage community verify that stakes in the ground are acceptable
- once the subgroup has an algorithm for determining ACL for memento it should go back to the spec group, since it won't be exactly the WebAC algo
- Andrew Woods: should we bring in Herbert (Memento author) to consult? pre-volunteed to participate
- Bethany Seeger: yes
- Bethany Seeger: identifying non-controversial pieces of Authz+Versioning and creating tickets
- Andrew Woods: start with "ACL on container" algo?
- Bethany Seeger et al: yes
- Andrew Woods: delete of versions?
- Bethany Seeger: it's a MAY in the spec, current fedora behavior is delete a resource
- Andrew Woods: do we tie memento lifecycle to resource lifecycle? deletes all versions, what does the community think?
- Jared Whiklo: yes
- Esmé Cowles: yes
- Danny Bernstein: AWS doesn't tie versions to resource
- Ben Pennell: no; memento allows original delete but retain history; good to look at how fedora's expected usage of versioning differs from web archiving and amazon
- Aaron Birkland: Wouldn't a safe way to delete a resource + versions be to DELETE the LDPCv (to delete versions implicitly), then the LDPRv?
- Andrew Woods: when you have versioned resource with LDP children, do we version the resource or the whole tree?
- Peter Eichman: versioning the whole tree makes the most sense
- Danny Bernstein: in abstract, yes; but potential for explosion of storage needs may be practically problematic
- Aaron Birkland: tree based versioning creates mementos for all children; current versioning copies all children, but those children aren't versioned
- Bethany Seeger: version trees, but requires work
- Andrew Woods: consensus is to version trees
- Bethany Seeger: safest bet to version children in a way they know about; needs to get fixed in code
- Peter Eichman: only use case is if the original version of a resource has sensitive info, made public after scrubbing, but original resource shouldn't be exposed
- don't have many use cases yet
- Aaron Birkland: that sort of fix may change how we use modeshape for versions significantly
- Ben Pennell: if you do that then you get the multiple containment issue though (two LDPCv's would contain the version of b)
- Jared Whiklo: what about outbound links in addition to children? does this end with a snapshot of the entire repo?
- Aaron Birkland: We could also do baby steps and start with single-resource versioning, then figure out trees :)
- Jared Whiklo: not advocating for whole repo snapshots nor even necessarily versioning linked resources, just trying to find the margins
- we will continue this discussion in special topic conversations on the Authz+Versioning issues
- Andrew Woods: continue with Mode versioning, or roll our own versioning system, memento implementation
- Aaron Birkland: probably abandon Mode
- Jared Whiklo: agree
- Ben Pennell: not sure about taking a default approach of making versioning totally backwards incompatible with fcrepo 4 by not initially taking a tree version approach
- Andrew Woods will be gone next week, call for facilitator?
- Aaron Birkland will facilitate
- Item 1.c: Aaron Birkland: flagging things that break backwards compat
- taking conservative approach, but not requiring backwards compat
- Andrew Woods: community expectation is there will be breaking changes
- limited to API is best
- helpful to have a 4.7.5 release with deprecation notices, and other bugfixes
- Item 2: Preservation spec
- Andrew Woods: there is ongoing interest in specifying what is actually on disk for Fedora, for implementations that write to disk
- Item 3: Mode 5.4/next fcrepo 4.7 release
- Peter Eichman: supports 4.7.5, Mode 5.4 so far seems to work in UMD's testing, avoids stuck threads issue
- Item 4: deferred to IRC
...