Proposal: normative changes for profiles

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