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

Compare with Current View Page History

« Previous Version 3 Next »

Date

Attendees

Goals

Discussion items

ItemWhoNotes
Announcements

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)

Final discussion of WG homepage review

  • KH: counting ARKs via API vs survey (pros/cons)


IETF standardization update

  • ARK as URN namespace (in addition to other IETF); might be easy
  • ARK as API rather than as identifier?
  • ARK as centralized silo rather than as distributed (see GJ's April 10 email about n2t)
  • Current ARK draft expires April 20


ARK spec transition

? what to call before and after -- call them V.I and V.II ?
? add those names to new spec, and add section about transition?

  • blog post https://arks.org/blog/upcoming-changes-to-the-ark-specification/
  • Changes (complete?):
    • 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)
    • ARK chars:    =   ~   *   +   @   _   $        %   -   .   /
         this removes #, adds ~
    • 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.

    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 T1 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 T2 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 T2 you should accept ARKs at least as long as 255 octets.

    5. If you validate ARKs, you should by time T1 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.



Action items

  •  
  • No labels