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

Aw: Re: Re: Conneg poll

From: <lars.svensson@web.de>
Date: Wed, 25 Sep 2019 14:01:52 +0200
Message-ID: <trinity-0d925268-9e70-435a-936f-7942d266c398-1569412912382@3c-app-webde-bs46>
To: andrea.perego@ec.europa.eu, "Ruben Verborgh" <ruben.verborgh@ugent.be>
Cc: azaroth42@gmail.com, rob@metalinkage.com.au, nicholas.car@surroundaustralia.com, public-dxwg-wg@w3.org
> Gesendet: Mittwoch, 25. September 2019 um 09:52 Uhr
> Von: andrea.perego@ec.europa.eu
> An: lars.svensson@web.de, azaroth42@gmail.com
> Cc: rob@metalinkage.com.au, nicholas.car@surroundaustralia.com, public-dxwg-wg@w3.org, ruben.verborgh@ugent.be
> Betreff: Re: Re: Conneg poll
>
> Hi, Lars.
> 
> Sorry for jumping in the conversation, but, IMO, option (1) is the way to go, also to be consistent with how this is addressed in HTTP Link headers, as Rob noted in his email:

Yes, and Link headers ar different from Accept-* headers... All other Accept-* headers work with tokens, so we don't really have a precedence case we can follow.

> https://tools.ietf.org/html/rfc5988#section-5.1

That link probably should be https://tools.ietf.org/html/rfc8288#section-3.1 now that RFC 5988 is obsoleted...

Best,

Lars
> ________________________________________
> From: lars.svensson@web.de <lars.svensson@web.de>
> Sent: 25 September 2019 09:44:07
> To: Robert Sanderson
> Cc: Rob Atkinson; Nick Car; DXWG WG List; Ruben Verborgh
> Subject: 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__w3c.github.io_dxwg_conneg-2Dby-2Dap_-23profileid&d=DwMBaQ&c=8NwulVB6ucrjuSGiwL_ckQ&r=3qWTbVstaahwJbbUOpQF8B0aYkdAx7yOqz0kFsu6am0&m=fifOHx88LRaoOLuivHscGmOEfhKgTFY1E6iZCYFOI10&s=cpg0sQoPzurdC8nFcEzmNbEIGwu3H8UAbUJrg8aNu20&e=>
> 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__w3c.github.io_dxwg_conneg-2Dby-2Dap_-23eg-2Dhttp-2Dget&d=DwMBaQ&c=8NwulVB6ucrjuSGiwL_ckQ&r=3qWTbVstaahwJbbUOpQF8B0aYkdAx7yOqz0kFsu6am0&m=fifOHx88LRaoOLuivHscGmOEfhKgTFY1E6iZCYFOI10&s=g-6UFR6OFGGXdELrTrbTkiJxqsZi_1auS_Q5Z-mrdGM&e=>
> 
> 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
> 
>
Received on Wednesday, 25 September 2019 12:02:35 UTC

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