cportele
commented
3 years ago I noticed that there is an I-D that discusses hints in links:
https://www.ietf.org/archive/id/draft-nottingham-link-hint-02.txt
Such a mechanism would not solve this issue (but it could be very handy in other cases, if it gets traction and is adopted), but maybe we can use the hints model as starting point and extend it with CRS information and use it in the response payload.
2021-FEB-01 SWG Meeting: Had a discussion about using the OPTIONS method for providing local (to the resource) operational metadata. What prompted this in the SWG meeting was the strorageCrs. In Part 4, there is a recommendation that clients post content in the storageCrs to prevent conversion errors BUT there is no way to tell the client that a server may in fact restrict inserts/updates/deletes to the storageCrs. The immediate reaction was to add a flag to the collection metadata but there were concerns expressed about an ever expanding metadata blob at the /collections or /collections/{collectionId} endpoints. Using OPTIONS would be an elegant solution since you could do an OPTIONS at the /collections/{collectionId}/items or /collections/{collectionId}/items/{featureId} and get information about whether, for example, the server only supports storageCrs for inserts/updates/replacements ... among other information that might be provided that may or may not be related to Part 4. Although, this is not the common practice with OPTIONS (it normally just provides the available methods and content types and other headers), it is not restricted in the specifications (see: https://tools.ietf.org/html/rfc7231#page-31). In fact the specification says:
"The response payload, if any, might also describe the communication options in a machine or human-readable representation. A standard format for such a representation is not defined by this specification, but might be defined by future extensions to HTTP."
which in my mind is a bit of a green light for to explore using OPTIONS in this way. My feeling is that existing clients would simply ignore the body (since they are likely written to only inspect the headers) but new Part 4 clients would know that they could optionally use the OPTIONS method to get more info about the endpoint prior to doing a Tx.