Suggested reply to Kam Hay Fung's mail on the comments list (FW: Feedback on profile negotiation I-D-Accept--Schema)

Dear all,

As per ACTION-213, here my suggested reply to Kam:

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

Dear Kam,

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

Thanks for your interest in our work, we appreciate your feedback very much!
 
> 
> **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.

The behaviour of this header field should be similar to other header fields, so your Example 1 and your Example 2 should indeed be seen as semantically equivalent. We'll add that to the draft.
 
> **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.

We fully agree here. We'll update the draft so that the response header is named "Content-Profile".

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

We discussed those use cases, and preliminary agreed on the following behaviour:
1) If a user agent does not support profile negotiation and the server does, the server SHOULD return content using its default profile. In that case the server SHOULD also set the Content-Profile header in order to make caching more efficient.
2) If a user agent sends a request containing an "Accept-Profile" header to a server that does not understand profile negotiation, the server SHOULD ignore that header and will accordingly not send an "Content-Profile" response header. This is in line with RFC 7231 § 3.2.1 that states:

   A proxy MUST forward unrecognized header fields unless the field-name
   is listed in the Connection header field (Section 6.1) or the proxy
   is specifically configured to block, or otherwise transform, such
   fields.  Other recipients SHOULD ignore unrecognized header fields.
   These requirements allow HTTP's functionality to be enhanced without
   requiring prior update of deployed intermediaries.

If a user agent sends an "Accept-Profile" header but does not receive a "Content-Profile" header, it should take this as a sign that the server does not understand profiles and that the profile of the returned content is unspecified.

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

Look-up of profiles without having to download the target resource is definitely in-scope and there already is a use case for that [2].

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

The use of http OPTIONS (returning available headers) and http HEAD (using e. g. a Link header to link to other profiles) for profile discovery is something we'll definitely consider. A third way may be to answer with a 300 Multiple Choices status code could also be seen as an option.

There are also other, non-http possibilities for a user agent to specify a preferred profile, e. g. through the use of URL query parameters [3]. That possibility, however, would not be part of the I-D but described in the accompanying Profile Negotiation Guidance document [4]

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

This we didn't quite understand: How should the server indicate its profile preference to the user agent?

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

User agents should assume that profiles identified by profile URIs are immutable, everything else would break backward compatibility. If a profile changes (or rather, if the way the transferred content changes in a way that makes it incompatible with the profile used so far) the profile MUST be given a new URI.

[1] https://tools.ietf.org/html/rfc7230#section-3.2.1
[2] https://w3c.github.io/dxwg/ucr/#ID5
[3] https://github.com/w3c/dxwg/issues/239
[4] https://w3c.github.io/dxwg/conneg-by-ap/
]]

Would that be OK?

Thanks,

Lars

Received on Friday, 14 September 2018 17:09:38 UTC