- From: Lars G. Svensson <lars.svensson@web.de>
- Date: Wed, 25 Sep 2019 20:51:41 +0200
- To: Robert Sanderson <azaroth42@gmail.com>
- Cc: DXWG WG List <public-dxwg-wg@w3.org>
- Message-ID: <c139abf5-b646-ab4b-0047-2f35ed4e74f6@web.de>
Thanks Rob! Best, Lars Am 25.09.2019 um 18:29 schrieb Robert Sanderson: > > Yes, the changes resolve my objections and I'm okay for resolution to > move to CR. Thank you for the engagement and the responses! > > Rob > > On Wed, Sep 25, 2019 at 9:18 AM <lars.svensson@web.de > <mailto:lars.svensson@web.de>> wrote: > > Hi Rob, > in a short meeting today, the editors of conneg-by-ap decided to > go for the solution of putting URIs in angle brackets. All > examples have been updated correspondingly [1,2]. > Further, all references to open issues have been removed from the > document. > Does this resolve your concerns about moving conneg-by-ap to CR? > [1] https://w3c.github.io/dxwg/conneg-by-ap/#http-getresourcebyprofile > [2] https://w3c.github.io/dxwg/conneg-by-ap/#eg-http-get > Thanks, > Lars > *Gesendet:* Mittwoch, 25. September 2019 um 09:44 Uhr > *Von:* lars.svensson@web.de <mailto:lars.svensson@web.de> > *An:* "Robert Sanderson" <azaroth42@gmail.com > <mailto:azaroth42@gmail.com>> > *Cc:* "Rob Atkinson" <rob@metalinkage.com.au > <mailto:rob@metalinkage.com.au>>, "Nick Car" > <nicholas.car@surroundaustralia.com > <mailto:nicholas.car@surroundaustralia.com>>, "DXWG WG List" > <public-dxwg-wg@w3.org <mailto:public-dxwg-wg@w3.org>>, "Ruben > Verborgh" <ruben.verborgh@ugent.be <mailto:ruben.verborgh@ugent.be>> > *Betreff:* Aw: Re: Conneg poll > Hi Rob, > OK, now I get your point about the ";q=" in URIs (needed to sleep > on that one...). > Yes, it's ambiguous since ';' belongs to the reserved characters > in URIs (part of sub-delims in RFC 3986) [1]. My original > intention was to keep the syntax of Accept-Header as similar as > possible to that of Accept, e. g. "text/turtle;q=0.9" which > obviously doesn't work as nicely with URI references as it does > with tokens... > So the question is which delimiters we use to separate the URI > reference from the q-value and from possible other URIs in the > same header. I see three options: > 1) Put all URIs in angle brackets: > Accept-Profile: > <urn:example:profile:1>[OWS];[OWS]q=0.9[OWS],[OWS]<urn:example:profile:2>[OWS];[OWS]q=0.8 > ([OWS]=Optional White Space) > 2) Put all URIs in quotation marks: > Accept-Profile: > "urn:example:profile:1"[OWS];[OWS]q=0.9[OWS],[OWS]"urn:example:profile:2"[OWS];[OWS]q=0.8 > 3) Use white space around all URIs: > Accept-Profile: > urn:example:profile:1[WS];[OWS]q=0.9[OWS],[WS]urn:example:profile:2[WS];[OWS]q=0.8 > 1) and 2) are more in line with "Delimiting a URI in Context" from > RFC 3986 [2]. What do you think? > [1] https://tools.ietf.org/html/rfc3986#appendix-A > [2] https://tools.ietf.org/html/rfc3986#appendix-C > Best, > Lars > *Gesendet:* Dienstag, 24. September 2019 um 22:35 Uhr > *Von:* "Robert Sanderson" <azaroth42@gmail.com > <mailto:azaroth42@gmail.com>> > *An:* lars.svensson@web.de <mailto:lars.svensson@web.de> > *Cc:* "Rob Atkinson" <rob@metalinkage.com.au > <mailto:rob@metalinkage.com.au>>, "Nick Car" > <nicholas.car@surroundaustralia.com > <mailto:nicholas.car@surroundaustralia.com>> > *Betreff:* Re: Conneg poll > I have two objections, one procedural and one technical: > The procedural objection is that the document contains Issue > blocks such as in https://w3c.github.io/dxwg/conneg-by-ap/#profileid > A document that contains unresolved issues is not ready for CR, > regardless of the technical content. If I were the W3M team, I > would immediately reject the transition request as CR documents > should be ready to be implemented with all of the issues > resolved. If there are no findings during CR, then apart from > typos or other minor editorial changes on that magnitude, the > document should be ready for TR. This document is not in that state. > For the technical URI issue, the problem is that the > Accept-Profile header content model is ambiguous, as there isn't a > way to delimit URIs from the header parameters. The example in > section 7.1.2 is: > urn:example:profile:x;q=1.0,urn:example:profile:y;q=0.6 > This is one URI -- there's no way to know that the ; and beyond is > not part of the urn. > The URIs need to be delimited in the same way as for Link headers. > My attack is simply to define a profile with ";q=1.0" as a part of > the URI, and then it will take precedence over other profiles. > The issue can be addressed before CR, or it can be addressed > during CR prompting a new CR period. I think the latter is preferable! > Rob > On Tue, Sep 24, 2019 at 6:05 AM <lars.svensson@web.de > <mailto:lars.svensson@web.de>> wrote: > > Piggy-backing on Nick's questions: > > I cannot find a single URI with ";q=" in it... Can you point > me to that specific location (I think it must be an error...). > > Or do you mean in example 13 [1] where it says > > Accept-Profile: > urn:example:profile:x;q=1.0,urn:example:profile:y;q=0.6 > > In those cases the ";q=" is not part or the URI, but are > q-values similar to > > Accept: text/turtle;q=0.8, application/xml;q=0.5 > > [1] https://w3c.github.io/dxwg/conneg-by-ap/#eg-http-get > > Thanks, > > Lars > > > Gesendet: Dienstag, 24. September 2019 um 14:58 Uhr > > Von: "Nicholas Car" <nicholas.car@surroundaustralia.com > <mailto:nicholas.car@surroundaustralia.com>> > > An: azaroth42@gmail.com <mailto:azaroth42@gmail.com> > > Cc: lars.svensson@web.de <mailto:lars.svensson@web.de>, > rob@metalinkage.com.au <mailto:rob@metalinkage.com.au> > > Betreff: Conneg poll > > > > Hi Rob, > > > > In the Conneg to CR poll you wrote: > > > > > There are still issue blocks saying "to be discussed", > there are still issues with the content negotiation approach > that make the requests ambiguous (for example a URI with ";q=" > in it), and the token approach is still under-motivated. > > > > As you note, there’s no time left now really so I fear that > your objection - the only ‘no’ - will ensure there is no > concerns us in 7 hours time, when we have to vote, and thus, > is consensus is required for us to proceed, the specification > will not make it to a Recommendation. > > > > How strongly do you feel about your points? > > > > The removal of the use of ;q= would be, I think, editorial > since examples are not normative. Also, we do not include > normative requirements ;q= use so if it’s in their incorrectly > or unhelpfully then removing it doesn’t change any normative > content even if it wasn’t in an example. > > > > You also said the token approach is under motivated. If so, > then this is our representation issue in the document: Rob A > and I both have legacy systems that use tokens that we wish to > “wrap” with Conneg and, without token support, implementing > this spec becomes unviable for us. > > > > Can you perhaps agree to allow us to proceed to CR to then > let us find implementation evidence for the token use? (sneak > peak: we have our two implementations and they are independent > - we’ve never collaborated on them and they both existed > before this WG!). > > > > I have to head to bed now before the plenary vote so I won’t > see any answer you make here before the plenary unfortunately. > > > > Thanks, > > > > Nick > > > > — > > Nicholas Car > > Data Systems Architect > > SURROUND Australia > > 0477 560 177 > > nicholas.car@surroundaustralia.com > <mailto:nicholas.car@surroundaustralia.com> > > -- > Rob Sanderson > Semantic Architect > The Getty Trust > Los Angeles, CA 90049 > > > > -- > Rob Sanderson > Semantic Architect > The Getty Trust > Los Angeles, CA 90049
Received on Wednesday, 25 September 2019 18:52:08 UTC