You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Date

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

  • 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.



Action items

  •  
  • No labels