Page tree
Skip to end of metadata
Go to start of metadata



(plus) (facilitator)
(star) (notetaker)

Agenda & Minutes

  1. Review of recently closed issues:
    • 4 process questions:

      • #123 Process for maintaining the Fedora ontology

      • #124 Process for proposing new extension specifications

      • #125 Process for amending the Fedora API specification

      • #127 What are the criteria for distinguishing between optional/core and optional/external

      • Simeon Warner proposes that we leave these 4 process questions closed and work within the current editorial remit
    • #209 Fix typo in JSON-LD context -> have created #216 to replace

    • #119 Clarification of InboundReferences -> Esmé Cowles had replied, issue to continue with or recreate?
    • #205 constrainedBy clarification -> no description
  2. Revisit strictness of requirements for external content, recursive deletion, client-specified ACLs, etc.
  3. Authorization issues
    1. issue-165: Removing support for acl:accessToClass?
      1. Wait on response to
      2. CLAW only uses ACLs for very basic partitioning of drupal instances
    2. issue-166: Requiring WebIDs?
      1. PR: — needs review from Andrew, Ben, Danny, Simeon
    3. issue-168: Cross-domain Authorization?
      1. PR: — needs review from Andrew, Ben, Simeon
    4. issue-170: Require acl:Append and acl:Control
      1. PR: — needs review from Andrew, Ben
    5. issue-172: Clarify algorithm for finding authorizations
      1. Still pending clarification from Solid
    6. issue-176: ACL creation and linking -- be explicitly silent or specify?
      1. PR: — needs review from Andrew, Ben, Danny
  4. Versioning issues:
    1. — clarifying creation of versions with PUT
    2. Other versioning questions from API Alignment sprint: Versioning - Authorization Design
  5. External content issues:
    1. Clarify "expires" parameter
    2. Clarify response when copying remote content
  6. Notifications section:
    1. Esmé and Danny to review and create issues
  7. Fixity section:
    1. Simeon to review and create issues
    2. Simeon Warner's review: I do not see anything wrong with the fixity section. In its current form, support for fixity in any form is entirely optional, it simply points of out parts of the underlying HTTP Digest specification that might be relevant to systems that implement either transmission and/or persistence checks. If this is something that any part of the community relies upon then I think there will need to be an additional specification with a number of MUSTs, or it will end up being de-facto defined by a particular implementation.
    3. Note related issue just created: – although we can't use the suggested RFC SHOULD in the non-normative section, this seems like a sensible addition


  1. Issue-165: Removing support for acl:accessToClass?
    1. Suggestion, add wording that indicates:
      1. implementations MUST do accessToClass
      2. explain what accessToClass does
      3. inference is a MAY 
  2. Request for editors to review the current sprint AuthZ/Versioning design discussions
    1. Lots of questions around the intersection of ACLs and Versions
  3. Issue-210: Clarify intent of external content expiration parameter
    1. Suggestions:
      1. Potentially remove the "expiration" header parameter
      2. Add "Content-Location" under PUT for ingest by reference
        1. If you wanted to add to repo, you would retrieve and upload
      3. Further discussion with Benjamin Armintor before taking action
  4. Meeting stopped at agenda item 5.b
  5. When do we publish the next increment of the spec?
    1. Targeting the end of Oct
    2. After the alignment sprints

Action Items

  • No labels


  1. Can someone share some of the reasoning / discussion about why implementing acl:accessToClass would be required? 

    1. There is some discussion in — the use case boils down to having large numbers of resources, with the ACL to use depending on the type of the resource (e.g., newspapers use this ACL, ETDs use that ACL, etc.).

      I think this is the combination of two different issues:

      1. You could have a large number of resources link to a single ACL, but there are concerns about the scalability of having a large number of links to a single resource.
      2. You could put different classes of resource into different containers, and then use the containers to manage the ACLs, but there has been consensus against having semantic notions in the URL, to avoid the URL changing if the semantics change.
  2. Thanks, Esmé Cowles – Curious, though – why not just a MAY then?  Then the impl could decide? 

  3. Bethany Seeger – I think MAY is the current proposal but since it is folks using F4 that think they want this (I'm not entirely convinced of need), I think they are expecting it in Modeshape Fedora. Is it hard to implement?

  4. It is implemented in the fedora modeshape implementation currently - at least a form of it is implemented.  

    In terms of difficulty in implementing it, it's my understanding that it's hard to implement "correctly" because the semantics of it are not defined and so it's hard to know what a "correct" implementation is in the first place.  

    Above in the notes it says MUST implement - but perhaps those are ideas and not the final decision.

    1. Bethany Seeger – indeed, now I recall we agreed on MUST to avoid complications of optionality and to provide a clearer notion of what a Fedora is. I agree that we need to define the semantics! I put a stab on #165 at