W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > September 2019

Re: State of ";q=" in URIs

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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 October 2019 00:15:58 UTC