– DRAFT –
DXWG CNEG Subgroup Telecon

<LarsG> this is DXWG CNEG Subgroup

<LarsG> rrsagent please draft minutes v2

approve last meeting's minutes

+0

<pchampin> +0

<LarsG> PROPOSED: Approve minutes at https://www.w3.org/2023/06/28-dxwg-minutes

<LarsG> +1

<YoucTagh> +1

RESOLUTION: Approve minutes at https://www.w3.org/2023/06/28-dxwg-minutes

Updates

roba: talking to OAS (OpenAPI) - will be exploring ConnegP binding to OpenAPI
… OGC will be engagigng OAS and exploring relationship between OAS and ConnecgP

LarsG: update on IETF
… with Reuben Verbough resumed work on IETF draft
… RFC9110 implications being explored
… incorporating editorial comments from @YouicTagh

YoucTagh: explained active vs reactive content negotiation - whether server makes choice or not

LarsG: might replace hints from current draft:

roba: does this apply only to HTTP - does it affect QSA binding?
… how should should we proceed?

LarsG: new information - will need to be decided on - timeframe to be determined

<LarsG> issue is ProfileNegotiation/I-D-Profile-Negotiation#38

LarsG: group to review after initial analysis

roba: Anything from RDF* ?

pchampin: not yet ready - will ping group again to elicit input
… open action to describe "conformance levels" - relationship to profiles

Issues due for closing

<LarsG> https://github.com/w3c/dx-connegp/issues?q=is%3Aissue+is%3Aopen+label%3A%22due+for+closing%22

roba: LarsG to add links to issue w3c/dx-connegp#6 to review before closing

roba: to review changes to PR 42

... I'll take 42 offline

<roba> w3c/dx-connegp#28

roba: I need to add my review
… straightforward
… but it's still blocked

pchampin: maybe nick's review was before some other changes? no

antoine: maybe it's because nick's alias is not in the group

pchampin: nick's review is grey, so not counted
… yes he's not counted as participants of the repo
… I'm assuming he's not listed in the DXWG anymore
… I'm happy to approve the PR

roba: ok, merging

<roba> w3c/dx-connegp#29

roba: straightforward

pchampin: approving

<roba> w3c/dx-connegp#46

roba: PR from YoucTagh related to changes in examples from canonical to alternate

YoucTagh: there's an issue on it

LarsG: example 19 shows two canonical links
… I'm not sure about the resolution

roba: yes it could be ok to say that there's one canonical html and one canonical turtle
… maybe we need to change the text. Or we allow canonical to be for a combination of mime-type and profile

LarsG: I think we much change the text, as YoucTagh is right

at w3c/dx-connegp#44

roba: YoucTagh are you ok with changing the text to say that canonical is for a mime-type?

YoucTagh: it clarifies, yes

<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"."

<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".

pchampin: is it legal in the first place to have several canonicals?

<pchampin> https://www.rfc-editor.org/rfc/rfc6596.html

pchampin: there is a *guideline* advising to have only one, but it has no MUST not SHOULD

<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.)"

pchampin: we would be stretching the guideline
… or we could remove it (having just one canonical) but then we remove expressivity.

LarsG: the text says, this is what to be returned if there's no indication of media type nor profile

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.

LarsG: yes we would lose expressivity

roba: I don't see anything in the IANA register that would provide alternative semantics

antoine: could we keep the current example, but flagging the issue that we've got a specific interpretation of a resource here?

roba: we could

pchampin: RFC doesn't seem to address content negotiation. It addresses "duplicative content"

roba: the profile defines the content

pchampin: any IRI that returns slightly different content. I'm not sure it would fit
… canonical would be appropriate for resources with the same content
… The rel can use several links. Maybe having both 'alternate' and 'canonical' would be ok
… I don't know how clients work with it

<pchampin> https://signposting.org/

roba: I've tried to force bookmarking specific resources using 'canonical' but it failed.

pchampin: the signposting website could be useful for inspiration

LarsG: search engines would use the canonical link to redirect users to

<pchampin> https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls

LarsG: this is the only use I've seen so far
… I agree with YoucTagh that we might stretch the RFC too far

roba: we could (1) remove 'canonical' altogether and let implementers do their stuff; (2) add a note about interpretation; (3) mint another link relationship
… we could prepare this and take feedback
… maybe we should take an action to see if having a new link relation type would be realistic
… I have no experience on how registration of new types work

pchampin: there is a template that we can use in the W3C document and the W3C team liaises with IETF

roba: given where we are, we could explore this.

LarsG: RFC8288 has the procedure

<LarsG> https://www.rfc-editor.org/rfc/rfc8288#section-2.1.1.1

roba: we should have a candidate name

ACTION: group to explore options for the link relation type

<YoucTagh> +1

ACTION: roba to cleanup YouTagh 's PR

LarsG: should we close the due for closing?

roba: I'd prefer to clean the PR(s) first

+1

<LarsG> +1

<roba> +1