Comments on "Feedback on profile negotiation I-D-Accept--Schema" from the comments list

All,

About two weeks ago, Kam Hay Fung from the NSW Department of Education, Australia, sent some comments on the proposed I-D for profile negotiation [0]. In the last CNEG meeting, I was charged with looking at the mail and report back (ACTION-181).

On Thursday, August 09, 2018 1:44 AM, Kam Hay Fung (Kam) [mailto:KamHay.Fung@det.nsw.edu.au] wrote:

> We are working on international standards in the educational sector. The profile
> negotiation proposal by Svensson and Verborgh

More correctly Svensson, Van De Sompel and Verborgh (we need to get Herbert's name into the document, too)

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

My view is that saying that a comma-separated list and a multi-line header are semantically equivalent is a sound requirement and that we should add that and an example to the I-D.

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

Valid point. No objections from me to keep things consistent with other header names.

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

This is probably something we need to discuss. Since there might be other ways than content negotiation to specify profiles (e. g. query strings in URLs) we need to decide on a preference order (that would probably land in the profile negotiation guidance document and not in the I-D).
 
> **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 is a use case for profile look-up [1] and this requirement fits there.

> There are existing ways in the HTTP spec for the look up.
> 1) HTTP HEAD (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 (https://www.w3.org/Protocols/rfc2616/rfc2616-
> sec9.html), used before HTTP POST/PUT/DELETE.

The references to the http specification should probably be RFC 7231 §4.3.2 for HEAD [2] and §4.3.7 for OPTIONS [3].

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

This is interesting. So the question is if we should talk not only about the "easy" case where the server picks a representation by evaluating the Accept-* headers but instead starts a negotiation dialogue using the "300 Multiple Options" reply.

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

If "the [weight] part" means using q-values, I'm all for it!
 
> **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 (https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html)
> and the Proposal might need to position a view for its readers.

This I don't understand. If a profile changes its URI, a cache should not re-use an entry with another (old) profile URI. Or would you say that I've misunderstood the proposal?

[0] https://lists.w3.org/Archives/Public/public-dxwg-comments/2018Aug/0002.html 
[1] https://w3c.github.io/dxwg/ucr/#ID5
[2] https://tools.ietf.org/html/rfc7231#section-4.3.2
[3] https://tools.ietf.org/html/rfc7231#section-4.3.7

Looking forward to your views on this,

Lars

Received on Monday, 20 August 2018 12:56:54 UTC