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

Re: State of ";q=" in URIs (was: Fw: Aw: Re: Conneg poll)

From: Robert Sanderson <azaroth42@gmail.com>
Date: Wed, 25 Sep 2019 09:29:12 -0700
Message-ID: <CABevsUF2H3JXX+24tGaKnE1ofRWn+YntsArZHwWD0D0CUxD7gg@mail.gmail.com>
To: lars.svensson@web.de
Cc: DXWG WG List <public-dxwg-wg@w3.org>
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> 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
> *An:* "Robert Sanderson" <azaroth42@gmail.com>
> *Cc:* "Rob Atkinson" <rob@metalinkage.com.au>, "Nick Car" <
> nicholas.car@surroundaustralia.com>, "DXWG WG List" <public-dxwg-wg@w3.org>,
> "Ruben Verborgh" <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>
> *An:* lars.svensson@web.de
> *Cc:* "Rob Atkinson" <rob@metalinkage.com.au>, "Nick Car" <
> 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> 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>
>> > An: azaroth42@gmail.com
>> > Cc: lars.svensson@web.de, 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
>
>
>
> --
> 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 16:29:37 UTC

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