Re: Proposal: normative changes for profiles

John, 

in section 4.5.7 I have concerns with SHOULD for chocolate servers.  
If the client doesn't satisfy the constraints, then I would expect the update to fail. If the client doesn't have "knowledge of the server-specific constraints" then it is even more likely to fail ... So, I don't know what SHOULD really means in this case. 

thanks 
Roger


On 24 Sep 2013, at 18:50, John Arwe wrote:

The 3 editors took a quick pass through the spec, looking at existing conditionals (may, should) to see where they might become MUSTs etc on a vanilla-class server. 
This is the set for which we all independently came to the same conclusion for both profiles.  The existing text and per-profile proposed value is listed below.  As with the "change to informative" proposal, since all 3 editors agreed taking independent passes (indicating that these may be non-controversial) I'm making it a single proposal.  In most cases where the chocolate constraint == today's (which is the vast majority), it's just a matter of keeping chocolate aligned with the existing base of WG decisions.

If you object (-1) to any of the listed sections being changed, please provide the specific list in your response and we'll simply treat those separately.   

If you do not object (+0 or +1), either save it for a WG decision on one of the next meetings or (if you're sending regrets for that meeting) email to get your vote in early. 


4.2.9 LDPR servers SHOULD enable simple creation and modification of LDPRs. 
vanilla: MUST 
chocolate: SHOULD 
This changes clause 1 of  4.2.9 only. 

4.3.3 LDPR servers SHOULD provide a text/turtle representation of the requested LDPR [TURTLE]. 
vanilla: MUST 
chocolate: MUST 

4.5.6 LDPR servers MAY choose to allow the creation of new resources using HTTP PUT. 
vanilla: MUST 
chocolate: MAY 

4.5.7 LDPR servers SHOULD allow clients to update resources without requiring detailed knowledge of server-specific constraints.   This is a consequence of the requirement to enable simple creation and modification of LPDRs. 
vanilla: MUST 
chocolate: SHOULD 

4.8.2 LDPR servers SHOULD allow clients to update resources without requiring detailed knowledge of server-specific constraints.   This is a consequence of the requirement to enable simple creation and modification of LPDRs. 
vanilla: MUST 
chocolate: SHOULD 

4.8.3 LDPR servers SHOULD NOT allow clients to create new resources using PATCH. POST (to an LDPC) and/or PUT should be used as the standard way to create new LDPRs. 
vanilla: MUST 
chocolate: MAY 
The replacement of Should Not was driven by the consideration: it would look strange to see us Must-ing it in one case (5789 explicitly mentions Create, so Must-ing it aligns with the PUT feedback from TimBL) and then Should Not-ing it in the other. 

4.10.2.1 LDPR servers SHOULD allow clients to retrieve large LDPRs in pages. 
No change ...here for context with the following sentence, below. 

4.10.2.1 In responses to GET requests with an LDPR as the Request-URI, LDPR servers that support paging SHOULD provide an HTTP Link header whose target URI is the first page resource, and whose link relation type is first [RFC5988]. 
vanilla: MUST 
chocolate: MUST 

5.8.1 LDPC servers are RECOMMENDED to support HTTP PATCH as the preferred method for updating LDPC non-membership properties. 
vanilla: MUST 
chocolate: SHOULD 


Best Regards, John

Voice US 845-435-9470  BluePages 
Tivoli OSLC Lead - Show me the Scenario