Dxwg: IETF submission must not include query param pattern requirements

[azaroth42]

I believe that any submission to the IETF for the processing rules around content negotiation for profiles that includes query parameters as a mechanism rather than the proposed Accept-Profile header will be rejected, as it conflicts with base W3C and IETF architectural constraints.

In particular:

• https://tools.ietf.org/html/rfc7320#section-2.4
  > Extensions MUST NOT constrain the format or semantics of queries.

Meaning that we must not say that uses of _view or _format or _profile or similar have special semantics.

• https://tools.ietf.org/html/rfc3986#section-3.4
  > The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource [...]

Meaning that the query parameter is included in the URI for determining the identity of the resource. Thus foo?_profile=p1 is a different resource (in RDF terms) from foo or foo?_profile=p2. This would make it not content negotiation at all, just separate resources.

• https://www.w3.org/TR/webarch/#frag-coneg
  > Content negotiation refers to the practice of making available multiple representations via the same URI.

Combined with the above, makes _profile not count as "content negotiation", as the URI is different because the query component of the URI is part of the opaque URI string.

And etc. I'm sure that @RubenVerborgh can provide further supporting documents.

This is NOT to say that the WG cannot specify such an approach, but that it must be separate from the formal content negotiation deliverable.

This is an expansion of https://github.com/w3c/dxwg/issues/74#issuecomment-391228832, and proposed clarification as to the scope.

[RubenVerborgh]

Ooh, those are lovely arguments. Mine was just more general: clients should not assume anything about a server's URL structure beyond what the URL specification mandates. Or the other way round: servers should not have their choice of URL constrained.

[RubenVerborgh]

This would make it not content negotiation at all, just separate resources.

Just one small remark here: representations CAN have their own identifiers, but 1) the server has the full freedom to choose those identifiers 2) for content negotiation purposes, an URL pointing to the non-negotiated resource should exist.

[azaroth42]

+1 to @RubenVerborgh's clarification about identity of the representation vs the protocol by which the representation is requested.

[nicholascar]

No one has ever suggested that an IETF submission contain query string arguments.

[azaroth42]

@nicholascar Great, I must be misinterpreting the deliverables list then :) It would be worth clarifying exactly where each of the mechanisms that will allow a client to get to data that has a particular profile are to be documented.

(edited for clarity)

[nicholascar]

The deliverable from this group is about profile guidance - a Best Practice doc. Then there are likely to be multiple implementations, one in HTTP, one using an API with QSAs and other things and an Ontology- ProfileDesc. They should be equivalent and adhere to the BP doc.

The pyLDAPI tool i’m Implementing handles both the HTTP methods (Accept-Profile & Profile headers, read only for now) and QSA API and will shortly implement ProfileDesc (it implements a precursor ontology). Not hard to see it easily doing all things equivalently as we are only proposing a few mechanics really.

[azaroth42]

I don't think that is possible, unfortunately. A non-rec-track best practice note cannot create new HTTP headers such as Accept-Profile. As far as I understand Process, the equivalent RFC2026 and the IETF/W3C liaison process, we can sponsor an RFC that will be well received (but not rubber stamped) because IETF recognizes the W3C process as sufficiently robust to generate appropriate quality specifications. We should discuss with Heather Flanagan and Mark Nottingham, hopefully before TPAC to avoid leaving it down to the wire.

If the group does not consider the registration of the Accept-Profile header with IETF to be in scope, then it should consider rechartering as it cannot fulfill its deliverables, as there won't be an RFC to reference.

[larsgsvensson]

@nicholascar scripsit:

The deliverable from this group is about profile guidance - a Best Practice doc. Then there are likely to be multiple implementations, one in HTTP, one using an API with QSAs and other things and an Ontology- ProfileDesc. They should be equivalent and adhere to the BP doc.

According to our charter the group has three rec-track deliverables:

• DCAT++
• Guidance on publishing application profiles of vocabularies (A definition of what is meant by an application profile and an explanation of one or more methods for publishing and sharing them).
• Content Negotiation by Application Profile (An explanation of how to implement the expected RFC and suitable fallback mechanisms as discussed at the SDSVoc workshop)

(So it's not only profile guidance...)

@azaroth42 scripsit:

I don't think that is possible, unfortunately. A non-rec-track best practice note cannot create new HTTP headers such as Accept-Profile.

So since the content-negotiation-by-application-profile deilverable is on rec track we should be fine. Best practice documents can be on rec track too, as shown by the Data on the Web BP. Spatial Data on the Web BP was on rec track, too, but we didn't manage to get it ready before the WG ended...

If the group does not consider the registration of the Accept-Profile header with IETF to be in scope, then it should consider rechartering as it cannot fulfill its deliverables, as there won't be an RFC to reference.

I'm probably biased, but I consider the registration to be in scope...

[nicholascar]

I have always considered the IETF doc to be in scope!

I'm pretty happy with the state as described by @larsgsvensson above.

[larsgsvensson]

Having read and re-read this thread, it seems that we agree that the IETF submission will not contain anything about Query String Arguments or any other kind of URL patterns. Particularly the comment from ncar "No one has ever suggested that an IETF submission contain query string arguments" suggests this. I suggest that we close this issue as resolved. @nicholascar, @RubenVerborgh, @azaroth42: any comments from you on this?

[RubenVerborgh]

I'm happy.

[nicholascar]

I’m happy too

[azaroth42]

:+1: Good to close?

[larsgsvensson]

I reopen so that we can stick to the process...