Feedback on profile negotiation I-D-Accept--Schema

Hi,

We are working on international standards in the educational sector. The profile negotiation proposal by Svensson and Verborgh https://profilenegotiation.github.io/I-D-Accept--Schema/I-D-accept-schema (hereafter referred to as the "Proposal") address similar problems in our context. It makes sense for us to rebase our work on the Proposal instead of reinventing the wheel.

At this stage, I have some feedback for the Proposal for consideration.


**Accept-Profile value list**
In RFC7230 3.2.2<https://tools.ietf.org/html/rfc7230#section-3.2.2>, header fields with the same name may be combined into one header field having all their values as a comma-separated list. So, the following examples are semantically equivalent:

Example 1:
Accept-Profile: <http://example.com/shapes/shape-1>; q=0.8,
               <http://example.com/shapes/shape-2>; q=0.5

Example 2:
Accept-Profile: <http://example.com/shapes/shape-1>; q=0.8
Accept-Profile: <http://example.com/shapes/shape-2>; q=0.5

It is unclear the Proposal will also mandate user agents and hosts to support multi-line Accept-Profile headers (i.e. example 2) since the semantics of "," in the Accept-Profile header syntax appears to be the same as that in RFC7230 3.2.2<https://tools.ietf.org/html/rfc7230#section-3.2.2>. If this is the case, a multi-line Accept-Profile example will greatly demonstrate it to the readers. Otherwise, the Proposal needs to make it clear that the multi-line feature is unsupported.


**Naming**
If a profile characterises the body of an HTTP payload only, perhaps the plain "Profile" name might be renamed to "Content-Profile" for consistency? All existing headers prefixed with "Content-" are associated with the payloads.


**Compatibility**
The Proposal does not suggest the extent to which a profile-negotiation-aware host will deal with a user agent not supporting profile negotiation. Options might include the host 1) trying to process requests using a default profile; 2) returning an HTTP error.

Likewise, clarification is needed for a profile-negotiation-aware user agent dealing with a host that does not support profiles.


**Negotiation**
The Proposal relies on HTTP error codes (e.g. 406, 500) in the negotiation process to let user agents determine the right profile to use. While this works for a host, it may overload the use of 406 and potentially fill up the log with lots of noisy errors. It might thus be desirable for a user agent to harmoniously "look up" profiles supported by a host without triggering HTTP errors.

There are existing ways in the HTTP spec for the look up.

  1.  HTTP HEAD (RFC2616 9.4<https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html>) for user agents to perform the "look up" before performing HTTP GET; and
  2.  Similarly, HTTP OPTIONS (RFC2616 9.4<https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html>), used before HTTP POST/PUT/DELETE.

More generally, it might be desirable for user agents and hosts to be more "chatty" at the outset of negotiation, exchanging a few dialogues with one another to determine the right profile(s) to use, and less "chatty" afterwards.

If the Proposal considers any of these lookup mechanisms, there might be further work to include the [weight] part to the Profile header let a host indicate its profile preference to a user agent for its generated content.


**Caching Consideration **
Hosts might wish to continuously upgrade to support/deprecate profiles. Hence, the Profile and Accept-Profile headers in the Proposal will not remain constant. This will influence caching in HTTP (RFC2616 13<https://www..w3.org/Protocols/rfc2616/rfc2616-sec13.html>) and the Proposal might need to position a view for its readers.

Cheers,

Kam Hay Fung
Integration Architect
Information Technology Directorate
NSW Department of Education, Australia



**********************************************************************
This message is intended for the addressee named and may contain
privileged information or confidential information or both. If you
are not the intended recipient please delete it and notify the sender.
**********************************************************************

Received on Thursday, 9 August 2018 15:43:35 UTC