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