Re: Proposal: normative changes for profiles

John, 

I take your point: it's going be tricky to get a constraints language which can express everything that the server wishes to constrain in one-shot, such that the client can then expect MUSTful behaviour from the server.

However, I still don't like SHOULD. When forms are filled, submitted, returned, tweaked, re-submitted, etc ... constraints are offered which should be observed along the way in that negotiation process. If the server doesn't like the request in some way at each stage then the reaction the client can expect of the server is actually a SHOULD NOT (or MUST NOT ?), until such a time comes when the server is eventually happy and then client can expect MUST.

Roger
Fujitsu Laboratories of Europe



On 4 Oct 2013, at 15:15, John Arwe wrote:

> types. The key thing seems to be 'as long as any constraints are obeyed'. 

Actually (in terms of intent of the text from the Submission), the key thing was that those constraints (should, since it was focused on what we now call chocolate servers) be Minimal. 

> As a suggestion, and just taking 4.2.9 as example, why not say 
> something like "providing constraints set by the server are met, 
> LDPR servers MUST enable creation and modification of LDPR's". Isn't
> this phrasing applicable to both the vanilla and chocolate cases ? 

It could apply (I dearly want to just say 'yes', but I see complications that lead to a more nuanced response). 

If I read it very literally, it's tautological and therefore of little interest; I'd rather delete tautological statements than distract people with them, generally. 

To make it interesting (non-tautological), I need to make those constraints visible to clients for introspection; that in turn shifts the issue to can the constraint language(s) cover ALL that an implementation might constrain.  I have yet to see even one that truly does; we usually just wave our hands after a certain point and fall back to natural language, whose intent is not yet available for strictly programmatic consumption.  We routinely take certain cases off the top (server limit of 4K on a URL, or 1MB on an input representation) and say those don't violate MUSTs, which is a practical concession to annoyingly complex reality. 

I had trouble quickly coming up with a substantive MUST statement in either direction; MUST-accept needs a "except for constraints not expressible via machine-readable constraint languages" disclaimer.  MUST-reject (those that fall outside the constraints) prevents them from using Postel's Law, which I find very friendly as an end user.  Maybe you can do better. 

Best Regards, John

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