...
| Time | Item | Who | Notes |
|---|---|---|---|
announcements New WG member: Dave Vieglais, Natural History Museum and Biodiversity Research Center, University of Kansas | |||
| upcoming meetings, calls for papers, submission deadlines | RDA? DV will check into. | ||
New spec (V27), with spec changes in response to last time: https://www.ietf.org/rfcdiff?url1=draft-kunze-ark-26.txt&url2=draft-kunze-ark-27.txt Note: propose dropping the the sorting of suffixes, eg, .../sect2/para3.en.v5.pdf.gz (original rationale for sorting was to support end-user "variant requests" in different orders, eg, does .en.v5 == .v5.en ?) Changes since before last meeting: https://www.ietf.org/rfcdiff?url1=draft-kunze-ark-24.txt&url2=draft-kunze-ark-27.txt | Clarified "high quality" language. Pursuant to last discussion, removed requirement to order suffixes during normalization. JK action item: clean up usages of term "suffix". | ||
Planning transition from V18 spec to V26+ spec, once it has settled. Requirements for received ARKs 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 32 octets? R4. Length restrictions are relaxed on the string formed from the Name (starting "ark:") plus Qualifier, which means systems must not reject as malformed any ARKs received (eg, externally produced) only because the string is longer than 128 octets. At a minimum, implementations that limit its length must accept strings of length 255 octets. | NAAN length: useful to have a limit, but 32 seems too big. Extra characters useful not so much because there will be huge numbers of NAANs, but to support possible distributed namespace control within NAANs. Consensus: limit in the range 10-16 seems good. | ||
Planning transition from V18 spec to V26+ spec, once it has settled. Requirements for generated ARKs after transition: 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? Big change – should it be a phased transition over N years? FAQ3: is there a validation service to test my ARKs? 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? |
...