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

Thanks Rob.

Any further comments until I send it to the comment list?

Best,

Lars

> -----Original Message-----
> From: Rob Atkinson [mailto:rob@metalinkage.com.au]
> Sent: Saturday, September 15, 2018 7:12 AM
> To: Svensson, Lars <L.Svensson@dnb.de>
> Cc: public-dxwg-wg@w3.org
> Subject: Re: Suggested reply to Kam Hay Fung's mail on the comments list (FW:
> Feedback on profile negotiation I-D-Accept--Schema)
> 
> +1
> 
> excellent work
> 
> 
> On Fri, 14 Sep 2018 at 19:09 Svensson, Lars <mailto:L.Svensson@dnb.de> wrote:
> Dear all,
> 
> As per ACTION-213, here my suggested reply to Kam:
> 
> [[
> Thursday, August 09, 2018 1:44 AM, Kam Hay Fung (Kam)
> [mailto: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 Tuesday, 18 September 2018 07:32:18 UTC