Resolved: confirmed agenda
Resolved: Approved minutes
<trackbot> action-193: Rob Atkinson to Move jmeter test suite to within w3c systems -- due 2018-09-05 -- OPEN
roba: waiting on implementation to test against
<trackbot> action-341: Lars G. Svensson to To final review and reply to tom formally -- due 2019-06-27 -- PENDINGREVIEW
larsg: sent out, can be closed
<LarsG> close action-341
<trackbot> Closed action-341.
<trackbot> action-343: Nicholas Car to Update qsa documentation with an equivalent to getcapabilities -- due 2019-07-11 -- OPEN
<ncar> we are working on equivalent functionality using conformance to profiles of the Conneg Doc
<ncar> we will leave this Action open until an equivalent mechanism is delivered
roba: we will "eat our own dog food" and show parts of conneg doc can be conformed to as alternative profiles
ncar: we have deferred the issue of what being conformant to conneg means..
roba: we need to call it out explicitly in conneg document and provide identifiers different profiles in the document (alternative mechanisms)
<trackbot> action-347: Rob Atkinson to Create new gh issue explaining the problem of redirects and refer to that issue in the wd -- due 2019-07-18 -- OPEN
ncar: reviewed specifications and it appears cannot pass headers via redirects
roba: we can do the same thing as for the getcpabilities idea and recommend a canonical way to embed this info in content - but cannot enforce it.
larsg: we should highlight these in 3PWD and solicit feedback
<trackbot> action-348: Nicholas Car to Create pr with real examples to solve #287 -- due 2019-07-18 -- OPEN
ncar: examples in github comment so far - @aisaac has approved - yet to put into document - so leave action open
<trackbot> action-349: Lars G. Svensson to Move text from ietf to conneg draft for #500 -- due 2019-07-18 -- PENDINGREVIEW
larsg: PR approved - can close
<LarsG> close action-349
<trackbot> Closed action-349.
<ncar> There are 4 open questions: 1. do we agree with the general thrust of this proposal? 2. if we agree, do we agree to use PROF to characterise profiles of Conneg by P? 3. If so, do we use PROF namespace for the Conneg by P profile instances? Seperately, 4. How do we link information about the non-informaiton resource (the service conforming to Conneg by P) to the information resources (content served by the services conforming)?
<ncar> LarsG: can conformance to Conneg by P specifications be described using profiling mechanics?
<ncar> ncar: I think it can - just write down the spec and conform to it
<ncar> roba: I think it can - loose interpretation of profiles
<ncar> LarsG: can we actually specify conformance criteria in Conneg by P?
<ncar> roba: yes, just look at all the conformance directives: MUST SHALL etc.
ncar: comes back to specifying what conformance means in the context of this community
roba: in a way we are declaring what information is passed and returned - so each specification can be seen as a "data profile"
ncar: no requirement for a machine actionable conformance test.
<ncar> roba: Q1, ok, Q2, ok, Q3 not necissarily. The profiles' detiail could be declared elsewhere with this doc only containing URIs for identification
<ncar> roba: correction (from tying error): Q2: no, we don't need to characterise anything beyond the corrent Conneg by P doc's language. Q3 I haven't addressed
<ncar> LarsG: Q1, yes, Q2, we MAY use PROF, not we SHOULD use PROF.
roba: change qsa-strict to qsa and qsa-loose to qsa-alt
<LarsG> LarsG: does the idea of having the profile URIs in the main document
<LarsG> ... and the PROF definitions of the profiles in an annex mean
<LarsG> ... that the profile URIs are normative and the PROF definitions are not?
roba: thats the intent
<LarsG> ncar: yes
<LarsG> RRSAgent: please draft minutes v2
Succeeded: s/email/github comment/
Succeeded: s/we may use PROF or we should/we MAY use PROF, not we SHOULD use PROF/