2024-05-14 Technical WG Agenda and Notes

will shortly announce a pan ARKA group list (union of working groups)

dv: put last month's transition on hold because of discrepancies that turned out to be shoulder info presented by N2T; then there was another issue with NAANs in use that weren't documented,

     eg, ark:/b5060/d8kw2m

jk: oh yes, that looks like a "shadow ARK" from EZID that wasn't ever supposed to make it out into the wild; we asked people to stop using them, but it looks like that only partly worked
dv: config details remain to be finalized, and all the rest is working fine

dv: we're in the process of deconvoluting the procedures, so that pushing change to main that have a release tag will trigger an update to the public site; it should be close to done
gg: who has access and what are the policies and procedures for updating?
dv: we could borrow from the carpentries content guidelines handbook/best practices
https://docs.carpentries.org/topic_folders/maintainers/maintainers.html

ACTION: gg and jk will work on policies and procedures for updating the static site

a first stab at /.well-known/ark* convention(s); goals

1. to start conversation with the IETF RFC editor
2. to tell agents (including humans) things like
   1. do expect to find an ARK service here
   2. what path to find that ARK service
   3. alternate way to get metadata (if ?info is problematic)
   4. ?where to find numbers of ARKs served here
   5. ?site verification/ownership

Example (strawperson) .well-known/ark.json:

{
    "service": {
        "path":       "index.php/didascalia/gateway/plugin/pubIdResolver/",
        "metadata":      "index.php/didascalia/gateway/plugin/pubIdMetadata/",
        "counts":    "index.php/didascalia/gateway/plugin/counts",
        "mastodon_verification":    "953088D7-0726-400C-81DC-945BE8B1115B"    }
}

g: is there a risk that no one else will be able to use our .well-known conventions without prior knowledge?
dv: it can be very simple, can start by just listing the location of a known ark service
kh: can this be that simple and satisfy the IETF requirements?
jk: I propose starting very simple and testing the waters
dv: willing to do be on a call with the RFC editor, suggest following openid config naming pattern and calling it "ark" or "arks" without a filename suffix (eg, not ark.json)

Leftover topics

jk: published very minor revisions to create the v39 spec; ok to point new implementers to it?
all: agreed

jk: expect a request for a first new shared NAAN shoulder on the 99999/... from a group in Chechia ; any problems expected?
dv: should work 

rm: I'd like to restart the discussion of persistence statements; has there been any progress?
jk: it's been on hold, but I'd be very supportive of producing a minimum viable product (MVP); I will send you the names of people who expressed interest in working on this