Meeting minutes
https://
Admin
approve minutes from last meeting
<roba> +1
<NicholasCar> +1
<YoucTagh> +1
PROPOSED: Approve last meeting's minutes
+1
RESOLUTION: Minutes from last meeting approved
Status of actions from last meeting
https://
No progress on any actions...
Open Github Issues
https://
roba: This meeting also caters for PROF issues
NicholasCar: PROF is necessary for our work on CNEG, so need to work on that, too
roba: We need to update the WG note on prof
… will contact pchampin to figure out the process
NicholasCar: will assign myself to relevant issues
<NicholasCar> (I want to do that but can't yet)
NicholasCar: #32, #27
There is a PR for #32
Still IPR issues for NicholasCar
#44
roba: Proposal is to remove multiple canonicals
YoucTagh: We decided to add text that profile
… takes presedence over media type
… (maybe we didn't say that profile takes presedence,
… but that is what the I-D says)
… there is a PR to fix that
… NicholasCar has already approved
… #46
#43
YoucTagh: It's about media types that explicitly have a profile parameter
roba: We need to create a PR to fix that, e. g. replacing text/turtle
… with application/ld+json (or any other media type
… that has a profile parameter)
#5
roba: Discussion in issue is to put it as future work
… implication is that we need implementations
… if we want to push it forward
… not high on priority but could be managed
… this is alwo related to #39
YoucTagh: If we just send a default representation
… we need to say which profile it conforms to
roba: The question is if the client knows that the server
… supports cneg
NicholasCar: If the client knows about conneg, it would
… do a HEAD request to figure out what the server has
… don't see the case of the server telling the client
… that it supports conneg
… because that is implicit in the conversation anyway
YoucTagh: If we use header-based negotiation, it makes sense
roba: Having 300 Multiple Choices does not really add value
… since that can be done through HEAD
LarsG: The absence of a Vary header with "accept-profile"
… is a sign to the client that the server does not
… support profile negotiation (as said by YoucTagh)
… that's what the I-D says
roba: See little rationale to implement this
NicholasCar: Our implementation answes with a default
… and the link header tells the client
… if he got what it asked for
… If you got what you asked for, everything is fine,
… and if you didn't, the server doesn't support it
… so that the client can do a follow-up request
roba: We don't have a specific requirement what to do in this case
… 300 Multiple Choices is a gentler way of engaging
… the client than just returning a default that the
… client might not be able to handle.
… Maybe 300 is a better default than 200
NicholasCar: Generally, servers answer with defaults
… whenever I don't specify media types, profles etc.
roba: Suggest to take this discussion offline, am willing
… to change behaviour of my implementation
NicholasCar: maybe replace "default" with "fallback"
roba: suggest that we add text that the server MAY respond
<NicholasCar> Here is a ConnegP resource returning a defalt view, since no profile is specified, with a notification in the HTML response to the Alt Profiles profile page: https://
roba: with 300
NicholasCar: The logic is the same as with the Accept header
roba: Will update implementation
ACTION: NicholasCar to hassle pchampin re write access
<pchampin> got that action
<pchampin> apologies about today's call, but I'm swamped with TPAC preparation
YoucTagh: we need to balance proactive and reactive conneg
… the other uses 200 + defaults using linked headers.
… If you're not using defaults, you need to answer with 406,
… meaning that I'm not willing to give you a default or options
ACTION: YoucTagh to add his preferred choice to #39
ACTION: LarsG to put wording from I-D into #39
#45
YoucTagh: Happy to provide a PR for that one
ACTION: YoucTagh to prepare PR for #45