Re: Server behaviour on PUT

>  From my point of view, we have to define in the specification the 
> restrictions on servers (which is what we will be defining test cases 
> and conformance levels for) and not on clients.
> 
> For example, the text in 4.4.4:
> "LDPR clients SHOULD assume that an LDPR server could..."
> does not directly specify the behaviour of a server, it could perfectly 
> be rewritten to:
> "LDPR servers MAY..."

Specs are consumed by multiple audiences, for multiple purposes.  You can 
choose different styles, and you get different trade-offs.

For audiences reading with a "I'm writing a server, just tell me what I 
have to do" mind-set, they're very happy with your point of view Raul. For 
other audiences reading with a different mind-set ("I'm writing a 
client..."), less so.  To the degree on any given point you only call out 
one, and rely on readers from other mind-sets to carefully work out the 
implications for themselves, you give the "others" ample opportunity to 
write what (compared to the spec authors' intent) "poorly behaved 
clients".  To the degree you call out both/all, you're vulnerable to 
introducing gaps and conflicts.  Natural language is imprecise, inverting 
statements is hard without creating gaps, can't make everyone happy, life 
is rough.

Regardless of who is deemed to be "at fault" however, the users of the 
solutions trying to accomplish some useful purpose from all this arcana 
are DOA until things are resolved.  I personally have become willing via 
lots of experience with implementers to Be Explicit when I want them to 
code to do something that's other than the least-effort approach.  So I'm 
not willing to just dump requirements on clients overboard entirely; we 
can talk about how to address those in a way that weaves a path amongst 
all the spec issues that all can live with, if that's deemed necessary.

Best Regards, John

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