calls for papers, submission deadlines, upcoming meetings: Calendar of events
normalizing unicode hyphens
"Implementors should be prepared to normalize some common invalid characters that may be found in ARKs copy pasted from processed text. For example, when pasting an ARK that was broken during line wrapping, a user may inadvertently introduce newlines and spaces that should be removed, or a variety of dash-like (eg, en dash) Unicode characters that should be removed or converted to hyphens."
GJ: "should be prepared" maybe too vague; perhaps this should be "best practice" or "it is recommended..." ACTION: GJ will try to reword this TC: implementors normalize; is this more for resolvers, or is it a purely a client-side issue? JK: in some ways it's a publisher problem; but since we have little influence over them it may be best to play defensively RM: similar situation with malformed PDFs JK: and same with decades of malformed HTML GJ: in the spec "normalization" is only currently mentioned only in terms of lexical equivalence; is it ok to leave it that way?
GJ: having two diagrams that are so similar is confusing
TC: I'd agree; I hadn't seen the check digit language before JK: check digits are still optional but the convention is explained GJ: are we too constrained by ascii art? maybe it would be good to have an actual diagram JK: the IETF specs are generally meant to be renderable with plain text TC: we might want to do a BNF grammar at some point RM: the diagrams are too similar; the first should be higher level than the second; it seems possible to eliminate some detail from the first? KH: agreed; or perhaps have more than two diagrams
TC: who is the audience for the resolver chain discussion; would be good to have some use cases JK: example, EZID will go from using N2T as a Metadata Responder to being its own Metadata Responder JK: an important use case for N2T retaining the ability to be a Metadata Responder is for namespace splitting TC: yes, we have seen namespace splitting
recommend/exemplify link header with resource response?
n/a
recommend/exemplify link header with metadata response?
KH: I like the link header example TC: agreed; maybe use the full URL instead of relative URL TC: would expect the "self" reference JK: missing: converse recommendation of link header for resource retrieval
adding n2t.net as infrastructure; current statement is weak
RM: the arks.org/specs/ endpoint is ok KH: agreed TC: agreed TC: nice to be able to see what the latest, up-to-date recommendation is ACTION: JK to establish specs stub page at endpoint
Action items
Greg Janée will try to reword the statement about normalizing alternate forms of received hyphens
John Kunze to establish specs stub page at endpoint