Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IETF submission must not include query param pattern requirements #263

Closed
azaroth42 opened this issue Jun 25, 2018 · 14 comments
Closed

IETF submission must not include query param pattern requirements #263

azaroth42 opened this issue Jun 25, 2018 · 14 comments

Comments

@azaroth42
Copy link

@azaroth42 azaroth42 commented Jun 25, 2018

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:

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.

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.

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 #74 (comment), and proposed clarification as to the scope.

@RubenVerborgh

This comment has been minimized.

Copy link
Member

@RubenVerborgh RubenVerborgh commented Jun 25, 2018

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 comment has been minimized.

Copy link
Member

@RubenVerborgh RubenVerborgh commented Jun 25, 2018

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

This comment has been minimized.

Copy link
Author

@azaroth42 azaroth42 commented Jun 25, 2018

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

@nicholascar

This comment has been minimized.

Copy link
Contributor

@nicholascar nicholascar commented Jun 25, 2018

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

@azaroth42

This comment has been minimized.

Copy link
Author

@azaroth42 azaroth42 commented Jun 25, 2018

@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

This comment has been minimized.

Copy link
Contributor

@nicholascar nicholascar commented Jun 25, 2018

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

This comment has been minimized.

Copy link
Author

@azaroth42 azaroth42 commented Jun 25, 2018

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

This comment has been minimized.

Copy link
Contributor

@larsgsvensson larsgsvensson commented Jun 26, 2018

@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

This comment has been minimized.

Copy link
Contributor

@nicholascar nicholascar commented Jun 26, 2018

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

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

@nicholascar nicholascar changed the title [conneg] IETF submission must not include query param pattern requirements IETF submission must not include query param pattern requirements Sep 1, 2018
@larsgsvensson

This comment has been minimized.

Copy link
Contributor

@larsgsvensson larsgsvensson commented Apr 3, 2019

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

This comment has been minimized.

Copy link
Member

@RubenVerborgh RubenVerborgh commented Apr 3, 2019

I'm happy.

@nicholascar

This comment has been minimized.

Copy link
Contributor

@nicholascar nicholascar commented Apr 3, 2019

I’m happy too

@azaroth42

This comment has been minimized.

Copy link
Author

@azaroth42 azaroth42 commented Apr 3, 2019

👍 Good to close?

@azaroth42 azaroth42 closed this Apr 3, 2019
Content Negotiation by Profile automation moved this from To do to Done Apr 3, 2019
@larsgsvensson

This comment has been minimized.

Copy link
Contributor

@larsgsvensson larsgsvensson commented Apr 3, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
4 participants
You can’t perform that action at this time.