2022-03-08 Technical WG Agenda and Notes

texas conference moving ahead, no publicity yet

mp: need formalize the roles of chair and vice-chair
mp: verify charter, people, roles,
tc: anyone not here should be considered as volunteering
mp: vice chair is kind of a backstop as default if the chair is can't make it
 -  organizing meetings, text for action items,
 -  witness the process of organizing
 -  cushion for when the chair has to step away
jk: ask Dave to be vice chair?
mp: ok, through the end of the calendar year
tc: agreed

Update on preliminary discussion with the RFC Independent Stream Editor

• BCP (Best Current Practice) 190 (RFC 8820)
• Conflict with reserving path "prefix"
• Conflict with reserving query string

On 04.03.22 06:56, Independent Submissions Editor (Eliot Lear) wrote:
The question really is... is an web server or client supposed to
behave in any special way when they see ark: somewhere buried in a
URL?  This is precisely what .well-known was meant to protect against.
...
I want to go into more detail here.  The point of BCP 190 is to preserve
namespaces to the owner of an origin.  That is- you don't get to
structure them if you are not the owner.  That includes queries.  The
exception we have for that is .well-known.  This is why I am very
concerned about the current state of your draft.

Some initial thoughts (jak's). This means that the IETF might not allow example.org/ark:12345/67890 and the ?info inflection unless they were expressed as something like

     example.org/.well-known/ark/12345/67890       and

     example.org/.well-known/ark-info/12345/67890

I (jak) don't think it means that one site, eg, n2t.net, couldn't recommend publishing as

     n2t.net/ark:12345/67890

and letting it redirect to local services that use the .well-known/ark... convention.

kh: about the feedback: would it help to separate the resolver piece from the syntax spec?
gj: can see the value in separating, along lines of how handle and doi did it,
    eg, 1. syntax and structure, 2. resolution, 3. metadata
tc: yes
gj: doi's and handles are uri compliant and have structure -- how do they do it?
jk: because they're rooted at one domain (one origin), as opposed to suggesting a path convention for all origins to do it
tc: maybe it could be modeled on how n2t does it, as long as it's not mandated

rm: if we in Luxembourg don't want to use n2t, do we have to use .well-known?
jk: possibly, if the ARK spec continues to require a path convention

kh: I second the idea to have a spec describing specifically what n2t.net does
cm: two documents is less convenient, but maybe necessary

New spec transition planning

• New spec blog post draft – go ahead anyway, or talk about new spec transition independent of the RFC process?