Re: Moving conneg-by-ap to CR -- addressing concerns about the use of tokens

Hi Annette,

Thanks for abstaining so as not to block the potential move to CR! Yes,
the schedule constraints do make me worry...

Regarding where to publish the token mappings so that they are
machine-readable, the use of a Link header still seems the most
convenient way (to me). It will certainly be part of the profile
description (cf. the discussion about prof:token vs. adms:identifier).
You mention the "returned list of options" as another possible place,
but that is only valid when you use QSA and doesn't work with http
negotiation.

I think that server configuration should not bee too difficult, but I've
written about that in my other mail.

Best,

Lars (who's thinking about the vote in 36 hour's time...)

Am 20.09.2019 um 03:29 schrieb Annette Greiner:
> Thanks, Lars, for pulling all this together. I was out for a couple of
> key weeks on holiday and have been working through the 700 emails that
> ended up in my w3c mail folder during that time. So, I'm sorry that
> these suggestions seem late, though they did seem to be under
> discussion by others pretty recently.
>
> My vote was to wait a bit before review and freezing, so that the
> editors would have a chance to finish up the discussion about the
> various issues still simmering and so that I would be able then to
> vote yes for moving to CR. When it became evident that there is no
> willingness to wait on the freeze due to schedule constraints, I
> switched to an abstention so as not to block things.
>
> Re the use of tokens, I support them for the case of a query string
> but not elsewhere. Removing all mention of them as identifiers
> satisfies one concern about how they are used. My other concern is
> just to keep things as simple as possible and avoid creating new
> required (if you use tokens) headers. I saw the conversation about
> where the mapping from token to URI should appear, and it occurred to
> me that that really doesn't need to appear in headers if it appears in
> the returned list of options itself. That takes care of letting the
> client know what token to use in a query to that server. The preferred
> token is something different, which I think would belong in the
> profile itself. As long as header-based negotiation can be done
> entirely with URIs, I think the role of tokens can be quite limited.
> We do need to offer a mapping between tokens and the profiles of
> datasets returned by a given server, but it doesn't need to be in
> headers. Technically, we wouldn't even need to do a mapping between
> tokens and URIs, but I think it would be best practice to do it anyway.
>
> Re the handling of conflicts, I think we need to offer guidance to
> developers of general-purpose server software that they can follow.
> Since they already support content negotiation for media types and
> languages, I would expect them to at least consider supporting conneg
> for profiles. I don't think we should ask them to parse query strings.
> There are a few other options, though. We could ask them to drop
> content negotiation if there is a query string present, and to send
> the request forward as if the conneg directives for the URL were not
> present. That would have the effect of preventing any future
> innovative uses of query strings for negotiated content, and it would
> do the wrong thing when a user adds a query string by accident. We
> could say the server should drop the query string and just do the
> content negotiation as if it weren't there. This handles the user
> error case nicely but probably does the wrong thing for the case of
> misconfiguration half the time, and it again prevents innovative use
> of the combination. Or the server could take a kind of literal
> approach and consider the query string as part of the mapping for the
> negotiation. That is, one could actually configure the server to
> handle negotiation for a URL with a specific query string and have it
> negotiate specifically for that case.
>
> There are a lot of cases here now that I think it all through. Here is
> what I would expect for the literalist approach:
>
> config    request    behavior
>
> conneg directive for URL w/out query string*    query string present**
>    pass to app
> conneg directive for URL w/out query string    query string not
> present    handle conneg (no conflict)
> conneg directive for URL w/query string    query string present handle
> conneg
> conneg directive for URL w/query string    query string not present   
> serve from file system or pass to app
> no matching directive for URL    query string not present    serve
> from file system or pass to app (no conflict)
> no matching directive for URL    query string present     serve from
> file system or pass to app (no conflict)
> no matching directive for URL w/query string but directive for URL
> w/out query string    query string present    pass to app
> no matching directive for URL w/out query string but directive for URL
> w/query string    query string not present    handle conneg
> conneg directive for URL w/query string and URL w/out query string   
> query string present    handle conneg for URL w/query string
> conneg directive for URL w/query string and URL w/out query string   
> query string not present   handle conneg for URL w/out query string
>
> *there is a directive in the server configuration that maps a URL that
> has no query string to a set of options.
> **the client issues a request to the server for a URL that includes
> query string arguments.
>
>
> Here is the approach where QSA always wins:
>
> config    request    behavior
>
> conneg directive for URL w/out query string*    query string present**
>    pass to app
> conneg directive for URL w/out query string    query string not
> present    handle conneg (no conflict)
> -conneg directive for URL w/query string    query string present   
> pass to app
> conneg directive for URL w/query string    query string not present   
> serve from file system or pass to app
> no matching directive for URL    query string not present    serve
> from file system or pass to app (no conflict)
> no matching directive for URL    query string present     serve from
> file system or pass to app (no conflict)
> no matching directive for URL w/query string but directive for URL
> w/out query string    query string present    pass to app
> -no matching directive for URL w/out query string but directive for
> URL w/query string    query string not present    pass to app
> -conneg directive for URL w/query string and URL w/out query string   
> query string present    pass to app
> -conneg directive for URL w/query string and URL w/out query string   
> query string not present   pas to app
>
> -differs from literalist approach
>
> I also have a comment on #1022 that hasn't been resolved, along with
> Isaac.
>
> -Annette
>
> On 9/18/19 8:39 AM, lars.svensson@web.de wrote:
>> Dear Annette,
>>
>> I couldn't attend the DXWG meeting yesterday but read the minutes
>> [0]. From what I understand, you oppose to moving conneg-by-ap to CR
>> (first voting -1, then 0) as you "think there are open conversations
>> issues".
>>
>> You have been very helpful in shaping the work of the conneg
>> deliverable and have provided valuable feedback and as one of the
>> editors I'm contacting you to see if there is chance to resolve those
>> open issues so that we can move the specification forward to CR.
>>
>> My understanding is that your main points of critique are about the
>> use of tokens. That indeed seems to be the most controversially
>> discussed feature in the spec with comments ranging from "tokens are
>> completely unnecessary and their use should be discouraged" to
>> "tokens are an essential feature of deployed APIs and we need to
>> standardise their use in order to improve interoperability".
>>
>> What I haven't understood yet is exactly where your position on this
>> is. From reading your comments in #453, #501 and #505, I get the
>> impression that you are not completely opposed to the use of tokens
>> but have concerns regarding how far it is possible to give normative
>> instructions on how to use them.
>>
>> In #453 (Consider use of adms:identifier instead of prof:token) you
>> say that the spec (in this case prof:) should not claim that tokens
>> are identifiers [1]. The editors of that spec have offered to change
>> the definition of prof:hasToken to accommodate that [2]. Would that
>> resolve that issue for you?
>>
>> In #501 (Registration of target attribute "profile" for the
>> Link-Header) I read your position to be that even if tokens in some
>> cases can be used to specify (or name) a profile, it is unnecessary
>> to provide a method to convey token/URI mappings in http headers
>> since that information can be transported in a profile description
>> (e. g. a human-readable document or an RDF graph using prof:). In
>> #501 you say that you have "not seen discussion that convinces me
>> that we really need token mappings" and that we've moved away from
>> the assumption that "a thing [sc. a token] has the same standing as a
>> URI and can be used in the same ways" [3]. As seen in #290 [4], there
>> is a plenary-approved requirement for this kind of mapping and given
>> that there has been much discussion in that issue over the last four
>> weeks I'm surprised that you voice your concerns so late in the
>> process. It might be that we have moved away from the assumption that
>> tokens have the same standing as URIs but I don't see how that
>> renders tokens – or a machine-readable mapping from tokens to URIs –
>> useless. Can you expand a bit on exactly what is your concern here?
>>
>> In #505 (Specify the realisation order of precedence for conflicting
>> profile negotiation situations) I read your concern to be that the
>> conneg-by-ap spec would force _all_ http server implementers to
>> change their software to be compliant [5]. My personal understanding
>> of the spec's intention is that the order of precedence is only
>> relevant for server implementations that implement _both_ QSA
>> negotiation _and_ http negotiation as specified in conneg-by-ap. If
>> you agree with that I'd be happy to discuss text edits that clarify
>> that (assuming that the other editors would agree...).
>>
>> I'm looking forward to your views on this and hope that we can have
>> it resolved in time for the vote.
>>
>> [0] https://www.w3.org/2019/09/17-dxwg-minutes
>> [1] https://github.com/w3c/dxwg/issues/453#issuecomment-532420615
>> [2] https://github.com/w3c/dxwg/issues/453#issuecomment-532442529
>> [3] https://github.com/w3c/dxwg/issues/501#issuecomment-532436539
>> [4] https://github.com/w3c/dxwg/issues/290
>> [5] https://github.com/w3c/dxwg/issues/505#issuecomment-532441285
>>
>> Best,
>>
>> Lars
>>

Received on Monday, 23 September 2019 04:44:48 UTC