Re: RFC defining "Content Negotiation" (was: RE: Regrets)

Good catch Lars,

and that does reinforce the point I was making - QSA based on a specific
selection from a provided list falls into the definiton of
content-negotiation, and now we have a formal reference we can cite to
justify this.

@Annette Greiner <amgreiner@lbl.gov> does this address your concern?

Rob


On Wed, 14 Nov 2018 at 21:39, Svensson, Lars <L.Svensson@dnb.de> wrote:

> Rob,
>
>
>
> When you quote „the IETF RFC“ it seems that you quote the definition from
> RFC 2616 §1.3 [1]. That RFC is obsoleted through RFC 7230-7234. RFC 7231
> §3.4 [2] offers a much deeper introduction to the topic including
> descriptions of “proactive negotiation” (a.k.a server-driven) and “reactive
> negotiation” (a.k.a. client-driven).
>
>
>
> I don’t know (yet) how to address that in the prof-conneg document…
>
>
>
> [1] https://tools.ietf.org/html/rfc2616#section-1.3
>
> [2] https://tools.ietf.org/html/rfc7231#section-3.4
>
>
>
> Best,
>
>
>
> Lars
>
>
>
> *From:* Rob Atkinson [mailto:rob@metalinkage.com.au]
> *Sent:* Wednesday, November 14, 2018 6:53 AM
> *To:* Simon Cox (E&M, Kensington) <Simon.Cox@csiro.au>
> *Cc:* Annette Greiner <amgreiner@lbl.gov>; pedro winstley <
> pedro.win.stan@googlemail.com>; Dataset Exchange Working Group <
> public-dxwg-wg@w3.org>
> *Subject:* Re: Regrets
>
>
>
> Asking for a list of options and picking one is still arguably
> "negotiation" - although "mediation" might also apply. the IETF RFC merely
> states
>
>
>
> " content negotiation
>
>      The mechanism for selecting the appropriate representation when
> servicing a request."
>
>
>
> It does not explicitly require support for lists of choices.
>
>
>
> This description
> https://en.wikipedia.org/wiki/Content_negotiation#Agent-driven explicitly
> includes the case where a list is provided and the client chooses - but I
> don't see where a specification that defines this is referenced.
>
>
>
> Then there is the sense that QSA may be multi-valued - there are no
> examples given, but this fits the sense of a list
>
>
>
> And finally there are the issues which do need an issue raised IMHO,
> about use of wildcards and returning a more specific profile given
> identifier of a general one. (these both occur in MIME type conneg, you
> dont have to specify sub-profiles of MIME types, but you may receive one.)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, 14 Nov 2018 at 15:53, <Simon.Cox@csiro.au> wrote:
>
> Thanks for clarification Annette. Indeed, I had not picked up the
> distinction.
>
>
>
> *From:* Annette Greiner [mailto:amgreiner@lbl.gov]
> *Sent:* Wednesday, 14 November, 2018 15:24
> *To:* Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>;
> pedro.win.stan@googlemail.com; public-dxwg-wg@w3.org
> *Subject:* Re: Regrets
>
>
>
> I'm distinguishing between negotiating for content and requesting specific
> content. I've not seen negotiation handled this way (where one indicates a
> list of acceptable options and gets a response chosen by the server),
> though I admit I may just not be aware of implementations. File-type
> suffixes allow selection of a particular file; they are not negotiation.
> Typical REST implementations provide another way to select specific files
> with a URL string as well, but those are not negotiations either.
>
>
>
> On 11/13/18 8:49 PM, Simon.Cox@csiro.au wrote:
>
> Ø  Enabling multiple ways to handle content negotiation doesn't seem like
> a win to me, as using query strings is not a standard way of doing content
> negotiation otherwise, so that is a departure from current conneg standards.
>
>
>
> Conneg using paths other than HTTP headers has been a common practice.
> File-type suffixes are the most obvious pattern. The Linked Data API that
> was developed primarily in UK government circles introduced some ‘standard’
> QSA keys like _format, _view, _metadata quite a few years ago. It is true
> that they didn’t get adopted as a standard and I guess you could argue that
> this was because the idea was flawed, but it was responding to a clear need
> which I don’t think has gone away.
>
>
>
> *From:* Annette Greiner [mailto:amgreiner@lbl.gov <amgreiner@lbl.gov>]
> *Sent:* Wednesday, 14 November, 2018 13:36
> *To:* pedro winstley <pedro.win.stan@googlemail.com>
> <pedro.win.stan@googlemail.com>; public-dxwg-wg@w3.org
> *Subject:* Re: Regrets
>
>
>
> I guess I never did it explicitly, but I meant to vote +1 for publishing
> the prof ontology.
>
> Sorry, but for conneg I have to vote -1 until a couple of issues have been
> addressed.
>
> We have two outstanding substantial issues with the conneg doc that I
> would like to see at least marked prominently. One is the presentation of
> the QSA stuff as normative. It should not be normative. Alejandra pointed
> that out quite a while ago, I believe, and I agree. The conneg doc is about
> a standard for header-based content negotiation, and I think it is beyond
> our charter to give normative requirements for a QSA-based approach to
> conneg. I thought this was agreed by the editors, but the document still
> treats that section as normative.
>
> In addition, I opened a second issue about the use of QSA to specify a
> second way of conducting content negotiation rather than as an example of
> how to enable discovery and selection of profiles by using query strings
> (#544).  I strongly supported a requirement for the latter, because it is
> necessary to enable human users to understand what is available and
> recognize when the data available are limited to a specific profile.
> Enabling multiple ways to handle content negotiation doesn't seem like a
> win to me, as using query strings is not a standard way of doing content
> negotiation otherwise, so that is a departure from current conneg
> standards. It may even be harmful, as it creates ambiguity as to whether
> content negotiation is available, since one would have to check both
> methods to determine that it was not available. Rather than addressing the
> issue of how negotiation obscures the choice of profile made behind the
> scenes for human users, it re-creates that problem in a new form. Finally,
> this additional approach is introducing new problems because it requires
> determination of how to handle situations where both types of negotiation
> are attempted.
>
> -Annette
>
>
>
> On 11/13/18 3:01 PM, pedro winstley wrote:
>
> Hi Annette
>
> Did you vote on the proposals for publication?
>
>
>
> On Tue, 13 Nov 2018, 21:00 Annette Greiner <amgreiner@lbl.gov wrote:
>
> Sorry, I won't be able to make today's meeting.
> -Annette
>
> Sent from my iPhone
>
>
>
> --
>
> Annette Greiner
>
> NERSC Data and Analytics Services
>
> Lawrence Berkeley National Laboratory
>
>
>
>
>
> --
>
> Annette Greiner
>
> NERSC Data and Analytics Services
>
> Lawrence Berkeley National Laboratory
>
>
>
>