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

Hi Lars,

Thanks for your reply.

My comments to your response are prefixed with "Kam>" below.

Cheers,

Kam

-----Original Message-----
From: Svensson, Lars <L.Svensson@dnb.de> 
Sent: Tuesday, 25 September 2018 3:57 AM
To: Kam Hay Fung (Kam) <KamHay.Fung@det.nsw.edu.au>
Cc: public-dxwg-comments@w3.org
Subject: RE: Feedback on profile negotiation I-D-Accept--Schema

Dear Kam,

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 
> https://profilenegotiation.github.io/I-D-Accept--Schema/I-D-accept-sch
> ema (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.

Thank you for your feedback and apologies for not coming back to you sooner.

We have discussed your mail in the DXWG Content Negotiation subgroup meeting on 2018-09-12 [0].

Kam> No worries.

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

Kam> Great.

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

Kam> Excellent.

> **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 for the negotiated content type. 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.

Kam> The clarification above makes sense now. If a smart client (which uses "Accept-Profile" is able to interrogate a server about its default profile, it can avoid sending "Accept-Profile" every time.

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

Kam> Perhaps this proposal includes an example of leveraging [2] to help the audience.

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

Kam> This is good. [4] might just need to clarify in this situation whether the headers or query parameters take precedence over the other, when both are present in an HTTP request.

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

Kam> I don't know a concrete way. A user agent might send an HTTP OPTIONS request to an endpoint to discover the server's preference. The server might reply with:
Kam>
Kam> Accept-Profile: <http://example.com/shapes/shape-1>; q=0.8, <http://example.com/shapes/shape-2>; q=0.5
Kam> Content-Profile: <http://example.com/shapes/shape-1>; q=0.8, <http://example.com/shapes/shape-2>; q=0.5
Kam>
Kam> This example overloads the semantics of "Content-Profile" since there won't be any payload to return to the user agent. Perhaps, a new HTTP header, "Produce-Profile" like below, is required to declare its preference. Just a thought:
Kam> Accept-Profile: <http://example.com/shapes/shape-1>; q=0.8, <http://example.com/shapes/shape-2>; q=0.5
Kam> Produce-Profile: <http://example.com/shapes/shape-1>; q=0.8, <http://example.com/shapes/shape-2>; q=0.5

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

Kam> I totally agree with the immutability.

[0] https://www.w3.org/2018/09/12-dxwgcneg-minutes.html#x03
[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/

Best,

Lars
**********************************************************************
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 Tuesday, 2 October 2018 05:52:34 UTC