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

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