jk and dw did first ARK workshop. Was very nice. Donny shared copy of slide deck with call participants
Any news items we should blog about? Any calls for papers, submission deadlines, upcoming meetings we should note? Please add to Calendar of events.
At arks.org/resources updated current spec link (v.18) from an external link to a PDF hosted onsite; updated current spec to landing page for IETF specs (easier to keep updated)
dw: clarify messaging around v.18 being "current" (elaborate on this?) vs e.g. v.36
jk: agreed we should clarify this. punting for now in favor of existing agenda items.
NAAN should be preceded by "ark:", as in ark:12345/x7th8, but the the V.I format should also be accepted as valid in perpetuity, ie, no links will break because of the transition
NAAN can be 1 or more betanumerics (no length limit mentioned)
inflections: add ?info (with ? and ?? reserved for future use, but undefined; ok to keep using them as you do for now)
For received ARKs, implementations must support a minimum length of 255 octets for the string composed of the Base Name plus Qualifier
Draft Transition Plan
Overall impact should be minimal. The fewer NAANs you deal with, the easier. Timings T1, T2, ..., T6 to be determined later.
1. If you produce ARKs, by time T1 you should produce ark:12345 instead of ark:/12345
2. If you produce ARKs but only ever produced new format (ark:/12345) ARKs, by time T2 you should prepare to receive your own ARKs in the old format (because others may unwittingly reformat your ARKs)
3. If you receive or resolve ARKs, by time T3 you should accept either ark:12345 or ark:/12345, and plan to do that in perpetuity.
4. If you receive or resolve ARKs, by time T4 you should accept ARKs at least as long as 255 octets.
5. If you validate ARKs, you should by time T5 make sure your validation is relaxed enough to not reject new format NAANs, ARKs with ~ or #, and Name and Qualifier parts longer than 128 octets.
6. If you receive or resolve ARKs, by time T6 you should recognize ?info and (a) not flag it as an error, (b) return metadata or return something other than 404 (eg, return the object as if no inflection).
dv: arks.org might be better for tying the spec to than n2t.net; I see big benefit to name branding, with arks.org distributed among different orgs kh: wordsmithing needed, separating centralized software from the service gj: spec is squishy wrt global resolution dv: should be trivially obvious where to go to find the resource, eg, any local resolver system could to see my notes https://hackmd.io/dor0GlmTSEuLYouGJ6TIjA?view comments welcome
gj: for transition, we don't have levers to force people to do this jk: maybe use social pressure, list of reference ARKs that should work dv: we could use contact info in the NAAN registry to reach out
Action items
John Kunze accept homepage changes and update lyrasis wiki
John Kunze create google doc and invite comments on transition plan; need to clarify what existing/current spec means
Dave Vieglaiswill look into registering arkid at w3id