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