Versions Compared

Old Version 3

changes.mady.by.user John Kunze

Saved on

compared with

New Version 4

changes.mady.by.user John Kunze

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Attendees

Goals

    new spec, new github repo for spec maintenance, proposed tweaks for impersistence and developer assistance

Discussion items

ItemWhoNotes
Announcements

Calls for papers, submission deadlines, upcoming meetings: Calendar of events


Any news items we should blog about?



New ARK spec (v30)

Diffs from v29->v30



This new (v30) spec is the first draft with raw XML stored in a github repo: jkunze/arkspec repo (first try with repo based draft, maybe not final home)

https://jkunze.github.io/arkspec/draft-kunze-ark.html

  • built from template designed for managing Internet Drafts (TY Mark for forwarding)
  • it's a first attempt, probably will need to redo it got messy making it work for draft in XML (not markdown)
  • volunteer to help make sure it's right technically
  • please test the sociology: can you do a pull request to fix typos? do we need more committers? what's missing?


Support (non-normative) for building ARK services using N2T's convention – should the ARK spec describe this as one known tool for resolver implementors?

  • Prefix extension. N2T supports a "prefix extension" feature that permits developers to extend a scheme or an ARK NAAN (both of which "prefix" an identifier) with -dev in order to forward to an alternate destination. For example, if the NAAN 12345 forwards to domain a.b.org, then ark:/12345-dev/678 forwards to a-dev.b.org/678. It works similarly for schemes, for example, if scheme xyzzy forwards to a.b.org/$id, then xyzzy-dev:foo forwards to a-dev.b.org/foo.



Questions about how to do short term ARKs keep coming up. All the ARK services, features, metadata, inflections could be used for ARKs that are persistent but within a defined ending term (eg, access expires in 12 months). How best to avoid confusion if ARKs can be used for both persistent and impersistent identifiers?

How about suggesting a NAAN-based convention, similar to how four particular NAANs (eg, 99999 and 12345) instantly (in the string itself, not requiring lookup) tell the recipient something this important?

Strawdog "Zero NAAN" proposal: every org that receives a NAAN, say 98765, also implicitly receives a second NAAN with a '0' (zero) prepended. We can promise that we will never assign a NAAN beginning with zero, but that if you publish an ARK with a NAAN starting with a zero, say "ark:098765/t7gh, the recipient can assume instantly that it is not suitable for long-term reference. Implementors would be encouraged (but it would be optional) to publish with a leading zero if and only if they want to reveal impersistence right away.Diffs from v29



Action items

  •