General Comments
IIIF - Implementation Notes - https://iiif.io/api/image/2.0/#appendices
| Time | Item | Who | Notes |
|---|---|---|---|
| remove #, add ~ | |||
| ark:/ becomes ark:[/] | (in many places) / now optional Do we need some sort of guidance/advice on "accepting" / while transitioning; Tom raises general question of content negotiation: should we indicate version of arks we are transmitting in syntax, rather than depend on content negotiation Greg: should we call this deprecated, or indicate old form transitional and indicate how to transition - John we have to make explicit support for older form, look for correct language on this Minters SHOULD not use slash; Resolvers MUST handle /; Mark - also should express whether current users should change URLs; JOHN where does upgrade path info go? Separate document? Appendix? Mark will add examples from IIIF | ||
| "resolvers to check for inflections before normalizing" | TBD | ||
| more flexible NAAN | Same digits as NOID (section 2.3); would enable mapping other id schemes without conflict in future | ||
| '?' inflection explicitly includes possibility of HTML with embedded metadata | TBD | ||
| Max length restriction removed | see new text | ||
| Extra: new co-author and IETF boilerplate changes | |||
| Extra: new anatomical definitions -- Resolver Service, Base Object Name, Core Immutable Identity | TBD | ||
| Extra: mention arks.org as Maintenance Agency (not AITO) | TBD | ||
| New proposed change: "http:" to become "https:" | Reflects change in boilerplate; but also think good idea for arks: AGREED John: deferred to make early important diffs less noisy | ||
| New proposed change: NMAH to be renamed NMA (simpler to teach about while still allowing a port designation) | John will add to next draft John: deferred to make early important diffs less noisy | ||
| Discuss: what about making '?' the same as '??' for easier implementation | Possibly related to issue of resolving version | ||
| Identifier length | Discussed in expert group discussion last year; Greg wondering if this is best practice (arbitrary length), plus pragmatic restrictions (db fields); Challenge for receiving systems would be burden; Would more conservative approach be better: warning about maximum length (eg anything larger than 255)? Especially since we are transition from hard limit of 128 to no limit - SO lets try new working reflecting current common RDB limits |