10:55:36 <RRSAgent> RRSAgent has joined #dxwg
10:55:40 <RRSAgent> logging to https://www.w3.org/2023/07/26-dxwg-irc
10:56:09 <LarsG> zakim, start meeting
10:56:09 <Zakim> RRSAgent, make logs Public
10:56:11 <Zakim> please title this meeting ("meeting: ..."), LarsG
10:56:36 <LarsG> this is DXWG CNEG Subgroup
10:57:27 <LarsG> rrsagent please draft minutes v2
10:58:06 <LarsG> meeting: DXWG CNEG Subgroup Telecon
10:58:21 <LarsG> RRSAgent, please draft minutes v2
10:58:23 <RRSAgent> I have made the request to generate https://www.w3.org/2023/07/26-dxwg-minutes.html LarsG
11:02:02 <LarsG> present+
11:02:07 <roba> roba has joined #dxwg
11:02:17 <roba> present+
11:02:53 <YoucTagh> YoucTagh has joined #dxwg
11:03:49 <YoucTagh> present+
11:05:19 <LarsG> Agenda https://www.w3.org/2017/dxwg/wiki/Meetings:Telecon2023.07.26
11:05:44 <roba> scribenick: roba
11:06:38 <pchampin> present+
11:06:50 <LarsG> Topic: approve last meeting's minutes
11:07:00 <roba> +0
11:07:09 <pchampin> +0
11:07:12 <LarsG> PROSOSED: Approve minutes at https://www.w3.org/2023/06/28-dxwg-minutes
11:07:22 <LarsG> +1
11:07:55 <YoucTagh> +1
11:08:10 <roba> s/PROSOSED/PROPOSED
11:08:27 <LarsG> RESOLVED: Approve minutes at https://www.w3.org/2023/06/28-dxwg-minutes
11:08:49 <LarsG> TOPIC: Updates
11:09:30 <roba> roba: talking to OAS (OpenAPI) - will be exploring ConnegP binding to OpenAPI
11:10:32 <roba> ...OGC will be engagigng OAS and exploring relationship between OAS and ConnecgP
11:10:39 <antoine> antoine has joined #dxwg
11:11:01 <roba> LarsG: update on IETF
11:11:20 <roba> ... with Reuben Verbough resumed work on IETF draft
11:11:40 <roba> ... RFC19110 implications being explored
11:12:07 <roba> ...incorporating editorial comments from @YouicTagh
11:12:31 <LarsG> s/RFC19110/RFC9110/
11:12:47 <roba> YoucTagh: explained active vs reactive content negotiation - whether server makes choice or not
11:14:09 <roba> LarsG: might replace hints from current draft:
11:14:37 <roba> roba: does this apply only to HTTP - does it affect QSA binding?
11:15:17 <roba> ...how should should we proceed?
11:15:51 <roba> LarsG: new information - will need to be decided on - timeframe to be determined
11:16:45 <LarsG> issue is https://github.com/ProfileNegotiation/I-D-Profile-Negotiation/issues/38
11:17:23 <roba> ... group to review after initial analysis
11:17:47 <roba> roba: Anything from RDF* ?
11:18:17 <roba> pchampin: not yet ready - will ping group again to elicit input
11:19:01 <roba> ...open action to describe "conformance levels" - relationship to profiles
11:19:07 <LarsG> Topic: Issues due for closing
11:19:12 <LarsG> https://github.com/w3c/dx-connegp/issues?q=is%3Aissue+is%3Aopen+label%3A%22due+for+closing%22
11:23:46 <antoine> rrsagent, please draft minutes v2
11:23:48 <RRSAgent> I have made the request to generate https://www.w3.org/2023/07/26-dxwg-minutes.html antoine
11:24:00 <roba> roba: LarsG to add links to issue https://github.com/w3c/dx-connegp/issues/6 to review before closing
11:25:43 <roba> roba: to review changes to PR 42
11:25:53 <antoine> scribenick: antoine
11:26:09 <antoine> ... I'll take 42 offline
11:26:30 <roba> https://github.com/w3c/dx-connegp/pull/28
11:26:50 <pchampin> q+
11:26:53 <antoine> rob: I need to add my review
11:27:11 <antoine> ... straightforward
11:27:23 <antoine> s/rob:/roba:
11:29:02 <antoine> ... but it's still blocked
11:29:22 <antoine> pchampin: maybe nick's review was before some other changes? no
11:29:39 <antoine> antoine: maybe it's because nick's alias is not in the group
11:29:50 <antoine> pchampin: nick's review is grey, so not counted
11:30:22 <antoine> ... yes he's not counted as participants of the repo
11:30:36 <antoine> ... I'm assuming he's not listed in the DXWG anymore
11:30:59 <antoine> ... I'm happy to approve the PR
11:31:53 <antoine> roba: ok, merging
11:32:14 <roba> https://github.com/w3c/dx-connegp/pull/29
11:32:37 <antoine> roba: straightforward
11:34:27 <antoine> pchampin: approving
11:35:11 <roba> https://github.com/w3c/dx-connegp/pull/46
11:35:38 <antoine> roba: PR from YoucTagh related to changes in examples from canonical to alternate
11:36:17 <antoine> YoucTagh: there's an issue on it
11:38:43 <antoine> LarsG: example 19 shows two canonical links
11:39:17 <antoine> ... I'm not sure about the resolution
11:39:39 <antoine> roba: yes it could be ok to say that there's one canonical html and one canonical turtle
11:40:54 <antoine> ... maybe we need to change the text. Or we allow canonical to be for a combination of mime-type and ??
11:41:32 <antoine> LarsG: I think we much change the text, as YoucTagh is right
11:41:36 <antoine> at https://github.com/w3c/dx-connegp/issues/44
11:42:11 <antoine> roba: YoucTagh are you ok with changing the text to say that canonical is for a mime-type?
11:42:16 <antoine> YoucTagh: it clarifies, yes
11:42:27 <roba> Current text "The default representation – the one that will be returned when no specific representation is requested – will be identified by rel="canonical", other representations by rel="alternate"."
11:42:44 <roba> Proposed: The default representation – the one that will be returned when no specific representation is requested for a specific MIME type – will be identified by rel="canonical", other representations by rel="alternate".
11:43:11 <pchampin> q+
11:43:36 <antoine> pchampin: is it legal in the first place to have several canonicals?
11:43:53 <pchampin> https://www.rfc-editor.org/rfc/rfc6596.html
11:43:55 <LarsG> ack pchampin
11:44:32 <antoine> pchampin: the text has no MUST not SHOULD
11:45:19 <pchampin> s/the text/there is a *guideline* advising to have only one, but it
11:45:39 <roba> RFC 6596: "To better ensure that applications properly handle the canonical link    relation, administrators ought to consider the following guidelines:     o  Specify only one canonical link relation for a resource.  (It       would be confusing to consider/label/designate more than one IRI       as authoritative.)"
11:46:38 <antoine> ... we would be stretching the guideline
11:47:04 <antoine> ... or we could remove it (having just one canonical) but then we remove expressivity.
11:47:44 <antoine> LarsG: the text says, this is what to be returned if there's no indication of media type nor profile
11:48:32 <antoine> roba: the issue is that if the client says they want html and there's two representations, then there's no way to indicate the prefered one.
11:48:57 <antoine> s/??/profile
11:49:08 <antoine> LarsG: yes we would lose expressivity
11:49:13 <pchampin> q+
11:49:31 <antoine> roba: I don't see anything in the IANA register that would provide alternative semantics
11:49:32 <antoine> q+
11:50:00 <LarsG> ack antoine
11:51:08 <antoine> antoine: could we keep the current example, but flagging the issue that we've got a specific interpretation of a resource here?
11:51:19 <antoine> roba: we could
11:51:46 <antoine> pchampin: RFC doesn't seem to address content negotiation. It addresses "duplicative content"
11:51:59 <antoine> roba: the profile defines the content
11:52:41 <antoine> pchampin: any IRI that returns slightly different content. I'm not sure it would fit
11:53:10 <antoine> ... canonical would be appropriate for resources with the same content
11:54:29 <antoine> ... The rel can use several links. Maybe having both 'alternate' and 'canonical' would be ok
11:54:59 <antoine> ... I don't know how clients work with it
11:55:13 <LarsG> q+
11:55:25 <LarsG> ack pchampin
11:55:27 <pchampin> https://signposting.org/
11:55:34 <antoine> roba: I've tried to force bookmarking specific resources using 'canonical' but it failed.
11:56:09 <antoine> pchampin: the signposting website could be useful for inspiration
11:56:37 <antoine> LarsG: search engines would use the canonical link to redirect users to
11:56:43 <pchampin> https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls
11:56:47 <antoine> ... this is the only use I've seen so far
11:57:07 <antoine> ... I agree with YoucTagh that we might stretch the RFC too far
11:57:55 <antoine> roba: we could (1) remove 'canonical' altogether and let implementers do their stuff; (2) add a note about interpretation; (3) ??
11:58:04 <antoine> ... we could prepare this and take feedback
11:58:37 <antoine> s/??/mint another link relationship
11:59:10 <antoine> ... maybe we should take an action to see if having a new link relation type would be realistic
11:59:31 <antoine> ... I have no experience on how registration of new types work
11:59:58 <antoine> pchampin: there is a template that we can use in the W3C document and the W3C team liaises with IETF
12:00:12 <antoine> roba: given where we are, we could explore this.
12:00:27 <antoine> LarsG: RFC8288 has the procedure
12:00:28 <LarsG> https://www.rfc-editor.org/rfc/rfc8288#section-2.1.1.1
12:00:40 <antoine> RRSAgent, please draft minutes v2
12:00:41 <RRSAgent> I have made the request to generate https://www.w3.org/2023/07/26-dxwg-minutes.html antoine
12:00:52 <antoine> roba: we should have a candidate name
12:01:11 <antoine> ACTION: group to explore options for the link relation type
12:01:33 <YoucTagh> +1
12:01:40 <antoine> ACTION: roba to cleanup the YoucTagh 's PR
12:02:20 <antoine> s/the YoucTagh/YouTagh
12:02:38 <antoine> LarsG: should we close the due for closing?
12:02:49 <antoine> roba: I'd prefer to clean the PR(s) first
12:02:50 <antoine> +1
12:02:57 <LarsG> +1
12:03:06 <antoine> RRSAgent, please draft minutes v2
12:03:07 <RRSAgent> I have made the request to generate https://www.w3.org/2023/07/26-dxwg-minutes.html antoine
12:03:13 <roba> +1
12:19:36 <LarsG> zakim, end meeting
12:19:36 <Zakim> As of this point the attendees have been LarsG, roba, YoucTagh, pchampin
12:19:38 <Zakim> RRSAgent, please draft minutes
12:19:39 <RRSAgent> I have made the request to generate https://www.w3.org/2023/07/26-dxwg-minutes.html Zakim
12:19:45 <Zakim> I am happy to have been of service, LarsG; please remember to excuse RRSAgent.  Goodbye
12:19:46 <Zakim> Zakim has left #dxwg