- From: Rob Atkinson <rob@metalinkage.com.au>
- Date: Wed, 14 Nov 2018 21:56:08 +1100
- To: Rob Atkinson <rob@metalinkage.com.au>
- Cc: "Svensson, Lars" <L.Svensson@dnb.de>, Annette Greiner <amgreiner@lbl.gov>, Dataset Exchange Working Group <public-dxwg-wg@w3.org>
- Message-ID: <CACfF9Lz5pM1-OkR6pTO_nP_qdRNxQntSL7epi944ZH-2FScTng@mail.gmail.com>
p.s. i mean the "negotiation" part - not the content-type specifics of course. On Wed, 14 Nov 2018 at 21:55, Rob Atkinson <rob@metalinkage.com.au> wrote: > 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 >> >> >> >>
Received on Wednesday, 14 November 2018 10:56:58 UTC