Re: ACTION on ALL - FPWDs / Comments on "Content Negotiation by Profile"

  Dear all, 

  here are my notes on "Content Negotiation by Profile" [1] as retrieved today, 11/13/2018.
 Beside this information I do not have objections preventing its WD publication.

> "When a non-existent or unsupported profile is requested, a server returns default content"

- clarify what is meant here:
    - non-existent: profile identifier not understood by server?
    - unsupported: generally well known profile applicable to variety of contents that happens to not be supported by given server?
        - this may imply there will be registry of profiles, like IANA offers for Media Types. But this is excluded later on:
        "There is no proposal yet to create a central register of profiles as this is thought by the authors to be un-sustainable
        in the long-term, given the likely numbers of profiles to be established."  
        
- section 2, definitions
    "profile", is ambiguous, "constraints on one or more identified base specifications",
    i.e. profiles constraint specifications or do they in fact reuse and "specialise clauses 
    from one or more base specifications" in order  to express constraints on content?

    "token", a short name identifying something (profile) --> better "alias"?

- section 5.1 Context
    "In some cases, a server may have to make a request of a client and receive a response."
    - which are these cases, is this relevant to mention while unclear?

    "These aspects are to be treated independently so content negotiation for a resource involving
    negotiation by profile and potentially multiple other aspects of a resource will not affect each other."

    - this is not the case, Media Type and Profile may and will inter-depend, only one set of Media types
    may be available for a particular profile, another set for a different profile. All these content
    constraints interact and are not independent of each other. 

- section 5.2. Requests and Responses
    - is there a reason why invoking "list profiles" can't deliver information of "list profiles tokens", making it obsolete?
    - response to "get resource by profile" should indicate the profile applied (the requested or the default one)

- section 6.1.1.2 Using a HTTP Link header field
    - Example 2, Using a Link-header to point list available profiles
    - the "Content-Location" does not seem to be used in accordance to HTTP spec, since referring to profile and not to a particular resource representation
        - https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.14
    - same holds for link relation, since performing a head on a resource (and not a profile) should not it read:
        - <link rel="profile" .. >?

- section 6.2.1 list profiles
    - I would not suggest reusing the same query parameter for identifying individual profiles (_profile=URI) *and* requesting a list of them (_profile=list)
    - a dedicated parameter may by used (_list), e.g. allowing for listing of profile (_list=profile) or media type (_list=media-type)

- section A.1 Requirements
    - is there a reason of stating CONNEG requirements separate from other (profile-related) requirements outside of the UCR document?

  Best regards
   Jaro

 [1] https://w3c.github.io/dxwg/conneg-by-ap/

 
On Sunday, November 11, 2018 16:34 CET, Karen Coyle <kcoyle@kcoyle.net> wrote: 
 
> All,
> 
> We have two documents that are ready to be issued as First Public
> Working Drafts,[1] [2]  and we want to promote them to this at the
> meeting on November 13.[3] The ACTION on everyone is to READ these
> documents and let us know IMMEDIATELY if you see a serious problem that
> would keep either of these from being published. Remember that a FPWD is
> a DRAFT and that anything can change in future drafts. The purpose of
> the draft is to solicit comments from the community on the direction of
> the work.
> 
> You can also comment on the content of the drafts where you see the need
> for modifications to future drafts, and we will create github issues and
> discuss these, but these comments will not delay the FPWD.
> 
> We will take a consensus vote on these at the meeting. If you are
> sending regrets, please also let us know how you would vote on these drafts:
> 
> +1 issue as FPWD
> 0 abstain (but don't object)
> -1 object (and give your reason in enough detail that it can be addressed)
> 
> kc
> [1] https://w3c.github.io/dxwg/conneg-by-ap/
> [2] https://w3c.github.io/dxwg/profilesont/
> [3] https://www.w3.org/2017/dxwg/wiki/Meetings:Telecon2018.11.13
> -- 
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> m: 1-510-435-8234 (Signal)
> skype: kcoylenet/+1-510-984-3600
> 
 
 
 
-- 
Jaroslav Pullmann
Fraunhofer Institute for Applied Information Technology FIT
User-Centered Ubiquitous Computing
Schloss Birlinghoven | D-53757 Sankt Augustin | Germany
Phone: +49-2241-143620 | Fax: +49-2241-142146

Received on Tuesday, 13 November 2018 20:35:10 UTC