Date
Attendees
Goals
- Plan transition to new spec
Discussion items
| Time | Item | Who | Notes |
|---|---|---|---|
announcements New WG member: Dave Vieglais, U. Kansas | |||
| upcoming meetings, calls for papers, submission deadlines | |||
| spec changes in response to last time | |||
Planning transition from V18 spec to V26+ spec, once it has settled. Requirements after transition: R1. "/" becomes optional (ark:/12345 = ark:12345), means systems must not reject as malformed any ARKs received (eg, externally produced) only because there is no "/" between the "ark:" and the NAAN. R2. All implementations, past and future, must not reject as malformed any ARK only because there is a "/" between the "ark:" and the NAAN. R3. NAAN no longer just 5 digits, means systems must not reject as malformed any ARKs received (eg, externally produced) only because the NAAN doesn't match the regex "^\d{5}$". The new restriction is to a run of one or more betanumeric (0123456789bcdfghjkmnpqrstvwxz) characters. Question: should there be a minimum maximum, eg, must accept NAANs of at least 64 octets? R4. Length restrictions are relaxed on the string formed from the Name (starting "ark:") plus Qualifier, means systems must not reject as malformed any ARKs received (eg, externally produced) only because there is this string is longer than 128 octets. At a minimum, implementations that limit its length must accept strings of length 255 octets. FAQ1: does this transition affect how my implementation is required to store my ARKs (eg, with or without "/")? NO FAQ2: does this transition affect how my implementation is required to advertise/publish ARKs? XXXXXX phased transition over N years? FAQ3: is there a validation service to test my ARKs? XXX FAQ4: when does the transition take effect? | |||
As we have seen before, a "provisional" ARK URI scheme is listed in the URI registry Do we have a position on it? Endorse? Must have? Would be nice? |
